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

Hi Nadim,

On 7/16/26 12:40, Nadim Kobeissi wrote:
> Jacob writes:
> 
>> 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.

We are discussing giving advice to implementers about a technical issue 
that was not understood as even being possible. I was asked for a list 
of concerns that describe the topics. I provided one and I offered to do 
the work to add it to the draft. That moved the discussion forward 
rather than keeping it stalled.

This is a discussion about adding a few sentences to a text file where 
the advice and observations are not technically incorrect, and the idea 
is to not paper over the issue but to give advice to implementers.

It is especially important to raise these kinds of issues in the text to 
ensure the IETF is not used as a vehicle to normalize or justify 
anything that could be used to harm user security.

This does not mean that we need to say that the intention behind the 
change was malicious but we can fairly, and should accurately describe 
the result. This seems especially true when NIST does not even disagree.

> You are basically demanding that the IETF undermine the entire point
> of NIST standardization,

No. I am not. I am making a succinct list as requested. It is part of 
the WG's responsibility to enumerate the Security Concerns.

NIST made the change, it is undeniable. They accept the result and 
justify it by advancing FIPS, but we are not discussing a draft that 
requires FIPS. It makes sense, and I support, ensuring that the FIPS 
construction is clearly explained. That is not undermining the entire 
point of NIST standardization but showing that the draft needs to 
surface that or things can go very very badly.

Regardless, it is not our responsibility to rubber stamp a NIST standard.

It is also not valid to dismiss these security concerns when the 
standardization process was described as having settled everything, and 
that it was noncontroversial because NIST issued FIPS 203.

The fact that they did not reply to official comments substantively, 
including the IPR concerns,

> on top of all your baseless insinuations
> about personal motivations of those who disagree with you

I do not believe this is a fair characterization of what I have written. 
Nothing about what I have expressed is baseless either.

Please be specific and I will gladly take responsibility if it is 
accurate or I will gladly provide clarification or some other response. 
It is not my intention to impugn anyone's personal character.

My suggested draft text is entirely about the ideas and not any person.

I am not emailing people off-list and maligning them or applying 
pressure either. I trust that you can say the same, but I know that this 
is not true for everyone.

> and your
> unreasonable threat modeling when thinking about the entire question
> of `m` in ML-KEM and sources of randomness.

This is a point of technical disagreement. We can settle it in a few ways.

I would advance the idea that the Extended Random draft allowed for more 
efficiently exploiting Dual_EC_DRBG, and the literature supports this 
including finding it deployed on the Internet.

I would also advance the idea that many software packages read from 
/dev/hwrng on GNU/Linux, and if you look at the Linux kernel's hardware 
random number generator drivers you will note that nearly all of them 
pass the data directly to that device unmodified. This is described in 
the kernel documentation. This means that hidden algebraic structure 
survives without transformation. Software uses /dev/hwrng.

Are those facts in dispute?

Now, if you mean to say that Dual_EC_DRBG and related constructions are 
not within the scope of any valid threat model, we disagree.

> 
> At what point does this become pure concern trolling?

You have put forth a symbolic model that cannot capture this security 
concern and then argued that it proves security. I agree with your 
analysis, especially about hybrids.

I found a gap in the proof because symbolic modeling does not generally 
model these internals. It is an assumption that the KEM works, and it is 
not an unreasonable assumption.

Nevertheless, I am able to decrypt TLS in both a passive and an active 
setting because of a change _introduced by NIST_, where they agree with 
me about the consequences of the change, the consequence applies with no 
other protocol involved, and it becomes worse with TLS because TLS 
itself has similar issues. Nick confirmed this matter, as did others, 
but we did not agree with the remedy proposed.

That is not concern trolling. It is also not pushing hybrids over pure 
PQC because I found that unfortunately the issue impacts both. I am not 
happy with this result but I agree with Paul, consistency is important.

It is unfortunately a valid criticism of hybrids where we find the 
hidden assumption that also lines up with a known standardized 
government backdoor which is involved with PROJECT BULLRUN. I am a 
proponent of hybrids, so I admit, I was not happy but it is important to 
try to resolve it. It also lines up with an example of how people 
wondered - might PQC introduce a problem that can be solved without a 
quantum computer, and might it be exploitable immediately? The answer is 
clearly yes, and yes, for any adversary with the actual keys to 
Dual_EC_DRBG. Again, Bouncy Castle _still ships Dual_EC_DRBG and ML-KEM_ 
today. That is one of the most popular java libraries in the world. 
Thankfully they aren't composed together by default. A survey of all 
uses is a separate research question.

Rob, I recall, suggested earlier that ISE RFC is the correct location 
for documents that do not achieve consensus. It is also a place for 
other national standards.

> I regret even
> making the effort to catch up on these discussions.
> 

I hope you do not take my results as being critical of your excellent 
modeling work. My goal is to ensure that the End User is protected, and 
unfortunately, I know that these kinds of kleptographic sabotage 
operations are both real, and extensively documented in the citations 
offered. We also see the results which include decryption of TLS and 
other cryptographic protocols. This is directly relevant to the working 
group.

I fully understand that your threat model and mine are probably 
different. I am considering a threat model for TLS as one of the most 
ubiquitous security protocols deployed today, and in the future. It may 
be wrong for your ontological view of adversary capabilities [0]. We 
might disagree about the real world capabilities of Adversaries and then 
of that, what matters. I trust we can agree that it can be pretty 
overwhelming and terrible.

With respect, I must disagree with your summary. I am not concern 
trolling. I hope we can either agree to disagree or at least not have a 
flame war here.

I certainly agree with your general sentiment that this entire 
discussion is no fun, and yet I cannot apologize for being on-guard 
against something that I have implemented as a functional attack. This 
is trivial to confirm and it has been confirmed as a valid technical issue.

There are TLS libraries take defense in depth measures to address this 
issue. In those libraries, the use of ML-KEM undermines the 
aforementioned defense in depth strategy. Interestingly, the use of 
Kyber does not. The difference is a hash call removed by NIST where they 
declared this to be an acceptable outcome. We obviously disagree. I hear 
you that you seem to be in agreement with NIST. I accept that we may 
have an irreconcilable difference of technical opinion but I trust that 
we can agree on the facts.

Putting those facts in the draft requires putting forth a suggestion as 
requested. Attack the ideas, not the person, indeed.

It is unfair to imply or to state that "my" threat model is 
unreasonable. I am not only person with these concerns, the public 
reporting cited, and the cited cryptographic literature over ~30 years 
supports the concerns.

Kind regards,
Jacob Appelbaum

[0] see page 14 of 
https://ccdcoe.org/uploads/2026/04/ONTOLOGICAL_FOUNDATIONS_OF_COGNITIVE_WARFARE.pdf

> Nadim Kobeissi Symbolic Software • https://symbolic.software
> 
>> On 15 Jul 2026, at 5:25 AM, Jacob Appelbaum <[email protected]>
>> 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
>> -- [email protected] To unsubscribe send an email to [email protected]
> 
> 

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]