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

[John Mattsson <[e-mail]>]

Nick Sullivan wrote:
>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.

That seems like a reasonable approach to me.

draft-sullivan-tls-xof-ciphers-00:
>deck function:  An extendable-output function evaluated over a sequence of framed input strings, with the output length bound into the sequence before any output is produced (Section 7.1). The construction beneath it is an XOF and takes no key parameter

Familiarizing myself further with deck functions, I have come to understand that a deck function is a keyed function. However, I am not particularly fond of the term “dec function”.
https://eprint.iacr.org/2018/767.pdf

Cheers,
John Preuß Mattsson

From: Nick Sullivan <[e-mail]>
Date: Friday, 31 July 2026 at 08:26
To: John Mattsson <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [TLS] Re: New Version Notification for draft-sullivan-tls-xof-ciphers-00.txt

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]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>