[TLS] Re: Last Call: <draft-ietf-tls-mlkem-09.txt> (ML-KEM Post-Quantum Key Agreement for TLS 1.3) to Informat ional RFC
David Benjamin <[email protected]>
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAF8qwaCnVmBg6AraXRLE36oT6S7RaEhJfzBgV=O4Q0wp7nP0aw@mail.gmail.com> |
Just answering the one misconception about TLS 1.3 in here: On Tue, Aug 11, 2026 at 5:33 PM Erwin Hoffmann <[email protected]> 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 _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]