[TLS] Re: Last Call: <draft-ietf-tls-mlkem-09.txt> (ML-KEM Post-Quantum Key Agreement for TLS 1.3) to Informational RFC

[David Benjamin <[e-mail]>]

Just answering the one misconception about TLS 1.3 in here:

On Tue, Aug 11, 2026 at 5:33 PM Erwin Hoffmann <[e-mail]> wrote:

> 4. The way the random number is used in ML-KEM, does IMHO not conform
> to this basic assumption: It is fed directly (not taking the
> transcript-hashes into account) to generate the Master Secret [2].
> Correct me, if I'm wrong.
>
> 5. Thus, at the bottom-line, the Master Secret depends solely of the
> quality of the PRNG. As explained in [1], its Algorithmic Information
> Content (AIC) is preserved given the ML-KEM handshake.
> This is a clear violation of risk-minimization because of disclosing
> its origin. Additional hashing would involve some additional
> computational cycles, of course.
>

While it is narrowly true that the TLS 1.3 "master secret" (called the
"main secret" in RFC 9846) does not incorporate the transcript, this is a
red herring. While it shares a name with a TLS 1.2 concept, they are not
used in the same way. The "master secret" in TLS 1.2 is the primary output
of the TLS 1.2 handshake. It is the resumption secret in a TLS 1.2 session,
and used to derive the TLS 1.2 record keys.

That is not how TLS 1.3 works. In TLS 1.3, this value is *not* the output
of the handshake. (Our implementation does not retain it after the
handshake at all!) The outputs of the handshake are not the HKDF-Extract
left spine of the key schedule, but the Derived-Secret values on the right.
Each of those incorporates the transcript. You'll see different prefixes in
the diagram, but this is simply because they're computed at different times.
https://www.rfc-editor.org/rfc/rfc9846.html#section-7.1-13

So, no, the TLS 1.3 handshake thoroughly uses the transcript hashes in all
of its outputs, whether the key agreement is ML-KEM or something else. All
this was part of very thorough analysis that the WG did when TLS 1.3 was
designed.

David