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

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.