[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[Nadim Kobeissi <[e-mail]>]

You misunderstood the quoting in my reply I think.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 16 Jul 2026, at 5:16 PM, Salz, Rich <[e-mail]> wrote:
> 
> 
> On 7/16/26, 9:57 AM, "Salz, Rich" <rsalz=[e-mail]> wrote:
> think it would be better as a separate RFC.  Perhaps collaborate with Don Eastlake
> 
> Changing the current drafts is a mistake. 
> 
> I received a couple of emails that made me realize I was over-zealous in trimming down.  It was in response to Nadim’s message below.
> 
> The draft is about using ML-KEM, not about using something based on Kyber. If you want to write about RNG, Don is looking at drafting a successor to 4086 so contact him. If you want to write a draft about how to use Kyber, that’s a separate document.
> 
> On 7/16/26, 6:41 AM, "Nadim Kobeissi" <[e-mail]> wrote:
> 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.
> 
> This is incredibly unreasonable to the point of being disruptive. You are basically demanding that the IETF undermine the entire point of NIST standardization, on top of all your baseless insinuations about personal motivations of those who disagree with you and your unreasonable threat modeling when thinking about the entire question of `m` in ML-KEM and sources of randomness.
> 
> At what point does this become pure concern trolling? I regret even making the effort to catch up on these discussions.
> 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> 
> On 15 Jul 2026, at 5:25 AM, Jacob Appelbaum <[e-mail]> wrote:
> 
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>