[Last-Call] Re: [TLS] Complaint to ADs and IESG regarding TLS WG chairs falsely claiming WG consensus to issue an RFC for draft-ietf-tls-mldsa

[Nadim Kobeissi <[e-mail]>]

I am writing this as someone who supported Prof. Bernstein’s previous, unrelated (for lack of a better term) litigation against the so-called “rough consensus” that was declared regarding the introduction of pure ML-KEM key agreement in TLS 1.3. My position was at the time, and continues to be, that such “rough consensus” never existed and I am glad to see that that decision was (this might be a procedurally imprecise term) reversed. Pure ML-KEM isn’t right for TLS when we have already deployed hybrid key agreement that employs the best of both pre-quantum and post-quantum cryptography.

While Prof. Bernstein’s work in pointing out the many procedural errors in the hybrid-vs-pure-key-agreement issue, it is my personal opinion that his employment of the same litigation tactics here in the context of ML-DSA is highly exaggerated and counterproductive.

There has to be a limit. There is a time for fighting, when nobody wants to hear what is right, but there is also a time for consensus-building.

These dynamics upset me. I genuinely believe that everyone on this list, including Prof. Bernstein as well as, say, Soatok, have many intelligent and good things to contribute.

However, I am often bitterly disappointed by many intellectual and personal shortfalls displayed on this list, which certainly must include my own.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 19 May 2026, at 1:28 PM, D. J. Bernstein <[e-mail]> wrote:
> 
> The TLS WG chairs wrote "The chairs have judged that there is consensus
> to progress this I-D." But there wasn't consensus; not even close. There
> also wasn't "rough consensus".
> 
> I'm hereby complaining to the security ADs (not just the one coming from
> NSA) under RFC 2026, Section 6.5, about the chairs' false declaration of
> consensus. I'm hereby asking the ADs to reverse this declaration, and to
> withdraw the forwarding to IESG of this declaration and spec.
> 
> I am, of course, not requesting parallel review by IESG of the lack of
> merits of the chair declaration. However, I'm hereby complaining to IESG
> that IESG's "last call" is based on a _disputed_ claim from the WG
> chairs and that the dispute has not yet been resolved. Procedurally,
> "last call" is threatening to sabotage the RFC 2026 appeal processes, is
> threatening to produce a non-consensual RFC falsely claiming consensus,
> and is adding further burdens to people objecting---people who have
> already been forced by previous chair abuses to state objections again
> and again and again. The damage here is far worse than the damage done
> by delaying issuance of an RFC during an appeal process. I'm hereby
> asking IESG to immediately withdraw the "last call" and to wait for
> completion of the appeals allowed by RFC 2026.
> 
> This complaint is organized as follows:
> 
> 1. The level of opposition to this spec
> 2. The level of support for this spec
> 3. The failure to resolve objections
> 4. The lack of consensus
> 5. The lack of "rough consensus"
> 6. Further violations of RFC 2418 and RFC 2026
> 7. Chair mishandling of complaints regarding the consensus claim, part 1
> 8. Chair mishandling of complaints regarding the consensus claim, part 2
> 9. Next steps
> 
> The last three sections include a review of the chairs insisting that
> their consensus claim was correct despite being challenged, and, within
> minutes, taking further action on this basis, evidently terminating the
> discussion. Escalation to the ADs is thus authorized under RFC 2026,
> Section 6.5. This is well within RFC 2026's two-month deadline.
> 
> 
> ## 1. The level of opposition to this spec
> 
> The chairs sent email to the WG mailing list on 9 April 2026 issuing
> "last call" at the WG level regarding issuance of an RFC for non-hybrid
> ML-DSA in TLS.
> 
> Contrary to what readers would expect from a "last call" for objections,
> there were already many objections stated on list _before_ 9 April 2026
> to all TLS usage of non-hybrid post-quantum cryptosystems. For example:
> 
> * Izzy Grosof wrote (along with further explanation): "The performance
>  improvements of a non-hybrid approach are trifling; the security risks
>  are immense ... Do not endorse or standardize any non-hybrid
>  post-quantum cryptosystem, via this document or any other."
> 
> * Tibor Jager wrote "I expressed that I do not support any draft that
>  does not use hybrid crypto, and provided concrete arguments why. ...
>  Many other cryptosystems have received considerable analysis before
>  they were broken."
> 
> * Christoph Striecks, quoting an earlier message from Tibor Jager that
>  said "currently do not support any draft that does not use hybrid
>  cryptography" etc., wrote "+1 on Tibor's thoughts".
> 
> * I wrote that "an RFC allowing non-hybrid PQ would be incurring
>  security risks---and frivolously doing so, since ECC+PQ has negligible
>  extra cost. ... my objection is not limited to the proposal of
>  non-hybrid ML-KEM in TLS; it also applies to, e.g., the proposal to
>  use non-hybrid ML-DSA in TLS."
> 
> Many objections were already stated by February 2026. The chairs had
> issued a "last call" for non-hybrid ML-KEM in TLS. 22 people filed
> objections to that: Andrey Jivsov, Christoph Striecks, Daniel J.
> Bernstein (me), David Stainton, Fabiana da Pieve, Ivan Visconti, Izzy
> Grosof, Jacob Appelbaum, John Mattsson, Joshua Nabors, Kurt Roeckx,
> Ludovic Perret, Muhammed Usama Sardar, Nadim Kobeissi, Nicola Tuveri,
> Rob Sayre, Simon Josefsson, Stephen Farrell, Tanja Lange, Thomas
> Bellebaum, Tibor Jager, Watson Ladd. (Quotes and links are collected in
> https://blog.cr.yp.to/20260405-votes.html.) The rationales stated for
> many of the objections (not all) were also applicable to non-hybrid
> ML-DSA in TLS.
> 
> Unfortunately, the chairs have never admitted the level of opposition
> here. They did promise that previously stated positions would be taken
> into account unless retracted ("If you did not recommend changes, then
> your position will remain the same, unless you state that you are
> reconsidering") but they later reneged upon this promise (see below).
> 
> In April 2026, despite the level of objections that had already been
> stated to non-hybrid post-quantum systems in TLS, the chairs suddenly
> issued their "last call" for non-hybrid ML-DSA in TLS. Beyond the people
> quoted above _already_ stating categorical objections to non-hybrid
> post-quantum systems in TLS, objections appeared on list specifically in
> response to this "last call" from 10 further people: David Stainton,
> Fabiana Da Pieve, Jacob Appelbaum, Ludovic Perret, Muhammad Usama
> Sardar, Nicola Tuveri, Simon Josefsson, Stephen Farrell, Tanja Lange,
> and Thomas Bellebaum.
> 
> Given previous behavior by the chairs, I did not trust the chairs to
> continue counting my objection, so I sent email to the list and to the
> chairs to object in response to the "last call". The chairs censored
> this message, so it did not appear on the list, but they certainly
> received it, and in any case I was already on record objecting.
> 
> To summarize, before the end of the specified "last call" period for
> non-hybrid ML-DSA in TLS, the following 14 people went on record
> objecting to non-hybrid ML-KEM in TLS _and_ objecting to non-hybrid
> ML-DSA in TLS:
> 
> 1. Christoph Striecks
> 2. Daniel J. Bernstein (me)
> 3. David Stainton
> 4. Fabiana Da Pieve
> 5. Izzy Grosof
> 6. Jacob Appelbaum
> 7. Ludovic Perret
> 8. Muhammad Usama Sardar
> 9. Nicola Tuveri
> 10. Simon Josefsson
> 11. Stephen Farrell
> 12. Tanja Lange
> 13. Thomas Bellebaum
> 14. Tibor Jager
> 
> My understanding is that Sardar's objection was later withdrawn. This
> does not rescue the chair claim of consensus.
> 
> 
> ## 2. The level of support for this spec
> 
> By my count, 37 people stated support for this spec on list before the
> end of the specified "last call" period. This includes, for example,
> three Google employees (David Adrian, David Benjamin, and spec coauthor
> Sophie Schmieg) and an NSA employee whose name has never shown up on the
> TLS mailing list before (Nicholas Gajcowski).
> 
> NSA is on record pressuring its "vendors" to support non-hybrids (for
> example, regarding non-hybrids, writing "If there is one vendor that
> produces one product that complies, then that is the product that goes
> on the compliance list and is approved for use. Our interactions with
> vendors suggests that this won't be a problem in most cases"). Most,
> although not all, of these 37 people are employees of NSA's vendors.
> 
> This is glaringly corrupt. It is completely contrary to IETF claiming
> to be a "_neutral_ standards body" in which "participants cannot exert
> influence as they could in a pay-to-play organization".
> 
> A legitimate standards-development organization would have, and would
> enforce, anti-corruption procedures. IETF instead encourages corruption
> by ignoring the primary conduits for corruption: for example, IETF says
> that people participate as individuals, not as company representatives.
> My understanding is that IETF does not have any mechanism to appeal
> documented instances of corruption or of an imbalance of interests; I'm
> hereby asking the ADs to let me know if there is such a mechanism. This
> complaint instead focuses on the false claim of consensus.
> 
> For double-checking, the 37 people are as follows: Andrei Popov,
> Christopher Patton, Corey Bonnell, Daniel Apon, Daniel Van Geest, David
> Adrian, David Benjamin, Dennis Jackson, Filippo Valsorda, Ilari
> Liusvaara, Jack Grigg, Jan Schaumann, John Mattsson, Jonathan Hammell,
> Joseph Birr-Pixton, Joshua Nabors, Kris Kwiatkowski, Loganaden
> Velvindron, Marc Penninga, Martin Thomson, Nadim Kobeissi, Nicholas
> Gajcowski, Peter Campbell, Quynh Dang, Rich Salz, Robert Relyea, Russ
> Housley, Scott Fluhrer, Soatok Dreamseeker, Sophie Schmieg, Thom
> Wiggers, Tim Hudson, Tirumal Reddy, Viktor Dukhovni, Wang Giulin, Yaakov
> Stein, Yaroslav Rosomakho.
> 
> 37 people is more than 14 people. However, it is not WG consensus. It is
> not even WG "rough consensus". What happened here violates IETF rules.
> See below.
> 
> 
> ## 3. The failure to resolve objections
> 
> Many objections were raised on list to non-hybrids in TLS. One
> objection, a procedural objection to the lack of "FATT" review of this
> spec, appears to have been resolved.
> 
> Many more objections have not been resolved. None of these objections
> have received a group response. Some objections have received individual
> responses; others have not. Some of the individual answers obviously
> cannot reach group agreement.
> 
> For example, one proponent answered security objections to non-hybrids
> by claiming that nobody outside NSA would use non-hybrid ML-KEM in TLS
> so any breaks will be "not impacting anyone else". Meanwhile another
> proponent claimed that deploying ECC+ML-KEM in TLS, rather than
> non-hybrid ML-KEM in TLS, would require a subsequent "large-scale
> engineering effort" for his company and would "consume literal years of
> my life". As these quotes illustrate, the case stated for non-hybrids is
> a pile of wildly incoherent claims regarding what's happening here.
> 
> The claims I'm quoting haven't been withdrawn. Both of them are wrong:
> there's overwhelming evidence that the non-hybrid specs are aimed at
> changing behavior outside NSA; meanwhile the "large-scale engineering
> effort" text is attacking a strawman. But my point isn't simply that the
> case for the spec is full of errors; my point is that _the working
> group_ hasn't settled on a case for the spec, and hasn't even tried,
> which is why one finds proponents stating irreconcilable arguments for
> the spec.
> 
> For this complaint, there's no need to go systematically through points
> and counterpoints (see https://blog.cr.yp.to/20260221-structure.html)
> One of the requirements of consensus is for _each_ overridden objection
> to receive an official response (see Section 4 below), so one example of
> an improperly handled objection shows that there wasn't consensus. RFC
> 2418 has a more stringent rule, requiring conflicts to be "resolved by a
> process of open review and discussion" (see Section 6 below).
> 
> 
> ## 4. The lack of consensus
> 
> The Longman dictionary says that "consensus" is "an opinion that
> everyone in a group agrees with or accepts". There are ample resources
> available such as https://www.seedsforchange.org.uk/shortconsensus
> explaining the process and value of building consensus, while
> emphasizing that consensus means unanimous acceptance.
> 
> With this concept of consensus, obviously the chairs were wrong in
> claiming consensus. But this is not the end of the analysis. The word
> "consensus" can be used in less stringent ways: for example, another
> source says that "consensus" can be "general agreement : unanimity" or
> "the judgment arrived at by most of those concerned".
> 
> Legitimate standards-development organizations need clear,
> well-documented procedures to protect against errors and abuse. These
> organizations converged many years ago on a concept of "consensus" that
> _can_ allow non-unanimous standards but that still imposes important
> procedural constraints to protect the interests of minorities. The
> central requirements are as follows:
> 
> * 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.
> 
> For example, the ISO/IEC Directives say "Committees are required to
> respond to all comments received"; define "consensus" as "General
> agreement, characterized by the absence of sustained opposition to
> substantial issues by any important part of the concerned interests and
> by a process that involves seeking to take into account the views of
> all parties concerned and to reconcile any conflicting arguments"; and
> say "Consensus, which requires the resolution of substantial objections,
> is an essential procedural principle and a necessary condition for the
> preparation of International Standards that will be accepted and widely
> used". Similar comments apply to ANSI, ASME, etc.
> 
> _None_ of these requirements were met when the TLS chairs claimed WG
> consensus to issue an RFC on non-hybrid ML-DSA in TLS:
> 
> * The working group did not reach general agreement on this action. The
>  relevant meaning of "general" from the Longman dictionary is "shared
>  by or affecting most people, or most of the people in a group"; "most"
>  means "nearly all of the people or things in a group, or nearly all of
>  something". 37 people is not "nearly all" of the 51 people who spoke
>  up---and it's only a small minority of the TLS working group.
> 
> * There was not fair consideration of each comment. There was not a
>  process of attempting to resolve each objection. There was not
>  documentation, for each objection, of why that objection was
>  overridden. Fundamentally, conflict resolution was replaced by a
>  voting process.
> 
> When the chairs claimed WG consensus, they were providing false
> information to essentially all readers, including readers who expect the
> word "consensus" to mean unanimity, readers who expect it to mean
> general agreement, and readers familiar with how legitimate
> standards-development organizations operate.
> 
> It doesn't matter here whether another definition of "consensus" for
> IETF insiders is buried somewhere in IETF documents (I'll discuss "rough
> consensus" below). IETF management's claims of consensus are _public_
> statements and need to avoid deceiving a general audience.
> 
> 
> ## 5. The lack of "rough consensus"
> 
> RFC 2418 includes some absolute requirements for WG decisions. One of
> them is to reach at least "rough consensus".
> 
> This did not happen for draft-ietf-tls-mldsa. The numbers for this "last
> call" (37 in favor, 14 opposed) are nothing at all like 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".
> 
> RFC 2418 states that "51% of the working group does not qualify" as
> "rough consensus". This does not merely say that 51% _of the people
> responding_ does not qualify; it says that 51% _of the working group_
> does not qualify.
> 
> In this case, 37 people is very far below 51% of the TLS working group,
> so it is very far below the level of support that RFC 2418 says is
> _still_ not enough. Declaring consensus violated this RFC 2418 rule.
> Declaring "rough consensus" would also violate this RFC 2418 rule.
> 
> (Just to be clear about who counts as part of the WG: IETF says in
> https://web.archive.org/web/20250603130154/https://www.ietf.org/about/introduction/
> that "Anyone can participate by signing up to a working group mailing
> list". RFC 2418 says the same: "Participation is open to all. This
> participation may be by on-line contribution, attendance at face-to-face
> sessions, or both. Anyone from the Internet community who has the time
> and interest is urged to participate in IETF meetings and any of its
> on-line working group discussions." So, according to the rules, even
> NSA's Nicholas Gajcowski counts as a participant---as do hundreds of
> people who _have not_ stated support for this spec.)
> 
> Furthermore, saying that "rough consensus" is _required_ doesn't mean
> that it's _sufficient_. The notion that it's _sufficient_ is directly
> contradicted by other IETF statements. For example:
> 
> * IETF prominently claims that it does not vote.
> 
> * IETF also prominently claims that its "decision-making requires
>  achieving broad consensus".
> 
> * Every WG-issued RFC claims "consensus of the IETF community". This
>  doesn't say "rough". It doesn't say "majority support". It doesn't say
>  "support of a majority within the people who spoke up on a WG mailing
>  list during a two-week WG last call".
> 
> The chairs claimed consensus. This claim is fraudulent and needs to be
> retracted for the record. If it is retracted and replaced by a claim
> that "rough consensus" suffices then the subsequent claim of "consensus
> of the IETF community" will be fraudulent. My complaint is primarily
> about the dishonesty here, where a controversial document is being
> non-consensually rammed through IETF and falsely labeled as consensus.
> 
> To be clear, dishonesty is not the only problem here. From a security
> perspective, security-damaging specs should not be allowed as any type
> of RFC, even something as minimal as an independent-stream RFC that
> makes no claims regarding consensus. Purchasing managers frequently
> specify RFCs without checking the wording of the RFCs.
> 
> (On 3 April 2026, Eric Rescorla wrote "I think it's clear that many
> regard the publication of an RFC by the TLS WG as a form of endorsement,
> even when Recommended=N ... this is precisely why the publication of
> some documents has become so controversial". People who don't actually
> read RFCs won't see "Recommended=N"---and also won't see whether those
> are WG documents in the first place.)
> 
> Having said that: False claims of consensus make the situation much
> worse, actively deceiving readers regarding what happened. These claims
> need to be corrected for the record.
> 
> 
> ## 6. Further violations of RFC 2418 and RFC 2026
> 
> Another RFC 2418 requirement that has been violated here, perhaps the
> most fundamental requirement, is the following: "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."
> 
> This mandated resolution process did not occur here. This isn't just a
> question of what happened during the April 2026 "last call": most of the
> objections were already raised earlier and still haven't been resolved.
> 
> Part of the responsibility of the chairs is to track disputes and
> enforce the "must be resolved" rule, so that spec proponents are forced
> to build consensus. What the chairs have instead been doing is issuing
> one "last call" after another while not acknowledging most of the
> objections to these non-hybrid specs.
> 
> For rich companies, it's no problem to pay employees to flood the IETF
> process with redundant support statements (and the costs are even less
> noticeable since the chairs allow one-line support statements). People
> acting in the public interest very often can't afford redundant work,
> and yet the chairs are demanding that objections be stated and explained
> again and again. RFC 2418 does not allow burdens to be shifted in this
> way: it requires the WG to resolve objections by a process of open
> review and discussion.
> 
> Furthermore, the chair censorship of my objections violates the openness
> component of the "open review and discussion" requirement in RFC 2418.
> The chairs claim, falsely, that my messages are "disruptive". I'm
> following the RFC 2418 process by raising objections; the chairs are
> sabotaging this process by censoring objections.
> 
> The chairs are also violating RFC 2026. As background, the spec in
> question is related to (and normatively cites) the TLS 1.3 spec, which
> is on the IETF standards track. This makes the spec "standards-related",
> bringing the chair discussion of the spec within RFC 2026's rule that
> the public record of IETF's "standards-related activity shall include at
> least the following: ... complete and accurate minutes of meetings; ...
> all written contributions from participants that pertain to the
> organization's standards-related activity". Obviously the chairs had a
> discussion of whether to issue a "last call" and of how to handle the
> results, but the records of those discussions aren't publicly available.
> This secrecy makes the appeal process unnecessarily difficult and
> violates RFC 2026.
> 
> 
> ## 7. Chair mishandling of complaints regarding the consensus claim, part 1
> 
> The chairs sent email dated 28 Apr 2026 16:24:37 -0400 stating "The
> chairs have judged that there is consensus to progress this I-D." The
> chairs gave no explanation for this astonishing claim.
> 
> At least six people (including me) challenged this claim of consensus.
> For example, Stephen Farrell wrote "that's a terse summary of a
> surprising conclusion", and Nadim Kobeissi wrote "I voted *for* this
> draft and even I'm surprised there was consensus."
> 
> The chairs responded on 6 May 2026 as follows: "In this case, during
> WGLC there was an almost 4:1 ratio for progressing this draft, which we
> judge fits within the numeric 'more than 51% and less than 99%' range
> suggested by this text for 'rough consensus' and represents the
> 'dominant view of the working group'."
> 
> There are several serious problems with this chair statement:
> 
> * Even after the vote-packing by NSA's "vendors", the actual ratio was
>  37/14, approximately 2.64. Calling this "almost 4:1" is ludicrous.
> 
> * Anyone who sees the actual numbers realizes how important the phrase
>  "during WGLC" is: the chairs are manipulating the numbers by throwing
>  away objections that were already filed before the WGLC began. This
>  discarding of objections is grossly improper---as noted above, people
>  objecting have been forced to state objections again and again and
>  again---and violates the chairs' specific promise that "If you did not
>  recommend changes, then your position will remain the same, unless you
>  state that you are reconsidering". All objections received before the
>  end of the specified WGLC period must be counted, _including_ the ones
>  that were already filed _before_ the WGLC was issued.
> 
> * Even _with_ the manipulation of numbers to disregard the objections
>  filed before WGLC by Izzy Grosof, Tibor Jager, and Christoph Striecks,
>  there were objections from 11 further people _during_ WGLC. The ratio
>  37/11, approximately 3.36, is not "almost 4:1".
> 
> * If the chairs _also_ disregard the objection that I sent to the list
>  during WGLC and that the chairs censored, then the ratio turns into
>  37/10 = 3.7, which in isolation can defensibly be described as "almost
>  4:1". But normal readers seeing the chairs claiming "an almost 4:1
>  ratio for progressing this draft" would be astonished to learn that
>  this relies on the chairs unilaterally disregarding some objections.
> 
> * The chairs didn't provide the lists of names that supposedly justify
>  their claims about what happened. It's already inexcusably error-prone
>  that the chairs didn't list names from the outset for something that
>  wasn't unanimous. After WG participants challenged the chair claim of
>  consensus, continuing to hide the lists was an assault against the
>  concept of independent review of chair actions.
> 
> * RFC 2418 says that "51% of the working group does not qualify as
>  'rough consensus' and 99% is better than rough". The chairs fabricated
>  a quote "more than 51% and less than 99%" (in quotation marks). Notice
>  that this omits "of the working group". The chairs falsely portrayed
>  the RFC 2418 rule as referring merely to percentages of the people
>  who spoke up. This fabrication by the chairs is important because, as
>  noted above, 37 people is above 51% of the people who spoke up but far
>  below 51% of the working group.
> 
> * As a separate issue, allowing anything "within the ... range" means
>  that 51.1% is okay since 51.1% is above 51%. But that's an insane
>  interpretation of RFC 2418. RFC 2418 says that "99% is better than
>  rough"; it gives an example where "100 people in a meeting" reach
>  agreement and "only a few people on the mailing list disagree with the
>  consensus"; the fact that RFC 2418 considers only such extreme cases
>  suggests a 95% cutoff. The choice of examples in RFC 2418 would make
>  no sense if 51.1%---or 72.5%---were acceptable.
> 
> * To the extent that there are ambiguities in RFC 2418 being exploited
>  by the chairs, that's a due-process violation and an abuse of power.
>  Standardization needs to follow clear rules, not dictators.
> 
> Back in 2014, the IETF subsidiary IRTF refused to remove an NSA employee
> as co-chair of CFRG. This refusal was by the IRTF chair, who quoted IRTF
> rules stating that co-chairs "perform the administrative functions of
> the group", and who concluded that "co-chairs are little more than group
> secretaries. Their ability to influence the technical work of the group
> is little different from that of any other group participant". (See
> <https://mailarchive.ietf.org/arch/msg/cfrg/Aqe9HaZQ4JStGeXeWujt6hLS6uU/>.)
> 
> But IETF rules, just like IRTF rules, state that co-chairs merely
> "perform the administrative functions of the group"! See RFC 2418.
> 
> If the TLS WG chairs can declare "consensus" on a controversial
> document, then it's _not_ true that they are merely performing
> "administrative functions", it's _not_ true that they are "little more
> than group secretaries", and it's _not_ true that their "ability to
> influence the technical work of the group is little different from that
> of any other group participant".
> 
> I agree with the chairs that RFC 2418 says that "the dominant view of
> the working group shall prevail". However, trying to use this to justify
> a decision is circular: the relevant meaning of the word "dominant" is
> "commanding, controlling, or prevailing over all others". More to the
> point, this cannot justify violating clear RFC 2418 rules, exaggerating
> the level of support for the spec, and falsely claiming consensus.
> 
> 
> ## 8. Chair mishandling of complaints regarding the consensus claim, part 2
> 
> The 6 May 2026 message from the chairs continued as follows: "In
> assessing rough consensus, we also considered the nature of the
> objections. In reviewing the list traffic, the majority of objections
> related to the status of pure MLDSA versus composite MLDSA-ECC,
> including (1) we should not publish a pure MLDSA specification at all;
> (2) we should recommend composites over pure MLDSA; (3) we should
> publish the composite and pure MLDSA specifications concurrently."
> 
> WG consensus requires general WG agreement, fair WG consideration of
> each comment, a WG process of attempting to resolve each objection,
> etc.; see Section 4 above. Merely having the chairs describe objections
> falls far short of this.
> 
> Furthermore, what the chairs wrote here is merely a summary of possible
> ways forward, not a summary of objections to the specific option that
> the chairs are pushing. There is no evidence backing up the chair claim
> to have "considered the nature of the objections". A reader cannot even
> see from the chair messages that there are _security_ objections to the
> spec at issue.
> 
> The chairs continued with generic claims that "the discussion on-list
> sufficiently aired the respective points of view", that "the right
> approach is fundamentally a judgment call", and that the chairs "see no
> reason to believe that participants were not able to make informed
> judgements".
> 
> In fact, for this spec, there was not sufficient airing of the
> respective points of view. Some ad-hoc arguments for this spec,
> supposedly very important arguments, were suddenly raised during WGLC,
> not leaving enough time for resolution. For example:
> 
> * During WGLC there were suddenly claims on list that for double-signing
>  with ECC+PQ the "complexity cost is vastly higher than hybrid key
>  exchange" since "Composite keys leak all over the API and
>  application/configuration layer" and these keys complicate "X.509
>  authentication"; "Having to store and apply two keys at the same time
>  will, as Filippo pointed out, propagate throughout the entire
>  library"; "enormous API complications"; "makes the cost of this
>  security blanket much higher"; etc.
> 
> * There were responses saying that, no, this supposed complexity
>  difference does not exist; the API and the calling code use ECC+PQ in
>  exactly the same way that they would use non-hybrid PQ; "Of course it
>  would internally have multiple keys, but that's no different from
>  existing algorithms whose keys have multiple components (e.g., RSA)";
>  "in no case would you have to explicitly worry about multiple keys at
>  the application layer"; "I implemented Composite ML-DSA in an OpenSSL
>  provider and it Just Worked. No X.509 changes. No TLS changes.";
>  "crazy amount of mis-understanding of composites on display here";
>  etc.
> 
> This debate wasn't resolved. Bogus complexity claims from proponents of
> the spec were not retracted. Instead proponents ran out the clock, using
> a time-limited voting process to skip resolution. The complexity debate
> is just one example; various further arguments that suddenly appeared
> during WGLC didn't even have time for discussion.
> 
> RFC 2418 requires conflicts to be "resolved by a process of open review
> and discussion". It does _not_ say "resolved by a process of open review
> and discussion or, alternatively, ignored because of time limits imposed
> by the chairs". Having resolution sabotaged by a WGLC time limit
> violates RFC 2418.
> 
> I agree with the chairs that _some_ objections were sufficiently aired.
> They were aired _by 14 people_ (see list of names above). There wasn't
> general WG agreement; ergo, there wasn't WG consensus.
> 
> The chairs have never admitted the level of opposition. Their "almost
> 4:1" claim wildly exaggerates the level of support.
> 
> The fact that objections were aired is also what triggers further
> requirements that were violated here, including
> 
> * the consensus requirement to _try_ to resolve objections,
> * the consensus requirement to document an official response to any
>  unresolved objection that is overridden by general agreement, and
> * the RFC 2418 requirement to _resolve_ objections.
> 
> Instead of addressing the question of whether there was consensus (and
> the rules question of whether RFC 2418 was obeyed), the chairs wandered
> off into generic claims about people making their own decisions. And yet
> the chairs closed by insisting that there was consensus.
> 
> Three minutes after sending that message, the chairs sent email to one
> of the security ADs requesting "publication of draft-ietf-tls-mldsa-03"
> and falsely describing this as "on behalf of the TLS working group".
> 
> 
> ## 9. Next steps
> 
> We are now past the "first discuss the matter with the Working Group's
> chair(s)" procedure in RFC 2026, Section 6.5. RFC 2026 provides an
> appeal provision: "If the disagreement cannot be resolved in this way,
> any of the parties involved may bring it to the attention of the Area
> Director(s) for the area in which the Working Group is chartered. The
> Area Director(s) shall attempt to resolve the dispute."
> 
> One of the unfortunate aspects of this provision is the extreme nature
> of the phrasing "cannot be resolved". The chairs did not explicitly say
> that they were terminating the discussion, and did not say that this can
> now be appealed to the ADs. But the chairs insisted on their (wrong)
> position and took (improper) action on that basis---triggering a final
> IESG "last call" with a time limit of mere weeks.
> 
> The chairs cannot be allowed to sabotage the independent review
> mechanisms described in RFC 2026. Consequently, the chair action has to
> be treated as terminating the discussion and allowing an appeal to the
> ADs---in particular, allowing this complaint to the ADs.
> 
> Regarding "any of the parties involved may bring it to the attention of
> the Area Director(s) for the area in which the Working Group is
> chartered": I am one of the parties involved, and I am hereby bringing
> this matter to the attention of both of "the Area Director(s)" for the
> security area.
> 
> RFC 2026 clearly requires _both_ of the ADs to attempt to resolve the
> dispute ("The Area Director(s) shall attempt to resolve the dispute"). I
> am aware that IESG has attempted to sabotage the plural "(s)" in this
> rule, but IESG has no authority under RFC 2026 to do this.
> 
> Finally, I am hereby requesting that the AD coming from NSA recuse
> herself in favor of an independent party (so this matter will be handled
> by the other security AD and someone else, obviously _not_ a defense
> contractor). My understanding is that the AD is continuing to receive
> pension payments from NSA, so recusal should be automatic even without
> consideration of revolving-door concepts.
> 
> ---D. J. Bernstein
> 
> 
> ===== NOTICES =====
> 
> IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
> (normative), "Rights in Contributions", 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.
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]