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

Hello Christian,

On 7/16/26 18:43, Christian Huitema wrote:
> 
> On 7/16/2026 3:40 AM, 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. 
>> 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.
> 
> I think that the discussion has established a couple of points:
> 
> * The MLKEM "decaps" function provides the TLS client with an exact 
> copy of the "m" bits chosen by the TLS server.

Roughly this is correct (e.g., `ML-KEM.Decaps_internal()` can recover
`m`) and so the API does not return m, but the decapsulating peer
can recover it [0].

This was a point of bitter dispute and it took a lot of time to
establish this fact. That difficulty was and is pretty concerning.

> * These bits are the direct output of the RNG used by the server in 
> the MLKEM "encaps" function.

Agreed however this skips that this is the result of the change made by
NIST. Let us ensure that they are properly credited for their
cryptographic interventions.

In FIPS 203, ML-KEM.Encaps samples a 32-byte m and passes it directly to
ML-KEM.Encaps_internal. The third-round Kyber specification instead
applied m <- H(m). Appendix C.1 says NIST removed that step because FIPS
203 requires approved randomness generation [0][1].

> * If the RNG does not have backward and forward replay protection, 
> these bits can be used to predict past or future outputs of the
> RNG, and this is bad.

That is roughly correct. I would describe this as prediction resistance
and backtracking resistance rather than "replay protection." For
Dual_EC_DRBG, the known trapdoor attack recovers enough state to predict
future output; it does not generally recover past output [2] and seeding
changes the sampling requirements. The relevant failure is hidden
algebraic structure, not necessarily low entropy.

However I caution that your description simplifies the hidden structure
issue and want to highlight and express serious caution: such a
simplification leads to people thinking we are discussing entropy. This
has led to a lot of wasted time.

With Dual_EC_DBRG, an adversary holding the trapdoor/secretkey(s) can
predict the future by attacking the structure but you should not be able
to do so in any case. Below, I explain the exception to 'in any case'
unfortunately.

> * RNGs that are compromised by some kind of supply chain attack
> will not provide backward and forward protection.

That is not the only vector and still it is a very important one.

Another vector that is extremely relevant is that governments in the
world, depending on jurisdiction, may be able to _mandate_ vendors do
something through a legal compulsion attack.

The same kind of "failure" could arise from the original design,
implementation, configuration, firmware, malicious substitution, or
compelled vendor modification. The protocol-level question does not
depend on which cause produced the structured output.

Other failures cause other problems and those failures are solved elsewhere.

> * The same RNG may or may not be used to derive TLS elements such
> as the Server Random bytes (depending on how implementers
> understand the public/private split discussed in annex C1 of TLS
> 1.3)

Yes, this is highly dependent on the developer's security posture.

This is _extremely_ implementation-dependent. If the same RBG
lineage feeds both public transcript fields and secret key material,
then public values may already create another state-recovery path. That
does not make the ML-KEM path harmless; it means implementations and
protocols should minimize every such exposure.

> * Key exchanges based on Diffie-Hellman operating on number fields 
> with an associative multiply function do not expose the random bits 
> used for generating the key.
> 

At the protocol level, I agree with a (no pun) point: a classical
Diffie-Hellman public value does not directly reveal the raw random
bytes supplied to key generation.

Composition and ordering still matter in a hybrid. If the ML-KEM
interaction exposes enough RBG output to recover the state before an
X25519 scalar is sampled from the same lineage, the adversary may
predict both components. If the X25519 scalar was generated earlier and
the RBG resists backtracking, that particular classical component may
remain independent of the later state recovery [2]. Exploiting this may
also require an adversary to just connect once or twice or to wait a
little while while watching.

There is also a distinct long-term quantum ...point? Ahem. A
sufficiently capable quantum computer could solve the elliptic-curve
discrete logarithm between the public Dual_EC points and thereby remove
the intended NOBUS exclusivity of those public parameter sets [3].

That does not prove that an X25519 public key reveals the exact 32-byte
Dual_EC_DRBG output that is used as an input to X25519 key generation:
X25519 first clamps (2^5) the input scalar, so the public key does not
uniquely encode all original input bits [4]. If the Dual_EC_DRBG output
is partially truncated (e.g., around 2^16) and clamped, it is still more
complicated.

However, I would agree that given an X25519 public key, a quantum
computer can recover the secret scalar. I would _assume_ that the secret
scalar input even after clamping is available and enough to attack
Dual_EC_DRBG _again_ with a quantum computer. However, I am not certain.

I have some unfinished analysis about these kinds of outputs in IETF
protocols. I recall that it was John who mentioned that the IETF has
many protocols that would be vulnerable, and so, I looked at his example
list. He was correct that there are many many problems but sometimes the
outputs are not in a sequence that lends itself to sampling enough
sequential bits. This is part of the existing Dual_EC_DRBG literature,
so it is not a new observation by any means. For a third-party
surveillance adversary, they could sample continuously by just watching
everything.

For example if some large scale adversary has a high resolution clock in 
their SORM or their XKeyScore deployment, and they also keep timing of 
packets accurately. I recall that the XKeyScore (Dell?) servers meet 
that criteria for what it is worth.

Meanwhill An unhashed m gives the decapsulating peer the RBG bytes directly.

That is to say if X25519 is an issue here, well, `m` is strictly worse
because you do not need to first attack X25519. Either way, attacking
X25519 requires work everytime using your new quantum computer.
Meanwhille Dual_EC_DRBG's NOBUS property falls with very little work
using that same quantum computer and that quantum attack only needs to
be done once.

Here's why: An unhashed `m` gives the decapsulating peer the RBG bytes
directly.

Hashing first removes that direct algebraic object and forces a separate
preimage or search problem. For an ideal 256-bit hash and a full-entropy
input, generic quantum preimage search requires on the order of 2^128
oracle queries [5]. I would not include the preliminary (2^5 to 2^21)
estimates here without a complete treatment of the exact RBG buffering,
truncation, clamping, group-order equivalences, and generation order.

So in summary:

Consider that all of the above _strengthens_ the argument for hashing
`m` as _everyone_ with a quantum computer should be able to solve for
the NIST standardized Dual_EC_DRBG backdoor parameters.

ML-KEM's `m` would then continue to be a stable way to sample the RNG
directly even after ECC crypto is eliminated elsewhere! Other PQC
options that I looked at do not have this exact issue issue, sntrup768
for example seems to not be straight forward to exploit in this
scenario. This is noteworthy when protocols decided to go from
sntrup769x25519 to mlkemx25519, for example. Other PQC is worth
analyzing. Everything depends very heavily on the implementation details
in any case.

Imagine a future where everyone is running around with their own quantum
computer of sufficient stability and capacity to carry out the relevant
  attacks. Let us assume that those people will be solving ECDLP at
cocktail parties for entertainment. That Adversary will be able to
attack any pure ML-KEM's `m` containing Dual_EC_DRBG output even after
X25519 is not in the picture. The attacker can almost always sample `m`,
so the safe bet is to hash _before_ sending to an attacker.

Without a doubt, a hashed `m` seems a _lot_ harder to attack than an
unhashed `m` even in a world with a quantum computer.

> The last point is an important difference. An RNG that is "good 
> enough" when using classic Diffie-Hellman for key exchange may not 
> be adequate for MLKEM. It is definitely worth pointing that out to 
> implementers. The reasonable solution is to build a resistant RNG
> by combining the standard RNG with an adequate DRBG [citation-
> needed].
> 

Right. An important difference here is also that TODAY `m` can be
recovered for any holder of the relevant trapdoor/secretkey(s). This
_obviously_ includes certain large-scale adversaries such as NSA or
GCHQ. They will not say much but I hope that I am not the only person
that wonders who else has those keys. For example, did the Shadow
Brokers loot those keys? Oof. They can do something pretty funny, if so.

Those trapdoor/secretkey(s) holders do not need a quantum computer
today. Right now they gain an advantage and introducing ML-KEM without
hashing `m` weakens many protocols _today_.

I am also working on a broader survey of public and peer-recoverable
randomness across protocols. Currently I have looked at dnssec, tls
(1.3), ikev1, ikev2, jose, l2tp-ipsec, matrix, mls, openpgp, openvpn,
pptp, quic, signal, sshv1, sshv2, tls (1.1, 1.2), wireguard, and a few
others.

The count of passive and active oracles for those protocols highly 
depends on exact implementation choices, generation order, state 
sharing, authentication phase, and whether a value is merely public or 
actually supports state recovery. I will publish the methodology and 
protocol-specific results once those distinctions are stable.  Some of 
those protocols have some very concerning problems but that is an email 
for another day.

For example to absolutely ensure that there is no panic, I think OpenSSH 
has a pre-auth oracle but it is unlikely to _ever_ take raw bytes from 
/dev/hwrng or Dual_EC_DRBG. I did not find a vulnerable implementation 
anywhere. I repeat, I am not claiming a security issue but rather I am 
showing that OpenSSH has the added burden to check as this is deep 
within the ML-KEM implementation. That last part is unreasonable in my 
view. But hey, NIST is certain that they are correct, and some people 
here accept this as fine. Okay!

If there is a protocol you're interested in - let me know, I am happy to
add it to my tooling for further analysis.

> I would suggest both a simple mention of the problem in the security 
> section of both MLKEM based drafts, and a somewhat longer term work 
> on an RFC discussing randomness requirement for TLS and maybe other 
> security functions.

Would you be willing to draft, or co-draft, the short Security
Considerations text? I think the minimal text should say:

- FIPS 203 requires approved randomness generation for
    ML-KEM.Encaps;

- ML-KEM.Decaps_internal reconstructs m', so a peer controlling
    its decapsulation implementation can recover it;

- third-round Kyber hashed m to safeguard against flawed randomness;

- FIPS 203 removed that step because of its approved-RBG requirement;

- NIST is responsible for making this less safe in the non-FIPS
   certified context by their own admission;

- implementations outside that assumption need explicit guidance; and

- Dual_EC_DRBG is the public standardized example showing why hidden
    algebraic structure differs from ordinary entropy failure.

I also support longer-term work on randomness, state separation, and
public or peer-recoverable RBG outputs across TLS and other protocols.

That _much_ broader work should not delay adding accurate Security
Considerations to the two ML-KEM drafts now.

Thank you for supporting my observations. I generally agree with you and 
it is fair to say that you get it. Thank you for saying so.

Kind regards,
Jacob Appelbaum

[0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

[1] https://pq-crystals.org/kyber/data/kyber-specification-
round3-20210804.pdf

[2] https://hovav.net/ucsd/dist/juniper.pdf

[3] https://arxiv.org/abs/quant-ph/0301141

[4] https://www.rfc-editor.org/rfc/rfc7748.html

[5] https://arxiv.org/abs/1603.09383

> 
> -- Christian Huitema
> 
> 
> 
> 
> 
> 
>> 
>> 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 
>>> <[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 tls- 
>>> [email protected]
>> 
>> 
>> _______________________________________________ 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]