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

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]