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

Hi Nico,

On 7/17/26 07:35, Nico Williams wrote:
 > On Fri, Jul 17, 2026 at 12:52:05AM +0200, Jacob Appelbaum wrote:
>> On 7/16/26 21:57, Nico Williams wrote:
>> 
>>> The objective answer is that the horse left the barn two decades
>>> ago when the IETF decided to get out of fighting about national
>>> cryptographic standards, therefore Deb's 37 years at the NSA are
>>> irrelevant in this case, and you're fighting the wrong battle if
>>> you want to change that two-decade-old decision.
>> 
>> That is not correct and the ISE could easily publish the drafts 
>> under discussion without consensus as Rob suggested more than a 
>> week ago.
> 
> Has that not been opposed too? / The relevant decision-makers would 
> be the authors and the Independent Submission Editor. I have not 
> seen a definitive objection from either, and I understood Eliot to 
> be open to considering the idea.
>
> Would that not be opposed too? It could certainly be opposed. What 
> kind of opposition do you mean?

Rob's (it was Rob, right?) suggestion appears to be a viable fallback.
The Independent Stream does not require IETF rough consensus, although
it is not an automatic bypass: the authors and ISE would have to pursue
it, and the IESG would still conduct the RFC 5742 conflict review
[0][1]. I note that the authors have largely not engaged in discussion.

> I swear I've seen arguments that users of RFCs don't really 
> understand these subtle differences in track and editor queues,
> that they take any RFC as a 'standard'.

Yes. Many readers treat any RFC number as a standard despite the stream
boilerplate. That is a real drawback, but it is also why the distinction
matters for _us_: Independent Stream publication would not assert IETF
consensus. In practice, I suspect very few outside of the IETF would
care about the distinction. It would allow us to provide clarity when
the matter is raised.

I still prefer resolving the issues in the working group. I am not
opposed to publication; I am trying to identify text that makes
publication responsible.

>>> What you're really litigating is a social death penalty for the 
>>> NSA -- something we *could* do, but shouldn't.  We really, 
>>> really shouldn't do that for at least several reasons, such as:
>> 
>> You may be surprised but I very strongly agree with you. We should
>> not litigate a social death penalty. I do not advocate for 
>> removing Deb from the IETF. No one should be harassing her. No one
>> should be making threats. No one should be giving her a hard time.
>> No one should be mocking her on social media. No one should be
>> sending threatening or slanderous or libelous emails.
> 
> It's not just the invectives against Deb.  It's also the invectives 
> against the I-D authors and those who have voiced support for the I-
> D.

I extend that to everyone: Deb, the authors, supporters, opponents,
and other participants. We need more technical communication, not
threats, harassment, ostracism, or censorship.

I have received several reports of troubling off-list conduct. That
should be handled through the appropriate conduct process rather than
mixed into the technical disposition of the drafts. It is unclear to me
if those reports will by sent by those persons to the IETF out of
(expressed to me) fear of retaliation.

> The incessant urging to not publish anything that might be tainted 
> by the NSA *is* very much akin to a social death penalty for the 
> NSA.

I do not oppose publication because NSA personnel were involved.

The immediate concern is a documented NIST design decision: FIPS 203
removed Kyber's `m <- H(m)` step, whose stated purpose was protection
against flawed randomness, because FIPS 203 requires approved randomness
generation [2][3]. The question is whether IETF documents should repeat
that assumption silently or not, describe and explain the peer-
recoverable value, and preserve a cheap local safeguard for deployments
that do not satisfy the full FIPS model.

It is indisputable that NIST removed the hash over `m`, ignored all
pushback, ignored official comments on the matter, and unrelated to much
of the discussion they then also declared that non FIPS-certified
settings are expected to simply fail catastrophically if the RNG has an
issue. So you see, removing the hash and qualatatively weakening the
design of Kyber, they assert is fine. That they accept this outcome and
state that they are correct was explictly stated by NIST on this very
list. They additionally also push this without a hybrid construction,
also over the express concerns of the authors of Kyber. Those two things
together and my ability to exploit ML-KEM in the Dual_EC_DRBG setting
correctly raise eyebrows.

NSA involvement is relevant historical context, but it is not a social
veto. NIST is not the final technical authority for the IETF, any more
than BSI, CSE, ETSI, ISO, IEEE, or a corporation would be. Former NIST
people dropping by to argue that the world should adopt their public
security posture is unreasonable. They have a traditionally had the
Suite A and Suite B security postures and we're being offered the B
option by another name, again. The IETF should have a stronger security
posture and wihtout being in a FIPS-certified setting. The same
scrutiny should apply to every source: examine the design, assumptions,
evidence, and consequences for the end user.

The still-incomplete public record concerning NIST/NSA coordination and
the answers given in this discussion make careful review more, not less,
appropriate. I would also welcome explicit clarification of the IPR
position, although the current drafts do not resolve it.

Comments that are not made by NIST have not brought clarity because any
such analysis carries no weight about NIST's actual position. If NIST
makes clear that we are free to hash `m` and retain the IPR waiver, we
would be able to resolve the issue of excess authority preventing a
stronger security posture, if it is desired. Do you see that they are
unwilling to bring this clarity? If they were gagged as John Kelsey was,
I would expect that bringing this clarity would be out of bounds. NIST
is free to say otherwise and what they did say on the matter is
contridicted by the public record. It could be credibly explained but
NIST did not deem it worthy of their time.

The American cliché "good enough for government" is the phrase that 
comes to mind here. Is that good enough for the IETF? No, it is not.

>> People should *especially* not be punished for the worst thing 
>> they are suspected of doing, and especially if they did not do it.
>> 
>> Even if they are guilty, they deserve a chance at redemption.
>> 
>> Everyone deserves a fair shot at re-integration.
> 
> For those who say TL;DR, the summary is that: IMO the ML-KEM I-D - 
> and all I-Ds specifying KEMs- should normatively state which DRBGs 
> are acceptable, and they should include informative text about the 
> unfortunate risk of RNG-based kleptography when using KEMs outside 
> DH hybrids.

I broadly agree, with the qualification if 'acceptable' is stated as a
'MUST' or a 'requirement imposed by NIST to achieve security' and that a
hybrid does not help if both components depend on the same recovered RBG
lineage.

> Ok then, here's my take:
> 
> * Ideally we should have a practical, strong PQ Diffie-Hellman.  We 
> do not. I agree in the strongest terms. Practical post-quantum 
> constructions with genuine Diffie-Hellman-like contributory
> behavior remain an important research goal.

MIKE seems interesting but I have not analyzed it, evaluated it, used an
implementation in a deployment.

CTIDH is somewhat more familar to me and while there is literature that
is relevant for the security in the quantum setting, I find it to be
extremely promising.

CTIDH and related commutative group-action work are interesting in that
respect. I help maintain an implementation released by an academic
group, but I did not design CTIDH and make no claim that it is ready to
replace standardized KEMs. In my own experimental use I combine it with
X25519.

More generally, I would not deploy a comparatively young post-quantum
construction without an independently generated classical component
today. On balance I have decided that in at least two protocol withs no
other PQC option available, a hybrid X25519 and CTIDH-512 or CTIDH-1024
were better than X25519 alone. This protects against CTIDH failures
today, and hedges against a future with quantum computers.

> * All KEMs are going to have this `m` problem in some fashion.  Is 
> that a correct statement?  That makes all of them suitable for RNG- 
> based kleptography. I do not think that all KEMs necessarily have 
> the same problem. We need a precise property: can an adversarial 
> recipient recover an unchanged, sufficiently large, ordered sample 
> of the sender's RBG output?

ML-KEM clearly exposes that shape in the most risky way possible and it
is unnecessary risk. To recap before we en-and-de-cap: `ML-KEM.Encaps`
samples a 32-byte `m`, and a decapsulating peer that controls its
implementation can retain the reconstructed `m'`. Third-round Kyber
instead hashed `m` before using it [2][3]. Other KEMs and their uses
have to be analyzed construction by construction; a ciphertext carrying
a recoverable secret is not necessarily carrying raw generator bytes.

In addition to Kyber where everything is essentially equal except the
hash in our discussion, sntrup761 is a useful contrast. It uses a
structured fixed-weight ternary polynomial `r`, not a raw 32-byte `m`.
In the reference sampler, many 32-bit random words are masked, sorted,
and mapped into the ternary polynomial before `r` is used, and the
shared key is derived by hashing its encoding [4]. The recipient can
recover `r`, but `r` is not an unchanged contiguous generator block. The
difference is extremely stark.

That does not prove immunity to every malicious or specially shaped
RBG. It means only that the direct ML-KEM argument does not transfer
unchanged. I made a preliminary attempt to recover a Dual_EC_DRBG block
through this sampler and did not succeed. I would welcome a better
analysis, especially from the sntrup761 authors: do you see a practical
method for reconstructing a full Dual_EC output block from the existing
fixed-weight sampler? The sntrup761 authors and implementations could
also hash the RNG as Kyber did to make the comparison even easier.
Regardless, NIST and a couple of other people may discuss the
construction of `m` and KEMs in a way that would lead a reasonable
person to believe a KEM always has this issue. However, it is simply not
true. A KEM does not imply an `m`  must be composed of contiguous sample
of the system RNG without transformation, otherwise. It is misleading
and it is dangerous as I have shown with Dual_EC_DRBG as an example. In
TLS this can lead to decryption of the connection, and future sessions.
This is acceptable to NIST, and it should not be to the IETF.

This difference is one reason I remain comfortable with sntrup761x25519
as a conservative OpenSSH option. The ML-KEM SSH exchange, like TLS,
gives an unauthenticated client an opportunity to supply the
encapsulation key and recover the server-generated `m` pre-auth; the
actual risk still depends on the implementation's RBG, state separation,
and generation order. This is a kind of landmine where it increases
analysis work and where implementations may get it wrong. It is not the
conservative choice that I would expect from the professionally prudent
securtiy minds that brought us OpenBSD and OpenSSH.

It however entirely makes sense if OpenSSH needs to provide ML-KEM. I
hope that they will ensure that `m` is hashed in practice but if not, it
only further underscores why the NIST's decision process and their
conclusion is unreasonable. OpenSSH is not only used in a FIPS-certified
setting, and I highly doubt that NIST will promote the various DRBGs
used by GNU/Linux, FreeBSD, NetBSD, and OpenBSD as qualified designs. I
would welcome it as long as they did not impose unreasonable changes as
they did with Kyber for `m` since those designs are what the world uses.

> For this reason I think we should have no RECOMMENDED=Y non-hybrid 
> KEMs.  But I don't see why not have RECOMMENDED=N KEMs.
> Interesting. I support hybrids as the conservative default, but the
> hybrid label alone is not sufficient for this issue.

If the ML-KEM interaction permits recovery of an RBG state before the
same state lineage generates the X25519 scalar, both components may be
predictable. If the X25519 scalar was generated first and the RBG
resists backtracking, that component may remain independent. Reseeding,
per-connection state, buffering, and call order all matter.

A compact version of my current classification is therefore:

scheme       recoverable value            raw RBG block?
ML-KEM       32-byte `m`                   yes
Kyber r3     `H(m)`                        no
sntrup761    fixed-weight ternary `r`      no

That table is deliberately narrow. I would not label every randomized
signature, OAEP seed, DH exponent, or structured KEM secret as a "raw
leak" merely because it depends on randomness; the transformation and
recoverability must be analyzed. I have done most of that analysis on
other IETF primitives but that is for a different email.

> * TLS 1.3 has insanely large nonces ('random'), and that's enough 
> for RNG-based kleptography.

Agreed. TLS `Random` fields already create a broader public-output
problem, and I regret not addressing it while TLS 1.3 was being written.
I am preparing separate work on public and peer-recoverable RBG outputs
across TLS, QUIC, MLS, SSH, IKE, and other protocols. That broader work
should not prevent fixing an additional clean oracle now.

> therefore ML-KEM adds nothing much new *except* that when using a 
> FIPS-140-3 validated module then ML-KEM can sneak a Dual_EC-style 
> DRBG in through the back door even when the TLS 1.3 implementation 
> would not otherwise use such a DRBG.

The word "except" is doing substantial work in your sentence. ML-KEM can
expose an additional sample of the randomness used for secret generation
even when an implementation separates or conditions other TLS-visible
fields.

A successful sabotage mechanism should be reliable, economical, and
plausibly deniable. The protocol should not make that job easier when a
wire-compatible hash removes the direct structured sample.

> * We can insist that the choice of DRBG to use MUST be one of a set 
> we approve of, and, impliedly, none of the ones we don't approve of.
> Agreed in principle. We should state the actual requirement rather
> than invent combined algorithm names. FIPS 203 requires fresh
> randomness from an approved RBG, with the required security 
> strength, under the SP 800-90 framework [2]. Hash_DRBG, HMAC_DRBG, 
> and CTR_DRBG are the SP 800-90A mechanisms, but the requirement
> also includes the entropy source and construction requirements in
> SP 800-90B and SP 800-90C.

I would then state the separate `m` issue. The approved-RBG requirement
is the primary layer; hashing `m` is a local layer that prevents this
consumer from returning algebraically structured output to a peer when
the primary assumption fails.

NIST and some of the IETF, such as myself, appear to have different risk
tolerances on that point. NIST has publicly acknowledged the limited
claim: hashing protected the KEM, while a broken RBG could still
compromise the wider system. That is not an argument that the KEM-level
protection has zero value but NIST agreeing that it has value, and that
it is not valuable to _them_. Okay! I am glad that they did not present
an attack as their original motivation to remove the hash. It is not a
security issue to have the hash. It is good that we do not disagree on
that point. The performance was also not a relevant concern. Their
expressed concern is how they logically separate things in a FIPS-
certified setting, and outside of that setting, they qualatiatively
weakened the design and accept the consequences. This tells us their
security posture, and it is less than the IETF should accept. These
kinds of "logical" separations are how we had IPsec failures with
Dual_EC_DRBG on the internet that allowed for full passive decryption
through nonce leakage. This was reportedly exploited by the NSA and it
is not in dispute. Juniper engineers probably deeply regret being
tricked by that kind of mistaken protocol and implementation design.

The public record concerning NIST/NSA coordination is, and remains,
incomplete. Materials produced through litigation appear relevant to
statements made during this discussion. My understanding is that the
litagion is ongoing and that production of documented related to NIST/
NSA collaboration remains unfinished. I do not need to resolve that
institutional history in this email. I do think NIST should answer
concrete questions and publish enough of the record for independent
evaluation. We could also wait for the lawsuit to finish but that is 
likely to take a long time, so NIST could really help speed things up by 
either stating their intention to 1) immediately and proactively produce 
the documents in question and/or 2) directly engage here with the 
understanding that if the documents later contridict them, they will be 
on the hook. Both of those seem incredibly unlikely and that is why an 
independent court has been involved to _force_ NIST to produce the facts.

Does it not concern you that the facts _already_ produced in that 
lawsuit do not match the claims made by NIST on this very list?

If not, what would be the line for you? I ask so that when the lawsuit 
is finished, we may do a proper retrospective analysis.

> The AES counter DRBG is plenty good enough. Which implementation?

CTR_DRBG can be a sound construction, but naming it does not guarantee a
side-channel-resistant implementation. Cohney et al. demonstrated cache-
based recovery against vulnerable table-based AES CTR_DRBG code in SGX,
including state recovery, loss of forward security, and an end-to-end 
TLS compromise [5]. This was an implementation attack, not a universal 
break of CTR_DRBG. These kinds of failures are possible because NIST's 
standards are below the security and the quality of the IETF's 
standards. There are examples worth considering such as the constraints 
described in NIST SP 800-90a.

The distinction matters. FIPS 197 specifies AES, but does not by itself
require a constant-time implementation or test for secret-indexed table
lookups. SP 800-90A specifies the DRBG construction, but cannot make a
leaky AES implementation safe. Hardware instructions can reduce this
particular risk, while introducing their own hardware and microcode
assumptions. Would you believe that one of the findings in [5] as 
presented in 2020 ( https://rwc.iacr.org/2020/slides/Cohney.pdf ) 
included an OpenSSL FIPS module, the NetBSD kernel systemwide PRG (!), 
mbedTLS _inside_ SGX, and also the nist_rng library. That includes a 
FIPS-certified setting. Perhaps the FIPS-certified setting is not as 
strong as the NIST advertising would have us believe?

NIST has not updated the corresponding standards in response to the 
publication [5] as far as I am aware. I am happy to be corrected on this 
point but if even NIST is able to get it right, maybe we should consider 
this as a factor in their security posture?

I want to note as a matter of honesty that here, hashing `m` does not 
save a system after the attacker has extracted the CTR_DRBG key; the 
attacker can reproduce the hash. It does, however, address a different 
failure class: algebraic structure in output that is otherwise handed 
directly to the peer. Therefore the correct guidance is not "CTR_DRBG is 
broken" or "the hash fixes everything." It is:

* exclude Dual_EC_DRBG and analogous structured generators;
* require a securely implemented, prediction-resistant RBG;
* require side-channel-resistant primitives and sound reseeding/state
   management;
* retain the local hash to avoid exporting raw structure;
* even NIST's standards and certified FIPS modules get this wrong;
* NIST updated their threat model in 2019;
* NIST did not update the actual standards to require safe defaults!

The longer document should review Hash_DRBG, HMAC_DRBG, and CTR_DRBG,
including side channels, fault attacks, entropy failure, reseeding, and
state compromise, rather than treating an approved algorithm name as an
implementation proof. The authors of [5] note that CTR_DRBG is not 
provably secure, they note that Woodage and Shumow found problems with 
HMAC_DRBG, and they encourage the use of Hash_DRBG.

Note that the authors in addition to the "Dual_EC Backdoor" they raise 
the "Juniper Dual_EC Incident" they also raise the DUHK Attack on ANSI 
X9.31.

So - lets recap that into some conclusions:
- No: Dual_EC_DRBG (withdrawn (!))
- No: CTR_DRBG (FIPS certifiable (!!) does not mean not exploitable)
- No: HMAC_DRBG (see Woodage and Shumow's related work, and others)

Meanwhile, NIST says they are working on an updated SP 800-90A where 
they announced a comment period ( 
https://csrc.nist.gov/pubs/sp/800/90/a/r2/iprd ) which closed in late 2025:

   Date Published: September 4, 2025
   Comments Due: November 4, 2025 (public comment period is CLOSED)

Aside from the absurdly short comment period, NIST says that public 
comments will be posted after the closing date. Nearly a year later, 
that statement remains true as someday they may be posted. As of today, 
the public comments have not been posted as far as I am aware.

Do you want to make a prediction about Hash_DRBG?

> This, however, may run into a problem where FIPS-140-3 validated 
> cryptographic modules might not be configurable as to DRBG choice. 
> However, it is enough to state this requirement.  We do not have a 
> Protocol Police function.

Agreed. Accurately summarizing the NIST requirement and adding the
right cross-references is sufficient for that part of the issue.

> * As long as there is one acceptable DRBG that can be selected, we 
> can state a normative requirement and give useful advice regarding 
> the dangers of RNG-based kleptography.

Agreed. I would list the approved constructions as examples, state
the required properties, and explain the kleptographic failure mode.

> * I do suspect that all KEMs enable Dual_EC-style kleptography. And 
> yet ML-KEM should be published.  Not because that's a good thing, 
> but because -once more- the horse left the barn when the nonces 
> (`Random`) were made more than large enough and when the codepoint 
> registries were made Specification Required. I do not think the 
> general conclusion about all KEMs follows, but I also do not think 
> this is a reason to withhold ML-KEM indefinitely. My request 
> concerns an avoidable, wire-compatible footgun and accurate
> Security Considerations, not ML-KEM's lattice hardness assumptions.

> But also I'd have to see how recovering *one* `m` value would allow 
> a kleptographer to steal *many* other clients' `m` values.

For Dual_EC_DRBG, the result depends on truncation and state
management. With an untruncated 32-byte output, one `m` may be enough 
for the trapdoor holder to recover the next state. With the standardized
P-256 truncation, the attacker normally enumerates the missing bits and
uses another output or other state information to identify the correct
candidate [8]. Once a long-lived shared state is recovered, later
outputs may be predicted until reseeding or separation defeats
synchronization.

Or put simply: you draw 32 bytes from the sabotaged RNG, you transmit 
it, you then draw 32 more bytes.

An adversary with the Dual_EC_DRBG trapdoor/secretkey(s) that receives 
your first 32 bytes is able to predict the 32 bytes of the second draw, 
even if you do not send them.

Would you like me to send you an implementation of this where you 
control the trapdoor/secretkey(s)?

> * The large size of `Random` is still problematic.

Agreed. I call these public or peer-recoverable wire oracles. TLS 1.1,
1.2, and 1.3 all expose large `Random` fields, and other protocols can 
inherit related risks through TLS or their own public randomness.

My broader survey remains preliminary because implementation choices,
state sharing, sequencing, and authentication phase change the answer.
If this attack class is deployed, however, the strategic value for mass
collection and real-time decryption could be substantial.

> [Heavy trimming follows.]

Thank you for tolerating my verbosity. I will try to return the favor.

>>> * If the NSA wants to get burned again by playing the Dual_EC 
>>> game again, let them!
>> 
>> This is frankly, reckless. We should not be used unwittingly or be
>> party to such folly.
> 
> My personal advice: sometimes that is the smart play -- if you never
> engage in tactical retreats thus badly losing some battles, you'll
> exhaust yourself and lose the war.

I take the advice. My claim here is bounded: we should learn from
Dual_EC_DRBG and treat it as the canonical public example of strategic
cryptographic sabotage. The tactical compromise I can support is to
publish after adding accurate RBG requirements and the `m` guidance,
while moving the larger analysis to separate work.

I am exhausted, but that is another reason to turn the dispute into
specific text rather than continue repeating it.

>>> * The NSA is not likely the monolith a social death penalty for 
>>> it would have to presume.
>> 
>> I do not understand this point but I agree that the NSA is not a 
>> monolith. Part of asking the questions that I asked is that there 
>> are NSA people I have directly spoken to who answered almost all 
>> of those questions without a problem. I am not only talking about 
>> whistleblowers but people whose job never involved cryptographic 
>> sabotage.
> 
> But you and/or others in these threads are treating all involved 
> with NSA in regards to ML-KEM as monolithically motivated by the 
> same interest in kleptography.  That amounts to treating the NSA as 
> a monolith.  "It's supported by NSA pEoPlE!!" is basically the 
> backup singers' line.

Thank you for clarifying. I do not infer a common motive from NSA
affiliation, nor do I want an institutional blacklist. I would apply the
same skepticism to Edward Snowden, Bill Binney, Thomas Drake, an NSA
engineer, a NIST employee, a defense contractor, or an independent
academic: examine what they propose, what assumptions they bring, how
they answer questions, and what outcomes their position produces. Most 
of all, I would want to examine their security posture.

Institutional background can still be relevant without making the
institution a monolith. People with access to classified systems may
know constraints or attacks that they cannot describe publicly. That can
create blind spots even without malicious intent. Suite A is the obvious
example: public reviewers cannot reason from secret knowledge they do 
not possess, and a person who possesses it may be unable to explain why 
or even _that_ a public design is unsafe.

Furthermore, they may feel that even if they _could_ do so, they do not 
agree with thwarting large-scale adversaries if it would thwart their 
favorite, civil-liberties respecting, honest, law-abiding, large-scale 
adversary... who they consider more as a friend in any case.

The solution is not personal exclusion. It is transparent threat models,
conflict disclosure where applicable, independent review, explicit
assumptions, and technical mitigations that do not depend on trusting a
person's institutional role. It is also important to look at the 
results. NIST's modified Kyber grants a cryptographic oracle in over a 
dozen protocols where the protocols are layered.

Example: your Signal client uses ML-KEM in TLS, and again in the Signal 
e2ee ratchet. Neither are required to be FIPS-certified, to put it mildly.

My own principle is simple: I will not support cryptographic sabotage or
an accommodation designed to preserve it or that allows for it as an 
acceptable consequence of an imposed change against the express wishes 
of the cryptographic primitive's designer(s). I will support technically
sound protections even when they protect people or institutions hostile
to me. RFC 7258 says pervasive monitoring is an attack; the relevant 
IETF value is to reduce harm to the end user [12].

>>> * There is no technical content regarding ML-KEM to back this 
>>> up.
>> 
>> I could easily believe that you were aware of these issues before 
>> the discussions on this list. Were you?
> 
> Some of them.

Agreed. As exhausting as it has been, the discussion has produced a
clearer technical record and some real convergence.
>> For example, were you aware that you could do this kind of thing, 
>> including recovering `m`?
> 
> I believe my earlier response (and the above) should make it clear 
> that I am.  Above is a fuller treatment of this issue.


Yes, now it is clearer. I was asking about before the discussion
because the point is subtle and was absent from the drafts' Security
Considerations and from several early responses. That suggests a gap in
our protocol-analysis process worth fixing.
>> Do you think that the removal of a hash function to enable it is 
>> not "technical content" when that single design choice was made 
>> exactly to counter this kind of thing?
> 
> Not sufficient to stop publication.  Instead it is sufficient to 
> argue that the choice of DRBG must be limited.


Then we agree that it is technical content. I am not asking for 
nonpublication as an end in itself. If the DRBG restriction includes the 
reason for it, the recoverability of `m`, and the Appendix C.1 tradeoff, 
we are close to agreement.
>> Are you really buying the argument from NIST where they made it 
>> worse and accept that as a fact, over what, ~300-1500 cycles?
> 
> With a non-kleptographic DRBG it seems fine. 

Does that still hold with the cited research showing that the current 
(not even including Dual_EC_DRBG!) NIST DRBG have non-trivial security 
failures?

Does it concern you at all that a practical full state recovery over the 
network against TLS was shown for CTR_DRBG in a FIPS-certified setting 
and NIST has so far only updated their _threat model_? If the authors 
did not catch that two month call for comments _five years later_, will 
NIST even address these issues?

Regardless, as of now, it does not seem fine to me. Updating the threat 
model is absolutely hilarious, I am sure that is very reassuring to 
impacted parties.

> I agree that the risk 
> of inserting a kleptographic DRBG is real, but not publishing is not
> really a good answer.


We agree that the kleptographic-RBG risk is real, and I agree that
nonpublication is not the only answer.

I still would not call the unhashed design equally safe. It is
qualitatively weaker than the same construction with one additional
hash because it relies entirely on the RBG and its implementation. The
hash was present specifically to tolerate one class of upstream failure.

CTR_DRBG illustrates the distinction between an algorithm and a deployed
system. The Cohney et al. work used cache leakage in a vulnerable AES
implementation to recover DRBG state and compromise TLS [5]. That does
not show that CTR_DRBG is kleptographic, but it does show that "use an
approved DRBG" is incomplete implementation guidance. Similar questions
exist for Hash_DRBG and HMAC_DRBG. What the relevant research literature
says about side channels, fault injection, entropy failure, reseeding, 
(RNG) state compromise, and malicious implementation all deserve
systematic analysis.

We should define the attack classes carefully. Young and Yung's SETUP
model is a natural starting point for deliberate kleptography, while
side-channel and fault attacks may belong in adjacent categories. The
engineering response can still be systematic:

* write down each attack strategy and the required capabilities;
* distinguish design, implementation, supply-chain, and compulsion
   failures;
* test whether each construction and implementation resists it;
* record mitigations and residual risk; and
* set a minimum profile for protocol use.

Hardware acceleration is not a magic boundary. AES instructions, RDRAND,
and SHA extensions reduce some software-side channels but add
assumptions about hardware, microcode, firmware signing, and update 
channels. Those assumptions can fail through ordinary bugs or 
sophisticated compromise.

The point is not that every extreme scenario is occurring; it is that
protocol guidance should not confuse a standardized algorithm with an
immutable, side-channel-free implementation. Also, IETF should not push 
a standard that requires FIPS-certified setting as a general matter when 
the general case was made weaker and imposed a new dependency to acheive 
security: the FIPS-certified setting!

I have preliminary experiments in which an ML-KEM interaction supplies a
useful observation point against a deliberately vulnerable table-based
CTR_DRBG implementation. I do not present that as a general break or a
finished result. The research from 2019/2020 still generally applies.

The immediate conclusion remains modest: require a defensible RBG,
require secure implementation and state management, and hash `m` so this
particular peer interface does not export raw structure. The longer-term
work can determine what additional requirements are needed for each
SP 800-90 construction.

Also just to restate the obvious: we are really discussing some text in 
a text file that is _advice_ to implemnters who are not building in a 
NIST-certified setting. Those implementers better understand the 
situation and are required to diligently follow NIST's standards. Yes, 
that still leads to certified implementations being broken in some cases 
and that is _also_ NIST's problem, not the core concern that we face.

>>> There is only the 1DES key weakening and the Dual_EC adventure,
>> 
>> This is not a fair or accurate accounting of the history. Even if 
>> you skip the Clipper Chip, export cryptography and all related 
>> attacks in SSL/TLS, and many other related matters, the issue of 
>> Dual_EC_DRBG amazingly *still* ships today in one of the most 
>> popular Java libraries in the world. It also ships ML-KEM. We 
>> agree about 1DES, of course.
> 
> Clipper was an overt attack on the public. There are at least two 
> distinct issues.

Clipper was an overt policy attack, but policy opposition was not the
whole story.

 From memory, Prof. Dr. Matt Blaze had to find a novel technical failure 
in the Escrowed Encryption Standard: the 16-bit LEAF authentication 
check could be searched so that a device retained strong Skipjack 
encryption while bypassing the escrow mechanism [9]. This was not a 
cryptanalytic break of Skipjack itself; it was a break of the key-escrow 
protocol surrounding it. That distinction strengthens, rather than 
weakens, the lesson that expert technical review can defeat a 
government-mandated access design. Skipjack itself followed the 1DES 
pattern with the 80-bit key and 64 bit block choices by the way.

> The 512-bit modular DH group precomputation thing was not a covert 
> attack on the standards process.

It is not only about 512-bit DH, of course.

I understand the perspective that export controls and weak 512-bit 
groups were not, by themselves, covert manipulation of the standards 
process.

Noteworthy however is that "covert" depends on a lot of assumptions 
about people's understanding of what certain technical framing means in 
a given context. The GSM cryptographic weaknesses may well have been 
understood by some telecom technician but most non-technical users of 
the phones most certainly did not always understand.

They were nevertheless policy-created weaknesses whose practical 
consequences were not understood by most users of products marketed as 
secure. We should classify the history precisely without minimizing the 
harm.

> Perhaps only Dual_EC was a covert attack on the standards process.

I do not think Dual_EC_DRBG exhausts the documented history of
SIGINT enabling or weakened communications standards.

GSM is one example. TETRA is another important case: the secret TEA1 
algorithm,  used in critical-communications systems, reduced an 
advertised 80- bit key to 32 effective bits and was only publicly 
understood after reverse engineering [10]. The researchers did not 
establish who inserted the weakening or whether it was exploited, but 
the result is directly relevant to how we evaluate secret or nationally
constrained cryptographic designs. TETRA is highly relevant to European 
security.
> ML-KEM might be a covert attack, but not on the standards process 
> because the codepoints were always going to be assigned, and of 
> course we're discussing the possibility that ML-KEM is kleptography 
> so much that everyone who needs to know that it could be, does.

The public, undeniable fact is that FIPS 203 removed the hash that
Kyber said protected against flawed randomness [2][3]. I am not claiming
that ML-KEM is itself a covert attack. I am saying that the change opens
a direct hidden-structure failure mode and that an approved algorithm
name does not eliminate implementation or side-channel risk and that is 
when we are speaking about the FIPS-certified setting. Outside of that 
NIST's change makes our lives harder which is not something that we are 
required to accept and to pass on to others. The NetBSD kernel wide DRBG 
CTR_DRBG example from [5] was impressive.

> Clipper being an overt attack, and ML-KEM maybe a covert attack, you
> can see that Clipper would be easier to defeat -- the whole public
> could see it.

Agreed: the removal is not covert. Appendix C.1 records it. The
technical effect is also public: relative to third-round Kyber, ML-KEM
no longer has that local safeguard against flawed randomness. Experts
therefore have a responsibility to explain the tradeoff and the
assumption that replaced it.

>>> And again, if your fears turn out to be true, then you win a big
>>> prize: more egg on the NSA's face.
>> 
>> This does not follow. It took over a decade for John Kelsey to 
>> come out with his public apology tour. It only happened because 
>> one person blew the whistle and essentially killed himself for us 
>> to know about it.
> 
> But the egg landed on their face much earlier.  Apologies and non- 
> apologies are merely the acknowledgement

Agreed that the reputational damage began earlier but it was also
paid in disrespect to people who raised the findings as a concern.
That pattern repeats here as a variation on the theme but this time,
the attack may be a fact to some but now instead of being in doubt,
it is dismissed as old news or as irrelevent or unexploitable, and so on.

The important point is not whether an institution eventually apologizes; 
it is how long users remain exposed before the technical problem is 
acknowledged and fixed. Shumow and Ferguson's 2007 rump-session 
observation, and Blaze's Clipper work, are reminders that early warnings 
deserve serious technical treatment.
>>> Thus I don't think there is anything we can do regarding `m` 
>>> other than give advice for non-FIPS implementations -- perhaps 
>>> we should do that much,
>> 
>> That sounds like the discussions have moved you!
> 
> Then you might like the above.  Except you might not because it 
> doesn't move the needle as much as you seem to want.

I will take the movement and thank you for several intense but useful
days of discussion.

>>> but that seems like something TLS and IETF should say much more 
>>> generally in a BCP rather than in each Internet protocol RFC 
>>> that somehow needs RNGs.
>> 
>> Or maybe, not? I guess I also agree with you that we need a draft 
>> about the overall issue. Would you be interested in co-authoring 
>> such a draft?
> 
> I cannot easily co-author I-Ds [for reasons], not with celerity.  I 
> can comment and suggest text.

Thank you. Comments and suggested text would be genuinely useful; I
could take responsibility for an updated draft but I think the draft 
authors should resolve the outstanding technical issues that they see as 
valid. That tells us about the security posture that they wish to 
advance in the IETF. That applies _equally_ to the hybrid and the pure 
ML-KEM drafts.

>>> * You and others are destroying your credibility and good will 
>>> towards yourselves and towards the IETF by really reaching in 
>>> your arguments against ML-KEM.
>> 
>> That is a fair point. [...]
> 
> That sounds like the discussions have moved you as well :)

Yes. The discussion has moved me toward a narrower, more actionable
position where now I see that NIST's current DRBG offerings are 
_exceeding dangerous_ in the TLS context. Simply presenting them
without qualification seriously misrepresents the risks as a general
solution. I remain concerned that credibility and tone sometimes
displace technical disposition, but I should also make my own arguments 
easier to assess and harder to dismiss.

>> I observed an intense desire for conformity and harmonization in 
>> the form of a popularity contest. There are a few people in the 
>> discussion who broke through that wall. Quite a few people 
>> demonstrated that when it came down to a factual point that they 
>> have a duty to the truth. I personally respect that a lot more 
>> than the parasocial shaming behavior and the foot dragging.
> 
> Last October I was on DJB's side.  His pounding the table got me to 
> abandon that side -- there were no real arguments other than 
> "they've done it before" and "of course they'd do it again".  Now 
> there's the `m` matter, and regarding that see the above.

The cases for and against pure PQC and hybrids are broader than those
two slogans. I also understand why perceptions of repetitive or abrasive 
presentation can cause readers to disengage. This is in part a big
structural failing of the NIST process and it is a problem in the IETF
as well.

At the same time, process cannot substitute reaction to style for a
technical disposition. NIST's participation raised factual questions
about the history and rationale of the change, and the answers did not
resolve all of them. My earlier comments also waited years for a partial
response. That history helps explain the frustration, although it does
not excuse unnecessary heat from any participant.

I will focus this reply on the concrete convergence: define the RBG
requirements, explain `m`, record the Kyber/FIPS change, and state the
mitigation.

> I really want to emphasize that DJB's manner of argument is a 
> tremendous turn-off.


I hear you. It should not determine whether a reproducible technical
claim is true. The working group needs both professional communication 
and a process that tracks substantive objections to a clear disposition.
>> We should still try to do good things for the betterment of all 
>> people, even if they're unappreciative.
> 
> Some people, when faced with a difficult war, choose a hill to die 
> on, then die on it.  Others fight until it's time to retreat to live
> to fight another day.  Martyrs don't win wars.
I understand. The useful response is not martyrdom but converting the
issue into durable text and reproducible work. While it remains in our
power, we should endeavor to create that centered around the End User's 
security. The End User that is not in the FIPS-certified setting 
especially as NIST has the FIPS-certified setting covered. It does not 
exactly inspire confidence that in the FIPS-certified setting the 
certified CTR_DRBG could be exploited to remotely extract the CTR_DRBG 
AES keys over a network through TLS. They have it covered alright! That 
security posture is their choice.

>> This mistake by NIST should be undone in so much as we should not 
>> go along with something when the research data shows that it is 
>> dangerous.
> 
> Look at it from NIST's point of view: that hash merely extends the 
> DRBG, and via FIPS they mandate DRBGs, so if the hash is important 
> then it should be included in the DRBG or the DRBG should be 
> designed so it's not needed because the DRBG is not necessary.

I understand that position. But a protocol-level hash is not merely
"more DRBG." It enforces a property at a separate boundary: the peer
receives `H(x)` rather than the DRBG output `x`. That matters precisely
when the upstream RBG assumption fails, and not every TLS deployment is
inside the FIPS validation model.

> Thus my [new] position is that we should limit the set of acceptable
> DRBGs. 

We may agree on limiting acceptable RBGs if phrased as NIST's 
requirements that must be imposed to acheive their notion of security.
Because approved construction names do not by themselves guarantee a
safe implementation, I would add implementation guidance here and
develop the broader requirements in a separate document. I was shocked
when I realized that the literature piles up but the FIPS standards do 
not keep pace, rather the _threat model_ is updated! TLS should become 
stronger and stronger as we learn new things, and the threat model 
should become _stronger_ as adversary capabilities improve. The purpose 
of TLS is to provide _security_ not a false sense of security, after all.
>> Yes, I understand the criticism that this appears to be contrived 
>> because you do not use /dev/hwrng or similar interfaces but I 
>> wonder what would change your mind?
> 
> The `m` issue did change my mind, as you noted.  Just not to the 
> point of opposing publication.  Rather, I propose normatively 
> limiting the choice of DRBGs to ones we believe are not 
> kleptographic.

I do not oppose publication once the immediate issues are written down
or referenced accurately.

>> For example, the Cavium SIGINT enabling - Cavium has a kernel 
>> driver for their hwrng and it presents as /dev/hwrng which does 
>> not transform the output. This kind of CPU is used in "security" 
>> devices.
>> 
>> Please consider that NSA claims it as a SIGINT Enabling Success.
> 
> If you have a TLA-in-the-box attack, you have bigger problems.  And 
> by you I mean we, naturally.

My question is whether "if" is the right prior and what evidence would
change it.

The Cavium reporting shows a knowledge-and-choice problem: users may 
rely on hardware and firmware they cannot meaningfully audit, and 
hardware RNG interfaces can feed operating-system entropy pools or be 
consumed directly. A compromised source is a system-wide problem, but 
that is not a reason to remove cheap local barriers at protocol 
boundaries. The reason for the removal is not required for security and
it re-introduces an entire class of security failures. Some large-scale 
deployments could easily remove that hash and no one will know, so in my 
view those kinds of deployments should not impose their extreme 
privilege on the rest of us. Most people, unlike the large defense 
contractors who mentioned hashing was going to impact their bottom line 
or the environment, do not have thousands of engineers working from the 
top to the bottom on their systems. Most people do not have absolute 
confidence in their full computing systems, they must make assumptions 
about trust which will change in a big way with this PQC transition.

>> Would you believe that someone does the wrong thing with that kind
>> of stack and does so in a way that harms security?
> 
> Certainly possible, even likely.

I am glad we agree.

>>> * We know they will go to IEEE if we don't publish.  IETF is 
>>> much more open, so if we abdicate our remit to more closed SDOs,
>>> what will you have achieved with this social death penalty?
>> 
>> I do not understand this part - the draft can go to the ISE if 
>> consensus can't be reached. Deb should not be pushed out of the 
>> IETF, and no one should be ostracizing her. This holds for anyone 
>> in these discussions, even convicted felons.
> 
> See above (at the very top).

Understood.

>> That said - if the authors of the draft want to take it elsewhere 
>> and publish it, especially because the WG won't rubberstamp 
>> something and want to add some basic security considerations, I 
>> would say that is their right. I note that they are welcome to 
>> integrate the text and then I think most objections would be 
>> handled. Most of us can't edit the draft by merging a pull 
>> request. I have the sneaking suspicion that that if I open the 
>> pull request that it would not be merged. If I am wrong, I would 
>> do the work.
> 
> Would you settle for publishing with a normative requirement that 
> the DRBG used to generate `m` be one we approve of?

Almost. I would settle on publication with a normative RBG requirement
plus text that explains why `m` matters and recommends restoring the
hash. The RBG restriction and the hash address different layers. The
same is true of CTR_DRBG: choosing the construction does not excuse a
leaky table-based AES implementation. That leaky table-based AES 
situation is catastrophic and that is for a current NIST DRBG. At the 
very least we should also normatively cite the (ever weaker?) NIST 
threat model!

>>> Really, pick your fights carefully!
>> 
>> I take your point(s) and I respectfully submit that I observe what
>> appear to be some oversight in a few of your priors. I appreciate
>> many of your points though.
> 
> Have I covered all points now?

Probably, yes. Remaining is some discussion above as well as the task to 
produce the exact text.

>> We all have a duty to resist and none of us have a duty to obey. 
>> We
> 
> I agree with this.

Good to know, I am glad.

>> have no requirement to simply go along with such things, 
>> especially if we think will lead to harm to the End User. With 
>> deep respect to the actual Indigenous people of the world: we the 
>> Indigenous Cryptographers of the Internet SHOULD help the End User
>> to resist targeted and mass surveillance and indeed, we MUST treat
>> pervasive monitoring as an attack [0].
>> 
>> To paraphrase Bill Hicks: there is a war on your privacy and each 
>> time that you protect your privacy with strong encryption, you're 
>> winning it.
> 
> On so many fronts.  The whole age verification stuff is clearly 
> aimed at ending anonymous and pseudonymous posting so as to force 
> self-censorship on people.

Agreed. The claimed benefit of broad age-verification mandates does
not justify the resulting surveillance, identity linkage, and chilling
of anonymous or pseudonymous expression.

>> [0] A term the NSA has given *us* and we should claim it, and wear
>> it with pride to stand in solidarity with other Indigenous peoples
>> of the world.  Note: "the fact that NSA/CSS makes cryptographic
>> modifications to commercial or indigenous cryptographic
>> information security devices or systems in order to make them
>> exploitable" is "Top Secret" - https://www.spiegel.de/ 
>> international/germany/inside-the-nsa-s-war-on-internet-security- 
>> a-1010361.html
> 
> But also public.  And something we basically knew to expect.

Yes. The history is public enough that surprise is no longer a
reasonable response. The standards question is which concrete
engineering lessons we apply now.

Kind regards,
Jacob Appelbaum

[0] https://datatracker.ietf.org/doc/html/rfc8730

[1] https://datatracker.ietf.org/doc/html/rfc5742

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

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

[4] https://ntruprime.cr.yp.to/nist/ntruprime-20201007.pdf

[5] https://eprint.iacr.org/2019/996

[6] https://datatracker.ietf.org/doc/html/rfc4086

[7] https://datatracker.ietf.org/doc/html/rfc8937

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

[9] https://www.mattblaze.org/papers/eesproto.pdf

[10] https://www.midnightblue.nl/research/tetraburst

[11] https://cr.yp.to/antiforgery/cachetiming-20050414.pdf

[12] https://datatracker.ietf.org/doc/html/rfc7258

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