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

[Sophie Schmieg <[e-mail]>]

And importantly, this transcript hash enforces that client and server will
always either get their preferred key exchange algorithm or fail the
exchange. This continues to be the main argument as to why this should be
standardized, even if one (as I do) believes that a hybrid is currently the
better choice for key exchange compared to pure. It simply does not impact
anyone who does not specifically and against recommendations set up their
client and server to actually negotiate the pure key exchange. If one
wishes to make that judgement call, one should be free to do so, given that
it has zero impact on anyone else.

Ultimately, this is not a question on which key exchange algorithm is more
secure, or more efficient, or has a brighter hue of blue coloration. None
of this matters beyond the recommendation section of the RFC.

On Wed, Aug 12, 2026 at 8:38 AM David Benjamin <[e-mail]>
wrote:

> 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.
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]