Skip to main content

Appeal regarding threat on the TLS Mailing List (D. J. Bernstein) - 2024-12-15
Appeal - 2024-12-15

From: "D. J. Bernstein" <djb@math.uic.edu>
To: iesg@ietf.org
CC: Joseph Salowey <joe@salowey.net>, Sean Turner <sean@sn3rd.com>
Date: Sun, 15 Dec 2024 01:25:45 -0000
Subject: Complaint regarding threat

Dear IESG:

This is a complaint regarding a threat issued on the TLS WG mailing list
by Joseph Salowey. Salowey also issued the threat in the name of Sean
Turner. I am cc'ing Salowey and Turner. Three initial procedural notes:

  • Another WG participant, Viktor Dukhovni, has already spoken up
    on-list to describe the threat as "excessive" (and, to start, as a
    "threat"), and to say why in considerable detail.

  • The threat appears to be under guise of WG-chair authority, so I
    request IESG reversal of this chair action; i.e., this complaint
    is an appeal under RFC 2026 Section 6.5.4 of a process failure
    under RFC 2026 Section 6.5.2. More specific requests appear below.

  • The security ADs have conflicts of interest regarding this matter.
    Having them participate in this discussion is contrary to the
    stated purpose of IESG's conflict-of-interest policy.

Obviously recusal has to be decided before anything else is discussed.
The first part of this message addresses the conflict-of-interest
issues. The second part of this message addresses the specific problem
at hand. When background is relevant to both parts, it's in the first
part, so please read both parts in any case.

I'm concerned that the security ADs will use their access to the second
part of this message to improperly influence the discussion, especially
given the general non-transparency of IESG's processing of complaints.
Unfortunately, RFC 2026 doesn't even mention conflicts of interest, and
doesn't provide a multi-stage procedure where conflict-of-interest
issues are resolved first, so I'm proceeding with both parts now.

As background, https://www.ietf.org/about/groups/iesg/iesg-coi-policy/
observes that IESG duties "may be - or may appear to be - incompatible
or in conflict with ... the interests of an organization of which the
Covered Individual is an employee, director, owner, or otherwise has a
business or other current or future financial interest."

The policy says that its purpose is "to prevent Covered Individuals from
using their IESG roles or the IESG's resources or decisions to
prioritize their own personal interests or the interests of their
related third parties over the best interest of the IETF community."

As an example of how some third parties have interests opposed to the
best interest of the IETF community, consider RFC 7258, "Pervasive
Monitoring Is an Attack", explicitly labeled as the consensus of the
IETF community, and in particular saying "The IETF Will Work to Mitigate
Pervasive Monitoring". This RFC was triggered by news articles in 2013
regarding mass surveillance by NSA and GCHQ. Several years later, the
European Court of Human Rights held that GCHQ's activites were illegal:

It's unclear what actual effect this court decision had on GCHQ.
Certainly the court decision has no power over NSA.

My blog post https://blog.cr.yp.to/20220805-nsa.html covers much more of
what's known about NSA's cryptographic sabotage. In particular, when
cryptographic standardization began, NSA adopted a secret policy of
trying to reduce competition in this space so as to reduce security:

Narrowing the encryption problem to a single, influential algorithm
might drive out competitors, and that would reduce the field that NSA
had to be concerned about. Could a public encryption standard be made
secure enough to protect against everything but a massive brute force
attack, but weak enough to still permit an attack of some nature using
very sophisticated (and expensive) techniques?

See pages 232-233 of https://archive.org/details/cold_war_iii-nsa, an
internal NSA book that was partially declassified in 2013 as a result of
journalists forcing declassification-review procedures. There has never
been a public statement from NSA revoking the above policy, nor would
such a statement be credible given NSA's long history of sabotage.

One cryptographic mechanism that NSA manipulated NIST, ISO, and ANSI
into standardizing was Dual EC, a backdoored standard for generating
random numbers using elliptic curves. Various other NSA-proposed
standards for elliptic-curve cryptography (ECC) turned out to be filled
with traps for implementors---traps that continue to cause exploitable
problems, as illustrated by CVE-2023-6135 in Firefox. For more about
Dual EC, see https://cr.yp.to/papers.html#dual-ec; for many further ECC
failures, see https://cr.yp.to/papers.html#safecurves.

Within IRTF, CFRG spent two years investigating ECC options in detail.
CFRG ended up selecting X25519, which is an encryption system that I had
designed, and Ed25519, a signature system that I had co-designed. CFRG
issued informational RFCs describing these cryptosystems. Various IETF
protocols added appropriate options; X25519 is now used in most TLS
connections, for example.

To be clear, this was IETF directly competing with NSA and other
organizations in setting ECC standards, and doing so successfully, with
a major influence not just on IETF protocols but also outside IETF. This
influence was good for the end users. The research explaining security
advantages of X25519/Ed25519 over NSA ECC have been repeatedly confirmed
by direct real-world comparisons: the "Minerva" attacks and the recent
breaks of "5G Subscription Concealed Identifiers" worked against
implementations of NSA ECC while failing against implementations of
X25519/Ed25519 in the same software.

Of course, there have been many other IETF RFCs on cryptography at
various layers, and there is a continuing demand for further RFCs, most
obviously in the context of post-quantum cryptography. There is ongoing
controversy about which post-quantum choices are best, as illustrated by

indicating that FrodoKEM is under consideration for standardization by
ISO, whereas NIST has removed FrodoKEM from consideration.

Now imagine an NSA employee saying that IETF and IRTF should stop
independently evaluating cryptography, and should instead endorse
whatever NSA endorses. By far the simplest explanation for this is the
same NSA policy---again, contrary to IETF interests:

Narrowing the encryption problem to a single, influential algorithm
might drive out competitors, and that would reduce the field that NSA
had to be concerned about. Could a public encryption standard be made
secure enough to protect against everything but a massive brute force
attack, but weak enough to still permit an attack of some nature using
very sophisticated (and expensive) techniques?

For purposes of evaluating conflicts of interest under IESG policy, it
really doesn't matter whether the people involved claim that this isn't
the reason for their actions; the fact that there appears to be a
conflict of interest is enough to force recusal.

https://datatracker.ietf.org/person/Deb%20Cooley says that IETF
security-area director Deb Cooley worked for NSA for "37+ years" and
retired in December 2023. Until very recently, the same page admitted
that Cooley was still "working as a Stand-by Active Reservist at
NSA/CSD", and NSA was listed as a disclosure for Cooley on
https://www.ietf.org/about/groups/iesg/iesg-coi-policy/. This was erased
three days ago, but

  1. presumably Cooley, as a retiree, is continuing to receive NSA pension payments;

  2. conflicts of interest don't disappear the moment payments stop; and

  3. the IESG policy says that it's not just about "actual" conflicts of interest but about "perceived" conflicts of interest.

Trying to argue that Cooley's many years of payments from NSA aren't
influencing her decisions is not going to be effective at combating
public perceptions of corruption.

Now let's look at some recent AD slides:

https://datatracker.ietf.org/meeting/120/materials/slides-120-saag-cryptography-at-the-ietf

These slides wildly understated IETF/IRTF activity in cryptography
(e.g., claiming that "CFRG does not analyse or evaluate cryptography
itself") and proposed to "limit publication of crypto RFCs". The brief
discussion at the meeting was enough for various people to give examples
of how the details of this proposal were (1) unclear and (2)
inconsistent with useful IETF/IRTF activity.

The proposal certainly didn't reach consensus at the meeting. It hasn't
shown up on the SAAG mailing list. It also didn't acknowledge previous
statements on the SAAG mailing list that sound opposed to the whole idea
of the proposal. For example, in April 2024, Rich Salz wrote "I agree
with Dan. We should certainly work on/with NIST algorithms, but it is
wrong for the IETF to cede crypto control to that singular US Agency."

The context of the April 2024 discussion is important here. TinySSH and
then OpenSSH added support for post-quantum cryptography---using
sntrup761, which I co-designed, and which, unlike NIST's new ML-KEM
standard, isn't in a patent minefield. OpenSSH 9.0 in April 2022 made
this default---the first major post-quantum deployment. Simon Josefsson
wrote an I-D documenting what was deployed.

There wasn't a working group, so progress of the I-D depended on AD
support. There were some AD claims opposing the I-D for reasons that
didn't stand up to examination. I raised objections on SAAG to those AD
claims. There was clear support for the I-D: e.g., Stephen Farrell wrote
"I think sntrup761 is credible enough so that, given it's deployment,
there's a benefit in documenting that as per the draft".

Eventually there was an AD proposal to (re-)form an ssh working group.
Some proposed charter text sounded too narrow to allow consideration of
this I-D. Various people objected to that. There was then a puzzling AD
response:

I asked for clarification:

There was an even more puzzling AD reply---not answering any of the
clarification questions, and instead sounding like another effort to
limit publication of crypto RFCs:

I asked for clarification of the reply:

At the end of the same message, I wrote the following:

Also, sorry to have to ask this, but aren't you obliged to recuse
yourself from all decisions on reducing the level of IETF involvement in
cryptographic standardization? When cryptographic standardization began,
NSA adopted a secret policy of trying to reduce competition in this
space so as to reduce security:

Narrowing the encryption problem to a single, influential algorithm
might drive out competitors, and that would reduce the field that NSA
had to be concerned about. Could a public encryption standard be made
secure enough to protect against everything but a massive brute force
attack, but weak enough to still permit an attack of some nature using
very sophisticated (and expensive) techniques?

See pages 232-233 of https://archive.org/details/cold_war_iii-nsa, an
internal NSA book that was partially declassified in 2013 as a result of
journalists forcing declassification-review procedures. It's not as if
there has been a statement revoking the above policy, nor would such a
statement be credible given the long history of sabotage. It's hard to
imagine how anything short of recusal would address the appearance of a
conflict of interest here.

There was then a ludicrous AD reply, saying that "Every IETF participant
is acting as individual and does not represent any current or former
employer" and wildly mischaracterizing the conflict-of-interest question
as a "personal attack against an individual":

This reply is making a mockery of the IESG conflict-of-interest policy.
The policy recognizes and tries to protect against the possibility of
IETF interests being overridden by other interests, including the
interests of employers of area directors. It has to be possible to have
a conflict-of-interest question raised and addressed without being
mischaracterized as a personal attack.

There's endless evidence of the security ADs acting in concert
throughout all of this (even though the underlying coordination isn't
transparent), so, for concluding that recusal is required to protect
IESG against conflicts of interest, it doesn't matter whether there's
documentation of the other AD, Paul Wouters, receiving financial
benefits from NSA. In any case, there are further reasons for Wouters to
recuse himself:

I don't know whether Wouters disclosed his personal interests here to
IESG, as required by IESG policy saying that covered individuals "must
promptly disclose when they become aware that a topic discussed by the
IESG or a decision to be made by the Covered Individual could be
perceived as an additional conflict of interest or potential conflict of
interest by a reasonable person who is aware of the Covered Individual's
situation".

It is, in any case, clear that the situation at hand creates the
appearance of other AD interests overriding IETF interests. Again, it
really doesn't matter for conflict-of-interest evaluations whether the
people involved claim that this isn't the reason for their actions; the
appearance of a conflict of interest forces recusal.

It's also not plausible that recusal will cause a problem for handling
complaints. There are many other IETF participants with security
experience; and the specific complaint at hand is about a process
failure.

This should settle the conflict-of-interest questions. However, even
termination of NSA ADs would not address a different attack by NSA, in
which NSA simply pays a cartel of companies to push low-security
specifications through IETF.

A week ago, Cisco employee Scott Fluhrer sent a message to the TLS
mailing list including the following text: "There are people whose
cryptographic expertise I cannot doubt who say that pure ML-KEM is the
right trade-off for them, and more importantly for my employer, that's
what they're willing to buy. Hence, Cisco will implement it; I am
essentially just asking for code points."

There are several problems here:

  • This was invoking the employer's name to influence IETF action.
    This is contrary to IETF's claim that "Participants engage in
    their individual capacity, not as company representatives".

  • This was disclosing market opportunities for Cisco. This exposes
    not just Cisco but also IETF to antitrust litigation. That's why
    RFC 9680 says that "discussions about market opportunities for
    specific companies" are "generally inappropriate" and that
    "avoiding these specific topics in the context of the
    collaborative IETF process best mitigates antitrust risks for the
    IETF and its participants".

  • This message didn't provide evidence for its claims. This is
    contrary to IETF's claim that "IETF activities are conducted with
    extreme transparency, in public forums".

  • Presumably "people" refers to NSA (although the message didn't say
    this explicitly). Allowing NSA to buy IETF endorsement of specs,
    whether directly or via middlemen, is contrary to the stated
    purpose of, and motivation for, BCP 188.

  • Instead of giving an engineering rationale, this message was
    giving a this-user-is-asking-for-it rationale. This is contrary to
    IETF's claim that "IETF participants use their best engineering
    judgment to find the best solution for the whole Internet, not
    just the best solution for any particular network, technology,
    vendor, or user".

  • In context, this is just one of the messages to the mailing list
    arguing for "pure ML-KEM" on the basis of NSA (supposedly) wanting
    that. This NSA-wants-it argument disrupts IETF discussion of the
    engineering considerations, which are very much against "pure
    ML-KEM". (The ML-KEM deployment in TLS is instead "hybrid ML-KEM",
    which follows the common-sense security practice of encrypting
    with ML-KEM and with ECC to limit the damage in case of ML-KEM
    security failures. Similarly, the sntrup761 deployment in ssh
    mentioned above is a hybrid, as are various other deployments.)

The IETF claims quoted above are included in

which according to

is the basis for some lawyers claiming that the IETF corporations are
protected against antitrust litigation. This last link admits that other
lawyers disagree.

I presume that Fluhrer, like most IETF participants, simply didn't
realize the constraints created by antitrust law: he thought he was
simultaneously doing his job for Cisco and providing useful input to
IETF, rather than providing unlawful input that disrupts what IETF is
supposed to be doing. I followed up to point out that there was an
antitrust issue and to request IETF LLC attention:

I was expecting IETF LLC to respond by saying something like "Everyone,
please review RFC 9680, and in particular please refrain from discussing
market opportunities for specific companies". Instead the response

acted as if there was no problem. It didn't even address the incident at
hand; instead it contained generic claims that "the IETF structure and
processes are designed to mitigate antitrust risks" and that this "view"
has been "thoroughly checked with multiple sets of counsel".

But wait a minute. IETF LLC had admitted in

that other lawyers had informed IETF "that, from the perspective of
antitrust litigators, our current processes and procedures would not
provide strong mitigation of antitrust risk and that could only be
achieved with a detailed compliance policy".

Before commenting on the antitrust issues, I had already spent time
reviewing court cases such as ASME v. Hydrolevel, reviewing current
antitrust rules such as

and published commentary on those rules, and comparing those rules to
how IETF operates. Those other lawyers are right; IETF is missing the
procedural protections that it needs to survive antitrust scrutiny.

When IETF LLC is on record admitting that various lawyers dispute the
IETF LLC position, why is IETF LLC claiming that its position was
"thoroughly checked with multiple sets of counsel"? This misinforms
readers into believing that there's no controversy regarding IETF LLC's
position. In context, this encourages unlawful behavior.

I am, of course, happy to engage in discussion of the disputed content.
I followed up accordingly, starting by quoting RFC 9680 saying that it's
"generally inappropriate" to discuss "market opportunities for specific
companies" and asking what the process was to address violations of RFC
9680:

The IETF LLC response selectively quoted the "generally inappropriate"
language to indicate that this was a "grey area":

The reason that this is selective quoting is that RFC 9680 also has a
clear statement that "avoiding these specific topics in the context of
the collaborative IETF process best mitigates antitrust risks for the
IETF and its participants". There's nothing gray about this: either IETF
is avoiding these topics, which is what the RFC says "best mitigates
antitrust risks", or it isn't. What this Cisco incident shows is that
IETF isn't avoiding these topics. IETF LLC is condoning this.

The IETF LLC response also commented on procedures. I had asked what the
IETF process was to address violations of RFC 9680. IETF LLC stated that
"RFC 9680 is not a policy", so the concept of violations of RFC 9680
doesn't exist.

Meanwhile IETF LLC, despite claiming that it had no power over the IETF
standardization process, admitted that it had contacted the WG chairs
("you will be getting an email in due course from the WG chairs"). The
WG chairs echoed IETF LLC's incorrect "grey area" statement and then
claimed that "Discussions about the contents of RFC 9860 are not
relevant to this mailing list and are considered off-topic":

Beyond a generic reference to list policy, there was no justification
for this specific claim about RFC 9680's supposed irrelevance.

Perhaps the justification is supposed to be that RFC 9680 is "not a
policy" and therefore has no control over WG activity (never mind the
problem that the RFC is supposed to address, namely IETF participants
being generally unaware of antitrust rules). Realistically, given that
RFC 9680 seems powerless to control even something as blatant as a
discussion of Cisco's market opportunities, I don't see a point in
referring further to RFC 9680. So I haven't bothered challenging the WG
chairs' unfounded assertion that RFC 9680 is off-topic, and I've
strictly avoided referring to the RFC on list since then.

Of course, antitrust law has a different status from RFC 9680: it's
binding on IETF. If the WG chairs had tried to shut down discussion of
antitrust law then I would have objected. But that's not what they did.

Meanwhile two commentators sent three messages claiming that what I had
said about antitrust law was "silly", "rather laughable legal
speculation", etc.:

I had backed up my statements with with various authoritative quotes and
references. These messages didn't provide any contrary evidence, nor did
they pinpoint what they claimed to be disputing; they relied entirely on
the rhetoric of "silly" etc. Presumably this disruption was the result
of IETF LLC falsely claiming lawyer unanimity on its position.

With this background in mind, let's look at the Salowey threat that I'm
now complaining to IESG about:

You continue to violate list policy with unprofessional commentary on other
participants' motivations and repeatedly raising points that are out of
scope. Please stop this behavior. This is the last warning before we will
take action and temporarily ban you from the list; see BCP 94 [0].

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

Content-wise, I dispute everything that this is claiming. Everything
I've sent to the TLS mailing list is professional, within scope, and
compliant with list policy. Salowey's claim that I've issued "commentary
on other participants' motivations" is wildly misrepresenting the facts:
I've simply commented on the merits of the rationales that other people
have sent to the list.

Concretely, it's not my fault that a Cisco employee wrote that "There
are people whose cryptographic expertise I cannot doubt who say that
pure ML-KEM is the right trade-off for them, and more importantly for my
employer, that's what they're willing to buy. Hence, Cisco will
implement it" etc. Criticism of the merits of this rationale is not a
personal attack. It is important and on-topic to resolve whether this
statement regarding Cisco's market opportunities is allowed at all as
input to WG decisions regarding the draft in question.

If Salowey were merely making claims regarding the facts then we could
simply discuss the facts and resolve the dispute. But what Salowey wrote
isn't just getting the facts wrong; it's also

  • issuing unfounded accusations of policy violations, and

  • issuing a threat to ban me "temporarily" from the mailing list.

Procedurally, there are many obvious problems with Salowey's action:

=* While the message sounds like a WG-chair action, the message
doesn't say that it's a WG-chair action.

  • The message doesn't say how I can appeal the action. The message
    doesn't even state that I have the right to object.

  • The message is phrased as a broad personal attack, rather than
    pinpointing the supposedly problematic text. Maybe the WG chairs
    are now trying to silence not just RFC 9680 discussion but all
    antitrust discussion---but they don't say this. How am I
    supposed to respond when I don't know which specific text is at
    issue? How is a review panel supposed to evaluate the dispute?

  • The message doesn't state any rationale for its claims that the
    text (whichever text precisely is at issue) is "out of scope" etc.
    This similarly sabotages the processes of response and appeal.

  • RFC 3934 contains a specific requirement for the WG chairs to
    begin by "communicating directly with the offending individual"
    before any "public warning". The WG chairs didn't do this; instead
    they proceeded directly to issuing public attacks and threats.

  • The WG chairs haven't issued similar public threats in response to
    some people (e.g., Google's Sophie Schmieg, covered by links
    above) repeatedly claiming that this Cisco incident doesn't
    create antitrust risks. So it's not that the WG chairs are acting
    consistently regarding all messages on the topic---they're just
    trying to selectively suppress one side of the debate.

It's remarkable how few of these problems are covered by objective IETF
policies and procedures. This IETF procedural failing is the obvious
explanation for

mentioning "the dearth of upheld appeals". Apparently IETF LLC found
some lawyers to claim that everything is fine and that the dearth of
upheld appeals "demonstrated the robustness of our processes before the
appeals stage", but that doesn't match what I've witnessed in IETF over
the past thirty years, and it definitely isn't true for the threat I'm
complaining about. The only "process" here has been the WG chairs
publicly attacking me in response to my whistleblowing.

Fortunately, antitrust law in the US requires standards organizations to
provide due process. See the OMB A-119 link above (where 108-237 gives
legal force to A-119 under antitrust law); also, the EU "unrestricted
participation" requirement has a similar impact. Due process is more
restrictive than RFC 3934. Allowing WG chairs to act purely on the basis
of their "opinions" is violating the law.

In your response, please explain the steps that IESG has taken to ensure
that the IETF actions here are consistent with antitrust law.

Furthermore, IETF does have some policies that have been violated
here---both by Cisco, which fully justifies my objections, and by the
WG chairs. Please specifically address each of the following policies in
your response:

  • "The IETF Will Work to Mitigate Pervasive Monitoring".

  • "Participants engage in their individual capacity, not as company
    representatives".

  • "IETF participants use their best engineering judgment to find the
    best solution for the whole Internet, not just the best solution
    for any particular network, technology, vendor, or user".

  • RFC 3934's requirement of private communication before any "public
    warning".

Finally, given IETF's claims that "IETF activities are conducted with
extreme transparency, in public forums" and that IETF LLC has no power
over the standardization process, please instruct the WG chairs to
forward me copies of their communications with IETF LLC regarding this
matter. To be clear, this includes communications with Jay Daley, but
it also includes communications with Brad Biddle; those communications
are outside IETF LLC and are not privileged.

Please let me know if you have any questions.

---D. J. Bernstein