[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

["Bellebaum, Thomas" <[e-mail]>]

> IIRC, rumour has it that those who need a FIPS-validated stack, and have  
> only an older stack with P-256/P-384 validated, but ML-KEM not yet  
> validated, can get a validated combination via ML-KEM plus ECDSA, but  
> not ML-KEM with X25519 or X448.

This does not make sense to me.
TLS with ML-KEM, oversimplified, would be ML-KEM with stuff (the entire handshake) hashed into the secret.
TLS with ML-KEM and X25519 would be ML-KEM with stuff (the entire handshake) hashed into the secret.

How could it ever be allowed to hash in all the TLS-protocol messages, which contain many custom-made countermeasures against all kinds of attacks, but not the output of the algorithm we call X25519?
Because X25519 has the reputation of being a key exchange? What if we used a custom algorithm which just happened to be identical/equivalent to X25519, but does not have this reputation?

-- TBB