I agree with Paul that it would be inappropriate to require this
document to require a warning about setting 'm' to a value taken
directly from a secure RBG, when the IETF and IRTF have in the past and
continues to approve documents that do this same thing.
It is not just daft-ietf-tls-ecdhe-mlkem and all other drafts/RFCs that
reference ML-KEM:
* RFC 8391 (XMSS) has a line "initialize SEED with a uniformly random
n-byte string," where "SEED" is part of the public key.
* RFC 8554 (LMS) has a line "Set I to a uniformly random 16-byte
string," where "I" is part of the public key.
* While RFC 9814 (Use of the SLH-DSA Signature Algorithm in the
Cryptographic Message Syntax (CMS)) notes the importance of using a good
PRNG to generate private keys, it doesn't warn about Algorithm 21 in
Section 10.1 of FIPS 205 setting PK.seed (part of the public key)
directly to the output of a RBG.
* RFC 5652 ( Cryptographic Message Syntax (CMS)) similarly notes the
importance of using a good PRNG to generate keys, but Section 6 just
says "A content-encryption key for a particular content-encryption
algorithm is generated at random." There is no warning about directly
using the output of a PRNG as the content-encryption key.
These are probably just a few. It's likely that there are many other
documents that have been approved by the IETF that call for a random
value to be generated and shared that do not include some warning about
setting that value directly to the output of a PRNG.
As others have noted, if you believe that "system randomness" should not
be used directly, then the solution is to change your RNG to hash (or
otherwise process) the output, so that all uses of random data are
protected, rather than attempting to modify each and every protocol that
uses random data.
Also, as others have noted, even if every use of an PRNG included a
requirement to hash the output of the PRNG before using it, that would
only mitigate against one specific type of PRNG failure. There are many
other ways to attacker could create a weak PRNG that would not be
mitigated by this.
On 7/8/26 09:07, Benjamin Kaduk 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.
-Ben
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
