Hi Paul, On 7/14/26 03:17, Paul Wouters wrote:
The draft does not define crypto, it normatively references some crypto. It cannot both normatively reference it and modify it to make its own.
I do not think that follows and while it does not define the code point, it does define how the cryptography is used in TLS including Security Considerations. A TLS draft can normatively reference FIPS 203 and still explain the relevant assumptions and tradeoffs in Security Considerations. FIPS 203 Appendix C itself documents that Kyber originally hashed `m` and that NIST removed that step because ML-KEM requires approved randomness generation. The TLS draft should say that plainly. Namely, quote the entirety of C.1: ``` C.1 Differences Between CRYSTALS-Kyber and FIPS 203 Initial Pub- lic Draft • In the third-round specification [4], the shared secret key was treated as a variable-length value whose length depended on how it would be used in the relevant application. In this specification, the length of the shared secret key is fixed to 256 bits. It can be used directly in applications as a symmetric key, or symmetric keys can be derived from it, as specified in Section 3.3. • The ML-KEM.Encaps and ML-KEM.Decaps algorithms in this specification use a different variant of the Fujisaki-Okamoto transform (see [24, 25]) than the third- round specifica- tion [4]. Specifically, ML-KEM.Encaps no longer includes a hash of the ciphertext in the derivation of the shared secret, and ML-KEM.Decaps has been adjusted to match this change. • In the third-round specification [4], the initial randomness 𝑚 in the ML-KEM.Encaps algo- rithm was first hashed before being used. Specifically, between lines 1 and 2 in Algorithm 20, there was an additional step that performed the operation 𝑚 ← 𝐻(𝑚). 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. • This specification includes explicit input checking steps that were not part of the third-round specification [4]. For example, ML-KEM.Encaps requires that the byte array containing the encapsulation key correctly decodes to an array of integers modulo 𝑞 without any modular reductions. ``` Alternatively highlight this part of C.1 from FIPS 203: ``` • In the third-round specification [4], the initial randomness 𝑚 in the ML-KEM.Encaps algorithm was first hashed before being used. Specifically, between lines 1 and 2 in Algorithm 20, there was an additional step that performed the operation 𝑚 ← 𝐻(𝑚). 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. ``` Then I would suggest describing the total set of requirements from FIPS203 or giving advice that `𝑚 ← 𝐻(𝑚)` should be used if the NIST- approved randomness generation requirement is not met. I would also probably want to say that this change by NIST is not robust against a failure of their DRBG, nor is it robust against providing an oracle, the m-oracle, I suppose which may be queries over TLS and/or used to sample the DRBG outputs directly.
The IETF cannot modify things that are an external normative reference. MLKEM is what NIST defined, not what you are trying to build now.
I am not asking the draft to pretend that NIST defined something else. I am asking the draft to document the consequence of what NIST defined: without the approved-RBG assumption, the rationale for removing Kyber's hash over `m` no longer holds. If the draft does not restore `m <- H(m)`, then it should at least state the FIPS 203 approved-RBG requirement and the fact that `m` is recovered by the decapsulating peer. This matters in practice. Many implementations will use `os.urandom`, `/dev/urandom`, `/dev/random`, `/dev/hwrng`, `getentropy()`, `getrandom()`, or another platform or library interface. Those may be excellent choices in a well-designed system, but they are not automatically the same thing as a NIST-approved RBG satisfying the FIPS 203 condition used to justify removing the hash. One way to make the dependency clear is to think of the real requirement as something closer to: - ML-KEM-512-Hash_DRBG - ML-KEM-512-HMAC_DRBG - ML-KEM-512-CTR_DRBG - ML-KEM-768-Hash_DRBG - ML-KEM-768-HMAC_DRBG - ML-KEM-768-CTR_DRBG - ML-KEM-1024-Hash_DRBG - ML-KEM-1024-HMAC_DRBG - ML-KEM-1024-CTR_DRBG Listing that is a concrete suggestion for the text but I do not feel strongly about where it goes in the text. These are shorthand examples names and I am not suggesting new algorithm names. The point is that FIPS 203 relies on an approved RBG of appropriate strength. If an implementation omits that part, the reason NIST gave for removing Kyber's hash over `m` no longer applies.
This answer circles the answer by not distinguishing between the RNG issue and any other issues. You still did not answer the question.
My answer is: not as-is. I am open to text that is applied consistently to both ML-KEM drafts. But a generic sentence about "use a good RNG" does not address the specific FIPS 203 requirement, nor the protocol consequence that `m` is recovered by the decapsulating peer.
This does answer it better, it seems your answer is "no".
No. My answer is not "no no matter what." My answer is "not as-is" because your suggestion is not even a full suggestion where I could just say yes.
Which is the same issue as the "m concern".
Related, not identical. The approved-RBG dependency is the assumption and a requirement. The `m` concern is the protocol consequence when that assumption is not met, or when it is hidden from implementers.
For one, this is not different between pure and hybrid, yet you have no issue with the hybrid Security Considerations?
I do have an issue with the hybrid draft on this point. The same Appendix C tradeoff and the same `m` issue apply there too. Hybrid helps against some failures, but it does not automatically help if the same recoverable RBG lineage later feeds the classical ephemeral scalar. The removal of the hash leads to some fun issues and not only with Dual_EC_DRBG but also.
Second, it seems as people said, TLS already provides a huge amount of options and parameters to use as a covert channel.
Agreed. That is why broader covert-channel work is also needed. But that does not justify leaving this specific ML-KEM issue unexplained in these drafts. It is a bit annoying to go back and forth between each layer where a different layer is used as a reason to ignore the issues in the layer under discussion.
What would a TLS implementer need to know when it uses a cryptographic library to support a new cipher, whether hybrid or pure?
They need to know at least: 1. FIPS 203 requires ML-KEM randomness from a NIST-approved RBG. 2. `m` is recovered by the decapsulating peer. 3. Kyber originally hashed `m` to protect against flawed randomness. 4. Dual_EC_DRBG is the public standardized example of a hidden-structure RBG failure. 5. Hybrid does not automatically help if the same recovered RBG lineage later feeds the classical ephemeral scalar. 6. This change was an intentional choice by NIST and the IETF does not agree with this change as it cannot mandiate the use of a specific DRBG.
First, it seems most of the items you just listed are the same item, and basically you want it to say "don't use pure, use hybrid instead",
That is not my position. The `m` issue applies to ML-KEM in both the standalone and hybrid drafts. My concern is that the drafts do not clearly state the FIPS 203 randomness requirement, the Appendix C tradeoff, or the peer-recoverability of `m`.
Second, if you want this document to proceed with some newly added text, it is up to you to propose such text to the WG.
Fair enough. Here is a start on a minimal list I think the text needs to cover: - cite the third-round Kyber submission; - cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)`; - state the FIPS 203 approved-RBG requirement; - state that `m` is recovered by the decapsulating peer; - recommend restoring Kyber's hashing of `m` as defense in depth against hidden-structure RBG failures; - cite Dual_EC_DRBG as the public standardized example. - quote the relevant part(s) of FIPS 203 C.1 I can turn that into concrete PR text. Before doing that, I would like to understand whether the WG is open to text at this level of specificity, or whether the only text people are willing to consider is a generic RNG sentence. If the generic sentence is the only thing on offer, I would request someone else draft it and I am happy to give feedback.
So "pure" is what the IETF is using now for consistency.
Point of clarification: did you mean ML-KEM or ML-KEM-WITH-A-DRBG when you said pure in that context?
The current text is the consensus proposal of two years of talk within the TLS WG.
The WGLC for draft-ietf-tls-mlkem-08 has ended, but I have not seen a declaration of consensus. We also do not yet have agreed text that addresses the FIPS 203 randomness requirement or Appendix C tradeoff.
I am not aware of any technical concerns.
Then let us test that with concrete text. The concern is not merely a different risk preference. It is that NIST's rationale for removing Kyber's hash depends on an approved-RBG requirement that the TLS draft does not clearly carry forward.
So to me that makes it clear that in practise, your answer will remain "no".
No. If the drafts clearly document the FIPS 203 approved-RBG assumption, the peer-recoverability of `m`, and the reason Kyber hashed `m`, I am open to changing my view. If the text is only "use a good RNG", then no, that is not enough.
As I explained above, you providing concrete text additions/ modifications will help determine consensus of your suggestions
I take that point. I can provide concrete text. My concern is that the Last Call has already closed, so I am asking how the chairs intend to handle new text if there is support for it.
Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.
Agreed. My position is that the issue has not yet been addressed. It has mostly been reframed as a generic RNG problem, which misses the specific Appendix C tradeoff and the `m` oracle.
The one thing that is clear to me is that what you are asking for is basically changing the normative reference.
I reject that framing. Security Considerations routinely explain assumptions, risks, and implementation guidance around normative references. That is what I am asking for here. The normative reference itself discusses Kyber and ML-KEM together in Appendix C. Quoting and explaining that text is not changing the normative reference. It is making the reference intelligible to TLS implementers.
Adding a generic statement about RNG is the only compromise possible.
I do not agree. A meaningful compromise would state the actual FIPS 203 approved-RBG requirement, state that `m` is recovered by the decapsulating peer, and explain that Kyber originally hashed `m` to protect against flawed randomness.
If that is not good enough for you, your only option is to voice that you are against publication -
That is not my only option. I am currently against publication as-is, but I am also trying to find text that could resolve the issue.
and to be consistent, I would expect you to be against publication of both the pure and hybrid mlkem drafts, as they are identical in that part, using the same normative reference of NIST.
I am against omitting the relevant FIPS 203 Appendix C details in both drafts. I am against omitting advice to implementers who are not running a FIPS-validated stack. I am against omitting the fact that `m` is available to the decapsulating peer. And I am against omitting the historical example of Dual_EC_DRBG when discussing hidden-structure RBG failures. A suggestion of generic RNG sentence that is not a concrete suggestion is not enough, no. Text that states the FIPS 203 approved-RBG requirement, the peer-recoverability of `m`, and the reason Kyber hashed `m` would be meaningful. Kind regards, Jacob Appelbaum _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
