On Wed, Jul 8, 2026 at 12:08 PM Benjamin Kaduk <bkaduk= [email protected]> wrote:
> 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. > Indeed. Fortunately, we *already* applied it to both anyway, so this is all moot. First, both draft-ietf-tls-mlkem and draft-ietf-tls-ecdhe-mlkem cite FIPS 203, which means any requirements in FIPS 203 apply unless we explicitly disavow them. (The quoted email cited whether something was a "FIPS-validated module", but I think there may be a confusion here between FIPS 203, which is an algorithm specification, and FIPS 140, which defines a whole module validation scheme. They both say FIPS in front, but that's like observing that IETF documents all say RFC in front.) But regardless, if one believes that the reader might ignore it, there *is* an IETF TLS RFC which also gives entropy guidance: https://www.rfc-editor.org/info/rfc8446/#appendix-C.1 In so far as one believes this needs to be restated at the TLS level (it's typically part of the crypto layer), this is the right place to state it than either draft-ietf-tls-mlkem or draft-ietf-tls-ecdhe-mlkem. That way it can apply uniformly to *all* entropy in TLS, including: * The client and server random values * The ephemeral X25519 key shares in pure X25519 * The client-generated ephemeral ML-KEM key in pure ML-KEM * The server-generated ML-KEM encap entropy in pure ML-KEM * The ephemeral X25519 key shares in hybrid ML-KEM * The client-generated ephemeral ML-KEM key in hybrid ML-KEM * The server-generated ML-KEM encap entropy in pure ML-KEM Secure randomness is a deeply-rooted requirement in much of cryptography, including TLS. It is definitely a concern, but it is a uniform one that we're well-experienced with by now. David
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
