Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Appeal Re: Complaint regarding threat (D. J. Bernstein) - 2025-02-20
Appeal - 2025-02-20

From: "D. J. Bernstein"
Subject: Re: Complaint regarding threat
Date: February 20, 2025 at 1:54:51 AM PST
To: IESG
Cc: Joseph Salowey, Sean Turner

Dear IESG:

I am writing (1) to refile with IESG the complaint that I had filed
regarding a threat issued on the TLS WG mailing list and (2) to point
out further procedural failures in how this matter has been handled.

1. Procedural history

Joseph Salowey, also in the name of Sean Turner, issued a threat by
email dated 13 Dec 2024 20:24:24 -0800 to the IETF TLS mailing list.

Regarding that threat, I filed a complaint with IESG, cc'ing Salowey and
Turner, by email dated 13 Dec 2024 20:24:24 -0800.

The IETF chair, in the name of IESG, sent an acknowledgment of receipt
dated 18 Dec 2024 12:33:56 +0000, and then a "response" dated 9 Jan 2025
17:45:08 +0000.

This "response" claimed that the complaint was misdirected, and
recommended that I "raise the matter with the responsible Area Director
(AD) of the TLS WG": a specific IESG member, namely Paul Wouters.

Following IESG's recommendation (while also noting various problems with
that recommendation---see below), I refiled my complaint with Wouters by
email dated 10 Jan 2025 16:44:51 +0100, cc'ing Salowey and Turner. A
copy of the refiling message appears below (minus a copy of the original
complaint).

Wouters sent email dated 11 Jan 2025 15:53:16 -0500 confirming receipt,
and then sent a "response" by email dated 20 Jan 2025 13:57:38 -0500,
cc'ing "TLS Chairs <tls-chairs@ietf.org>" (which includes more than
Salowey and Turner). A copy of this "response" appears below.

This "response" does not address the substance of my complaint. (See
below.) I am filing this renewed complaint with IESG, cc'ing Salowey and
Turner.

2. Applicability of RFC 2026 Section 6.5.2

My original complaint to IESG included the following paragraph: "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."

IESG's "response" claimed that Section 6.5.2 governs (only) "action
taken by the IESG". On the basis of this claim, IESG recharacterized my
complaint as an appeal of a WG action under Section 6.5.1.

Procedurally, Section 6.5.1 allows appeals to IESG only when a
disagreement cannot be resolved by ADs. This was IESG's basis for
claiming that my complaint was misdirected. (IESG wrote "WG disputes are
first escalated to the responsible AD before they come to the IESG".)

However, IESG's selective quote from Section 6.5.2 ignores the first
paragraph of Section 6.5.2, which says the following: "This document
sets forward procedures required to be followed to ensure openness and
fairness of the Internet Standards Process, and the technical viability
of the standards created. The IESG is the principal agent of the IETF
for this purpose, and it is the IESG that is charged with ensuring that
the required procedures have been followed, and that any necessary
prerequisites to a standards action have been met."

IETF's standardization process places requirements on much more than
just IESG. For example, RFC 2026 requires each WG to maintain a public
record of "every activity in which it engages, to the extent that the
activity represents the prosecution of any part of the Internet
Standards Process". A violation of this openness requirement wouldn't be
an "action taken by the IESG"; Section 6.5.2 nevertheless places
responsibility upon IESG for ensuring that this requirement has been
followed.

My complaint spelled out a series of procedural problems that occurred
in this case, specifically including violations of

the procedural requirements that antitrust law places upon
standards-development organizations;
IETF's policy stating that "The IETF Will Work to Mitigate
Pervasive Monitoring";
IETF's policy stating that "Participants engage in their
individual capacity, not as company representatives";
IETF's policy stating 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"; and
RFC 3934's requirement of private communication before any "public
warning".

Section 6.5.2 assigns oversight responsibility regarding procedural
violations to IESG, not to specific ADs. By deflecting my complaint,
IESG was shirking this responsibility and delaying resolution of the
matter at hand.

One might think that this is water under the bridge at this point, given
that Section 6.5.1 says "If the disagreement cannot be resolved by the
Area Director(s) any of the parties involved may then appeal to the IESG
as a whole". But the correct classification matters for two reasons.

First, even though the AD's "response" is failing to engage with the
substance of the complaint (see below) and would warrant an appeal in
any reasonable process, the "cannot be resolved" text seems to allow
arbitrary further delays in which IESG claims that resolution might
still be possible via further AD discussion (or perhaps discussion with
the other AD). Section 6.5.2 does not allow this type of evasion.

Second, Section 6.5.1 gives open-ended authority to IESG to "review the
situation and attempt to resolve it in a manner of its own choosing",
whereas Section 6.5.2 has some actual content, placing responsibility on
IESG to make sure that "the required procedures have been followed". The
current situation is that a reviewer (e.g., an antitrust regulator) can
see that IESG is violating 6.5.2, whereas it's hard to imagine any sort
of meaningful review of specific IESG actions under 6.5.1.

Please confirm for the record that IESG will accept complaints under
Section 6.5.2 regarding procedural violations; that IESG was wrong in
previously limiting this to complaints about violations by IESG; and in
particular that IESG was wrong in its previous handling of my complaint.

3. Applicability of RFC 3934

As a consequence of its mishandling of Section 6.5.2 of RFC 2026 (see
above), IESG refused to address almost the entire substance of my
complaint.

The reason I'm saying "almost" is that IESG did include a retroactive
characterization of the threat I was complaining about, in particular
claiming that this was an action "under the terms of [RFC3934]".

However, my complaint had already explained that the action violates
RFC 3934, meaning that it isn't under the terms of that RFC. IESG
didn't address this, or any of the other problems pointed out in my
complaint.

In particular, if "behavior on a mailing list" is "disruptive to the WG
process", and the "WG chair" has communicated "directly with the
offending individual", and the "behavior persists", then RFC 3934 allows
the WG chair to send a "public warning on the WG mailing list". But
Salowey's public threat wasn't preceded by private communication.

I should note that this isn't the only reason that the behavior wasn't
under the terms of RFC 3934. For example, as I noted in my complaint,
Salowey's message was not labeled as a WG chair message. Furthermore, to
the extent that RFC 3934 gives WG chairs arbitrary unreviewable power to
decide what constitutes "disruptive" behavior, that's a violation of the
procedural requirements of antitrust law, such as the requirement of due
process and the requirement of an appeals process. A dictator has no
place in a standards-development organization, no matter how narrow the
scope is of the dictatorship.

Please withdraw IESG's false claim that Salowey's action was "under the
terms of [RFC3934]".

4. Conflicts of interest

My complaint began by reviewing conflicts of interest by the security
ADs (Deb Cooley and Paul Wouters) regarding this case.

IESG said that the security ADs didn't take part in the handling of this
matter. However, IESG provided no assurance that this protection will
remain in place. On the contrary, IESG claimed to have "found no
credible basis for an actual or perceived COI that relates to this
topic".

IESG's brief comments on the topic were the sort of evasion that one
would expect from a fundamentally corrupt organization. Specifically,
IESG claimed without evidence that secret proceedings of a "NomCom"
committee had already adequately considered the consequences of the
money that Deb Cooley had received from NSA.

Anyone who reads through my description of the conflicts of interest can
see that IESG's "response" is failing to address the problems at hand.
Procedurally, the way that IESG hides behind unreviewable claims about
secret proceedings is contrary to IETF's claims of transparency, is
contrary to the due-process requirement of antitrust law, and is
contrary to the appeals requirement of antitrust law.

Please quote and respond directly to each of the paragraphs in my
complaint, including the conflict-of-interest paragraphs.

5. AD mishandling of the complaint

As noted above, Wouters has sent a "response" to my complaint. I'll go
through this "response" point by point to show how evasive it is, not
addressing the substance of my complaint. I'll also note that the
Wouters "response" contains a remarkable density of factual errors.

Paul Wouters writes:

Your message did not clearly indicate which specific WG chairs'
decision you are appealing.

This is not true. My complaint started by saying "This is a complaint
regarding a threat issued on the TLS WG mailing list"; and, after
reviewing relevant background, said "let's look at the Salowey threat
that I'm now complaining to IESG about" and continued by quoting the
specific threat at issue. I was perfectly clear in asking for reversal
of this threat, along with asking for specific further information.

For this appeal answer, I am going to assume you are
referring to this TLS WG chairs decision:
https://mailarchive.ietf.org/arch/msg/tls/_15N-0uipLJAIBEPlEq_7F2NB2Q/

That's the message I had already quoted, yes.

The TLS CHairs have indicated their action is based on BCP94

This is wrong on multiple levels. First, as my complaint had already
noted: "While the message sounds like a WG-chair action, the message
doesn't say that it's a WG-chair action." Second, while Salowey wrote
"see BCP 94", he didn't claim that he was taking action compliant with
BCP 94 (RFC 3934), nor would that claim have been correct if he had
made it (see above), as my complaint already pointed out.

Labeling is an important part of due process. It has to be clear for the
record what official status an action has. More to the point, Wouters
should be addressing what my complaint said about the lack of labeling;
instead he's pretending that the labels were already there.

[ after quoting various text from BCP 94: ]

The TLS Chairs have sent you a public warning on the WG mailing list
as per BCP94.

No, they didn't follow those procedures. See above. The AD is simply
ignoring what my complaint said about this. The AD is also ignoring all
of the surrounding procedural violations raised in my complaint.

Your appeal to the Area Director falls under RFC 2026 Section 6.5.1.

No, it's under 6.5.2. See above.

Your reasoning for an objection to the WG Chairs decision is given by
you as:

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.

It's correct that this is a quote from my complaint, but it's only one
small fragment of the rationale stated in the complaint. The AD is
ignoring everything else the complaint said.

I disagree with this defense. After reviewing one year of your
messages to the TLS list (xx), I believe you indeed continue to send
messages to the TLS list that are "unprofessional commentary on other
participants' motivations and repeatedly raising points that are out
of scope.".

Here the AD is issuing a fact-free ad-hominem attack while failing to
address the specific action that I had complained about.

If you have difficulty assessing the appropriateness of your messages to
IETF lists, I recommend you find someone to assist you with composing
messages before sending them to IETF lists.

Here the AD is issuing paternalistic rhetoric to try to bolster the
aforementioned ad-hominem attack. This again fails to address the
specific action that I had complained about.

I believe the TLS WG Chairs' decision that gave you a public last
warning to stop the disruptions on the TLS WG mailing list conforms to
the process as per BCP94 Section 2.
Your Appeal is denied.

Here the AD is failing to address any of the specific procedural
problems raised in my complaint.

For reference, you have received similar warnings on other lists for
similar behaviour:

This is just another ad-hominem attack (and the details don't support
the attack: see below), again failing to address the specific action
that I had complained about.

SSH #1 by me as then-moderator:
https://mailarchive.ietf.org/arch/browse/ssh/?so=frm&q=paul%20wouters

This link shows me a message from Bob Beck that doesn't mention me and
that doesn't contain any sort of warning.

SAAG #1 by me as moderator:
https://mailarchive.ietf.org/arch/msg/saag/nMj8idhnBaMV0MRdUlEA3CpFfQU/

It's true that this link is to a message from Wouters that (if one reads
far enough) includes an accusation that I had issued an "at hominem
attack that violates the code of conduct".

However, there was no warning in that message. More importantly, the
accusation itself is absurd. See my detailed comments here:

https://mailarchive.ietf.org/arch/msg/saag/7lwm2Z3_Vrzcit4HDLdH7bK60D0/

Wouters briefly replied "I disagree" and pivoted to other topics.

To summarize: Wouters issued a fake accusation of misbehavior; neither
defended it nor retracted it when challenged; and now brings up the same
fake accusation again, obviously trying to distract attention from the
specific complaint at hand.

SSH #2 by the SSHM Working Group Chairs: //
mailarchive.ietf.org/arch/msg/ssh/6CSqlvU70IUd0HbBkQsMf-UVwl4/

This is another message that doesn't mention me and that doesn't contain
any sort of warning.

To summarize: The AD has now had a chance to address the complaint, has
failed to do so, has shown no interest in engaging in discussion (for
example, the AD didn't ask me about any of the AD's claims above before
using those claims as part of the AD's decision), and should have
recused himself in the first place (see my original complaint).

6. Followup procedures

As noted above, I'm now refiling my original complaint with the full
IESG. I haven't withdrawn any of my requests, and in particular I
continue to request that the rest of the IESG keep the security ADs out
of the discussion, even if they continue to fail to recuse themselves.

Please let me know if you have any questions.

---D. J. Bernstein

D. J. Bernstein writes:

Subject: Complaint regarding threat
From: "D. J. Bernstein"
Date: Fri, 10 Jan 2025 16:44:51 +0100
To: Paul Wouters
Cc: Joseph Salowey, Sean Turner
Message-ID: <20250110154451.83898.qmail@cr.yp.to>

Dear Security AD responsible for the TLS WG:

Last month, I sent IESG a complaint regarding a threat issued by Joseph
Salowey and Sean Turner (in cc), and a followup adding an example of the
impact of that threat in encouraging illegal activity.

Yesterday IESG, claiming that I should instead have complained to you,
refused to address almost the entire substance of the complaint. I'm
saying "almost" because IESG did include a retroactive characterization
of the action I was complaining about, in particular claiming that this
was an action "under the terms of [RFC3934]". But my complaint had
already explained that the action violates RFC 3934, meaning that it
isn't under the terms of that RFC. IESG didn't address this, or any of
the other problems pointed out in my complaint.

Copies of the complaint and followup appear below. I am hereby
addressing the same material, including the requests therein, to you.

Before you address the threat that I'm complaining about, please begin
by considering the conflicts of interest covered at the top of the
complaint. To avoid the risk of IETF interests being overridden by
outside interests in this matter, you will have to recuse yourself, ask
your co-AD to recuse herself, and turn this matter over to someone
independent. There is no legitimate reason for you to personally handle
this matter.

Please let me know if you have any questions.

---D. J. Bernstein