My blog post yesterday regarding NSA's corruption of IETF mentioned that there's a current stealth project to silence dissent in IETF. This project aims to change IETF rules so that new censors can permanently ban people from IETF participation simply for (e.g.) objecting to NSA's proposals to weaken cryptographic standards. The new rules will go into effect unless enough people hear what's happening and file objections by Tuesday the 7th of October, which, at the time I'm writing this, is still in the future.
This censorship matters for the same reason that NSA sends people to participate in IETF in the first place: IETF standards are influential. Dissent has a chance of stopping harmful IETF projects, such as current NSA-driven proposals of "non-hybrid" PQ in TLS, before those turn into standards; censoring dissent takes this chance away.
The new censorship rules aren't in place yet. IETF says that "IETF participation is free and open to all interested individuals", and that "anyone from the Internet community who has the time and interest is urged to participate". IETF also says that "IETF activities are conducted with extreme transparency, in public forums"; that "decision-making requires achieving broad consensus via these public processes"; that each "Working Group (WG) has its own mailing list with most of its interaction, and all of it official work, conducted on this list"; and that 51% of a working group "does not qualify as 'rough consensus' ".
The stealth working group that's proposing new rules, a group called MODPOD, isn't an exception to the current rules. In theory, anyone interested in this topic, whether an opponent of censorship or a supporter of censorship, can simply show up on the mailing list and have a voice in whether the group will approve the new rules. For example, you can simply join the mod-discuss mailing list and then, from your subscription address, send email along the following lines:
To: mod-discuss@ietf.org
My understanding is that working-group last call (WGLC) was issued in September for a MODPOD draft, with a deadline of "Tuesday October 7 (in any time zone)" for WGLC input.
Until recently, I was not adequately informed of what is happening here. I have now heard about Keith Moore's objection that the draft will do "tremendous harm to IETF's ability to build genuine consensus". This possibility was not obvious from the announcement https://web.archive.org/web/20250827091120/https://mailarchive.ietf.org/arch/msg/ietf-announce/TBaquQhQAndS0o8kBlfWpjBcSSo/ of the creation of MODPOD. I would like more time to evaluate this objection and more broadly to evaluate the costs and benefits of the draft, so I object to WG approval of the draft at this time.
If support within the working group is only 51% (or lower) then, according to the current rules, the group cannot approve the new rules.
In reality, most people affected by the new rules haven't spoken up yet, since they simply don't realize what's going on. There are various reasons for the lack of awareness:
Unlike typical standards-development organizations, IETF frequently creates single-project WGs. This creates so many announcements of new WGs that most people, even most people already involved in IETF, have no way to keep up with the ietf-announce mailing list. The general IETF mailing list is even more difficult to keep up with.
Even within the limited set of people who did see the MODPOD charter, most readers will understand the stated scope of work as a tedious task of resolving inconsistencies in existing procedures. Certainly readers were not informed that the goal of MODPOD was specifically to add new censorship powers, even if that's allowed by the wording choices in the scope of work.
Readers who have limited time to look at the draft itself, or at the mailing-list archives, are met with a torrent of marketing. Seeing the draft's power grab requires taking the time to read more carefully, which I encourage you to do. I'll also highlight the most important quotes later in this blog post.
I did eventually find out about MODPOD. I joined the mailing list in May and, after catching up on what had happened, filed objections starting in July. The chairs suddenly issued "WG last call" in August, even though the official list of MODPOD milestones says "Nov 2025 - WGLC".
In this last call, the chairs asked participants to publicly "indicate your support or objection to proceed with the publication of this document". In context, "publication" would mean the WG endorsing the rules. Only 15 people spoke up in favor of the document. Meanwhile I collected quotes from 6 people, including me, who had pointed out serious problems with the approach taken by the draft.
Aren't these shockingly small participation numbers? Shouldn't many more people be involved in evaluating costs and benefits of different approaches, to decide on the best path forward?
This is a draft setting IETF-wide rules. Supporters are saying that the draft avoids an existing situation of "community war". Opponents are saying that the draft will do tremendous harm. Here's more of what Keith Moore wrote:
I oppose WG approval of this document. If adopted, I believe it will do tremendous harm to IETF's ability to build genuine consensus; and for that reason, threaten IETF's very legitimacy (or public perception thereof).
This document delegates nearly arbitrary power to a moderation committee, which as I interpret the document, allows that committee to both make rules that regulate discussions within IETF, and (at least in some cases) to impose sanctions on those which (in its sole judgment) are said to break its arbitrary rules.
... Even though this document explicitly says that merely expressing an opinion outside the rough consensus should not be considered disruptive, it leaves open the possibility that to try to argue for or build support for an opinion outside the current (perceived) rough consensus would be considered disruptive merely because that person makes a best effort to be persuasive. Indeed, the history of this very group shows numerous examples when some participants insisted that anyone with an "in the rough" opinion had an obligation to stop trying to build support for that opinion very early, denying them an opportunity to convince anyone of the merit of that alternative view. This is not a good way to build technical sound consensus or even compromise. It's instead a way to short-circuit discussions even of very important issues, causing profound harm to the Internet and its users.
Something is seriously wrong when IETF allows a tiny group of people to quietly go off in a corner and make rules controlling many other people, especially when IETF says that "decision-making requires achieving broad consensus".
I wrote that the chairs are "obliged to reach out to broaden the WG membership before allowing any WG decisions". The chairs responded that this was "out of scope". I've tried some steps to draw broader attention to what's going on; this blog post is the newest of those steps.
That last call had an 11 September deadline. The chairs didn't declare WG approval of the document, nor did they declare WG rejection of the document. Instead they announced on 19 September, that there would be a "second WGLC". Procedurally, I find the chair announcement striking for two reasons:
The chairs didn't state any reasons for their actions. Can chairs just do whatever they want? The lack of explanation sabotages appeal processes. My best guess is that they would have been happy to claim "consensus" on the basis of a 15–6 vote, but they realized that it looked bad to have the draft still changing during the last-call process. As Tim Hudson put it recently regarding a different IETF draft in a different WG: "I find it a somewhat unexpected process to have a WGLC active and to be simultanously changing the document."
The chairs declared that "more topics will be ruled out of scope". This sounds like a declaration of chair authority to unilaterally narrow the scope of the WG, something the MODPOD chairs have done repeatedly rather than quoting and sticking to the official MODPOD scope of work in the MODPOD charter.
For comparison, IETF rules say that a charter is a "contract between a working group and the IETF". When IETF subsidiary IRTF refused back in 2014 to remove an NSA employee as a chair, it claimed that chairs "are little more than group secretaries". (This refusal was by Lars Eggert, one of the two authors of the MODPOD draft.)
Anyway, the MODPOD chairs issued a second WGLC four days later, 23 September. That's the currently open last call, closing "Tuesday October 7 (in any time zone)".
The underlying problem. There's nothing in IETF procedures that requires working groups to track and officially answer objections.
For example, my previous blog post traced how the IETF TLS WG chairs declared "consensus" to "adopt" a non-hybrid-PQ-in-TLS draft, without an official answer to any of the objections that had been raised to the draft. The non-responsiveness per se doesn't violate IETF's procedures; it's normal practice in IETF.
For comparison, let's look at ANSI, an organization that has a century of experience and millions of participants. Here's a quote from the ANSI Essential Requirements: "Prompt consideration shall be given to the written views and objections of all participants ... each such objector shall be advised in writing (including electronic communications) of the disposition of the objection and the reasons therefor".
In legitimate standards-development organizations, people who object know that each objection will be tracked and officially answered. This process forces groups to discuss each objection in enough detail to agree on an answer. Usually this settles the issue one way or the other. Appeal procedures are available, and there might occasionally be an appeal regarding an important answer that received general agreement within the WG but not unanimity; ANSI writes that consideration of appeals "shall be fair and unbiased and shall fully address the concerns expressed".
In IETF, there's no requirement for a WG to discuss each objection in enough detail to agree on an official response to each objection. An IETF WG can have objections being ignored entirely. An IETF WG can have objections being met with an incoherent mix of individual responses. For example, various objections within MODPOD have been met with
claims that the draft is good because it will expand censorship (for example: "any of the choices currently available to resolve such behaviour are inadequate"); and
claims that the draft is good because it will reduce censorship (for example: "The goal of this document is to stop banning people").
Simon Josefsson's comment on this was "you can't have it both ways". Any legitimate organization would be saying "We clearly need to discuss this more carefully to come to a shared understanding of what's going on".
IETF has an appeal process, but doesn't have a process to appeal the WG response to an objection. There's no official WG response in the first place. There are, at best, individual responses. Even when those responses are easily debunked, IETF takes no responsibility for the errors or for the consequences of those errors.
What matters in IETF is whether the talking points from document proponents end up with enough positive votes for the document as a whole. Meanwhile the fiction that IETF doesn't vote means that there's also no punishment for the peer-pressure game of misrepresenting vote counts, such as a "security area director" writing "There is clearly consensus based on the 67 responses to the adoption call. ... The vast majority was in favour of adoption ... There were a few dissenting opinions" regarding a call that actually received 20 positive votes, 2 conditional positive votes, and 7 people objecting.
Dissenters keep speaking up, explaining why they disagree with the majority, hoping to convince enough people to flip the majority. Meanwhile supporters keep repeating their talking points, hoping to maintain their majority.
This is tremendously inefficient. The obvious way to improve the situation is to require chairs of IETF WGs to centrally track objections and to provide an official answer to each objection, in particular not declaring consensus before everything is answered. I'll repeat a note here from my previous blog post: "Here's a random example of what an objection-response document looks like in ISO, IEC, etc. Not the best user interface, but it gets the job done."
IETF's current procedures even contain some recognition of the efficiency issue here: "unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion". But this doesn't recognize the importance of tracking objections that haven't been discussed, and in any event the current procedures don't require any tracking.
Proponents of the MODPOD draft have repeatedly (ahem) pointed to repetition as bad, and have even described "repeating the same arguments" as "the most common form of content in need of moderation". Why, then, isn't MODPOD taking the obvious step to eliminate the underlying procedural failure that makes people feel compelled to repeat themselves?
Some people have claimed that rules requiring chairs to track objections would be out of scope for MODPOD. That's not true. The official MODPOD scope of work says that MODPOD "will revise existing and define new moderation procedures suitable for all IETF communication channels". The relevant meaning of "moderator" is "someone who presides over an assembly, meeting, or discussion" such as "the chairman of a discussion group"; the word "moderation" is the noun form of the verb "moderate", which means "to act as a moderator". Telling moderators of all IETF communication channels that they have to track objections perfectly fits this scope.
But, of course, having objections tracked and answered isn't in the interests of NSA and other parties that are trying to ram non-consensual standards through the IETF process.
One question in an IETF-wide survey in 2024 was whether "The IETF produces RFCs that reflect IETF consensus". (See page 19, Q25; beware that the text is not searchable.) Allowed answers were "almost always", "often", "sometimes", "rarely", and "almost never". Only 31% of 1060 respondents agreed with "almost always": i.e., several hundred respondents said that RFCs don't always reflect IETF consensus. This is an indictment of IETF's current procedures. Remember that IETF claims that "decision-making requires achieving broad consensus via these public processes".
Current IETF censorship procedures, part 1. The MODPOD draft isn't the first step of IETF into censoring dissent; it just makes the censorship much more extreme. In the rest of this blog post, I'll review two existing powers that can be abused to censor dissent, and then I'll explain five ways that the MODPOD draft expands this censorship.
RFC 3683, also known as IETF BCP 83, claims without citations that there had been a few cases where "a participant has engaged in what amounts to a 'denial-of-service' attack to disrupt the consensus-driven process", typically by "repeatedly posting messages that are off-topic, inflammatory, or otherwise counter-productive" whereas "good faith disagreement is a healthy part of the consensus-driven process". BCP 83 gives IESG authority to publicly cite messages "that appear to be abusive of the consensus-driven process" and to respond with a ban of the author from the IETF mailing list containing those messages. If IESG does this, then BCP 83 also allows maintainers of other IETF mailing lists to apply the same ban.
What's this "IESG" thing? IETF standards are approved by WG chairs and then by an "Internet Engineering Steering Group" (IESG), which also appoints the WG chairs in the first place. IESG members are appointed via non-transparent procedures by a "Nominating Committee" (NomCom). Membership in NomCom is restricted to people who can afford to frequently attend IETF meetings, for example because they're being paid by Internet companies to attend. The voting members of the 2024 Nominating Committee were
When IESG is appointed by a group like this, do you think IESG will have a majority in favor of allowing dissent? That IESG will have a majority against approving new censorship rules from MODPOD? That IESG will overturn typical censorship decisions?
BCP 83 has been used five times. Looking at the most recent example, a ban of Dan Harkins that started in 2022 and that wasn't lifted until 2025, shows how easy it is to use BCP 83 to suppress dissent.
The context of this example is that there were proposals to rename various words that have taken on technical meanings, such as "master" and "slave". There are many different meanings of the noun "slave" in English: for example, meaning I.1 is "A person who has the (legal) status of being the property of another, has no personal freedom or rights, and is used as forced labour or as an unpaid servant; an enslaved person", and meaning II.5 is "A component that is controlled by, or closely follows the action of, another component of a system". An IETF draft described the latter meaning as "an oppressive metaphor that will and should never become fully detached from history"; said that the meaning was "unprofessional", was "inappropriate", was "arcane", was "historically inaccurate", and "stifles participation"; and (following various earlier documents) suggested replacing "master" and "slave" with, e.g., "leader" and "follower". The document also suggested replacing "blacklist" and "whitelist".
Followup proposals suggested replacing other words, such as "nonce". This is a standard English word meaning "the one, particular, or present occasion, purpose, or use", or "the time being", or, as an adjective, "occurring, used, or made only once or for a special occasion". The word is used in various security contexts to refer to a number used once. The stated reason for replacing the word is that "nonce" is "slang for a paedophile" in "British English". This slang was then claimed to be archaic. A followup stated the following: "I haven't lived in the UK for over 10 years but when I was there this was not archaic but was sort of regional (London and surrounding area + criminal culture such as prisons, gritty TV shows) and common parlance in that context. I was surprised when I discovered the security usage in my 20s but I’ve never considered there to be much chance of confusion between the two communities that use the word differently."
Harkins objected to the proposal to rename "master" and "slave", for example writing the following: "I want racial equality too (and a cure for cancer!). But imposing speech codes and calling people racist is not the way to go about achieving that. ... It seems that you're suggesting that publication of your draft, and the changing of certain metaphors in RFCs, is an effective way to achieve racial equality in the IETF. That is magical thinking. It's unhinged from reality." In reply to the proposal to rename "nonce", Harkins suggested replacing the keyword "native" with "indigenous" in the Java programming language. Obviously he wasn't actually endorsing replacing "native"; he was using "native" as an example to question the principles behind the replacement proposals.
These two messages from Harkins are among the messages that IESG claimed were "inconsistent with the IETF Guidelines for Conduct (RFC 7154) and thereby 'disrupt the consensus-driven process' (RFC 3683)". IESG said that some unspecified subset of the messages "express racism in the form of denying, belittling, and ridiculing anti-racist sentiment and efforts" and "are rude and abusive, and often amount to insulting ridicule". The suggestion by Harkins to replace "native" with "indigenous", in response to the suggestion to rename "nonce", seems to be what IESG meant by "ridiculing anti-racist sentiment and efforts".
For the record, I'm happy to move away from, e.g., the use of "slave" in RFC 1996 to "replica". However, whatever one thinks of the content of what Harkins was writing, the notion that these Harkins messages were disrupting the consensus-driven process is absurd. Here's what IETF rules say about this process:
Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved; however, there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion.
IESG wasn't protecting this process: it was sabotaging the process by censoring dissent.
Not all of the applications of BCP 83 were to suppress dissent. For example, in 2019, IESG revoked posting rights for "Pradeep Kumar Xplorer", in response to postings to IETF mailing lists that were obviously off-topic, such as "I need to father a child. I am pegged to californians and not let in and i can moveon with thai English but I need my money as cash to restart my life. I am 49" in email to ietf-smtp@ietf.org dated 26 Apr 2019 17:21:54 +0000. Of course, this revocation failed to stop "Pradeep Kumar Xplorer" from continuing to post to IETF mailing lists.
Current IETF censorship procedures, part 2. The other existing IETF power that can be abused to censor dissent is RFC 3934, part of IETF BCP 94. This RFC gives WG chairs the following authority:
As in face-to-face sessions, occasionally one or more individuals may engage in behavior on a mailing list that, in the opinion of the WG chair, is disruptive to the WG process. Unless the disruptive behavior is severe enough that it must be stopped immediately, the WG chair should attempt to discourage the disruptive behavior by communicating directly with the offending individual. If the behavior persists, the WG chair should send at least one public warning on the WG mailing list. As a last resort and typically after one or more explicit warnings and consultation with the responsible Area Director, the WG chair may suspend the mailing list posting privileges of the disruptive individual for a period of not more than 30 days.
It's very easy to abuse this to censor dissent: the WG chair simply has to claim that the dissent is disrupting the WG process, and that the disruption is severe enough that it must be stopped immediately. The limitation to 30 days is meaningless when, e.g., a document is in a last-call period.
Sometimes a WG chair will feel uncomfortable invoking the "must be stopped immediately" provision. But then the WG chair is not required to engage in direct communication (this is merely "should"), to provide a public warning (this is also merely "should"), or to consult with the responsible AD (this is merely "typical"). The only requirements are
that "the behavior persists" (which is normal for dissent, and the only option available when an objection is not fully addressed after the first time it is raised) and
that suspension is a "last resort" (so the WG chair has to take some steps before suspension).
RFC 3934 says that any chair decision, including "any suspension of posting privileges", is subject to appeal to an "area director", but the "area director" is merely required to "attempt" to resolve the dispute. If this complaint doesn't work, that the subject of censorship can appeal to IESG—but IESG is merely required to "review the situation and attempt to resolve it in a manner of its own choosing". That's the complete description of the appeal process: there are no requirements for an investigation of whether any part of the WG process was in fact disrupted, for example, and there are no procedural protections such as having appeals handled by a neutral party (remember that WG chairs are appointed by IESG in the first place). The only further recourse within IETF is to a board called "IAB", where similar comments apply.
Given the lack of any protections in this appeals process, one would expect appeals to rarely be upheld—and, indeed, the IETF corporation's Executive Director has admitted that there is a "dearth of upheld appeals" (while he claims that this somehow shows "the robustness of our processes before the appeals stage"). This is not just for appeals of RFC 3934 actions: every appeal of an IETF standardization decision follows this path.
Even if an appeal is upheld, the dissent will have been delayed. Meanwhile many other people censor themselves, downplaying their most serious objections out of fear that speaking honestly will result in a ban by the people in power.
Unlike BCP 83, RFC 3934 does not require public records of its suspensions. Victims also have to worry that publicly objecting to what happened will result in retaliation.
The main protection that RFC 3934 provides against censorship is that some WG chairs won't be willing to place themselves in a fantasy world where dissent is disrupting, rather than following, the WG process.
How the MODPOD draft expands censorship powers. The MODPOD draft obliterates the minimal RFC 3934 guardrails that I described above. Here are five ways that the draft authorizes censorship far beyond RFC 3934. Again, I encourage you to carefully read through the draft to see that it does in fact have these effects.
First, the proposal creates five new IETF-wide censorship positions, labeled as an "IETF Moderator Team". If a chair refuses to declare that dissent is disruption, surely one of the five "moderators" will be willing to substitute.
Second, the draft no longer refers to disruption of the WG process. In the draft, "disruptive behavior" is a free-floating concept without regard to what is being disrupted.
Imagine, for example, that enough people raise objections to a spec that standardization of the spec is stopped. The censor can claim that the spec would normally have been standardized, and that this was disrupted by those troublemakers raising objections. (For comparison, the same claim cannot trigger RFC 3934: it isn't claiming that the WG process was disrupted.) Or the censor, following the draft itself, can simply say "disruptive behavior" without even bothering to say what was supposedly disrupted.
Third, the draft declares various open-ended categories of material to be "disruptive" by fiat—so the censors merely have to assert that the dissent is within one of those categories, not that the dissent is actually disrupting anything.
For example, the censor can declare that the dissent includes "incessant requests for evidence"—that's one of the categories listed in the draft. IETF's procedures don't oblige proponents to provide any evidence of the problem that their specs supposedly address, so of course there are many examples of people asking for evidence; the proponents can simply stonewall, and then the censor can silence any further requests for evidence as "incessant".
Or the censor can declare that the dissent is "uncivil commentary"—that's another category listed in the draft. After listing five categories, the draft says the following:
These items are examples. Moderators and administrators may take moderation actions for many other cases.
The moderator team's task consists of subjective judgement calls. Behaviors not listed here might require moderation, and it is not possible to write a complete list of all such behaviors.
In other words, censors are authorized to make up their own ad-hoc excuses for censoring whatever content they want to suppress. This will of course be selectively applied in a way that favors the people in power.
Fourth, RFC 3934's concrete escalation recommendations and requirements are gone, replaced by a vague "expectation" for the censors to take "the minimal actions necessary". Suppression is no longer a "last resort".
Fifth, the draft provides "the widest possible freedom of action to administrators and moderators" up to and including "temporary or permanent bans in one or more fora"—so there is nothing stopping a censor from issuing an IETF-wide ban. For comparison, RFC 3934 allows only a 30-day ban in one forum by the chair of that forum regarding messages on that forum. Similarly, BCP 83 allows IESG to issue bans for a forum only in response to messages on that forum; it does let WG chairs copy the ban for their own lists, but an IETF-wide ban would require many WG chairs to act.
There's still an appeal process, but still with the same problems as discussed above. Given the tremendous powers of the censors and the lack of any meaningful guardrails, most IETF participants will censor themselves rather than risk doing anything that might trigger the censors.
Maybe some people will still object to, e.g., non-hybrid PQ in TLS. But then any censor has the power to say, for example, "Allegations that non-hybrids add security risks compared to hybrids are out of scope!" or "This is a non-hybrid draft, and comparing it to hybrids is out of scope!" or "This objection has been discussed before!", whether or not that's actually true. In the end the censor is completely free to punish dissent as "disruptive behavior". Minor objections will be allowed, but major objections that don't serve the interests of the people in power will be silenced.
Regarding the TLS WG chairs claiming "consensus" to adopt non-hybrid PQ in TLS, my previous blog post quoted a "security area director" writing "you calling into question this consensus call of the WG chair is abusive and follows a repetitive pattern. Nevertheless, for now this is your right ... there comes a point where you will be prevented from further playing these games". "Area directors" are IESG members, and this particular "area director" has voted for the MODPOD draft. His words "for now" and "will be prevented" suddenly make sense, don't they?
It's already bad that the IETF TLS WG adopted non-hybrid PQ without official answers to the objections that were raised. It's much worse if the objections can't be raised in the first place.