On Wed, 8 Jul 2026, David Gessel wrote:
I do not support publication of draft-ietf-tls-mlkem-08 in its current form.My objection rests on uncontested text in FIPS 203 itself. Appendix C.1 (third bullet) documents that the round-3 Kyber step m <- H(m) was removed from ML-KEM.Encaps, and states the rationale plainly: "The purpose of this step was to safeguard against the use of flawed randomness generation processes. As this standard requires the use of NIST-approved randomness generation, this step is unnecessary and is not performed in ML-KEM."
For those people with this argument, why didn't you also oppose draft-ietf-tls-ecdhe-mlkem that has the same issue?
Should the WG proceed despite these objections, the Security Considerations should at minimum (a) state explicitly that ML-KEM's security argument assumes randomness of approved-RBG quality, (b) cite FIPS 203 Appendix C.1 so implementers understand the m-hash removal and its stated precondition, and (c) reaffirm hybrid key agreement as the recommended deployment.
Are you then also in favour of pulling draft-ietf-tls-ecdhe-mlkem which has the same issue you raise? I am confused about the arguments against MLKEM as the algorithm itself, as the discussions on the mlkem hybrid had no issue with the mlkem parts. Also, if you think mlkem is unsafe as PQ algorithm, which alternative would you propose? How would we reach consensus without rerunning a NISTlike algorithm competition. And run it quickly to defend against "store now, decrypt later" ? And why would this be a TLS WG effort, instead of building on actual consensus of cryptographers? That is to say, I think selectively applying this argument to draft-ietf-tls-mlkem but not draft-ietf-tls-ecdhe-mlkem is invalid. Paul _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
