[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt
Nadim Kobeissi <[email protected]> Sun, 26 Jul 2026 12:03:45 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <[email protected]> |
--===============6133558995407466601== Content-Type: multipart/alternative; boundary="Apple-Mail=_BD91CC10-5790-486E-81E4-853F4F788FF3" --Apple-Mail=_BD91CC10-5790-486E-81E4-853F4F788FF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nick, This looks like an excellent potential improvement to TLS 1.3 and I=E2=80=99= m fully on board! I think your comments regarding the timeliness of such a change (it = being enabled by XOF constructions becoming widely available in = cryptographic libraries) makes a lot of sense, and that=E2=80=99s the = first thing that came to my mind when I stumbled upon your proposal. A few weeks ago, I updated some of our ProVerif TLS models in order to = help contribute more constructively to the hybrid-vs-pure-ML-KEM debate = [1]. This draft looks interesting, so I would like to volunteer to = maintain some ProVerif models that track its development and run formal = analysis that tracks security properties across implementations that use = your XOF draft and those that are using current TLS 1.3, running in = parallel. I've pushed an initial ProVerif model for the draft [2]. This model = layers the deck schedule over our existing RFC 8446bis models as a = separate library, so the published models stay byte-identical and = sessions of both schedules run side by side under one attacker, across = all three key-exchange modes (classical (EC)DHE, standalone ML-KEM, and = the hybrid). The modeling follows the draft's own abstractions closely: section = 7.1.2's one-shot equivalence, since every derived value becomes a single = deck-function application over its injectively framed path. The = governing cipher suite is bound at each leaf, hybrid component secrets = are absorbed as separate "dh" items in group order rather than = concatenated, the MAC is a distinct keyed function, and the transcript = hash comes from the same XOF as the schedule. As in previous reftls models, the schedule gets its own weak/strong knob = (WeakXOF, alongside the existing WeakDH/WeakKEM/WeakHash), so results = take the form "secure unless this component breaks". The query battery = I'm running covers: 1. Whether the robustness results from [1] survive the change of = combiner, 2. Cross-schedule and cross-profile key separation under concurrent = composition, 3. Anew control checking that a broken permutation alone sinks a deck = session even with a sound hybrid key exchange. As always, the usual caveats of symbolic model verification apply. = Everything here, as in all previous ProVerif reftls work, assumes = idealized primitives, no output-length arithmetic, etc. etc. =E2=80=94 = I'll post complete results and transcripts once the full runs are = stable. If there are properties you'd particularly like to see machine-checked = as the draft evolves, or places where you'd expect the model to diverge = from your intent, please let me know! [1] https://eprint.iacr.org/2026/1147 [2] = https://github.com/symbolicsoft/reftls/commit/de76f8046a88d1383d2c5d60d168= 06341b0f92e1=20 Nadim Kobeissi Symbolic Software =E2=80=A2 https://symbolic.software > On 7 Jul 2026, at 1:23=E2=80=AFAM, Nick Sullivan = <[email protected]> wrote: >=20 > Dear TLS, >=20 > 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. >=20 > 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. >=20 > A cipher suite names an AEAD plus a schedule profile, and nothing else > changes. There is no new extension, and the state machine, record > layer, and wire format are untouched. Two profiles are defined, one on > the standard SHA-3 function and one on a faster reduced-round variant. > Test vectors are pinned to cipher-suite values, so the final vectors > will follow the code point assignment. >=20 > https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/ >=20 > 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. >=20 > Best, > Nick >=20 > On Mon, Jul 6, 2026 at 7:03=E2=80=AFPM <[email protected]> = wrote: >>=20 >> A new version of Internet-Draft draft-sullivan-tls-xof-ciphers-00.txt = has been >> successfully submitted by Nick Sullivan and posted to the >> IETF repository. >>=20 >> Name: draft-sullivan-tls-xof-ciphers >> Revision: 00 >> Title: TLS 1.3 Cipher Suites with Alternative Key-Schedule = Profiles >> Date: 2026-07-06 >> Group: Individual Submission >> Pages: 46 >> URL: = https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/ >> HTML: = https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.html >> HTMLized: = https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-ciphers >>=20 >>=20 >> Abstract: >>=20 >> TLS 1.3 builds its key schedule on HKDF over the cipher suite's = hash. >> This document defines TLS 1.3 cipher suites that build it on a deck >> function over a single permutation instead, the one a deployment >> already carries when it uses SHA-3, ML-KEM, or ML-DSA. One >> permutation then runs the whole schedule, and a full handshake = takes >> about a third of the permutation calls an HKDF schedule over that >> permutation would. Such a cipher suite names an AEAD algorithm >> together with a schedule profile that defines every key-schedule >> function the connection uses. The profile follows from the >> negotiated cipher suite alone, so no new extension is defined and = the >> TLS 1.3 state machine and wire format are unchanged. Two profiles >> are defined, one on the standard SHA-3 function and one on a faster >> reduced-round variant of it. >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >=20 > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] --Apple-Mail=_BD91CC10-5790-486E-81E4-853F4F788FF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">Hi Nick,<div><br></div><div>This looks = like an excellent potential improvement to TLS 1.3 and I=E2=80=99m fully = on board!</div><div><br></div><div>I think your comments regarding the = timeliness of such a change (it being enabled by XOF constructions = becoming widely available in cryptographic libraries) makes a lot of = sense, and that=E2=80=99s the first thing that came to my mind when I = stumbled upon your proposal.</div><div><br></div><div>A few weeks ago, I = updated some of our ProVerif TLS models in order to help contribute more = constructively to the hybrid-vs-pure-ML-KEM debate [1]. This draft looks = interesting, so I would like to volunteer to maintain some ProVerif = models that track its development and run formal analysis that tracks = security properties across implementations that use your XOF draft and = those that are using current TLS 1.3, running in = parallel.</div><div><br></div><div>I've pushed an initial ProVerif model = for the draft [2]. This model layers the deck schedule over our existing = RFC 8446bis models as a separate library, so the published models stay = byte-identical and sessions of both schedules run side by side under one = attacker, across all three key-exchange modes (classical (EC)DHE, = standalone ML-KEM, and the hybrid).</div><div><br></div><div>The = modeling follows the draft's own abstractions closely: section 7.1.2's = one-shot equivalence, since every derived value becomes a single = deck-function application over its injectively framed path. The = governing cipher suite is bound at each leaf, hybrid component secrets = are absorbed as separate "dh" items in group order rather than = concatenated, the MAC is a distinct keyed function, and the transcript = hash comes from the same XOF as the = schedule.</div><div><div><br></div><div>As in previous reftls models, = the schedule gets its own weak/strong knob (WeakXOF, alongside the = existing WeakDH/WeakKEM/WeakHash), so results take the form "secure = unless this component breaks". The query battery I'm running = covers:</div><div><br></div><div>1. Whether the robustness results from = [1] survive the change of combiner,</div><div>2. Cross-schedule and = cross-profile key separation under concurrent composition,</div><div>3. = Anew control checking that a broken permutation alone sinks a deck = session even with a sound hybrid key = exchange.</div><div><br></div><div>As always, the usual caveats of = symbolic model verification apply. Everything here, as in all previous = ProVerif reftls work, assumes idealized primitives, no output-length = arithmetic, etc. etc. =E2=80=94 I'll post complete results and = transcripts once the full runs are stable.</div><div><br></div><div>If = there are properties you'd particularly like to see machine-checked as = the draft evolves, or places where you'd expect the model to diverge = from your intent, please let me = know!</div></div><div><br></div><div>[1] <a = href=3D"https://eprint.iacr.org/2026/1147">https://eprint.iacr.org/2026/11= 47</a></div><div>[2] <a = href=3D"https://github.com/symbolicsoft/reftls/commit/de76f8046a88d1383d2c= 5d60d16806341b0f92e1">https://github.com/symbolicsoft/reftls/commit/de76f8= 046a88d1383d2c5d60d16806341b0f92e1</a> <br = id=3D"lineBreakAtBeginningOfMessage"><div> <meta charset=3D"UTF-8"><br>Nadim Kobeissi<br>Symbolic Software = =E2=80=A2 https://symbolic.software<br> </div> <div><br><blockquote type=3D"cite"><div>On 7 Jul 2026, at 1:23=E2=80=AFAM,= Nick Sullivan <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div>Dear TLS,<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 newly<br>practical because deployments using SHA-3, = ML-KEM, or ML-DSA already<br>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 cipher suite names an AEAD plus a schedule profile, and = nothing else<br>changes. There is no new extension, and the state = machine, record<br>layer, and wire format are untouched. Two profiles = are defined, one on<br>the standard SHA-3 function and one on a faster = reduced-round variant.<br>Test vectors are pinned to cipher-suite = values, so the final vectors<br>will follow the code point = assignment.<br><br>https://datatracker.ietf.org/doc/draft-sullivan-tls-xof= -ciphers/<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>Best,<br>Nick<br><br>On = Mon, Jul 6, 2026 at 7:03=E2=80=AFPM <[email protected]> = wrote:<br><blockquote type=3D"cite"><br>A new version of Internet-Draft = draft-sullivan-tls-xof-ciphers-00.txt has been<br>successfully submitted = by Nick Sullivan and posted to the<br>IETF repository.<br><br>Name: = draft-sullivan-tls-xof-ciphers<br>Revision: = 00<br>Title: TLS 1.3 Cipher Suites with Alternative = Key-Schedule Profiles<br>Date: = 2026-07-06<br>Group: = Individual Submission<br>Pages: = 46<br>URL: = https://www.ietf.org/archive/id/draft-sulliv= an-tls-xof-ciphers-00.txt<br>Status: = https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-cipher= s/<br>HTML: = https://www.ietf.org/archive/id/draft-sullivan-tls= -xof-ciphers-00.html<br>HTMLized: = https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-ciphers<br><b= r><br>Abstract:<br><br> TLS 1.3 builds its key schedule on = HKDF over the cipher suite's hash.<br> This document defines = TLS 1.3 cipher suites that build it on a deck<br> function = over a single permutation instead, the one a deployment<br> = already carries when it uses SHA-3, ML-KEM, or ML-DSA. = One<br> permutation then runs the whole schedule, and = a full handshake takes<br> about a third of the permutation = calls an HKDF schedule over that<br> permutation would. = Such a cipher suite names an AEAD algorithm<br> = together with a schedule profile that defines every = key-schedule<br> function the connection uses. The = profile follows from the<br> negotiated cipher suite alone, = so no new extension is defined and the<br> TLS 1.3 state = machine and wire format are unchanged. Two profiles<br> = are defined, one on the standard SHA-3 function and one on a = faster<br> reduced-round variant of it.<br><br><br><br>The = IETF = Secretariat<br><br><br></blockquote><br>__________________________________= _____________<br>TLS mailing list -- [email protected]<br>To unsubscribe send = an email to = [email protected]<br></div></div></blockquote></div><br></div></body></ht= ml>= --Apple-Mail=_BD91CC10-5790-486E-81E4-853F4F788FF3-- --===============6133558995407466601== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============6133558995407466601==--