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

--===============4530246866738395241==
Content-Type: multipart/alternative; boundary="0000000000004d75440657e2462e"

--0000000000004d75440657e2462e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi John,

I=E2=80=99ve been thinking recently about how best to generalize HKDF-to-XO=
F key
schedule updates across any protocol and I don=E2=80=99t think we=E2=80=99r=
e 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=E2=80=99d suggest we start by trying to apply this tran=
slation
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=E2=80=99s Derive =
and
Hash/Expand/Extract. When HPKE-PQ introduced (Turbo)SHAKE as a one-stage
KDF, it didn=E2=80=99t define the equivalent Expand/Extract functions becau=
se 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=E2=80=AFPM John Mattsson <john.mattsson=3D
[email protected]> 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 performe=
d
> 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=C3=9F Mattsson
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

--0000000000004d75440657e2462e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Hi John,</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I=E2=80=99ve been thinking recently about how best to generalize =
HKDF-to-XOF key schedule updates across any protocol and I don=E2=80=99t th=
ink we=E2=80=99re there yet. As discussed here,=C2=A0<span>there are a vari=
ety of ways to instantiate these intermediate representation-style key sche=
dule 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=E2=80=99d suggest we=C2=
=A0start by trying to apply this translation exercise for two or more proto=
cols before generalizing or splitting out new documents.</span></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">MLS is a great example of a second =
protocol that could use this exercise. As specified, MLS depends on the sam=
e HKDF-based primitives as TLS but it piggybacks on HPKE for the definition=
 of the key schedule=E2=80=99s Derive and Hash/Expand/Extract. When HPKE-PQ=
 introduced (Turbo)SHAKE as a one-stage KDF, it didn=E2=80=99t define the e=
quivalent Expand/Extract functions because they were not needed in HPKE. Th=
is left=C2=A0<span>MLS, dependent on HPKE for its KDF definitions, function=
ally unable to use the new single-stage KDFs in its key schedule.=C2=A0</sp=
an><span>This is probably a good thing because a direct mapping would be=C2=
=A0inefficient. A version of=C2=A0this TLS-XOF draft written for MLS would =
be a good test of the generalizability of the approach beyond TLS and a ste=
p worth taking before considering splitting this document up.</span></div><=
/div><div><div dir=3D"auto"><br></div><div dir=3D"auto">Nick</div><div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Ju=
l 28, 2026 at 2:28=E2=80=AFPM John Mattsson &lt;john.mattsson=3D<a href=3D"=
mailto:[email protected]" target=3D"_blank">40ericsson.com@dmar=
c.ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">



<div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
Hi,</div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c=
olor:rgb(0,0,0)">
Would it make sense to specify the deck function in a separate draft and th=
en reference that from the TLS draft?</div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c=
olor:rgb(0,0,0)">
For example:</div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c=
olor:rgb(0,0,0)">
draft-sullivan-tls-deck-schedule + draft-sullivan-deck, or</div>
<div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c=
olor:rgb(0,0,0)">
draft-sullivan-tls-deck-schedule + draft-keccakteam-flightdeck.</div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c=
olor:rgb(0,0,0)">
I think this would make the architecture cleaner, simplify discussions with=
in the TLS WG, allow the security analysis of the deck to be performed inde=
pendently of TLS, make it easier for TLS to support different deck function=
s, allow deck functions not based
 on an XOF API, and a generic deck-function specification would clearly hav=
e value beyond TLS.</div>
<div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo=
nt-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c=
olor:rgb(0,0,0)">
Cheers,</div>
<div style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;c=
olor:rgb(0,0,0)">
John Preu=C3=9F Mattsson</div>
</div>

_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">tls@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br>
</blockquote></div></div>
</div>

--0000000000004d75440657e2462e--


--===============4530246866738395241==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp
bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0
bHMtbGVhdmVAaWV0Zi5vcmcK

--===============4530246866738395241==--