[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt

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 <[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] <mailto:[email protected]>>
>> 
>> 
>> On Tue, Jul 7, 2026 at 2:34 AM Nick Sullivan <[email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]>
>>> To unsubscribe send an email to [email protected] <mailto:[email protected]>
>> 
>> 
>> _______________________________________________
>> TLS mailing list -- [email protected] <mailto:[email protected]>
>> To unsubscribe send an email to [email protected] <mailto:[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]