[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]>]

On Wed, Aug 12, 2026 at 10:24 AM Erwin Hoffmann <[e-mail]> wrote:

> Hi David,
>
> Am Dienstag, dem 11.08.2026 um 17:46 -0400 schrieb David Benjamin:
> > 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.
>
> hm, did you look at my drawing, explaining this as well? [2]
>

I did look at your drawing. As pointed out elsewhere, it mistakenly claims
only the Hello messages are hashed. The arrow on the left spine can also be
misread as thinking the "master secret" continues on, when it does not.
Please see the actual diagram in the specification, which I linked to above.


> The transscript hash adds entropy and uniqueness (and some state) to
> the calculation - certainly in a better way using the HKDF - rather
> than TLS 1.2 with the combination of MD5 and SHA1 together with some
> string constants. But still: It is public material and does not improve
> security at that point.
>
> But maybe, I've missunderstood your reply.


Your message specifically cited a lack of transcript hashing:

> > 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.

This was indeed wrong, so I've corrected it per your request. :-) The
transcript hashes are incorporated into every output of the TLS 1.3
handshake. This very much improves security, Take a look at the long
history of issues in TLS 1.2 (e.g. 3-SHAKE) for why we do this.

I see you are now bringing a new concern that the transcript hash and other
non-shared-secret inputs are "public material"[*]. This is just how such
handshakes work. In a non-PSK TLS 1.3 handshake, the *entire point* of the
asymmetric shared secret is to provide *the* non-public input to the key
schedule. This is why, if one uses a legacy ECC algorithm as the asymmetric
shared secret, an attacker with a CRQC can decrypt the connection. If you
choose X to provide the asymmetric shared secret, you are relying on X to
do so securely. And, yes, part of that depends on any PRNG inputs to X
meeting the security requirements of a PRNG. There isn't really any way
around that here.

One can evaluate subjective tradeoffs on which X are more likely secure,
which X are more expensive, which X are more complex, and which X are carry
a high coordination cost, but those are ultimately subjective tradeoffs.
The TLS WG spent an inordinate amount of time exploring that tradeoff
already and incorporated the results into the document.

David

[*] Strictly speaking, the transcript hash actually isn't strictly public
per se because part of the TLS 1.3 handshake is encrypted, but this is
somewhat a digression. I don't believe we actually depend on this fact for
the security of the handshake itself, but I may be misremembering.