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

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

hm, did you look at my drawing, explaining this as well? [2]

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.

Regards.
--eh.   

[2] https://www.fehcom.de/qmail/smtptls.html##keyMgmt

> 
> David

-- 
Dr. Erwin Hoffmann | www.fehcom.de
PGP key-id: 36553F7F9C58D1CC
PGP key-fingerprint:  950B 5555 0B08 5A2A 1C00 9594 3655 3F7F 9C58 D1CC

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

-----BEGIN PGP SIGNATURE-----

iKAEABYKAEgWIQSVC1VVCwhaKhwAlZQ2VT9/nFjRzAUCanyBixsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDMOHGZlaEBmZWhjb20uZGUACgkQNlU/f5xY0cyUEwD/
Wkka8f0+QWlhwqdbQx2pxgnL/6T/D7S4SbxsuZjvUfkA/2euCffVJcqgL46J9Drz
Z+LQGEbWYzxFt9txRu7thWYP
=Um+O
-----END PGP SIGNATURE-----