[TLS] Re: Response to CoI Complaints

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]