[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-schedule-00.txt
Nick Sullivan <[email protected]> Fri, 24 Jul 2026 15:30:55 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAOjisRwFq+7tsfs4XWXm7xMiDJYi5QQJb_Wu2TYNOhhTMbk66A@mail.gmail.com> |
--===============3346894953598239601== Content-Type: multipart/alternative; boundary="0000000000008524f606575b624a" --0000000000008524f606575b624a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable TLSWG, TLS 1.3 runs its entire key schedule on HKDF over SHA-2. This draft defines an extension that replaces that schedule with one built on an extendable-output function, so no SHA-2 remains in the key schedule: the negotiated KDF governs every derivation, the Finished and binder MACs, and the transcript hash. This is draft-sullivan-tls-xof-ciphers-00, reworked and renamed. The old name came from a design that negotiated the schedule through cipher suites. The KDF now has its own extension, so the old name was wrong. https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-schedule/ What it does not change: the cipher suites, the AEAD algorithms, the state machine, and the record layer. A connection whose ClientHello does not carry the extension uses HKDF exactly as today; absence is the default, and the default is TLS 1.3. The KDF is negotiated in its own extension carrying a TLS KDF Identifier, so it is not bound to a cipher suite, and there is no new TLS version. The draft updates RFC 9258. Two KDFs are defined: SHAKE256, and the reduced-round TurboSHAKE256. Both run the schedule on a single Keccak permutation, the one a deployment already carries if it uses SHA-3, ML-KEM, or ML-DSA. The schedule is four operations on a running sponge (Init, Absorb, Derive, Ratchet), and it keeps RFC 9846's shape and its output names. One full handshake costs 39 permutation calls, against 117 for TLS 1.3 with KMAC primitives and 156 for HKDF-SHA3-256 over the same permutation. The draft states what is not yet established, in its own section: the random-oracle substitution is argued rather than proven, the chaining analysis over a carried accumulator is owed, the 12-round permutation is not proven, and the EUF-CMA security of the reduced-round MAC is open. The appendix now has tentative test vectors for both profiles. The target is a SHA-2-free key schedule for PSK-only and post-quantum deployments. Nick On Fri, Jul 24, 2026 at 3:29=E2=80=AFPM <[email protected]> wrote: > A new version of Internet-Draft draft-sullivan-tls-xof-schedule-00.txt ha= s > been successfully submitted by Nick Sullivan and posted to the > IETF repository. > > Name: draft-sullivan-tls-xof-schedule > Revision: 00 > Title: XOF-based key schedules for TLS 1.3 > Date: 2026-07-24 > Group: Individual Submission > Pages: 58 > URL: > https://www.ietf.org/archive/id/draft-sullivan-tls-xof-schedule-00.txt > Status: > https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-schedule/ > HTML: > https://www.ietf.org/archive/id/draft-sullivan-tls-xof-schedule-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-schedule > > > Abstract: > > TLS 1.3 runs its entire key schedule on HKDF over SHA-2. This > document defines an extension that replaces that schedule with one > built on an extendable-output function (XOF): the negotiated KDF > governs every derivation, the Finished and binder MACs, and the > transcript hash, so no SHA-2 remains in the key schedule. The cipher > suites, AEAD algorithms, state machine, and record layer are > unchanged, and a connection without the extension uses HKDF as today. > Two KDFs are defined, SHAKE256 and the reduced-round TurboSHAKE256. > This document updates RFC 9258. > > > > The IETF Secretariat > > > --0000000000008524f606575b624a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>TLSWG,</div><div><br></div>TLS 1.3 runs its entire ke= y schedule on HKDF over SHA-2. This draft defines an extension that replace= s that schedule with one built on an extendable-output function, so no SHA-= 2 remains in the key schedule: the negotiated KDF governs every derivation,= the Finished and binder MACs, and the transcript hash.<br><br>This is draf= t-sullivan-tls-xof-ciphers-00, reworked and renamed. The old name came from= a design that negotiated the schedule through cipher suites. The KDF now h= as its own extension, so the old name was wrong.<br><br><a href=3D"https://= datatracker.ietf.org/doc/draft-sullivan-tls-xof-schedule/">https://datatrac= ker.ietf.org/doc/draft-sullivan-tls-xof-schedule/</a><br><br>What it does n= ot change: the cipher suites, the AEAD algorithms, the state machine, and t= he record layer. A connection whose ClientHello does not carry the extensio= n uses HKDF exactly as today; absence is the default, and the default is TL= S 1.3. The KDF is negotiated in its own extension carrying a TLS KDF Identi= fier, so it is not bound to a cipher suite, and there is no new TLS version= . The draft updates RFC 9258.<br><br>Two KDFs are defined: SHAKE256, and th= e reduced-round TurboSHAKE256. Both run the schedule on a single Keccak per= mutation, the one a deployment already carries if it uses SHA-3, ML-KEM, or= ML-DSA. The schedule is four operations on a running sponge (Init, Absorb,= Derive, Ratchet), and it keeps RFC 9846's shape and its output names. = One full handshake costs 39 permutation calls, against 117 for TLS 1.3 with= KMAC primitives and 156 for HKDF-SHA3-256 over the same permutation.<br><b= r>The draft states what is not yet established, in its own section: the ran= dom-oracle substitution is argued rather than proven, the chaining analysis= over a carried accumulator is owed, the 12-round permutation is not proven= , and the EUF-CMA security of the reduced-round MAC is open. The appendix n= ow has tentative test vectors for both profiles.<br><br>The target is a SHA= -2-free key schedule for PSK-only and post-quantum deployments.<br><br>Nick= </div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr"= class=3D"gmail_attr">On Fri, Jul 24, 2026 at 3:29=E2=80=AFPM <<a href= =3D"mailto:[email protected]">[email protected]</a>> wrote= :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A new version = of Internet-Draft draft-sullivan-tls-xof-schedule-00.txt has<br> been successfully submitted by Nick Sullivan and posted to the<br> IETF repository.<br> <br> Name:=C2=A0 =C2=A0 =C2=A0draft-sullivan-tls-xof-schedule<br> Revision: 00<br> Title:=C2=A0 =C2=A0 XOF-based key schedules for TLS 1.3<br> Date:=C2=A0 =C2=A0 =C2=A02026-07-24<br> Group:=C2=A0 =C2=A0 Individual Submission<br> Pages:=C2=A0 =C2=A0 58<br> URL:=C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/archive/id/draft-s= ullivan-tls-xof-schedule-00.txt" rel=3D"noreferrer" target=3D"_blank">https= ://www.ietf.org/archive/id/draft-sullivan-tls-xof-schedule-00.txt</a><br> Status:=C2=A0 =C2=A0<a href=3D"https://datatracker.ietf.org/doc/draft-sulli= van-tls-xof-schedule/" rel=3D"noreferrer" target=3D"_blank">https://datatra= cker.ietf.org/doc/draft-sullivan-tls-xof-schedule/</a><br> HTML:=C2=A0 =C2=A0 =C2=A0<a href=3D"https://www.ietf.org/archive/id/draft-s= ullivan-tls-xof-schedule-00.html" rel=3D"noreferrer" target=3D"_blank">http= s://www.ietf.org/archive/id/draft-sullivan-tls-xof-schedule-00.html</a><br> HTMLized: <a href=3D"https://datatracker.ietf.org/doc/html/draft-sullivan-t= ls-xof-schedule" rel=3D"noreferrer" target=3D"_blank">https://datatracker.i= etf.org/doc/html/draft-sullivan-tls-xof-schedule</a><br> <br> <br> Abstract:<br> <br> =C2=A0 =C2=A0TLS 1.3 runs its entire key schedule on HKDF over SHA-2.=C2=A0= This<br> =C2=A0 =C2=A0document defines an extension that replaces that schedule with= one<br> =C2=A0 =C2=A0built on an extendable-output function (XOF): the negotiated K= DF<br> =C2=A0 =C2=A0governs every derivation, the Finished and binder MACs, and th= e<br> =C2=A0 =C2=A0transcript hash, so no SHA-2 remains in the key schedule.=C2= =A0 The cipher<br> =C2=A0 =C2=A0suites, AEAD algorithms, state machine, and record layer are<b= r> =C2=A0 =C2=A0unchanged, and a connection without the extension uses HKDF as= today.<br> =C2=A0 =C2=A0Two KDFs are defined, SHAKE256 and the reduced-round TurboSHAK= E256.<br> =C2=A0 =C2=A0This document updates RFC 9258.<br> <br> <br> <br> The IETF Secretariat<br> <br> <br> </blockquote></div> --0000000000008524f606575b624a-- --===============3346894953598239601== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============3346894953598239601==--