Sorry, one sentence in my previous email was erroneously unfinished: "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...”
Should be: "While Prof. Bernstein’s work in pointing out the many procedural errors in the hybrid-vs-pure-key-agreement issue was valuable and appropriate, it is my personal opinion that..." Nadim Kobeissi Symbolic Software • https://symbolic.software > On 22 May 2026, at 9:44 AM, Nadim Kobeissi <[email protected]> wrote: > > 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 <[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]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
