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

[Nick Sullivan <[e-mail]>]

Hi John,

I’ve been thinking recently about how best to generalize HKDF-to-XOF key
schedule updates across any protocol and I don’t think we’re there yet. As
discussed here, there are a variety of ways to instantiate these
intermediate representation-style key schedule functions (Derive, Hash,
Ratchet, etc.) as functions of a XOF (duplex, OD, with/without KMAC, etc.).
Choosing the right one depends on the shape of the key schedule and other
factors. For now, I’d suggest we start by trying to apply this translation
exercise for two or more protocols before generalizing or splitting out new
documents.

MLS is a great example of a second protocol that could use this exercise.
As specified, MLS depends on the same HKDF-based primitives as TLS but it
piggybacks on HPKE for the definition of the key schedule’s Derive and
Hash/Expand/Extract. When HPKE-PQ introduced (Turbo)SHAKE as a one-stage
KDF, it didn’t define the equivalent Expand/Extract functions because they
were not needed in HPKE. This left MLS, dependent on HPKE for its KDF
definitions, functionally unable to use the new single-stage KDFs in its
key schedule. This is probably a good thing because a direct mapping would
be inefficient. A version of this TLS-XOF draft written for MLS would be a
good test of the generalizability of the approach beyond TLS and a step
worth taking before considering splitting this document up.

Nick

On Tue, Jul 28, 2026 at 2:28 PM John Mattsson <john.mattsson=
[e-mail]> wrote:

> Hi,
>
> Would it make sense to specify the deck function in a separate draft and
> then reference that from the TLS draft?
>
> For example:
>
> draft-sullivan-tls-deck-schedule + draft-sullivan-deck, or
> draft-sullivan-tls-deck-schedule + draft-keccakteam-flightdeck.
>
> I think this would make the architecture cleaner, simplify discussions
> within the TLS WG, allow the security analysis of the deck to be performed
> independently of TLS, make it easier for TLS to support different deck
> functions, allow deck functions not based on an XOF API, and a generic
> deck-function specification would clearly have value beyond TLS.
>
> Cheers,
> John Preuß Mattsson
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>