[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt
Nick Sullivan <[email protected]> Fri, 24 Jul 2026 15:31:02 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAOjisRwDY+yBDSfG+92+1L_=SyO3Fd3Ji-GHjwBY5Fzwf7mXoA@mail.gmail.com> |
--===============5684919624981946020== Content-Type: multipart/alternative; boundary="000000000000e9fcd406575b629a" --000000000000e9fcd406575b629a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks to Markku, Thom, Joan, Ilari and others for the reviews. The rewrite into four operations (Init, Absorb, Derive, Ratchet) resolved a class of comments by construction. Ilari, several of your examples are from the -00 text, the Fork/Squeeze form with the cipher suite injected per leaf. Resolved by the rewrite: - One Derive per leaf; three labels collapse to one. - The cipher-suite binding is retired; the schedule binds no suite. - A leaf that binds a transcript binds it at the leaf; trunks and the ratchet chain bind none. binder_key is the exception, a leaf with no context, and the binder's transcript enters at the MAC. - Flat Derive(...); the nested prefix syntax is gone. Per reviewer: - Markku: your 41/46 was measured against -00's encoding. The count no longer differs between the profiles: one number, 39, against 117 for TLS 1.3 with KMAC primitives and 156 for HKDF-SHA3-256 over the same permutation. Your framing was useful: the advantage is structural, not merely the use of Keccak. - Thom: TurboKMAC256 EUF-CMA is now marked as open work, with TLS13_SHAKE256 (whose MAC is NIST KMAC256) as the escape. That escape is not unconditional: an external PSK imported under both KDFs has one epsk beneath its two ipsks, so it is absorbed under both permutations. The MA= C layout stays generic and the KMAC-equality claim moved into the profiles= . - Ilari: your terminology point stands, and that is the document's fault. "Ratchet" names an operation. The key update has the one-way property without being that operation, and the glossary only denies the operation. I kept the name. Better wording welcome. Your fork observatio= n, and your point that the two-layer exporter cannot collapse without chang= ing semantics, are both taken. Held: labels stay identical to TLS 1.3; finished_key keeps RFC 9846's two layers until a proof justifies collapsing them. Declined, with the reason: - Clone instead of Ratchet, because a carried accumulator is invertible and a later compromise re-derives earlier secrets where a one-way squeez= e does not. and a Keccak AEAD in this document, which is a follow-on, with CFRG first as one route rather than the only one. Open, and what I plan on bringing to the meeting today: - Over-tagging. Does injective length-framing already separate "th" and "out", so both could go? - Round count. 12 or 24, with no default and no mandatory-to-implement KDF. Adopt Joan's "comfortable margin" framing, or keep both open? - Overwrite-duplex, from Joan. Not in this revision and not settled. Best, Nick On Tue, Jul 21, 2026 at 12:31=E2=80=AFPM Nick Sullivan <nicholas.sullivan@g= mail.com> wrote: > Hi Ilari, > > I'm in the middle of a major revamp of the draft based on the feedback on > the list (including yours, thanks!) and just further refinement. I expect > most of these points will be addressed in a new draft by the end of the > week. It's already much slimmer. I also have some nice diagrams I'll be > presenting at the TLS meeting that should make the design much more > comprehensible. It's more aligned with the existing TLS 1.3 key schedule > while still keeping the performance benefits of the deck structure. It's > still a very conservative design. > > I haven't looked deeply enough into the duplex construction you sketched > out, so I expect further optimization or state management designs may be > possible. > > Best, > Nick > > On Mon, Jul 20, 2026 at 6:07=E2=80=AFPM Ilari Liusvaara <ilariliusvaara@w= elho.com> > wrote: > >> On Mon, Jul 06, 2026 at 07:23:41PM -0400, Nick Sullivan wrote: >> > >> > I'm sharing a draft for the group's consideration. >> > draft-sullivan-tls-xof-ciphers-00 runs the entire TLS 1.3 key schedule >> > on a single Keccak permutation, instead of HKDF built on HMAC built on >> > the cipher suite's hash, which today is always SHA-2. This is newly >> > practical because deployments using SHA-3, ML-KEM, or ML-DSA already >> > carry a Keccak permutation, so the primitive is already in the stack. >> > >> > Each derived value comes out in one pass, so a full handshake costs >> > about a third of the permutation calls an HKDF schedule over the same >> > permutation would spend. >> > >> > https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/ >> > >> > This is a big change to the key schedule, and the draft is very >> > preliminary. Feedback on the approach, or interest in implementing it, >> > would help a lot. >> >> I took a new look. There seems to be a lot of extraneous stuff. >> >> - Extraneous labels. >> >> An example of 3 labels when only one would do: >> >> c_e_traffic =3D Squeeze(Absorb(Fork(E, "c e traffic", suite), >> "th", TH_CH), "out", SecretLen) >> >> There is at least one another triplicate label, and number of >> duplicate ones. >> >> - Ciphersuite seems to get re-injected a lot, should only be >> injected once. >> >> - Both c_e_traffic and e_exp_master have TH_CH, whereas rest of the >> handshake pre-injects transcript hashes to state instead. >> >> - Exporters and resumption PSK fork the state without using the >> original. >> >> - Ratchet() is not useful: The only place that needs it (key update) >> does not use it. >> >> There is no long-term hash state, and early/rest can be handled by >> cloning the state, so nothing needs ratchet. >> >> - Binders/Finished probably do not need two layers of hashing. Might >> have been needed with SHA-2, but Keccak is far stronger. >> >> - There also looks to be a lot more text than what is needed. >> >> >> Other stuff: >> >> - The two-layer exporter construct from TLS 1.3 can not be replaced by >> single-layer one without changing semantics. >> >> - The labels from TLS 1.3 lack the implicit prefix. >> >> - The split shared secret is going to be very nasty surprise for >> implementations. Many implementations have no idea if group is >> hybrid or not. >> >> - Also, using postfix syntax would probably look cleaner than prefix >> syntax. >> >> >> >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > --000000000000e9fcd406575b629a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks to Markku, Thom, Joan, Ilari and others for the rev= iews. The rewrite into four operations (Init, Absorb, Derive, Ratchet) reso= lved a class of comments by construction. Ilari, several of your examples a= re from the -00 text, the Fork/Squeeze form with the cipher suite injected = per leaf.<br><br>Resolved by the rewrite:<br><ul><li>One Derive per leaf; t= hree labels collapse to one.</li><li>The cipher-suite binding is retired; t= he schedule binds no suite.</li><li>A leaf that binds a transcript binds it= at the leaf; trunks and the ratchet chain bind none. binder_key is the exc= eption, a leaf with no context, and the binder's transcript enters at t= he MAC.</li><li>Flat Derive(...); the nested prefix syntax is gone.</li></u= l>Per reviewer:<br><ul><li>Markku: your 41/46 was measured against -00'= s encoding. The count no longer differs between the profiles: one number, 3= 9, against 117 for TLS 1.3 with KMAC primitives and 156 for HKDF-SHA3-256 o= ver the same permutation. Your framing was useful: the advantage is structu= ral, not merely the use of Keccak.</li><li><span style=3D"background-color:= transparent">Thom:=C2=A0</span>TurboKMAC256 EUF-CMA is now marked as open w= ork, with TLS13_SHAKE256 (whose MAC is NIST KMAC256) as the escape. That es= cape is not unconditional: an external PSK imported under both KDFs has one= epsk beneath its two ipsks, so it is absorbed under both permutations. The= MAC layout stays generic and the KMAC-equality claim moved into the profil= es.</li><li><span style=3D"background-color:transparent">Ilari: your termin= ology point stands, and that is the document's fault. "Ratchet&quo= t; names an operation. The key update has the one-way property without bein= g that operation, and the glossary only denies the operation. I kept the na= me. Better wording welcome. Your fork observation, and your point that the = two-layer exporter cannot collapse without changing semantics, are both tak= en.</span></li></ul>Held: labels stay identical to TLS 1.3; finished_key ke= eps RFC 9846's two layers until a proof justifies collapsing them.<br><= br>Declined, with the reason:<div><ul><li>Clone instead of Ratchet, because= a carried accumulator is invertible and a later compromise re-derives earl= ier secrets where a one-way squeeze does not. and a Keccak AEAD in this doc= ument, which is a follow-on, with CFRG first as one route rather than the o= nly one.</li></ul>Open, and what I plan on bringing to the meeting today:<u= l><li>Over-tagging. Does injective length-framing already separate "th= " and "out", so both could go?</li><li>Round count. 12 or 24= , with no default and no mandatory-to-implement KDF. Adopt Joan's "= ;comfortable margin" framing, or keep both open?</li><li>Overwrite-dup= lex, from Joan. Not in this revision and not settled.</li></ul><div>Best,<b= r>Nick</div></div></div><br><div class=3D"gmail_quote gmail_quote_container= "><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jul 21, 2026 at 12:31=E2=80= =AFPM Nick Sullivan <<a href=3D"mailto:[email protected]">nich= [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"><div dir=3D"ltr">Hi Ilari,<div><br></div><div>I'= m in the middle of a major revamp of the draft based on the feedback on the= list (including yours, thanks!) and just further refinement. I expect most= of these points=C2=A0will be addressed in a new draft by the=C2=A0end of t= he week. It's already much slimmer. I also have some nice diagrams I= 9;ll be presenting at the TLS meeting that should make the design much more= comprehensible.=C2=A0It's more aligned with the existing TLS 1.3 key s= chedule while still keeping the performance benefits of the deck structure.= It's still a very conservative design.</div><div><br></div><div>I have= n't looked deeply enough into the duplex construction you sketched out,= so I expect further=C2=A0optimization or state management designs may be p= ossible.</div><div><br></div><div>Best,</div><div>Nick</div></div><br><div = class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 20,= 2026 at 6:07=E2=80=AFPM Ilari Liusvaara <<a href=3D"mailto:ilariliusvaa= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Jul 06, 202= 6 at 07:23:41PM -0400, Nick Sullivan wrote:<br> > <br> > I'm sharing a draft for the group's consideration.<br> > draft-sullivan-tls-xof-ciphers-00 runs the entire TLS 1.3 key schedule= <br> > on a single Keccak permutation, instead of HKDF built on HMAC built on= <br> > the cipher suite's hash, which today is always SHA-2. This is newl= y<br> > practical because deployments using SHA-3, ML-KEM, or ML-DSA already<b= r> > carry a Keccak permutation, so the primitive is already in the stack.<= br> > <br> > Each derived value comes out in one pass, so a full handshake costs<br= > > about a third of the permutation calls an HKDF schedule over the same<= br> > permutation would spend.<br> ><br> > <a href=3D"https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-cip= hers/" rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/do= c/draft-sullivan-tls-xof-ciphers/</a><br> > <br> > This is a big change to the key schedule, and the draft is very<br> > preliminary. Feedback on the approach, or interest in implementing it,= <br> > would help a lot.<br> <br> I took a new look. There seems to be a lot of extraneous stuff.<br> <br> - Extraneous labels.<br> <br> =C2=A0 An example of 3 labels when only one would do:<br> <br> =C2=A0 c_e_traffic=C2=A0 =3D Squeeze(Absorb(Fork(E, "c e traffic"= , suite),<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "th", TH_CH), "out", Se= cretLen)<br> <br> =C2=A0 There is at least one another triplicate label, and number of<br> =C2=A0 duplicate ones.<br> <br> - Ciphersuite seems to get re-injected a lot, should only be<br> =C2=A0 injected once.<br> <br> - Both c_e_traffic and e_exp_master have TH_CH, whereas rest of the<br> =C2=A0 handshake pre-injects transcript hashes to state instead.<br> <br> - Exporters and resumption PSK fork the state without using the<br> =C2=A0 original.<br> <br> - Ratchet() is not useful: The only place that needs it (key update)<br> =C2=A0 does not use it.<br> <br> =C2=A0 There is no long-term hash state, and early/rest can be handled by<b= r> =C2=A0 cloning the state, so nothing needs ratchet.<br> <br> - Binders/Finished probably do not need two layers of hashing. Might<br> =C2=A0 have been needed with SHA-2, but Keccak is far stronger.<br> <br> - There also looks to be a lot more text than what is needed.<br> <br> <br> Other stuff:<br> <br> - The two-layer exporter construct from TLS 1.3 can not be replaced by<br> =C2=A0 single-layer one without changing semantics.<br> <br> - The labels from TLS 1.3 lack the implicit prefix.<br> <br> - The split shared secret is going to be very nasty surprise for<br> =C2=A0 implementations. Many implementations have no idea if group is<br> =C2=A0 hybrid or not.<br> <br> - Also, using postfix syntax would probably look cleaner than prefix<br> =C2=A0 syntax.<br> <br> <br> <br> <br> -Ilari<br> <br> _______________________________________________<br> TLS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">tls@i= etf.org</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a><br> </blockquote></div> </blockquote></div> --000000000000e9fcd406575b629a-- --===============5684919624981946020== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============5684919624981946020==--