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

Dear all,

We are enthusiastic about Nick Sullivan's announcement of his RFC draft 
for a TLS 1.3 key schedule based on Keccak and happy with the many 
reactions on the mailing list, so we thought it would be good to give 
you our 2 cents.

# Including a Keccak-based AEAD option

In Table 1, the draft proposes AES-GCM and ChaCha20-Poly1305 as AEAD 
schemes, but no Keccak-based scheme. As suggested by other participants, 
it would be nice to also offer the option of a Keccak-based AEAD scheme. 
This would allow one to potentially reduce the code size (or area) and 
trust surface even further.

We did the exercise recently in our paper "Shaking up authenticated 
encryption" presented at EuroS&P (https://eprint.iacr.org/2024/1618). It 
defines two fully committing AEAD schemes, both with security provably 
reducible to (Turbo)SHAKE128/256.


# Instantiating the key derivation

The EuroS&P paper also defines a duplex object and a deck function, both 
also reducing to the security of (Turbo)SHAKE128/256. Thanks to this 
reduction, the former could be used as primitives in the key derivation, 
solving much of the domain separation. The use of "trailer" bytes that 
accumulate all domain separation bits the final functions are very 
simple to implement. Moreover, by overwriting input blocks (instead of 
XORing them in), they have a nice property that each call to the 
underlying permutation can be a ratchet: the only requirement is that at 
least 128/256 bits of the output shall not be returned.


# Kravatte vs (Turbo)SHAKE

Kravatte is a very fast primitive that could be used for AEAD. However, 
it needs a secret key upon initialization and is therefore not suited 
for key derivation.

Kravatte is a deck function obtained by applying the Farfalle 
construction with Keccak-p[6 rounds] and two rolling functions. It is 
*not* built on top of Keccak and therefore it security cannot be reduced 
to that of (Turbo)SHAKE. Actually, its security cannot be reduced to a 
simpler primitive, so the security of Kravatte must be established by 
the cryptanalysis of Kravatte itself.


# On the number of rounds

MarsupilamiFourteen (M14) was given as an example of a function calling 
Keccak-p with a number of rounds that is not a multiple of 6.

M14 dates back from 2018 as a 256-bit version of (now called) KT128. The 
reasoning for adding two rounds was to allow for extra safety margin 
while giving more budget to the adversary. Since then, we have seen the 
number of rounds that can be attacked under cryptanalysis slow down, and 
now we think that 12 rounds provides a comfortable safety margin for 
Keccak, even when targeting 256-bit security with a capacity of 512 
bits. So, RFC 9861 proposes TurboSHAKE256 and KT256 on top of 
Keccak-p[12 rounds] and not 14 rounds.

Note by Joan: I answered Markku indeed that I could not think of any 
proposal where the round count would not be a multiple of 6, thereby 
dismissing MarsipulamiFourteen but also our CAESAR AEAD candidate Ketje 
that does single-round calls in the encryption phase. My mindset was 
that both were proposals for which we think we have more interesting 
alternatives.


Kind regards,

The Keccak team
Guido Bertoni, Joan Daemen, Seth Hoffert, Silvia Mella, Michaël Peeters, 
Gilles Van Assche and Ronny Van Keer

Op 08-07-2026 om 18:01 schreef Nick Sullivan:
> 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
>>     <[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 [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 [email protected]

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]