Dr. Bernstein, This is frankly embarrassing behavior, and I'm saying this as a furry. Consensus doesn't have to include every Tom, Dick, and Harry that you summon from X (formerly Twitter), including celebrated rapist Jacob Appelbaum [1].
Please get a better hobby. [1] https://geekfeminism.fandom.com/wiki/Jacob_Appelbaum_rape_report On Tue, May 19, 2026 at 7:29 AM D. J. Bernstein <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
