Re: Complaint to IAB regarding a declaration of consensus to adopt a non-hybrid draft

Eliot Lear <[email protected]> Sun, 26 Apr 2026 12:06:22 +0200
Newsgroups	gmane.ietf.general
Message-ID	<[email protected]>
Hi Dan,

While I am reproducing the entirety of your message below, I am focusing 
on the following points you raised:

  * Misunderstanding of my personal views;
  * Lack of consensus on working group adoption; and
  * The role of an IETF working group chair;
  * The role of an IRTF research group chair;  and
  * "Extreme Transparency"
  * Legal arguments versus actual experience

To begin with, I have not articulated a position regarding the ML-KEM 
draft, and I won't do so here.  I have said that the IAB has freedom to 
address both technical and procedural concerns, and that is regardless 
of what your appeal actually requests.  I also have not suggested that 
anyone in this discussion or in the TLS working group is in any way a 
bad actor, but rather that our processes are intended to protect us from 
bad actors.  I am also not making any claims about WGLC.  That process, 
as I understand it, is still ongoing.

You should study further RFC 2418.  That document does not mention 
working group adoption. As a matter of practice, working groups adopt 
drafts to indicate that the work in which they are engaged.  This is 
also reflected in our tooling.  The chair here asked the precise 
questions that every other working group chair asks on adoption.  That 
is a matter of practice, not policy.

However, it is worth keeping in mind the following statement from 2418:

    It is stressed here that Internet-Drafts are working documents and
    have no official standards status whatsoever.

That's because 2418 does not recognize "working group drafts".

Your argument that all technical concerns be addressed at time of 
adoption would require that all documents going *into* the process are 
essentially in their final form, which would obviate the need for 
working groups to work on them at all.  What matters from a 2418 
perspective is the group's output.

As 2418 states, working groups generally operate via rough consensus.  
Section 3.3 of RFC 2418 states clearly:

    It is left to the discretion of the working group chair how to evaluate the
    level of consensus.

Discretion is clearly *not* clerical.  In fact it is the opposite.  This 
is as it must be because rough consensus by its very nature is a vague 
notion. This is why the IAB and IESG need to give some deference to 
chairs, lest they end up doing the chairs' work.  Even though 76% is 
mildly closer to 99% than 51%, chairs really must use their judgment to 
understand whether the draft is likely to gain rough consensus to 
publish.  As a WG chair, I would likely accept a weaker consensus to 
adopt than to publish.

In answer to your question about the IRTF, which is *not* the IETF, 
research group chairs look a bit like program committee chairs in 
academia.  In my experience, that is a bit more than clerical, because 
the chairs are often the ones who fill the room with people who are 
interested in a particular research area.

You've gotten a lot of mileage out of a web site that talks about the 
IETF operating with extreme transparency.  For what it's worth, while I 
hate using the word "extreme" so much, the sentiment is about right.  
Discussion takes place on publicly archived mailing lists and in 
meetings that are available for download, decades of standards, their 
histories, drafts, presentations, and meeting minutes are freely 
available.  The IETF pretty much set the bar for transparency.  IMHO 
A.119 was written with the IETF in mind as a positive role model for others.

Finally, I mentioned the secretary effect because it actually happened 
in another standards organization.  This involved a single misbehaving 
company.  There was no law suit, but a lot of yelling, deriding, a 
healthy helping of embarrassment, and process change as a result.  The 
case you cite is interesting, but the case I was referring to didn't 
involve collusion between companies.  The point is that those objecting 
need to actively participate in the process and demonstrate at least a 
modicum of competence in the topic.  That's how work improves.

Eliot

On 26.04.2026 02:49, D. J. Bernstein wrote:
> Eliot Lear writes:
>> I want to comment on two substantial concerns you raised:
>>   * Technical: publishing a non-hybrid draft will harm the security of
>>     the Internet.
> I said at the top of this complaint what I'm complaining to IAB about:
> namely, the TLS chairs issuing a fake claim of consensus to adopt a
> non-hybrid draft.
>
> IAB can and should set the record straight. There wasn't consensus. The
> issue isn't merely a lack of unanimity; 22 in favor and 7 against isn't
> general agreement.
>
> Even worse, there was essentially zero effort to resolve objections. The
> handling of objections is an indispensable part of reaching consensus,
> and is mandated by RFC 2418: "To achieve the goals of openness and
> fairness, such conflicts must be resolved by a process of open review
> and discussion."
>
> The chairs erred in conflating the consensus question with the question
> of whether there was, in their words, "sufficient interest to work on
> this draft". Asking about "sufficient interest" is ignoring objections;
> it's _obviously_ the wrong question.
>
> Furthermore, to avoid placing improper burdens upon people challenging
> the chair action, the chairs should have stated their rationale _at the
> outset_. It was wrong for them to skip this---to announce "it looks like
> we have consensus to adopt this draft as a working group item" without
> presenting a rationale for this claim.
>
> When the chairs were asked for their rationale, the AD should not have
> jumped in with claims about "the obvious way the consensus was validly
> called". The AD's description of the adoption call as producing "67
> responses ... vast majority was in favour of adoption ... a few
> dissenting opinions" (reminiscent of RFC 2418's example where "100
> people in a meeting" reach agreement and "only a few people on the
> mailing list disagree with the consensus of the meeting") is divorced
> from the reality of what actually happened for this spec.
>
> IESG was similarly wrong in claiming that "most" of the responses
> "professed willingness to review and contribute to the draft"; and was
> wrong in claiming that consensus is merely a matter of "sufficient
> interest in reviewing and contributing to the work".
>
> None of this requires IAB to draw conclusions as to the merits of the
> objections, such as the security objections. BCP 9 requires "a detailed
> and specific description of the facts of the dispute", so of course my
> complaint describes the objections (and the non-responses) as part of
> demonstrating the lack of _consensus_; but if you have a response to the
> _content_ of the objections then you should quote and reply to those
> objections in the TLS threads where they were raised in the first place.
>
>> it seems to me that the IAB would benefit from the process running a
>> bit longer in order for the broader community and IESG to have an
>> opportunity to evaluate the draft
> The draft never had WG consensus on adoption in the first place. By
> pretending otherwise and then issuing two "last calls" for objections to
> issuance of an RFC, the chairs have forced opponents to raise objections
> again and again. The most recent "last call" for this spec had 21 people
> stating support for issuance of an RFC and 22 people stating objections:
>
>      https://blog.cr.yp.to/20260405-votes.html
>
> Instead of acknowledging the level of opposition, the chairs declared
> their intention to run a third "last call". As one WG participant put
> it: "the WGLCs will continue until morale improves!"
>
> Every legitimate standards-development organization tracks objections
> and requires a group answer to every objection. The process we see in
> this TLS example is vastly less efficient, with no excuse whatsoever for
> the inefficiency. This isn't a big deal for companies with business
> interests in the results, but it's damaging for the public interest.
>
> You seem to be endorsing the efforts by the chairs to non-consensually
> ram this document through the WG, after which "the broader community and
> IESG" would have an "opportunity" to weigh in. This would be even worse
> than the current situation: it would mean that we would have not just a
> fake claim of WG consensus to adopt the document but also a fake claim
> of WG consensus to issue the document as an RFC. The review by IESG
> would be a review by the same committee that already endorsed a fake
> consensus claim by the chairs. The review by the "broader community"
> would have no power whatsoever over IESG. The resulting RFC would then
> be fraudulently labeled as "consensus of the IETF community".
>
>> On the procedural, in my view the role of the chair
>> and the meaning of rough consensus are intertwined.
> RFC 2418 gives the chair the task to "determine if rough consensus has
> been reached". That's the clerical responsibility of tracking what's
> happening. It isn't Humpty Dumpty-style authority to say that "rough
> consensus" means whatever the chairs think it means---in this case,
> "sufficient interest", simply ignoring objections.
>
> Back in 2014, the IRTF chair, your collaborator Lars Eggert, refused to
> remove an NSA employee as co-chair of CFRG. He quoted the IRTF rule that
> chairs "perform the administrative functions of the group" and concluded
> on this basis that "co-chairs are little more than group secretaries".
> IETF has the same rule. Do you think he was wrong?
>
>> To permit the chair role to to be viewed as merely
>> functionary would allow for gaming of the mechanisms
>> the IETF has put in place.
> There are many problems with IETF's procedures. As the current incident
> illustrates, centralizing control makes the problems even worse.
>
>> Precisely because anyone can participate, if random email addresses
>> simply helicopter in, claim "I object for reasons stated [elsewhere]",
>> and then helicopter out, any and all work could literally be stymied
>> by a single individual or small number of bad actors.
> Are you saying that
>
>      * Stephen Farrell ("I'm opposed to adoption, at this time"),
>
>      * Rich Salz ("I was all set to say that I am in favor of adoption,
>        but Stephen's post changed my mind. [paragraph break] The
>        conservative and safe thing is to stick to hybrids and that is
>        what the IETF should do for now"),
>
>      * Thomas Bellebaum ("I agree with Stephen on this one and would not
>        support adoption of non-hybrids"),
>
>      * Sun Shuzhou ("I'm opposed to adoption"),
>
>      * Andrey Jivsov ("I am opposed to the adoption of ML-KEM at this
>        time"),
>
>      * Rob Sayre ("I oppose adoption"),
>
> and I were "bad actors" helicoptering in to "stymie" adoption? Are you
> saying that the 22 people who filed objections in response to the most
> recent WGLC for the same document are "bad actors"? Also, regarding
> "small number", are you saying that
>
>      https://www.eff.org/files/2014/04/09/20130905-guard-sigint_enabling.pdf
>
> describes a perfectly acceptable type of corruption of cryptographic
> standardization processes since it has a very large budget that can pay
> for many people?
>
> IETF claims that "IETF activities are conducted with extreme
> transparency, in public forums. Decision-making requires achieving broad
> consensus via these public processes." IETF prominently labels every
> WG-issued RFC as having "consensus of the IETF community". You can't
> have it both ways, claiming that everything has consensus but then
> attacking dissenters.
>
>>   * The Secretary Effect: A company literally sent a secretary and as
>>     many others as they could to vote on a particular ballot.  When this
>>     was learned, the SDO evolved its rules to establish attendance
>>     requirements.  We do not have, nor do we want, such requirements.
> Actually, what happened was a lawsuit, culminating in the Supreme Court
> emphasizing the importance of "safeguards sufficient to prevent the
> standard-setting process from being biased by members with economic
> interests in restraining competition". The full decision is well worth
> reading:https://supreme.justia.com/cases/federal/us/486/492/
>
> Legitimate SDOs then converged on a core set of safeguards, including
> openness, a balance of interests, due process, an appeals process, and
> consensus---where consensus _can_ allow non-unanimous decisions but
> always requires general agreement, fair consideration of each comment,
> a process of attempting to resolve each objection, and documentation,
> for any objection that was not resolved but that was instead overridden
> by general agreement, of _why_ that objection was overridden.
>
> What the culprits (Allied Tube and their co-conspirators) exploited in
> the case you're alluding to was the failure of the standards-development
> organization (NFPA) to ensure a balance of interests. One sees the same
> type of failure when a cartel of NSA contractors dominates an IETF WG
> decision. IETF doesn't even _try_ to make sure that the public interest
> in stopping attacks is adequately represented.
>
> Describing this as being about "attendance requirements" is doing a
> spectacular job of missing the point.
>
>> The only sure fire safe guard we have against this
>> sort of gaming is to empower the chairs
> Here's another Supreme Court case illustrating how chair power invites
> corruption:https://supreme.justia.com/cases/federal/us/456/556/
>
>> as we have
>> done, to use their judgment as to whether rough
>> consensus has been reached.
> Why are you not quoting the actual RFC 2418 text? RFC 2418 says "It is
> up to the Chair to determine if rough consensus has been reached". The
> relevant meaning of "determine" is "find out by investigation" (see
> https://www.merriam-webster.com/dictionary/determine meaning 4). That's
> a clerical responsibility of observing the facts, as I said.
>
>> Their judgment can be
>> checked through the appeals process, but appellant
>> bodies must give some deference to those who are
>> directly managing the situation.
> "Must"? RFC 2418 says that chairs "manage the group process" but it also
> says there are "procedures for requesting a review of WG, Chair, Area
> Director or IESG actions". Where does it say that this review has to
> provide "deference" to the chairs? Sounds to me like (1) a bad idea,
> begging for abuse, and (2) not what IETF rules say.
>
>> Indeed you quoted a very
>> specific way in which one of your objections *was*
>> addressed by quoting someone representing a vendor.
> To clarify, you're alluding to the part of my complaint where I said
> "There was a response to one word in the lack-of-principles objection"?
>
> The lack-of-principles objection was from Stephen Farrell. The response
> was by an employee of a vendor---a vendor that triple-voted in the most
> recent TLS procedural abuse---but IETF claims that people participate as
> individuals. Anyway, I tried engaging that person in discussion on list,
> and there was no reply. (Within the chart in
>
>      https://blog.cr.yp.to/20260221-structure.html
>
> of arguments and counterarguments, I was replying to the "cannot be true
> at the same time" claim; in an engineering organization, this would have
> been easily resolved.)
>
> More to the point, as I wrote right after this in my complaint: "A brief
> note by one supporter tangentially related to one objection falls far
> short of fair consideration of each objection by the group as a whole."
>
>> That we should document what are implementing is in my
>> view a *primary* function of the RFC series, though it
>> need not be the primary function of standards.
> Advocating documentation of what someone is implementing is circular as
> a response to safety concerns. More to the point, your advocacy of the
> spec isn't addressing my complaint about the fake consensus call.
>
>> The draft can contain a clear warning on the
>> risks of the technology.
> It would be better to have a separate document that focuses on the
> warning, like various earlier RFCs discouraging other poor practices.
> But this discussion of options is again missing the point. There is no
> WG consensus on _any_ action here---not even adoption.
>
>> The working group has addressed the risk of non-hybrid KEMs in Section
>> 5 of the document.
> No, the _working group_ has not taken any action here. Furthermore, all
> text that I've seen from the _author_ has been wildly exaggerating the
> benefit while downplaying the safety risks.
>
>> Is 22:7 rough consensus?  I can't and won't say, and
>> neither should the IAB solely based on that number.
> That doesn't even qualify as "general agreement", never mind the other
> requirements for consensus. See Section 7 (#consensus) of my complaint.
>
>> The chairs have the context.  They know who of those
>> 29 people are real and active participants and are
>> bringing new issues to the fore.  The further away
>> from the working group you get, the less context the
>> appellant body has.
> "IETF activities are conducted with extreme transparency, in public
> forums. Decision-making requires achieving broad consensus via these
> public processes."
>
> The appeals body can and should independently review the records of what
> happened, and undo the chairs' fake declaration of consensus. It's not a
> good look to say ~"we're lazy, we'll trust the chairs".
>
> The chairs have had ample opportunity by now to speak up with any
> supposedly missing context. Did they claim, e.g., that the people who
> raised objections aren't "real and active participants", and that this
> somehow allows the objections to be ignored? No. Did they claim that
> that any conflicts had been "resolved by a process of open review and
> discussion" (as required by RFC 2418)? No. Did they claim that there
> was general agreement to adopt the document? No.
>
> Here's what the chairs _did_ say: "Joe and I, as WG chairs and with
> Deirdre recusing as she is an author, declared consensus to adopt
> draft-connolly-tls-mlkem-key-agreement. We did this because there is
> clearly sufficient interest to work on this draft. ... 'Sufficient' to
> Joe and I means that there were enough people willing to review the
> draft."
>
> This is a glaring error in evaluating consensus. It's simply ignoring
> objections. But the chairs refuse to correct this error, one AD refuses
> to comment (despite BCP 9 requiring both ADs to attempt to resolve the
> dispute), the other AD refuses to correct this error, and the full IESG
> endorses this error. So now we're at the IAB stage.
>
>> What the IAB can pass judgment on
>> is whether all issues raised were addressed and
>> whether the IESG handled your lower level appeals
>> appropriately.
> BCP 9 says that IAB shall "review the situation" and then decide what to
> do. BCP 9 doesn't authorize IAB to narrow its review in the way that
> you'd like.
>
>> Finally, an ISEish comment: The ISE has before him the
>> CNSA 2.0 drafts (see draft-*-cnsa2*).  Any and all
>> reviews are welcome (please send them to
>> [email protected]).  No publication decision has
>> been made at this time.
> Thanks for the heads-up. The objections on security grounds to NSA's
> push for non-hybrids apply to these documents too. The independent
> stream doesn't claim IETF consensus, but purchasing managers will often
> understand the mere word "RFC" as IETF endorsement.
>
> ---D. J. Bernstein
>
>
> ===== NOTICES =====
>
> IETF BCP 78, "Rights Contributors Provide to the IETF Trust", provides a
> modification right "unless explicitly disallowed in the notices
> contained in a Contribution (in the form specified by the Legend
> Instructions)".
>
> The official language from IETF's "Legend Instructions"
> for the situation that "the Contributor does not wish to allow
> modifications nor to allow publication as an RFC" is as follows: "This
> document may not be modified, and derivative works of it may not be
> created, and it may not be published except as an Internet-Draft."
> <https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>
>
> The same language is used in, e.g., RFC 5831. The same language hereby
> applies to this document. This is not disclaiming or limiting the
> applicability of IETF policies; it is strictly following IETF policies.
>
> Rationale: I'm fine with redistribution of copies of this document. The
> issue is with modification, such as (1) IESG's May 2025 posting of an
> IESG-mangled version of an appeal that I had filed and (2) IETF
> management selling IETF mailing-list text to AI companies.
>
OpenPGP_0x87B66B46D9D27A33.asc (application/pgp-keys, 2.6 KB)
OpenPGP_signature.asc (application/pgp-signature, 495 B)