On Wed, Jul 08, 2026 at 11:16:21AM -0400, Paul Wouters wrote: > > 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?
I had the same question -- if this is an issue with ML-KEM, isn't it an issue with any use of ML-KEM, regardless of hybrid or standalone? > That is to say, I think selectively applying this argument to > draft-ietf-tls-mlkem but not draft-ietf-tls-ecdhe-mlkem is invalid. I'm reluctant to use the word "invalid" in this way; while a given technical concern can be valid or invalid, if we decide that it's valid then we have a duty to deal with it everywhere that it applies, and it's not up to someone commienting on a single draft to say that we can limit the consideration of the concern to just one of multiple impacted drafts. Whether or not the technical concern is valid or not is independent of whether it's raised on just one or multiple documents. -Ben _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
