[TLS] Re: Response to CoI Complaints

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? / Would that not be opposed too?  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'.

> > 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.

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.

> 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.

Ok then, here's my take:

 - Ideally we should have a practical, strong PQ Diffie-Hellman.  We do
   not.

 - 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.

   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.

 - TLS 1.3 has insanely large nonces ('random'), and that's enough for
   RNG-based kleptography, 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.

 - 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.

   The AES counter DRBG is plenty good enough.

   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.

 - 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.

 - 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.

   But also I'd have to see how recovering _one_ `m` value would allow a
   kleptographer to steal _many_ other clients' `m` values.

 - The large size of `Random` is still problematic.

[Heavy trimming follows.]

> > - 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.

> > - 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.

> > - 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.

> 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.

> 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.

> 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.  I agree that the risk of
inserting a kleptographic DRBG is real, but not publishing is not really
a good answer.

> > 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.  The 512-bit modular DH group
precomputation thing was not a covert attack on the standards process.

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

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.

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.

> > 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

> > 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.

> > 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.

> > - 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 :)

> 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.

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

> 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.

> 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.

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

> 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.

> 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.

> 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.

> > - 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).

> 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?

> > 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?

> We all have a duty to resist and none of us have a duty to obey. We

I agree with this.

> 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.

> [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.

Nico
-- 

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