[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt
Nick Sullivan <[email protected]> Tue, 21 Jul 2026 12:31:55 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAOjisRx=q3XftOkYU79075vpeTHcF0GtxLRw_Wp2SW6iZB+dwA@mail.gmail.com> |
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 PM Ilari Liusvaara <[email protected]> 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 = 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] > _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]