Hi Hannes, As Thom noted below in the chain, the motivation is to modernize the key schedule, which has two main advantages:
1. Efficiency gains: As the analysis on-list spells out, it’s a dramatic improvement to the number of hashes/permutations needed. But as you noted, is not the hot path at all. 2. Removing a hard dependency on SHA-2 from future designs, as Thom noted. This gain isn’t immediate, but it clears the way for future configurations that don’t rely on SHA-2 for the CertificateVerify to drop SHA-2 completely from the code base. Nick On Wed, Jul 8, 2026 at 3:58 PM Thom Wiggers <[email protected]> wrote: > Hi Hannes, > > I don’t think runtime performance is an issue, but rather code size (or > area), by getting rid of SHA2. (Of course, this is long into the future). > The sponge-based constructions also have theoretical benefits. > > Cheers, > > Thom > > > Op 8 jul 2026, om 13:47 heeft Hannes Tschofenig <hannes.tschofenig= > [email protected]> het volgende geschreven: > > Hi Markku, Hi Nick! > > I will certainly look closer into the details but it appears that you are > optimizing TLS in the wrong place. The key derivation is the least > expensive part in TLS and spending time optimizing it will bring little > benefit. I am saying this because I have for years been looking at > optimizing different parts of the TLS protocol with constrained IoT in mind. > > This brings me to the core question: What is the problem you are trying to > solve in the first place? I do not recall that anyone has voiced > performance problems with the key derivation in TLS before this draft was > published. > > Ciao > Hannes > > > Am 08.07.2026 um 12:16 schrieb Markku-Juhani O. Saarinen: > > 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] > > _______________________________________________ > 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]
