I'm not going to say that John is right or wrong, read or write, I simply haven't thought hard enough about having this schedule run more (is it going to produce the bitstream for a cipher too? how often do you need to fork and what does that do to state and computation costs?) but I do think that coupling the negotiation of the KDF to the AEAD is probably not what you want. I'd suggest a new extension to negotiate the KDF. (Reserve a value of 0 to mean HKDF as per the core protocol.)
The real challenge then is that stacks will have to run multiple hashes in parallel until the matter is decided, which was annoying before, but even more annoying when more functions are added. So maybe... pick one? On Tue, Jul 7, 2026, at 16:08, John Mattsson wrote: > Hi Nick > > This seems like a great start! > > I would like to see much broader use of deck functions that provide > fine-grained cryptographic services, rather than having the IETF > assemble protocols from various distinct symmetric primitives. > Constructions such as HMAC and HKDF were developed around hash > functions with inherent security and functional limitations, and they > are not a good foundation for modern protocol design. > > Instead of performing a full permutation for the relatively infrequent > key updates, it may be preferable to also use a lightweight "roll" > function to support inexpensive per-message ratcheting, similar to the > approach used by the Signal protocol. > > The current draft still hands off record protection to a separate AEAD, > with the deck function merely deriving the traffic keys. In my view, > this leaves one of the most compelling opportunities unexplored. The > key schedule and record encryption could be integrated into a single > running duplex object. > > Cheers, > John Preuß Mattsson > > *From: *Nick Sullivan <[email protected]> > *Date: *Tuesday, 7 July 2026 at 01:33 > *To: *[email protected] <[email protected]> > *Subject: *[TLS] Re: New Version Notification for > draft-sullivan-tls-xof-ciphers-00.txt > > Dear TLS, > > 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. > > 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. > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-sullivan-tls-xof-ciphers%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C914556f9a3c24e7dcfa008dedbb70c08%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189776381975014%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GxZ%2B0t2dt0rzRtzLXH1ld5tO3SoX9a9urbdxCT3meic%3D&reserved=0 > > <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. > > Best, > Nick > > On Mon, Jul 6, 2026 at 7:03 PM <[email protected]> wrote: >> >> 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. >> >> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-sullivan-tls-xof-ciphers-00.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C914556f9a3c24e7dcfa008dedbb70c08%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189776382001211%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5AhG0%2By8MfxmkVDfDkMjZagD4Ga8jRJ6IRtXJRVFHRg%3D&reserved=0 >> <https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.txt> >> Status: >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-sullivan-tls-xof-ciphers%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C914556f9a3c24e7dcfa008dedbb70c08%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189776382019313%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gCL6u%2FvbSu9GEKQAcDe1k4cz7r1S7afVTs%2FtF%2BHYKiM%3D&reserved=0 >> <https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/> >> HTML: >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-sullivan-tls-xof-ciphers-00.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C914556f9a3c24e7dcfa008dedbb70c08%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189776382040668%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LVUGmbDZ5IKxCRjjHKVls6Y3n52P2NpufEhCnXZhOqY%3D&reserved=0 >> <https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.html> >> HTMLized: >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-sullivan-tls-xof-ciphers&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C914556f9a3c24e7dcfa008dedbb70c08%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189776382057873%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RkQd4KObWnFazkizW4uQZLYZpwmWCkemqb32dvGHDpk%3D&reserved=0 >> <https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-ciphers> >> >> >> Abstract: >> >> 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. >> >> >> >> The IETF Secretariat >> >> > > _______________________________________________ > 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
