[TLS] Re: Response to CoI Complaints

Hi Nico,

On 7/16/26 21:57, Nico Williams wrote:
> On Thu, Jul 16, 2026 at 09:22:38AM -0700, Andrew Lee wrote:
>> Furthermore, the issue isn't whether or not Deb Cooley is a person
>> of proper moral turpitude. Instead, it's whether a 37-year NSA
>> veteran can serve as a neutral arbiter in a process where NSA 
>> employees are flooding the list in support, most of whom are 
>> participating for their first time, where NSA's CNSA 2.0 framework
>> requires the exact outcome the NSA desires from this process, and
>> where NSA's Canadian partner stated on-list [2] that they are
>> waiting for this RFC so they can recommend solo ML-KEM nationally.
> 
> I guess you wouldn't object to former NSA employee Ed Snowden being 
> an AD in charge of TLS WG,

That is a funny example. I trust that someone has alerted Ed to this
discussion. I don't know if I would object but it depends on a lot of
factors. If he refused to answer questions posed to him, I would not be
comfortable.

> so it's not really about NSA but about whether Deb is plausibly an 
> agent working under cover to sabotage Internet specifications.

This conclusion does not follow. Also, there is a layer that you are
missing.

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

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

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.

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

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

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

For example, were you aware that you could do this kind of thing,
including recovering `m`?

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?

It sure looks like a trap, and NIST fell right into it. Maybe because
they do not care about non-FIPS certified settings but maybe I do not
understand. NIST did make clear that I am wrong because I am not a NIST
certified Top Cryptographer. After all, Top Cryptographers know, wasn't
that what NIST told us?

Are you really buying the argument from NIST where they made it worse
and accept that as a fact, over what, ~300-1500 cycles?

Come on!

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


> but these are not relevant to ML-KEM except in a FUD-y way.

It is not FUD to show that NIST removed the hash and by their own
admission this makes ML-KEM less safe in a non FIPS-certified setting.
Unless you think that NIST's own summary is FUD?

That this exactly fits a Dual_EC_DRBG-shaped backdoor is just a
coincidence, I suppose. I do not know, I am not really a coincidence
theorist here.

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

> 
> Yes, I know about `m` not being hashed.  No, I don't think that's 
> particularly problematic for non-FIPS implementations because those 
> can use any RNGs and whiten them as needed, and no peer could tell 
> that they are not using a NIST DRBG.

I looked recently and found roughly ~27 packages in a modern GNU/Linux
distro that reference /dev/hwrng and this is an interface where the
kernel backs with the output of a hardware RNG directly. This may not
always be true but it looked true according to the kernel documentation
and my own cursory audit of several backing drivers. Auditing any and
all of the corresponding hardware is a very large project. It should be
done but it is not going to be a cheap job.

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


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

> 
> - 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. One thing that is very interesting here is that
indeed social credit is a major component. More than one person has
raised that issue in various forms. It took a very long time for people
to accept that the issues raised were even possible. It was grueling and
difficult and well, we have made a lot of progress in reaching a better
understanding.

Regarding the credibility, it is lucky for us, that independence is the
counter-balance to people's incorrect perceptions.

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.

The arguments made are factually correct and testable. There is one part
that remains to be demonstrated because the NOBUS design is tricky to
confirm, namely exploiting a specific device and decrypting the existing
hidden structure with NIST/NSA's Dual_EC_DRBG trapdoor/secretkey(s).

I do not concern myself appearing credible to people who are willing to
let even a _chance_ of this happen again. There are people on this list 
who have created (major) backdoors and that sell wiretapping equipment. 
it is a big tent, this wild IETF.

Still, I would not even want someone who hates me to fall to such 
subterfuge. Some things are bigger than our personal differences. If 
anyone involved in enabling targeted and mass surveillance through 
cryptographic sabotage does not appreciate my interventions, well, okay. 
I understand and I accept that one cannot please everyone.

We should still try to do good things for the betterment of all people,
even if they're unappreciative.

> 
> - Why use up your/our political capital over ML-KEN -a relatively 
> minor matter- rather than keeping the powder dry for a more 
> important fight that might be around the corner?

This issue demonstrates an example of the class of attacks that people
"proved" was impossible and it shows that this is only possible due to
NIST's change, and it was done against the objections of many people in
the community and even the designers of Kyber. Part of John Kelsey's
apology tour was the point that NIST made mistakes and should have
listened to the community when they raised theses issues. This is
repeating even if you or others personally can't imagine someone will
fall prey to this kind of issue.

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.

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?

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.

Would you believe that someone does the wrong thing with that kind of
stack and does so in a way that harms security?

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

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.

> Nothing good, IMO.

It is good to try to protect the End User even if the discussions are
time consuming and frankly at times, miserable.

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

We all have a duty to resist and none of us have a duty to obey. We 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.

A luta continua, vitória é certa!

Kind regards and with respect,
Jacob Appelbaum

[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

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