Hi, Thanks for this. I quickly put together an implementation of draft-sullivan-tls-xof-ciphers-00.txt around Rustls to do some measurements:
https://github.com/mjosaarinen/altkdf-rs ( Editorial comments in https://github.com/mjosaarinen/altkdf-rs/blob/main/FINDINGS.md ) The theoretical side of the design seems very defensible -- clean proof target. In terms of concrete security, the Keccak variants have a much larger security margin than the SHA-2 family. Given how much work we put into reducing the number of permutation calls with ML-KEM and Hybrid combiners -- carefully debating and analyzing each permutation -- this one yields a staggering reduction, making the key schedule much faster (and the handshake probably too.) For the representative full handshake: PSK + (EC)DHE + 0-RTT leaves + NewSessionTicket + one KeyUpdate each direction + one exporter, the per-endpoint counts over 24-round Keccak-f[1600] are: 41 * f1600: Deck implementation, measured stateful 46 * f1600: Deck implementation, measured recompute 52 * f1600: Section A.1 in draft-sullivan-tls-xof-ciphers-00 156 * f1600: HKDF-SHA3-256 / RFC 8446 baseline 117 * f1600: Appendix D "FIPS" KMAC256 schedule So 41 vs 156 permutations by my count. ( Note: The draft slightly overcounts permutations in its estimates. ) It's a quick prototype built with extensive AI assistance, but it includes basic correctness measures: primitive KATs (RFC 9861 TurboSHAKE256, FIPS 202 SHAKE256, SP 800-185 KMAC256, including multi-block and long-output), 73 self-generated Appendix C/D vectors, and byte-for-byte reproduction of all of them by an independent Python implementation written from the draft alone. - Keccak-p[1600,nr] permutation and the rate-136/capacity-512 sponge - Five framed deck operations (Init/Absorb/Fork/Squeeze/Ratchet) - KMAC-layout MAC - Three-stage E/H/T schedule with its two ratchets - Section 5 derivations (record keys, Finished/PSK binders, exporters, resumption and key-update, and the §10 external-PSK importer with ImportedIdentityV2). - All five cipher suites (0xFF01–0xFF05, both profiles, three AEADs) Plus for comparisons: - Appendix D FIPS-component schedule (RFC 8446 with KMAC256 as the PRF) - a permutation-count benchmark reproducing §A.1, live-secret zeroization (§15.7.2.2) Cheers, -markku Dr. Markku-Juhani O. Saarinen <[email protected]> On Tue, Jul 7, 2026 at 2:34 AM Nick Sullivan <[email protected]> wrote: > 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://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://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 > > > > > > 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]
