[TLS] Re: [EXT] Re: Response to CoI Complaints

I agree with Daniel and second his request. Enough is enough.

—
Regards,
Uri

MIT

On Jul 16, 2026, at 20:56, Daniel Apon <[email protected]> wrote:

 







Jacob, This is a disgusting and, frankly, small way to drag NIST's name across a public mailing list. I publicly request the TLS Chairs moderate Jacob's posts to the TLS mailing list if he can't focus on technical content in a professional





ZjQcmQRYFpfptBannerStart











This Message Is From an External Sender




This message came from outside the Laboratory.













ZjQcmQRYFpfptBannerEnd





Jacob,

This is a disgusting and, frankly, small way to drag NIST's name across a public mailing list.
I publicly request the TLS Chairs moderate Jacob's posts to the TLS mailing list if he can't focus on technical content in a professional manner in the future.
Surely the TLS WG can be better than this brain rot.

--Daniel

On Thu, Jul 16, 2026 at 6:54 PM Jacob Appelbaum <[email protected] > wrote:

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]



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