To the Security ADs, cc'ing [email protected]: I am writing to file the complaint below with both of you. For transparency, please use the relevant public mailing list ([email protected]) for all discussion of this matter. Please acknowledge receipt, and please confirm that you aren't going to present any further ad-hoc excuses for not handling the actual content of this complaint. Thanks in advance.
Also, please note: 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. That sentence is 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". I'm fine with this document appearing on the list, obviously. ---D. J. Bernstein # Complaint to ADs regarding a declaration of consensus to adopt a non-hybrid draft Daniel J. Bernstein, 2025-10-13 ## 0. Overview and procedural status This is a complaint to the "Area Directors" (ADs) for the "Security Area" of the "Internet Engineering Task Force" (IETF). This complaint is self-contained and includes "a detailed and specific description of the facts of the dispute" as required by RFC 2026. Various URLs are provided for background. This complaint is regarding the following specific action: Joseph Salowey and Sean Turner, in their roles as chairs of an IETF "Working Group" (WG) named "Transport Layer Security" (TLS), declared that the WG had consensus to adopt a draft named "draft-connolly-tls-mlkem-key-agreement". (The WG has a third chair, Deirdre Connolly, but the other chairs later said she was "recusing as she is an author".) I have three reasons for complaining about this specific action: * The chair message claiming consensus did not present the basis for this claim. This lack of information obstructed followup procedures. * The procedure that the chairs (eventually) said they used for the consensus declaration was improper, having essentially nothing to do with the concept of consensus. See Section 12 below. * The chair conclusion that there was consensus is simply wrong. See Section 5 below. Other sections of this complaint provide more information regarding the relevant background, the events during the adoption call issued by the chairs, and what happened when I challenged their claim of consensus. It is important to set the record straight: to issue an erratum for the misinformation issued by the chairs on this topic. The chairs called for adoption. That call _failed_ to reach WG consensus on adoption. Uncorrected misinformation tends to snowball. For example, I am told that this month an AD, Paul Wouters, wrote "it is possible that 30+ TLS participants, 2 Working Group Chairs, 13 IESG members and 13 IAB members are all corrupt and only djb is right" in a public posting. Compared to the actual levels of support and opposition that were produced by the adoption call in question during the specified call period (see Section 5 below), the AD is overstating the level of support and understating the level of opposition. The underlying claim of consensus was an official claim by the chairs and needs a similarly official correction. It is, of course, also important to undo the unauthorized chair action that directly resulted from the erroneous consensus call, namely the adoption of the document. It is also clear that the chairs need training in how to evaluate consensus; the procedures that they are following threaten to do damage far beyond the specific incident at hand. BCP 9 (RFC 2026), Section 6.5.1, includes the following three paragraphs: > A person who disagrees with a Working Group recommendation shall > always first discuss the matter with the Working Group's chair(s), > who may involve other members of the Working Group (or the Working > Group as a whole) in the discussion. > > 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. > > If the disagreement cannot be resolved by the Area Director(s) any of > the parties involved may then appeal to the IESG as a whole. The > IESG shall then review the situation and attempt to resolve it in a > manner of its own choosing. This complaint is hereby invoking the second of these BCP 9 paragraphs. Note that RFC 3934 (which is part of BCP 94 and explicitly updates BCP 25) says that _all_ "WG chair decisions" are "subject to appeal". To review preconditions: I explicitly invoked the first of these BCP 9 paragraphs by email to the TLS mailing list dated 18 Apr 2025 14:02:55 -0000, asking for the "discussion to be on-list for transparency". The chairs sent very few public email messages about this, concluding with email dated 25 Apr 2025 15:04:39 -0400 saying that they stood by their consensus call and that I "can appeal". (The sequence of events is described in more detail below.) The second BCP 9 paragraph has a prerequisite that "the disagreement cannot be resolved in this way". Procedurally, is this triggered when the chairs say that I "can appeal"? Or would ADs be able to evade addressing the content of a complaint by saying "The chairs were wrong in saying that you can appeal; there's no proof that the disagreement cannot be resolved by the chairs; go back to them"? Despite the lack of procedural clarity, I sent email to the ADs dated 5 Jun 2025 18:51:36 -0000 to file <https://cr.yp.to/2025/20250605-non-hybrid.pdf> as a complaint under the second paragraph. I cc'ed the TLS mailing list, and requested that all discussion take place on the TLS mailing list, including, but not limited to, any discussions of this matter among IESG members, IAB members, agents of IETF Administration LLC, etc. There are two ADs. They didn't recuse themselves, despite my pointing out conflicts of interest. Also, despite RFC 2026 clearly stating "The Area Director(s) shall attempt to resolve the dispute", it seems that one of the ADs ignored my complaint, on the grounds of the other AD being "responsible" for the TLS WG. I have received responses only from that other AD, namely Wouters. That AD sent email dated 12 Jun 2025 15:58:44 -0400 under a different subject line ("AD response to message on WG chair consensus call draft-connolly-tls- mlkem-key-agreement by D. J. Bernstein of 2025-06-05"), also not following IETF's standards for marking the message as a reply. The AD's email refused, for a variety of reasons (covered below), to "get to the content of the complaint (aka appeal)". Despite the AD's mislabeling of the email, I did see the email. I followed up by email dated 14 Jun 2025 01:15:38 -0000 (switching back to the original subject line while following IETF's standards for marking my message as a reply). I responded point by point to the AD's refusal to address the complaint, and I asked the AD to "please go ahead with answering the contents". The AD did not respond. The third BCP 9 paragraph has a prerequisite that "the disagreement cannot be resolved by the Area Director(s)". Is this triggered by a non-responsive AD? Or would IESG be able to evade addressing the content of a complaint by saying "There's no proof that the diagreement cannot be resolved by the ADs; go back to them"? Further time passed, still with no response from the AD. I filed an appeal <https://cr.yp.to/2025/20250812-non-hybrid.pdf> with IESG shortly before the two-month deadline for appeals under BCP 9. IESG did not respond beyond acknowledging receipt. More time passed. On 1 October 2025, without addressing the actual content of my complaint, IESG wrote that it "directs the appellant to file a valid complaint to the SEC ADs for consideration". IESG rejected one of the AD's excuses for not handling my complaint in the first place but supported another one, saying that a particular paragraph in my complaint made the complaint "invalid". I disagree but, in order to move things forward, decided to remove that paragraph. On 6 October 2025, I filed a revised complaint <https://cr.yp.to/2025/20251006-non-hybrid.pdf>. On 7 October 2025, the AD refused to process my complaint, claiming that "appeals must be in a specific format and this appeal does not conform to that so it will not be processed". The AD cited a document <https://datatracker.ietf.org/doc/statement-iesg-statement-on-the-conflict-resolution-and-appeals-processes/>. I asked various followup questions on 9 October 2025: > Let me make sure I understand. You're refusing to obey RFC 2026's > "shall attempt to resolve the dispute" requirement, and your reason is > that I didn't use a "specific format" described in some IESG statement? > > Did IESG announce its statement for IETF consideration? When? Where? > I certainly hadn't seen any such announcement when I prepared and filed > my complaint. > > Maybe I missed an announcement, but if this is an _ex post facto_ rule > ("now that you've done the work to file a revised complaint, we'll tell > you about new rules that we just posted, and retroactively throw your > complaint away on this basis, ha ha ha") then it's glaringly unethical. > > Beyond timeline questions, why exactly do you believe that you and/or > the full IESG have authority to make exceptions to RFC 2026's "shall > attempt to resolve the dispute" requirement? > > Also, you objected to my email normatively citing what you called "a > remotely hosted PDF", but then you didn't answer my followup question: > "For the record, is draft-ietf-tls-mlkem going to be banned because it > normatively cites FIPS 203, which is a remotely hosted PDF?" > > I filed the actual content of my complaint more than four months ago. > With all due respect: It looks terrible for an AD and IESG to have been > making up retroactive, ad-hoc, selectively enforced excuses to not > address the content of the complaint. It is now 13 October 2025. There is still no reply from the AD. My understanding is that the AD and IESG will refuse to consider any further complaints regarding this matter if I do not file a complaint by 15 October 2025. I have now taken the time to review <https://datatracker.ietf.org/doc/statement-iesg-statement-on-the-conflict-resolution-and-appeals-processes/>. That statement is dated 1 October 2025. As far as I can tell from various searches, the statement was not announced anywhere until after I had filed my 6 October 2025 complaint. The statement has 1314 words and imposes a variety of _content_ requirements, not merely formatting requirements. To move things forward, I have revised this complaint to comply with all of IESG's latest demands. ## 1. Context, part 1: NSA BCP 188 (RFC 7258), "Pervasive Monitoring Is an Attack", says (among other things) "The IETF Will Work to Mitigate Pervasive Monitoring". This RFC was triggered by news articles in 2013 regarding mass surveillance by NSA and GCHQ. For example, <https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security> reported that NSA was budgeting a quarter billion dollars a year for a project that "actively engages US and foreign IT industries to covertly influence and/or overtly leverage their commercial products' designs" to make the designs "exploitable ... To the consumer and other adversaries, however, the systems' security remains intact." NSA's budget document (<https://embed.documentcloud.org/documents/784285-sigint-enabling-project/>) includes the following specific goal: "Influence policies, standards and specification for commercial public key technologies". NSA was not just passively recording Internet traffic; it already had a large budget to influence standardization processes so that the resulting standards would be exploitable. My blog post <https://blog.cr.yp.to/20220805-nsa.html> covers much more of what is known about NSA's cryptographic sabotage. In particular, when cryptographic standardization began, NSA adopted a secret policy of trying to reduce competition in this space so as to reduce security: > Narrowing the encryption problem to a single, influential algorithm > might drive out competitors, and that would reduce the field that NSA > had to be concerned about. Could a public encryption standard be made > secure enough to protect against everything but a massive brute force > attack, but weak enough to still permit an attack of some nature using > very sophisticated (and expensive) techniques? This is a quote from pages 232--233 of <https://archive.org/details/cold_war_iii-nsa>, an internal NSA book that was partially declassified in 2013 as a result of journalists forcing declassification-review procedures. There has never been a public statement from NSA revoking the above policy, nor would such a statement be credible given NSA's long history of sabotage. One cryptographic mechanism that NSA manipulated NIST, ISO, and ANSI into standardizing was Dual EC, a backdoored standard for generating random numbers using elliptic curves. Various other NSA-proposed standards for elliptic-curve cryptography (ECC) turned out to be filled with traps for implementors---traps that continue to cause exploitable problems, as illustrated by CVE-2023-6135 in Firefox. For more about Dual EC, see <https://cr.yp.to/papers.html#dual-ec>; for many further ECC failures, see <https://cr.yp.to/papers.html#safecurves>. In short, despite what one might think from the "National Security Agency" name, NSA has again and again shown its willingness to damage American security for the sake of mass surveillance. This is what NSA did with DES, with export controls, with DSA, with Dual EC, and with any number of unknown targets of NSA's quarter billion dollars a year to make commercial products "exploitable". See <https://blog.cr.yp.to/20250930-stealth.html>. NSA's influence on cryptography goes beyond this quarter billion dollars a year. For example, the United States military budget is approaching a trillion dollars per year; NSA sets rules for the cryptographic part of this purchasing (see, e.g., <https://web.archive.org/web/20221022163808/https://www.jcs.mil/Portals/36/Documents/Library/Instructions/CJCSI%206510.02F.pdf?ver=qUEnOsWpGPcGGMFTb4yYVA%3D%3D>). Some people think that NSA's willingness to damage American security doesn't extend to the American military, but in the end NSA's mission (see <https://web.archive.org/web/20250418203700/https://www.archives.gov/federal-register/codification/executive-order/12333.html>) is primarily surveillance, not security. NSA has different rules for the data it really cares about: as a public example, <https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf> is an NSA program that mandates using two independent encryption layers "to mitigate the ability of an adversary to exploit a single cryptographic implementation". ## 2. Context, part 2: hybrid ECC+PQ "Post-quantum cryptography" (I coined the term in 2003) tries to protect against attackers with quantum computers. This isn't easy to get right. For example, 48% of the 69 round-1 submissions in 2017 to the NIST Post-Quantum Cryptography Standardization Project have been broken by now; 25% of the submissions that survived round 1 have been broken by now; and 36% of the submissions selected by NIST for round 2 have been broken by now. See my paper <https://cr.yp.to/papers.html#qrcsp> for details and references. One of the broken systems, SIKE, had been applied on a large scale to real user data. To quantify "large scale": <https://blog.cloudflare.com/the-tls-post-quantum-experiment/> said that "approximately one third" of the participating TLS connections used SIKE, and that sampling 5% of the participating TLS connections produced "millions of data samples". In short, tens of millions of user TLS connections were encrypted with SIKE. See <https://eprint.iacr.org/2023/376> for an attack taking 11 seconds to break larger SIKE keys. (The first SIKE breaks were slower.) Fortunately, SIKE was rolled out only as an _extra_ layer of defense on top of elliptic-curve cryptography (ECC), rather than as a _replacement_ for ECC. ECC+SIKE was failing to protect against quantum computers, but it least it had the strength of ECC against non-quantum attacks, whereas rolling out SIKE by itself would have been an immediate disaster. More broadly, it's normal for PQ to be rolled out as ECC+PQ, typically called a "hybrid" between ECC and PQ. ECC generally consumes far less Internet traffic than PQ; ECC's computational costs are negligible; ECC software is practically everywhere anyway. So deploying ECC+PQ rather than just PQ is an easy common-sense win, and would remain dominant in a free market. (The situation is different for a market warped by NSA influence: see Section 3.) The TLS WG adopted an ECC+PQ draft in March 2025 (<https://mailarchive.ietf.org/arch/msg/tls/iGLZeIYzsIZPYO1ezA2Eulv5x98/>). There were no objections to the declaration of consensus on adopting that draft. I had pointed out two BCP 79 issues regarding the draft in its current form (stemming from the draft's requirement to use a patented algorithm, Kyber), but I said that the first issue could be fixed after adoption, and I now think that this is also true for the second issue. There was a recent last call regarding that draft; further discussion of the status does not matter for this complaint. ## 3. Context, part 3: NSA's influence on PQ draft-connolly-tls-mlkem-key-agreement was first posted in March 2024. Of course someone asked "what the motivation is for being 'fully post-quantum' rather than hybrid". The draft author responded: "FIPS / CNSA 2.0 compliance guidelines ... currently are a big 'maybe' at best for 'hybrid solutions', and the timetables for compliant browsers, servers, and services are to exclusively use FIPS 203 at level V (ML-KEM-1024) by 2033. I figure there will be demand for pure ML-KEM key agreement, not hybrid (with no questions that come along with it of whether it's actually allowed or not)." <https://mailarchive.ietf.org/arch/msg/tls/qFRxBSnEPJcdlt7MO0cIL2kW5qc/> In June 2024, NSA's William Layton wrote that "we do not anticipate supporting hybrid in NSS". <https://mailarchive.ietf.org/arch/msg/tls/ESCdYNwVeF4VkvoORFJLJk_87VU/> In December 2024, a Cisco employee wrote the following: "There are people whose cryptographic expertise I cannot doubt who say that pure ML-KEM is the right trade-off for them, and more importantly for my employer, that's what they're willing to buy. Hence, Cisco will implement it; I am essentially just asking for code points." <https://mailarchive.ietf.org/arch/msg/tls/S9Mwv28VEHrG189ZtoubUani7J8/> In June 2025, NSA's Mike Jenkins posted the following: "As the CNSA 2.0 profiles should make clear, we are looking for products that support /standalone/ ML-DSA-87 and /standalone/ ML-KEM-1024. 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." <https://mailarchive.ietf.org/arch/msg/spasm/xUKIoHQwm1BjNZWS2x3xb-BhsLI/> ## 4. Survey of objections to the draft Turner, also on behalf of Salowey, sent email dated 1 Apr 2025 08:58:01 -0400 that included the following announcement: "This time we are issuing a WG adoption call for the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this draft, please send a message to the list and indicate why. This call will close at 2359 UTC on 15 April 2025." The cited draft was <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>. The following paragraphs give quotes showing that various objections were raised during the specified period for the adoption call. This is just a high-level survey of the objections. These quotes are not intended to convey the full text of objections on the mailing list, and are also not intended to convey how many people were objecting (see Section 5). ### The draft creates security risks See, e.g., my email dated 1 Apr 2025 21:38:16 -0000 (<https://mailarchive.ietf.org/arch/msg/tls/2Dfu4x678DEKCzF-fkdvJHJkS-8/>): "SIKE was applied to large volumes of user data as part of the CECPQ2 experiment in 2019. SIKE was publicly broken in 2022. [paragraph break] The _only_ reason that this didn't immediately give away the user data to attackers is that CECPQ2 was ECC+SIKE, rather than just SIKE. [paragraph break] Should we keep rolling out post-quantum cryptosystems to _try_ to stop future quantum attacks? Yes, of course. But, just in case this goes horribly wrong _again_, let's make sure to keep ECC in place. Any draft violating this should be rejected as a security risk not just by WGs but also by the ISE." ### The draft violates BCP 188 See, e.g., my email dated 15 Apr 2025 22:33:23 -0000 (<https://mailarchive.ietf.org/arch/msg/tls/xJqwB30b5wf3GVlAiIP3O4tuBIE/>): "To the extent that this is an allusion to NSA purchasing, it violates BCP 188 ('IETF Will Work to Mitigate Pervasive Monitoring')." ### The draft violates the WG charter See, e.g., my email dated 15 Apr 2025 22:33:23 -0000 (<https://mailarchive.ietf.org/arch/msg/tls/xJqwB30b5wf3GVlAiIP3O4tuBIE/>): saying that "the draft's regression from ECC+PQ to just PQ" is "a contravention of the 'improve security' goal in the WG charter". ### There are no principles supporting the adoption decision See, e.g., Stephen Farrell's email dated 1 Apr 2025 15:30:02 +0100 (<https://mailarchive.ietf.org/arch/msg/tls/toxVUv_d1pdDspbfo8OxcJeC_QU/>): "I don't see what criteria we might use in adopting this that wouldn't leave the WG open to accusations of favouritism if we don't adopt other pure PQ national standards that will certainly arise". ### The draft's motivation section is circular For example, my email dated 3 Apr 2025 16:18:57 -0000 (<https://mailarchive.ietf.org/arch/msg/tls/YNSu6ZO5e0JMJ1cRlnxh6oIjyZg/>) said that there is "a preliminary step that has been skipped here, namely identifying why the proposal is claimed to be adding something important. The draft's motivation sentence consists of rearranging buzzwords without answering the question: 'Having a fully post-quantum (not hybrid) key agreement option for TLS 1.3 is necessary for migrating beyond hybrids and for users that need to be fully post-quantum.' " ### The draft increases software complexity See, e.g., Andrey Jivsov's email dated 15 Apr 2025 13:49:52 -0700 (<https://mailarchive.ietf.org/arch/msg/tls/uOmcMEqlyekrvcOgdsf7GtIlf3w/>): "The main stated benefit of using a standalone ML-KEM is complexity reduction, but with the current progress in the deployment of the ML-KEM + ECC hybrid method, a standalone ML-KEM method actually increases overall complexity in software stacks." As context: Thomas Bellebaum, in email dated 1 Apr 2025 15:18:16 +0000 (<https://mailarchive.ietf.org/arch/msg/tls/YyemGJF-4-hRVwOcJ47Rw4Nu8Js/>), had quoted "users that need to be fully post-quantum", and had asked for "a specific example of such users and their motivation". The draft author sent a reply dated 1 Apr 2025 11:31:55 -0400 saying "A specific example is moving to a compute / dependency base that is minimalist to only PQ primitives they wish to maintain, such as those that have long update / deployment cycles, as well as those that want a minimalist PQ interop target". Jivsov's objection says that adding the non-hybrid option actually makes software _more_ complicated overall. The non-hybrid option doesn't exist in a vacuum: it is on top of the already deployed hybrid option. ## 5. Lack of consensus <https://www.ldoceonline.com/dictionary/consensus> says "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 erred in claiming consensus. But this is not the end of the analysis. The word "consensus" can be used in less stringent ways: for example, <https://www.merriam-webster.com/dictionary/consensus> says "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". The point of this section is that _none_ of these requirements were met when the TLS WG chairs claimed "consensus" to adopt draft-connolly-tls-mlkem-key-agreement. There was not general agreement. 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, consensus evaluation was replaced by a majority-voting process. ### There was not general agreement During the adoption-call period, there were statements from 20 people unequivocally supporting adoption: David Adrian, Joseph Birr-Pixton, Uri Blumenthal, GCHQ's Florence Driscoll, NIST's Quynh Dang, Viktor Dukhovni, Scott Fluhrer, NSA's Rebecca Guthrie, Russ Housley, Alicja Kario, Kris Kwiatkowski, Andrei Popov, Tirumal Reddy, Yaroslav Rosomakho, Jan Schaumann, Sophie Schmieg, Martin Thomson, Filippo Valsorda, Loganaden Velvindron, and Thom Wiggers. There were also statements from 2 people _conditionally_ supporting adoption: Yaakov Stein ("I support adoption of pure PQC KEMs drafts with Intended status: Informational (meaning that the IETF is not recommending using)") and John Mattsson ("I support adoption as long as reuse of ephemeral keys is normatively forbidden, i.e. MUST NOT reuse"). However, there were statements from 7 people unequivocally opposing adoption: Thomas Bellebaum (<https://mailarchive.ietf.org/arch/msg/tls/YyemGJF-4-hRVwOcJ47Rw4Nu8Js/>: "I agree with Stephen on this one and would not support adoption of non-hybrids"), Andrey Jivsov (<https://mailarchive.ietf.org/arch/msg/tls/uOmcMEqlyekrvcOgdsf7GtIlf3w/>: "I am opposed to the adoption of ML-KEM at this time"), Stephen Farrell (<https://mailarchive.ietf.org/arch/msg/tls/toxVUv_d1pdDspbfo8OxcJeC_QU/>: "I'm opposed to adoption, at this time"), Rich Salz (<https://mailarchive.ietf.org/arch/msg/tls/0f6XBGPElMLNoiS1Eh3u7EhzoGc/>: "I was all set to say that I am in favor of adoption, but Stephen's post changed my mind. [paragraph break] The conservative and safe thing is to stick to hybrids and that is what the IETF should do for now"), Rob Sayre (<https://mailarchive.ietf.org/arch/msg/tls/uhWI53zIjWJT5ZiS_UthyBe2k9Y/>: "I oppose adoption"), Sun Shuzhou (<https://mailarchive.ietf.org/arch/msg/tls/EzKcwjagajQqcRpH4TDTn70W9hc/>: "I'm opposed to adoption"), and me. (There was much more text stating reasons for the objections.) Even assuming that the 2 statements of conditional support are treated as positive votes, the overall situation here---22 positive votes and 7 negative votes---does not qualify as general agreement. "General" means "shared by or affecting most people, or most of the people in a group" (<https://www.ldoceonline.com/dictionary/general>); "most" means "nearly all of the people or things in a group, or nearly all of something" (<https://www.ldoceonline.com/dictionary/most>); the phrase "general agreement" means that nearly everyone agrees. Merely having three quarters agree is not good enough. Even for readers who understand "consensus" as meaning merely "general agreement" or "the judgment arrived at by most of those concerned" without any further constraints, the chairs were communicating false information when they claimed consensus. ### There was not fair consideration of each objection Within the statements in favor of adoption, most of the statements were very short: e.g., just the words "I support adoption" with no further comments. Some statements in favor of adoption did say more, such as stating circular arguments for the draft (e.g.: "as time progresses, non-hybrid key exchanges will become more and more commonplace, so why not have it already defined?"), or expressing concerns about key reuse (e.g.: "I also share John's concerns about key reuse, but would prefer to litigate that in the working group, rather than during adoption"), without responding to the content of the objections. There was a response to one word in the lack-of-principles objection. (The response was as follows: "The NIST competition was international, and Kyber was developed by an international team. I struggle to understand how adopting this document would somehow be 'favoritism'.") A brief note by one supporter tangentially related to one objection falls far short of fair consideration of each objection by the group as a whole. ### There was not a process of attempting to resolve each objection I tried to engage that supporter in discussion. I started by quoting the following earlier statement in the commentator's message: "I find it to be cognitive dissonance to simultaneously argue that the quantum threat requires immediate work, and yet we are also somehow uncertain of if the algorithms are totally broken. Both cannot be true at the same time." I responded as follows: > Rolling out PQ is trying to reduce the damage from an attacker having a > quantum computer within the security lifetime of the user data. Doing > that as ECC+PQ instead of just PQ is trying to reduce the damage in case > the PQ part is broken. These actions are compatible, so how exactly do > you believe they're contradictory? > > Here's an analogous example of basic risk mitigation: there's endless > work that goes into having planes not crash, not hit turbulence, etc., > but we still ask airplane passengers to keep their seatbelts on whenever > they're in their seats. My email was dated 1 Apr 2025 21:38:16 -0000 (<https://mailarchive.ietf.org/arch/msg/tls/2Dfu4x678DEKCzF-fkdvJHJkS-8/>). By the time the adoption call closed two weeks later, there was still no reply. The broader pattern was that objectors were engaging in discussion while supporters were not. The majority process wasn't "attempting to resolve each objection"; it was simply collecting positive votes. ### There was not documentation, for each objection, of why that objection was overridden When there's an objection, consensus requires not just fairly considering the objection, and not just attempting to resolve the objection, but---if resolution fails---having the group agree on the contents of a _response_ to the objection. That's an official statement of _why_ the objection was overridden. For the proposal at hand---the proposal for the WG to adopt a particular draft---there was an objection saying, in a nutshell, that the draft creates security risks. Where's the official TLS WG statement of why this objection was overridden? Answer: The statement doesn't exist. Same for all of the other objections. ### Fundamentally, consensus evaluation was replaced by a majority-voting process A majority-voting process allows the majority to _override_ objections from the minority without even _answering_ those objections, let alone trying to _resolve_ them. That's what happened here. The chairs asked objectors to state their objections ("If you do not support adoption of this draft, please send a message to the list and indicate why"). Meanwhile the chairs asked supporters merely to state their support ("If you support adoption and are willing to review and contribute text, please send a message to the list"). The chairs didn't ask supporters to respond to objections. Unsurprisingly, there were detailed statements of objections, while the majority simply cast their votes without responding to the objections. If this _wasn't_ a majority-vote process, what's the supposed dividing line between this process and a majority-vote process? How would minority interests ever be protected against being overrun by the majority? The call for adoption succeeded in achieving majority support, but it failed to achieve consensus. The chairs should have clearly explained from the outset that consensus was required, and should have accurately explained what this means. (Presumably the objections would then have been discussed---perhaps resolved one way or the other.) But the chairs didn't do this. ### What IETF says about consensus Some people tell me that, beyond saying (1) that the chairs communicated false information when they claimed "consensus" and (2) that non-consensually ramming this document through standardization processes is improper, I should be saying (3) that what happened here isn't consistent with IETF's promises regarding how IETF works. A prominent IETF statement says the following: "IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes." Another prominent IETF statement says that WG decisions are _not_ taken by voting. BCP 9 recognizes "the importance of establishing widespread community consensus". For many years, IETF has marked each standard (or "Proposed Standard") with a notice that the standard "represents the consensus of the IETF community". Furthermore, there is ample evidence of IETF participants using the word "consensus" in the strong sense of unanimity. On the other hand, RFC 2418, part of BCP 25, says that WG decisions require merely "rough consensus" within the WG rather than having "all participants agree". Does this mean that the prominent claims of consensus are false advertising by IETF? A closer look shows that RFC 2418 includes most, if not all, of the procedural constraints that I've been highlighting. For example, after saying that unanimity is not required, RFC 2418 says that 51% doesn't qualify as "rough consensus" while 99% is "better than rough". This doesn't pin down a dividing line, but naming 99% would make no sense if 75% were sufficient; it suggests that the cutoff is more like 95%. Here is another example from RFC 2418: "100 people in a meeting" reach "consensus" but then "a few people" on the mailing list object. RFC 2418 then says that "the consensus should be seen as being verified"; evidently this means that there is still "rough consensus" so the group goes ahead. Taking such an extreme example again would make no sense if 75% were sufficient for "rough consensus". As for handling of objections, RFC 2418 says the following: "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." People objecting to draft-connolly-tls-mlkem-key-agreement were trying to engage in this resolution process, but people supporting the draft were skipping the process. The chairs violated this "must" from RFC 2418 when they moved ahead without the conflicts having been resolved. I'll close this section with one more way to see that what the chairs did in this case doesn't match IETF's promises. 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". Several other group participants have spoken up to indicate that this draft should be discarded. ## 6. The erroneous consensus declaration, and questioning it After a message dated 14 Apr 2025 00:02:15 -0400 saying "Just a reminder that this WG adoption call closes tomorrow", Turner sent email dated 15 Apr 2025 13:26:43 -0400 (before the announced closing date of "2359 UTC on 15 April 2025") saying "It looks like we have consensus to adopt this draft as a working group item". There were some notes on followup procedures, but there was no explanation of the rationale for this claim of consensus. I sent email dated 15 Apr 2025 19:53:51 -0000 quoting "It looks like we have consensus to adopt this draft as a working group item". I continued as follows: > Um, what? There were several people (including me) raising objections on > list to basic flaws in this draft, such as (1) the failure to provide an > ECC backup to limit the damage from further security problems in the PQ > layer, (2) the failure to provide an engineering justification for this > option, and (3) the lack of any principles that would justify saying no > to options selected by other governments if this option is allowed. > > Your message doesn't explain how you came to the conclusion that there's > consensus. Surely you aren't relying on some tally of positive votes to > ram this document through while ignoring objections; voting isn't how > IETF is supposed to work. So how _did_ you come to this conclusion? > > As a procedural matter, this lack of explanation is in violation of > "IETF activities are conducted with extreme transparency, in public > forums". Please rectify this violation immediately. Also, please state > the procedures for appealing your action. Thanks in advance. ## 7. AD disruption One of the ADs, Paul Wouters, sent email dated 16 Apr 2025 09:36:17 -0400 regarding the dispute. Recall the procedure specified in BCP 9 (RFC 2026), Section 6.5.1: someone who disagrees with a WG recommendation _first_ discusses the matter with the WG chairs. _If_ "the disagreement cannot be resolved in this way", then the procedure authorizes anyone involved to ask the ADs to "attempt to resolve the dispute". I had summarized my disagreement and had started a discussion with the WG chairs. Instead of waiting for the discussion with the chairs to finish as per BCP 9, the AD was jumping into the discussion. (The chairs hadn't even posted a reply yet!) Furthermore, the contents of the AD's message (see below) were simply taking sides, rather than attempting to resolve the dispute. IESG has quoted BCP 9's text "The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention" as justifying the AD's disruption here. But that text is only for "matters of working group process and staffing" (which IESG failed to quote); obviously the AD's comments went far beyond those limits, never mind the point that the circumstances warranted the AD _not_ interrupting. ### Basic flaws Regarding my comment on "basic flaws in the draft", the AD wrote the following: > The term "basic flaws" here is mis-used. There are no known "basic flaws" > in pure ML-KEM. If you know of a flaw, please present evidence in the > form of a proper reference to the flaw. Your preference for hybrid over > pure is not a "basic flaw", and those preferring hybrids can choose to > only use hybrids. This AD comment, like the voting process that preceded it, is non-responsive to the content of the objections. The first objection that I had highlighted was to the **security risk** incurred by the draft leaving out the common-sense protection of a hybrid. As I said, "the failure to provide an ECC backup to limit the damage from further security problems in the PQ layer" is a basic flaw in the draft. Claiming that this is merely a "preference" is not even acknowledging, let alone responding to, the core point of the objection. The second and third objections that I had highlighted were to critical gaps in the rationale provided for the draft. Both of these, like the first objection, are foundational issues challenging the notion that the draft is a good idea in the first place, so the word "basic" is proper terminology. The AD did move on to quoting the specific objections, but did not respond to the content of the objections. See below. ### Failure to provide an ECC backup Regarding the objection to "the failure to provide an ECC backup to limit the damage from further security problems in the PQ layer", the AD wrote the following: > Not being a hybrid KEM is not a "basic flaw". The only reason that CECPQ2 didn't expose user data to pre-quantum attackers is that it had the common sense to include an ECC layer. > The additional security > from hybrids comes at a complexity cost that people have different > opinions about. Costs are facts, not opinions. Upgrading from ECC to ECC+PQ is only marginally more expensive than switching to non-hybrid PQ; see <https://blog.cr.yp.to/20240102-hybrid.html> for quantification. Furthermore, given the fact that the ecosystem includes ECC+PQ anyway, adding non-hybrid PQ as another option makes the ecosystem _more_ complicated. > There will also obviously be differences of opinion on > when hybrids will have outlived their security premise in the future, The proposal was to adopt the draft _now_. The objections were to that proposal. The AD's argument about the future is not responsive to the objections, and in particular is not responsive to "the failure to provide an ECC backup to limit the damage from further security problems in the PQ layer". As a side note, the AD's argument starts with the claim that hybrids will eventually disappear. This _could_ be correct, but maybe not; see the "cheaper to attack" paragraph in <https://blog.cr.yp.to/20240102-hybrid.html>. > and so supporting both now and letting implementers make their own > choices on which defaults to use now and when to migrate in the future > is up to them. This is not responsive to the objections; it is another circular argument that the document is good for people who think it's good. > The TLS WG, along with CFRG backed by the larger > cryptography community will continue to play an advisory role here > over the next years. This generic comment is not responsive to the objections. ### Failure to provide justification Regarding the objection to "the failure to provide an engineering justification for this option", the AD wrote the following: > This is your own made up condition. No, it isn't: "Rather than bringing a fully-formed solution and looking for a use, begin by articulating _what issue or gap needs to be addressed_. ... In other words, _donât put the cart before the horse_: first convince the group that there's an important problem to solve." These quotes aren't from something binding on the TLS WG---they're quotes from a CFRG process document (see <https://web.archive.org/web/20250325135726/https://wiki.ietf.org/en/group/cfrg/CFRG-Process>)---but they're still doing a nice job of pinpointing one of the basic flaws in the draft at issue. IETF claims that "IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user". The available evidence indicates that this claim is not true in this case: see Section 3, or simply consider the AD's claim that it's okay to not provide an engineering justification. If there _is_ an engineering justification for the draft, then this should have been spelled out before the adoption call. Anyway, claiming that an objection is a "made up condition" doesn't change the fact that the objection was raised. Consensus requires each objection to be addressed: see Section 5. > People who do not wish to rely on > pure PQ can already use a hybrid PQ. There are those who wish to use > pure PQs, and your reasons for not letting them are not widely supported > within the IETF or the TLS WG, as can be seen by other protocols also > implementing pure PQ algorithms. This is another circular argument that the document is good for people who think it's good. This is again not responding to the objections. As for "other protocols also implementing pure PQ algorithms", certainly the effects described in Section 3 are creating _some_ of this regression, but leaping from such examples to the claim of hybrids being "not widely supported" is wildly inaccurate. The post-quantum connections from Chrome etc. to Cloudflare---a third of Cloudflare's HTTPS connections this year---are hybrid ECC+PQ. ANSSI requires hybrids. BSI requires hybrids. Remember that <https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf> asked for two independent encryption layers "to mitigate the ability of an adversary to exploit a single cryptographic implementation". As for "reasons ... not widely supported within the IETF or the TLS WG": The TLS WG wasn't polled (and certainly IETF as a whole wasn't polled) regarding "reasons", so how does the AD claim to know what the support fraction is for these reasons? The TLS WG chairs merely asked supporters for votes, not for explanations. Some of the supporters nevertheless tempered their votes with text communicating concerns (for example, <https://mailarchive.ietf.org/arch/msg/tls/hz-BtcGhXX2eN_rbVKMypP8XhW8/> said "I might oppose Recommended: Y"; <https://mailarchive.ietf.org/arch/msg/tls/Yvjdn-wpF440E-6kjVHsrQMU5Nk/> said "we should be very careful"; <https://mailarchive.ietf.org/arch/msg/tls/ppDcmr9twLRiMh-3hGYc0S_t66U/> supported adoption but only if IETF is "not recommending using"). Presumably security was the top source of concerns. Certainly security featured prominently in the stated objections. Meanwhile far fewer people said that they _weren't_ concerned about security. Perhaps the people who didn't say anything one way or the other weren't concerned, but _they didn't say that_. Perhaps the data on this point was biased by the nature of the call (again, the chairs didn't ask supporters to explain their votes), but the AD's claims here _definitely_ aren't backed by evidence. It's improper to report guesses as facts. ### Failure to provide selection principles Regarding the objection to "the lack of any principles that would justify saying no to options selected by other governments if this option is allowed", the AD wrote the following: > This document does not set policy for other documents or governments, > so this "reason" is out of scope for the IETF. Non sequitur. Supporting endless options is a systemic security problem, so the WG shouldn't take every option that's proposed---but then there should be principles for the dividing line. This is entirely about what the WG is endorsing, not about the level of WG power over anyone else. NSA's selection of non-hybrid Kyber has been repeatedly, sometimes explicitly, cited as justification for the draft in question. NSA is a United States government agency. Meanwhile other governments are making different, often incompatible, selections: for example, hybrid FrodoKEM is one of the selections by BSI, a German government agency. If the TLS WG is adopting the U.S. government selection, will the TLS WG also adopt the German government selection, the Chinese government selection, etc.? There have to be principles for the answer---engineering principles, not giving special power to the United States government. The data flow here is from the governments _to_ the TLS WG. What the AD is talking about is (1) in the opposite direction and (2) considering only the extreme case of setting policy. ### The consensus question Regarding my question of how the chairs came to the conclusion that there's consensus, the AD wrote the following: > I have reviewed the responses to this WGLC. There is clearly consensus > based on the 67 responses to the adoption call. There were only 29 people responding to the adoption call (even if some of them, including me, sent multiple messages). Only 22 stated support for adoption, and only 20 of those were unequivocal, while 7 stated unequivocal opposition. In short, the adoption proposal didn't even reach general agreement, never mind the other criteria for consensus. See Section 5. It's wrong to equate a clear _majority_ with clear _consensus_. By highlighting the number 67, and by claiming that consensus was "clear", the AD's message discourages reviewers from checking the facts. This is inappropriate. > I support the TLS WG Chairs > decision on calling consensus. As I stated above, the AD's message is taking sides, not attempting to resolve the dispute. > If you wish to appeal the TLS WG Chairs > decision based on RFC 2026, Section 6.5.1 you may do so by contacting me > using a working email address. This is violating the BCP 9 procedure. The procedure clearly states that "A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s)". I had briefly summarized the top three objections to the draft, and had asked the chairs how they came to the conclusion that there was consensus. I was still waiting to hear back from the chairs. The AD should have allowed that process to proceed, rather than disrupting it. > If you present no new information to your > appeal to the chairs, I would deny your appeal. So we have one of the ADs preemptively declaring, before even receiving an appeal, that the appeal will be rejected (unless the appeal somehow digs up "new information" beyond the archives of the responses to the adoption call). This is a violation of "The Area Director(s) shall attempt to resolve the dispute". > My decision could then > be appealed with the IESG. The existence of a subsequent appeal stage does not remove the "shall attempt to resolve the dispute" requirement placed upon the ADs. > The vast majority was in favour of adoption, "Vast majority" means "almost all of a group of people or things" (<https://www.ldoceonline.com/dictionary/the-vast-majority-of-something>). The 22 people in favor (including 2 with conditions) are not "almost all" of the 29 people who spoke up. > and this included several > vendors who stated they have implementations. I noticed only two such statements. Also, if we're counting vendors, then why were Google's David Adrian and Google's Sophie Schmieg allowed to cast separate votes? Anyway, IETF claims that "Participants engage in their individual capacity, not as company representatives". More to the point, the top objection here is not to the draft's implementability, but to its security risks. > There were further no > raised technical issues. I don't know what this claim means, and I don't know why it's supposed to be relevant. The concept of consensus puts constraints on how _all_ comments and objections are handled, not just "technical issues". > There were a few dissenting opinions that > preferred pure PQ should not be done at all. Recall the earlier text claiming that there is "clearly consensus based on the 67 responses to the adoption call". Notice the contrast between "67 responses" and "a few dissenting opinions". The reader is being told that the supporters-to-objectors ratio was something like 20 to 1. But this is simply not true. The actual tallies are as follows: during the specified adoption-call period, 20 people expressed unequivocal support, 2 people expressed conditional support, and 7 people unequivocally objected. See Section 5. It is **astounding** that the AD still has not issued an erratum regarding "67 responses ... vast majority was in favour of adoption ... There were a few dissenting opinions". The gap between the AD's text and the facts was pointed out in April; see Section 10. > Note that this document > does not set a mandatory to implement or RECOMMENDED Y option, allowing > those who wish to avoid pure PQ to keep avoiding these in the future. > Your arguments on whether hybrid is more secure than pure would be > valid arguments in a discussion about MTI or RECOMMENDED status. > However, this is not that discussion. This is not responsive to the objections. The objections were stated as objections to the actual proposal on the table, the proposal to adopt the draft. They were not merely objections to a potential proposal to recommend or require the draft. ### The transparency violation Regarding my statement that the lack of explanation for the consensus call was in violation of "IETF activities are conducted with extreme transparency, in public forums", the AD wrote the following: > There is no such violation, The public was not provided records showing how the chairs concluded that there was consensus. That's not "extreme transparency". This is also not compliant with the record-keeping requirements in BCP 9, Section 8, which requires a public record of "complete and accurate minutes of meetings" along with "all written contributions from participants that pertain to the organization's standards-related activity". The chairs must have discussed the consensus question, whether by a virtual meeting (telephone, Zoom, etc.) or by a physical meeting or by email; so where are the records of the email, or the minutes of the meeting? [I have appealed the transparency failure here to IAB.] > and you cherry-picking when to call > consensus evaluation "voting" The word "voting" accurately describes what actually happened in this incident. See Section 5. If it walks like a vote and quacks like a vote then it's a vote. > depending on whether misnaming this > is in your advantage (eg recently on the ssh list) is dishonestly > manipulative and has no place on this list or anywhere else at the IETF. This is not responsive to any of the objections at hand, and also doesn't answer the question of how the chairs arrived at their conclusion that there was consensus. The AD is also violating IETF's code of conduct by issuing this ad-hominem attack. > Your insinuation that this WGLC was not conducted with "extreme > transparency" is in itself a violation of our code of conduct No. It's properly filing a complaint about a transparency violation: "As a procedural matter, this lack of explanation is in violation of 'IETF activities are conducted with extreme transparency, in public forums'. Please rectify this violation immediately." As a side note, the word "insinuation" means "something that someone says which seems to mean something unpleasant, but does not say this openly" (<https://www.ldoceonline.com/dictionary/insinuation>). > through > insinuations and a continuation of behaviour you have been warned > about recently by the TLS WG chairs, confirmed via me as the TLS AD, > and the IESG[1]. I recommend you voluntarily stop this kind of behaviour > to avoid triggering measures under the terms of RFC3934 which is part > of BCP25. > You are free to voice your dissent. You are not free to make up > accusations against process or individuals. The specific citation "[1]" is to <https://datatracker.ietf.org/group/iesg/appeals/artifact/126>. That document said that an appeal to IESG was misdirected; it didn't comment on the content of the appeal, let alone taking the position that the AD attributes to the IESG here. Anyway, this text from the AD is again not responding to the topics at hand; it is just another ad-hominem attack. ## 8. Questions about the AD disruption I sent email dated 16 Apr 2025 15:10:18 -0000 with clarification questions about portions of the AD's message. I started by quoting "Responding as AD" and continuing as follows: > Hmmm. I thought that a "person who disagrees with a Working Group > recommendation shall always first discuss the matter with the Working > Group's chair(s)", whereas AD involvement is only if "the disagreement > cannot be resolved in this way". This provides multiple levels of > opportunities to resolve disagreements. > > So I posed a question to the chairs: specifically, asking how they came > to the conclusion that there was consensus here. I also explained why I > was asking. (Procedurally, I also shouldn't have to ask.) > > Does the new AD interruption mean that the chairs are no longer obliged > to engage in discussion of their action? In other words, has the AD > single-handedly destroyed a mandated opportunity for resolution? If so, > what's the authorization for this under IETF procedures? > > The situation was already a bit messy before this (for example, were the > chairs deterring input when they issued a consensus declaration before > the end of the call period?), but at this point it's very difficult to > figure out how the situation relates to how the IETF standardization > process is supposed to work. > > I'm also not sure how this can be brought back to the proper procedures. > Withdrawing the AD message isn't going to magically restore independent > evaluation by the chairs. I then quoted the AD's "There is clearly consensus based on the 67 responses to the adoption call" and "The vast majority was in favour of adoption" vs. "a few dissenting opinions". I asked the following questions: > I have an easy question and a harder question. > > The easy question, just to make completely sure that I'm not missing > something: You're saying that the numbers here, such as "67" and "a > few", were considered as part of your forming a conclusion that there's > consensus here? > > (I assume the answer is simply "yes"---why else would the numbers have > been brought up?---but I'd just like to make sure.) > > The harder question: For transparency, please explain how many different > people you're referring to in saying "67 responses" and "vast majority" > and "a few", and please provide details so that the rest of us can check > your tallies. > > My impression from watching the list is that the actual ratio between > the numbers of objectors and supporters is vastly larger than the ratio > between "a few" and "67", for any reasonable understanding of "a few". Finally, regarding the AD's claim that there were "no raised technical issues", I wrote the following: > Can you please clarify what exactly you mean by "technical" here, why > this criterion factors into the question of whether there's consensus, > and why the issues raised (e.g., the security risks of non-hybrids) > don't qualify as "technical"? Thanks in advance. I also included short responses to specific AD comments on the objections that I had highlighted as flaws 1, 2, and 3. Those responses are included in the more comprehensive text in Section 7, so I won't repeat them here. ## 9. AD disruption, continued The AD sent email dated 16 Apr 2025 20:43:21 -0400 as follows. ### The violation of BCP 9's resolution procedures I had written the following: "I thought that a 'person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s)', whereas AD involvement is only if 'the disagreement cannot be resolved in this way'. This provides multiple levels of opportunities to resolve disagreements." The AD wrote the following: > If you look at an individual issue, then yes that is the regular > procedure. In your case, you seem to object to most WG decisions not in > your favour and question motivations of every decision and individual > involved in the decision chain. And frankly, it is already a denial of > service on the time of many volunteers within IETF, from WG chair to > the IESG. > To make it more clear and blunt, you calling into question this consensus > call of the WG chair is abusive and follows a repetitive pattern. > Nevertheless, for now this is your right, and we will walk through > the process. Here the AD is engaging in further ad-hominem attacks, again violating IETF's code of conduct. The reader is forced to wade through all of this to see that the AD isn't responding to the point at hand, namely that the AD violated BCP 9. ### The transparency question, again Regarding my paragraph "So I posed a question to the chairs: specifically, asking how they came to the conclusion that there was consensus here. I also explained why I was asking. (Procedurally, I also shouldn't have to ask.)", the AD wrote the following: > Unfortunately, it looks like you are attempting to bait the chairs to > say they took inventory of the public emails and then throw in some > quotes about "you counted votes but IETF does not vote". In fact, my first message questioning the claim of consensus had said the following: "Surely you aren't relying on some tally of positive votes to ram this document through while ignoring objections; voting isn't how IETF is supposed to work. So how _did_ you come to this conclusion?" So the AD's "bait" claim makes no sense. I had _already_ pointed out that voting isn't how IETF is supposed to work. I was asking for transparency regarding how the chairs had arrived at their conclusion that there was consensus. At this point there still wasn't an answer from the chairs; there was just the AD disruption. > My previous > email explained the obvious way the consensus was validly called. > This > can be independently verified by anyone reading the email thread. No. Repeatedly declaring something to be clear and obvious doesn't make it so, nor does it answer the transparency question about how the chairs had arrived at their conclusion. (The chairs later ended up providing information that can't be reconciled with what the AD claimed was "the obvious way the consensus was validly called". See Section 12.) > The fact that you are the only one questioning the consensus should be an > indication that your reasoning to doubt the consensus call might in fact > be erroneous. When an objection is raised, the content of the objection should simply be addressed. Sometimes people speak up with clarifications to the objection, supplements to the objection, etc., but if the objection is clear and complete in the first place then having other people speak up merely to reiterate the objection is neither required nor desirable. This is supposed to be the Internet Engineering Task Force, not the Internet Politics Task Force. Replying "you are the only one questioning the consensus", and claiming that this is an indication of error, is both procedurally improper and factually unsupported. In this case it's also factually incorrect, both in the premise and in the conclusion. (In response to the AD, Thomas Bellebaum wrote "He is not the only one"; see Section 10. Regarding the conclusion, see Section 5.) ### The violation of BCP 9's resolution procedures, again Regarding my questions "Does the new AD interruption mean that the chairs are no longer obliged to engage in discussion of their action? In other words, has the AD single-handedly destroyed a mandated opportunity for resolution? If so, what's the authorization for this under IETF procedures?", the AD began by issuing a threat: > Dan, there comes a point where you will be prevented from further playing > these games. There are processes for that, that we really try hard to > avoid invoking. But as some point you leave us no choice. The AD continued by claiming that consensus was not just "obvious" but "_very_ obvious": > This consensus call was _very_ obvious based on the email thread content, > again as I explained in my previous message. Whether the TLS Chairs > feel obliged to send you another message repeating the obvious is pretty > irrelavant other than taking up valuable time an energy of an entire WG > in playing a process game with you. Unless you are invoking an appeal > as per RFC 2026 Section 6.5.1 against the WG chairs decision that there > is consensus to adopt, they are under no obligation to answer you with > something they deem obvious. It is completely up to the chairs to make > their own decision here. Either way is acceptable in our process. I had questioned the consensus call, briefly explaning why and asking the chairs for explanation. This was following the BCP 9 procedure ("A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s)"). But I hadn't explicitly _pointed_ to BCP 9. The AD's paragraph seems to be saying that, because of this, the chairs were not obliged to engage in discussion. I later followed up with an explicit reference to BCP 9; see Section 11. Regarding "game", see above. > Once you send an RFC 2026 Section 6.5.1 appeal to them, according to > process they MUST respond to you. Presumbly once denied - if they are > not convinced by your arguments in your appeal - you can then send the > same text, with your usual disclaimer that in your opinion I need to > recuse myself, to me as TLS AD, and I will reply with "based on the > public discussion on the list, with the overwhelming majority being in > favour of adoption as long as the MTI/RECOMMENDED values would remain > "NO", with a few dissenting views of wanting to block all pure PQ in > all IETF protocols in favour of IETF only adopting hybrids, and with > no technical flaws pointed out in the specified protocol by anyone, > considering there are already a number of interoperable implementations > based on early code points, it is unmistakenly clear that the TLS Chairs > correctly called consensus on adoption of this document. Your appeal > is denied". Upon which you can file another appeal of my decision to > the IESG. Content-wise, this is similar to the previous claims about "67 responses" with just "a few dissenting", and about there being "no technical flaws". Some of the wording is different: "vast majority" has changed to "overwhelming majority", and "clear" has changed to "unmistakenly clear". ### The violation of the specified call period Regarding my comment "The situation was already a bit messy before this (for example, were the chairs deterring input when they issued a consensus declaration before the end of the call period?)", the AD wrote the following: > According to > https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/history/ > a two week adoption call went out on 2025-04-01 and the document status > was set to adopted on 2025-04-15. (datatracker provides no finer > granularity in its History tab) This matches the email dates on the > respective TLS email messages: > Start: 01 April 2025 12:58 UTC > https://mailarchive.ietf.org/arch/msg/tls/PpVAwrBTuRb5pR6D0C1ipdQuvYc/ > End: 15 April 2025 17:27 UTC > https://mailarchive.ietf.org/arch/msg/tls/_AWy51BSgX1ipv0hfnAzLrDrTYI/ > You are correct that Sean did say in the announcement that the call > would close at "2359 UTC on 15 April 2025", so indeed technically > speaking it was called 6 hours too early. However, usually adoption and > last calls are send out for a period of weeks and usually chairs send > out a message on which day a call ends without further hourly > granularity. Regardless, it was obvious that at the time no active > discussion about fundamental issues was taking place and calling this > adoption ended on the last day of the adoption call period caused no > stiffling of discussion. I am further confident that if any real > discussion had taken place, the chairs would have not called it and > would have extended the adoption call to give any active discussions > more time to settle. I also see no valid reason to extend the adoption > call by 6 hours. The claim that no "real discussion had taken place" is correct in the sense that supporters were ignoring the content of the objections. But this was improper---recall from Section 5 that consensus requires addressing each objection---and certainly cannot justify further procedural violations. ### The lack of procedural clarity Regarding "at this point it's very difficult to figure out how the situation relates to how the IETF standardization process is supposed to work", the AD wrote the following: > As in all cases regarding WG level document disagreements on WG chairs > decisions, you should follow RFC 2026 Section 6.5.1 as indicated to you > a number of times over the last few months. If you feel the WG Chairs or > AD is giving you conflicting information, you should stick to RFC 2026. I don't find BCP 9 (RFC 2026) so clear---for example, when BCP 9 says "A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s)", it doesn't say "the person shall cite this provision", whereas the AD seemed to think this was a critical requirement---but, as noted above, I did end up explicitly invoking it after the AD disruption. See Section 11. ### The lack of independence Regarding "I'm also not sure how this can be brought back to the proper procedures. Withdrawing the AD message isn't going to magically restore independent evaluation by the chairs", the AD wrote the following: > I disagree we are deviating from existing procedures. You just had a > glimpse of the obvious continuation of the process, were you to invoke > process from RFC 2026 Section 6.5.1. You have not yet invoked that > process as far as I know. You have until June 15 17:27 UTC to appeal. This is not responding to the point about independence. Under BCP 9, a disagreement is supposed to be discussed with the chairs first. That's a first stage that could resolve the dispute. If that doesn't settle things, anyone can contact the AD, who "shall attempt to resolve the dispute". That's a second independent stage trying to resolve the dispute. (Theoretically independent, at least.) What happened here was instead that the AD replaced both steps of this procedure with preemptively taking one side of the dispute, not even giving the chairs a chance to resolve the dispute. ### The AD's wrong numbers Regarding my question "You're saying that the numbers here, such as '67' and 'a few', were considered as part of your forming a conclusion that there's consensus here?", the AD wrote the following: > The use of the number 67 refered to the number and content of all messages > in the adoption call email thread on the TLS list - which is the entire > information base upon which the consensus call by the chairs took place, > and also constitutes the information on why I believe the chairs reached > the right conclusion. This is dodging the question. I had asked how the chairs had arrived at their conclusion regarding consensus. The AD had jumped in saying "There is clearly consensus based on the 67 responses to the adoption call. ... The vast majority was in favour of adoption ... There were a few dissenting opinions"---along with some other text, but the statements about "67 responses" and "vast majority" and "a few" are prominently placed and look like important parts of the AD's argument that there was consensus. Having watched the actual responses to the adoption call, I was under the impression that the AD's numbers were divorced from reality. However, I hadn't done the work to tally the actual numbers at that point. So, before doing that work, I wanted to check that, yes, the AD's claim of consensus was based in part on these numbers. Regarding my parenthetical comment "I assume the answer is simply 'yes'---why else would the numbers have been brought up?---but I'd just like to make sure.", the AD wrote the following: > I am not answering your question as a boolean. See my previous paragraph. This is an easy yes-or-no question. Yes means that these numbers are part of the rationale for the AD's conclusion. No means that they aren't. Leaving out the numbers would have sounded very different---"clearly consensus based on the responses"; "There were dissenting opinions"; "The majority was in favour of adoption"---basically telling readers that the AD was defining "consensus" as "majority". What the AD actually wrote sounded much more lopsided (as one would expect given the requirement of general agreement): "vast majority" of "67 responses" vs. "a few dissenting". So I was expecting a quick response saying, yes, of course these numbers are part of the rationale. Instead the AD refused to give a straight answer. Being ambiguous about the answer is a transparency violation, and sabotages the appeal process. Imagine doing the work to challenge the numbers, and _then_ receiving a response saying "No, those numbers were never part of the rationale". Regarding "please explain how many different people you're referring to in saying '67 responses' and 'vast majority' and 'a few', and please provide details so that the rest of us can check your tallies", the AD wrote the following: > The only way to win is not to play. I am not playing your game of > forcing me to use numbers only to have you call out "counting is voting". > The content of 67 messages was produced by the WG. Based on the entirety > of the content of those messages, consensus was determined. This is dodging the question, and violating the requirement of transparency. Regarding my stated impression "that the actual ratio between the numbers of objectors and supporters is vastly larger than the ratio between 'a few' and '67', for any reasonable understanding of 'a few' ", the AD wrote the following: > I never put "a few" against "67". That is a misleading construct you > devised, not me, nor the chairs. This is baffling. Where is the AD's "vast majority" claim coming from, if not those numbers? Why didn't the AD provide exact numbers in the first place? Did the AD ever actually do the work to go through the messages? ### Flaw 1, again Regarding "The only reason that CECPQ2 didn't expose user data to pre-quantum attackers is that it had the common sense to include an ECC layer", the AD wrote the following: > This is not new information. The WG heard your statement and people took it > into consideration when they expressed their opinion on whether to adopt > the document. Saying that an objection isn't new (1) isn't responding to the objection, and (2) isn't defending the specific AD claim at issue, namely the AD claim that omitting hybridization isn't a "basic flaw". ### Flaw 2, again Regarding "the failure to provide an engineering justification for this option", the AD had falsely claimed that this "is your own made up condition", and in response I had quoted a CFRG document saying "begin by articulating _what issue or gap needs to be addressed_". Instead of admitting error, the AD wrote the following: > If you had expressed these views at the start of the adoption call, > people could have taken this into account. Some of the people that > participated on the adoption call were undoubtedly already aware of > these quotes. > Regardless, "providing an engineering justification" is not something > that one individual (you) can add to the TLS charter in an adhoc matter. This is not responsive. Certainly the charter can be a source of objections---and in fact it was in this case: I objected that this draft was in contravention of the "improve security" goal in the charter. But this doesn't mean that the charter is the _only_ allowed source of objections. On the contrary, consensus requires general agreement _and_ addressing _each_ objection. See Section 5. Furthermore, a WG charter cannot override IETF's broader claim that "IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user". It is puzzling that the AD persists in claiming that an engineering justification isn't required. ### Flaw 3, again Regarding "the lack of any principles that would justify saying no to options selected by other governments if this option is allowed", the AD had claimed that this was out of scope since the draft "does not set policy for other documents or governments", and I had said "Non sequitur. Supporting endless options is a systemic security problem, so the WG shouldn't take every option that's proposed---but then there should be principles for the dividing line. This is entirely about what the WG is endorsing, not about the level of WG power over anyone else". The AD wrote the following: > This is not about "endless options". This is about pure ML-KEM. It is > clear your view on pure ML-KEM is not universally agreed upon. The objection here is explicitly looking beyond the particular draft at hand, and asking for principles regarding what to include and what to exclude. Making ad-hoc decisions is a due-process violation. Saying that this particular draft is about just one option is not addressing the objection. ### "Technical issues" Finally, regarding the AD's claim that there were "no raised technical issues", I had asked "Can you please clarify what exactly you mean by 'technical' here, why this criterion factors into the question of whether there's consensus, and why the issues raised (e.g., the security risks of non-hybrids) don't qualify as 'technical'?" The AD wrote the following: > I meant a concrete issue or flaw. Not a hypothetical one. Nor the number > of airbags deemed not enough or too much in your hypothetical car with > seatbelts. Two preliminary notes seem warranted here. First, regarding vocabulary: "hypothetical" means "based on a situation that is not real, but that might happen" (<https://www.ldoceonline.com/dictionary/hypothetical>). Second, regarding security: A tremendous amount of research and development has gone into systematically considering and proactively eliminating large classes of potential attacks---or at least proactively reducing the damage---rather than merely reacting to demonstrated attacks. This is what happens in every paper on security proofs. This is the motivation for a wide range of standard security tools: for example, key erasure reduces the damage if a device is compromised, and password hashing reduces the damage if a backup is compromised. This is also the motivation for hybrids, reducing the damage if post-quantum systems are compromised---as happened in the case of SIKE. Ignoring hypothetical attacks would be a remarkable regression from the state of the art. Now back to the discussion. The AD's text here is very far from a clear answer to the three questions I had asked. If the AD is claiming that security failures of non-hybrids are hypothetical, how does the AD explain SIKE? Furthermore, it is completely unclear how non-hypothetical is supposed to be connected to "technical" and, via that, to the question of whether there was consensus. ## 10. Terminating the AD disruption Thomas Bellebaum sent email dated 17 Apr 2025 10:01:30 +0000 that started "I am sorry for interrupting your argument, but as you are discussing this on-list:", quoted the AD's "you are the only one questioning the consensus" paragraph, and then wrote the following (plus line breaks suppressed here): > He is not the only one. Using the independently verifiable mail thread, I > actually > did count by a rough look over the messages (sorry if I missed/misinterpreted > someone): > Pro Adoption: > - Alicja Kario > - Andrei Popov > - David Adrian > - Filippo Valsorda > - Flo D > - Jan Schaumann > - John Mattson > - Joseph Birr-Pixton > - Kris Kwiatkowski > - Loganaden Velvindron > - Martin Thomson > - Quynh Dang > - Rebecca Guthrie > - Russ Housley > - Scott Fluhrer > - Sophie Schmieg > - Thom Wiggers > - Tirumal Reddy > - Uri Blumenthal > - Viktor Dukhovni > - Yaakov Stein > - Yaroslav Rosomakho > Against Adoption: > - Andrey Jivsov > - Dan Bernstein > - Rich Salz > - Rob Sayre > - Stephen Farrell > - Sun Shuzhou > - Thomas Bellebaum > I am counting 22 expressions in favor of adoption and 7 opposing adoption. > This amounts to about every fourth person objecting the draft in its current > state at > this time, which seems more than can be explained by mere blocking of few > individuals. The AD sent a followup dated 17 Apr 2025 09:04:10 -0400 saying "Note that the consensus call was for Working Group Adoption. Not publishing as is". This is non-responsive. The call was for adoption of the draft, and all seven people listed above (including me, obviously) were stating unequivocal objections to adoption of the draft. (See Section 5 for quotes and links.) Bellebaum continued with procedural objections, which the AD never quoted and never replied to: > I am not questioning that this is a sound majority, but consensus is a harsh > word. > Neither am I threatening to appeal, but I do share the view that merely > declaring > concerns such as "hybrids are way more conservative" as > hypothetical/irrelevant to > whether or not to publish this is not a reasonable way forward. The feeling > (I am > not saying "the fact") of this happening is valid. > However, openly accusing others of playing games or ignoring procedures does > not > result in good specifications. > Raised points should be discussed and adequately addressed to reach a > consensus (i.e. > significantly better than 3 out of 4). We are not making a black-or-white > decision > on publishing or not, we are influencing many aspects of the document. Bellebaum finished by stating a wishlist for "the new WG item". The AD did quote that part, and claimed that "This sounds like you are not objecting to adoption, but objecting only to publication as is?". Bellebaum responded to the contrary: "I still believe that not adopting this would have been better, but I am willing to follow along and help improve the document." Of course, standards-development organizations cannot force participants to withdraw an objection to a document as a condition for participating in further development of the document. More to the point, this complaint is challenging the validity of the consensus declaration in the first place. There was a specified period for the adoption call, and that call failed to produce consensus on adoption; see Section 5. Consequently, this draft was never a valid WG draft. The only way to change this would be to obtain general agreement while properly addressing every remaining objection. Amazingly, the AD _still_ has not withdrawn his text about "67 responses" with the "vast majority" supposedly in favor and just "a few dissenting". But Bellebaum's tallying of the facts did seem to stop the AD from commenting further, while it triggered further messages regarding the question of how to evaluate consensus. ## 11. Explicitly invoking RFC 2026 I sent email dated 18 Apr 2025 14:02:55 -0000 quoting Bellebaum's "I am counting 22 expressions in favor of adoption and 7 opposing adoption" and continuing as follows: > Thanks for doing the work to tally this, and for posting the details so > that people can check your message and post any necessary adjustments. > These numbers sound radically different from the AD's portrayal ("67 > responses ... vast majority was in favour ... a few dissenting > opinions"). My own impression, from having read all messages as they > came in, was about a quarter of the people opposing, so I will be very > surprised if adjustments end up big enough to rescue the AD's portrayal. > So: Can we please now have an explanation from the chairs of how they > arrived at "It looks like we have consensus to adopt this draft as a > working group item"? > To prevent any confusion about the procedures: Based on what I've seen > (the whole discussion, not just the fragmentary information conveyed by > numbers), I disagree with this declaration of consensus. I am therefore > invoking the "first discuss the matter with the Working Group's > chair(s)" provision of RFC 2026, Section 6.5.1. I ask for this > discussion to be on-list for transparency. > Within that, what I'm suggesting---both because I think it's the natural > way forward, and because of transparency considerations; I'm not saying > this is the only possibility under RFC 2026---is for the chairs to start > by explaining to the WG how they evaluated consensus, so that we can all > consider the explanation, rather than starting with a bunch of > conflicting guesses from the rest of us regarding how consensus might > have been evaluated. By now I have double-checked Bellebaum's list and concur with the tallies, except that the support statements from Mattsson and Stein were conditional (see Section 5 for quotes). To be clear, even if there had been 22 unequivocal supporters vs. 7 unequivocal objectors, that would not have constituted "general agreement", never mind the other requirements for declaring consensus. ## 12. Conflating consensus with interest Turner sent email dated 18 Apr 2025 11:27:36 -0400, apparently on behalf of the chairs, as follows: > Joe and I, as WG chairs and with Deirdre recusing as she is an author, > declared > consensus to adopt draft-connolly-tls-mlkem-key-agreement. We did this > because there > is clearly sufficient interest to work on this draft. Different working > groups have > different styles with respect to how much work is done by the individual > author, > versus how much work is done by the WG after adopting the work. Now that the > draft > is a WG draft, we will follow WG process by discussing concerns, already > raised and > new ones, under IETF change control and progressing after there is consensus. I sent email dated 18 Apr 2025 16:47:14 -0000 starting by responding to the first two sentences as follows: > Thanks for your message. > "Sufficient interest to work on this draft" is ambiguous (sufficient for > what?), and in any case clearly not the correct criterion for declaring > consensus to adopt a draft. > As an extreme example, this criterion would allow a draft to be adopted > over amply justified objections of almost all WG participants, simply > because the chairs and a few participants say they have enough interest > in working on the draft! That's more extreme than what happened here, > but it shows that the criterion stated above is procedurally improper. > So I'm guessing that you had some further points in mind in deciding > that there was consensus to adopt this draft. For transparency, can you > please, without omissions, say why you declared consensus to adopt? Or, > if the above really is the complete explanation, can you please say so > explicitly, to enable an appeal saying that this was improper? Either > way, can you please clarify what "sufficient" is referring to? Thanks > in advance. Regarding the "different working groups" sentence, I wrote the following: > This generic background information about WG work allocation seems off > topic (the topic being the disagreement regarding consensus). Certainly > this background information doesn't say anything about the draft at > hand. If I'm missing some connection, please elaborate. Finally, regarding the "we will follow WG process" sentence, I wrote the following: > This also isn't addressing the consensus question, plus it seems to be > denying the existence of the active RFC 2026 Section 6.5.1 procedure > challenging the chairs' decision to adopt in the first place. Turner sent email dated 25 Apr 2025 15:04:39 -0400, apparently on behalf of the chairs, as follows: > "Sufficient" to Joe and I means that there were enough people willing to > review the > draft. WGs groups have adopted drafts with much less support than this one > received. > Now that the document is adopted by the WG, consensus, as judged by the WG > chairs > (minus Deirdre because she is an author), is needed to progress the draft. > Joe and I have reviewed the WG adoption call messages for ML-KEM Post-Quantum > Key > Agreement for TLS 1.3 [0] and stand by our consensus call. You can appeal > this with > the AD: Paul Wouters, but also consider his reply here [1]. Reference "[0]" was to <https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/>, and reference "[1]" was to <https://mailarchive.ietf.org/arch/msg/tls/nqouPVfPtU7hm-RF0lSDHCfze54/>. Let's now review the procedure that the chairs say they used for evaluating consensus to adopt: * The procedure asks purely whether there is "sufficient interest to work on this draft", meaning "enough people to review the draft". (Presumably the number of people is compared to the complexity of reviewing the draft.) * The procedure does not place a minimum requirement on the number of people stating support. "Much less" than 22 is fine. * This procedure does not consider objections to adoption. Notice that, structurally, this procedure is an ad-hoc procedure for evaluating consensus to adopt, rather than being a general procedure to evaluate consensus on any decision. Notice also that this procedure is radically different from what the AD had claimed was the obvious reason for the consensus declaration (67 responses, "vast majority" supporters, just "a few dissenting", etc.). Of course, that claim was before Bellebaum posted the actual numbers (22 supporters, 7 objectors). Most importantly, this procedure is missing all of the consensus requirements reviewed in Section 5. The procedure does not even say that a majority is required, let alone general agreement, never mind any of the specific requirements for handling comments and objections. I am not saying that this procedure, applied to the situation at hand, would say that there were not enough reviewers for the draft. I am saying that this procedure is not evaluating consensus. Properly evaluating consensus, as in Section 5, shows a variety of reasons that this adoption call failed to reach consensus. ## 13. Complaining to the ADs I filed a complaint with the ADs on 5 June 2025. I quoted the authority under BCP 9 to bring this matter "to the attention of the Area Director(s) for the area in which the Working Group is chartered". There are two ADs for this area, and I explicitly brought it to the attention of both of them. I also quoted BCP 9 saying that "The Area Director(s) shall attempt to resolve the dispute". I pointed out that, since there are two ADs, this procedure requires _both_ of the ADs to attempt to resolve the dispute. (BCP 9 does not authorize ADs, or IESG as a whole, to make any exceptions to this requirement.) I also noted that I had already, before the complaint, laid out a case that both ADs should recuse themselves from various matters. (The behavior by one AD regarding this matter is further evidence on point. Observers with no prior knowledge regarding the AD, simply looking at how the AD has behaved here, will correctly infer that the AD has a conflict of interest. Conflict-of-interest policies protect the organization by requiring recusal when there is even the _appearance_ of a conflict.) My complaint was within that scope: i.e., the two ADs should have turned this matter over to two neutral arbiters. I said, however, that my understanding was that the ADs were refusing to do so. ## 14. AD evasion The AD who had disrupted the earlier discussion (see Section 7) sent email on 12 June 2025 refusing to handle the contents of my complaint. I sent email on 14 June 2025 addressing the AD's excuses for refusing to handle the complaint. Neither AD replied. This section goes through the AD's excuses for not handling the complaint. This section is similar to my email on 14 June 2025. The AD's email started as follows: > Before we can get to the content of the complaint (aka appeal), I need > to clarify some process issues with your message. I replied as follows: "Happy to discuss. However, the 'need' statement is incorrect (see below), so please go ahead with answering the contents." > First, the Security Area Directors have divided their work based on Working > Groups, with me being the responsible AD for the TLS WG so as per the > Security Area workflow decided by the Security Area Directors, RFC 2026 says "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". There is a dispute about the mid-April declaration that there was TLS WG consensus to adopt this non-hybrid Kyber draft. I explicitly brought this dispute to the attention of both ADs. Ergo, both ADs "shall attempt to resolve the dispute". There is nothing in RFC 2026 allowing one of the ADs to shirk this responsibility by declaring that the responsibility falls solely upon the other AD. This RFC 2026 requirement is not overridden by generic language in RFC 2026 saying that appeals bodies can define their appeals procedures. The requirement is also not overridden by whatever might be said in RFC 3710, which describes IESG: RFC 3710 is an Informational RFC, not an IETF policy. RFC 2026 has a precondition involving discussion with the WG chairs. In the case at hand, that discussion led to the WG chairs (1) sticking to their claim of consensus and (2) explicitly authorizing an appeal. I continued my reply as follows: "Structurally, the message that I'm replying to doesn't appear to be arguing that the situation at hand is somehow outside RFC 2026's 'shall attempt to resolve the dispute' requirement. It's raising various side issues---which, again, I'm happy to discuss, but this discussion doesn't remove this RFC 2026 requirement." > I will be > the only Area Director handling your message at this point, I asked the following clarification questions: "To clarify, you're saying that the other AD won't attempt to resolve this dispute? Surely you wouldn't be able to make such a statement without discussion with the other AD; can you please point to the records of that discussion? (Dates, minutes, email records, etc.)" There was never any answer to these questions. It's clear that the ADs intentionally violated the record-keeping requirements in BCP 9. (As noted above, this is now on appeal to IAB.) > which is presumably aimed to be a message under BCP 9 (RFC 2026) > Section 6.5.1. The document explicitly says it's invoking Section 6.5.1 of RFC 2026, and pinpoints the specific paragraph it's invoking. Consequently, the word "presumably" is inaccurate. > Second, I am unable to respond privately I began my reply to this as follows: "You can send private email to [email protected], but you shouldn't: that would be a transparency violation. This is a complaint about an action by TLS WG chairs regarding TLS WG activity, so I requested that all discussion of this complant be cc'ed to the TLS mailing list." Anyway, "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for ADs who ask for non-transparency. > The TLS WG list should not be used as a backup for not being able to > receive direct emails. This statement has nothing to do with my complaint. My complaint cited various transparency requirements, and on that basis asked for the discussion of this TLS WG consensus call to take place on the relevant mailing list, the TLS list. > Note that as per Section 6.5.1, it is the Working Group Chairs who may > decide whether or not to involve the WG as a whole: No. A quote saying that a WG chair "may" do something doesn't say that other people can't. > That is to say, WG Chairs may decide a complaint is or isnât suitable for > further discussion on the WG list. RFC 2026 doesn't say that. Furthermore, transparency requires IETF to be public in how it handles complaints about IETF standardization activity. > By continuing your participation using Contributions, you are > agreeing to operate under this Note Well. See above. > This raises concerns since there is no guarantee of the > permanence of the material behind that link, and the content will not be > part of the IETF public mail archive. <https://web.archive.org/web/20250613195523/https://cr.yp.to/2025/20250605-non-hybrid.pdf> has a copy, so the archiving concern seems misplaced. More to the point, "The Area Director(s) shall attempt to resolve the dispute" is not limited to disputes that were brought to AD attention via permanently archived documents. > The PDF format also discourages participation Such a broad general statement is certainly not true. For example, other formats are more likely than PDFs to be displayed in mangled form; when that happens, those formats are discouraging participation. I'm not saying PDF is always better than other formats. The evaluation depends on many factors, such as the type of material being presented. I often post PDFs, but I often post information in other formats. PDF is also one of the formats that IETF habitually uses, although certainly not the only one. Anyway, "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for disputes documented as PDFs. > as the content cannot be easily replied to preserving context via > email threads on the TLS WG mailing list. The AD's 12 June 2025 email is replying to my 5 June 2025 email---but for some reason _doesn't_ use the standard threading header fields to show this. So it's puzzling to see the message also recognizing that threading is a positive feature. A reply can and should be posted under the original subject line, in the same thread, for easy tracking, even if the reply is simply a link to another document. It seems that the AD's mail software doesn't make it as easy for the AD to quote a PDF as to quote something else, but typing time is a very small part of normal procedures for dispute resolution. > Thus, an email to the TLS WG mailing list consisting of a (link to) > PDF does not "involve the Working Group as a whole in the discussion". It provides the requisite transparency. It provides other people an opportunity to comment if they would like to. > This is not a valid use of the TLS WG mailing list. My complaint is on topic for the TLS WG mailing list. See above. The AD's message was unnecessarily "meta": in particular, it explicitly avoided the actual content of the complaint. But that doesn't make my messages off-topic, nor would it have justified hiding the AD's message from interested TLS WG participants. Furthermore, since the AD's message was portrayed as a step towards addressing the content, my reply to that message---trying to move things forward---was also on-topic. Interested parties have a right to see what's going on, and the TLS mailing list is the obvious place for that. > Furthermore, previous efforts of converting your remotely hosted PDFs > to a local location within the IETF archives for the community by the > IESG My guess here was and is that the AD was talking specifically about one particular earlier PDF, namely <https://cr.yp.to/2025/20250501-bcp-79.pdf>. IESG did _not_ simply repost a copy of that PDF. In particular, that document has a central diagram with two main items and various subitems; IESG posted a modified version of the document that destroyed this structure, instead showing a dozen main items in the diagram. Eventually I noticed this and complained, and it was fixed---but what other changes did IESG make? The bigger problem, before and after the fix, is that IESG placed a burden on the reader to (1) realize that something changed and (2) figure out what changed. The issue here isn't permanence. The issue is IESG turning a simple situation of a single document into an unnecessarily complicated situation of (1) an original document and (2) an unauthorized IESG-modified version of the document. There still has been no statement of why IESG modified the document in the first place. > have resulted in claims on your end of "gross misrepresentation" It's true that the words "gross misrepresentation" appear in the email that's linked at the end of this paragraph in the AD's message. However, that email wasn't from me. Amazingly, the AD still hasn't issued an erratum here. One basic part of proper dispute resolution is simply tracking who said what. One of my reasons to ask for multiple people to handle this complaint is that this reduces the risk of error. > merely for containing formatting changes: Claiming that the changes were just "formatting changes" ignores the fact that IESG changed the meaning of the document. > https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/ Having this link is what made the AD's comment about the linked message particularly easy to debunk. My reply was as follows: "Thank you for the link." > Your remotely hosted PDF furthermore contains text disallowing the > content to be reformatted and thus quoted. See above. > This prevents me and others from discussing the content. No, it does not. For example, copyright has a "fair use" exception, which I'm comfortably relying upon here in giving many quotes and commenting individually on each quote, allowing readers to easily track which comment is in reply to which quote. > Additionally, as you did not mail the PDF to any IETF mailing list, > there is now a question as to whether this link to a remotely hosted > PDF is considered a Contribution under the IETF Note Well. Again: "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for disputes documented as PDFs. > If it is not a Contribution, it cannot be a complaint (appeal) under RFC > 2026 Section 6.5.1. That section says no such thing. Regarding the specific complaints about PDF etc., see above. > If it is a Contribution, it cannot come with its own stipulated > restrictions. See above. > The text, which you did not consent me to quote, does not > comply with your agreed participation under the Note Well. "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for ADs issuing complaints about alleged violations of other procedures. > BCP 9 (RFC 2026) > Section 10.2 states: > 10.2 Confidentiality Obligations > No contribution that is subject to any requirement of confidentiality > or any restriction on its dissemination may be considered in any part > of the Internet Standards Process My complaint is not confidential. Creating derived works, as IESG did with a previous PDF, is modification, not dissemination. > This text states that due to your dissemination modifier, your PDF file > cannot be considered a Contribution in any part of the Standards Process. No, the text certainly doesn't state this, nor does it imply it, nor do any of these references to confidentiality provisions create exceptions to "The Area Director(s) shall attempt to resolve the dispute". I'll stop commenting on the "Contribution"-related claims after this. > This is, however, further updated by RFC3978 Section 3.2 which states: > 3.2. Confidentiality Obligations Again, this is not a confidential document. I asked the AD two questions at this point: "Are your discussions with other IETF LLC agents regarding this matter confidential? Where are the records of those discussions?" There were never any answers to these questions. > However, it is also possible to argue that remotely linked content has not > in fact been submitted under the IETF Note Well and are thus not > Contributions as per RFC3978. In that case, you have not actually submitted > a complaint under RFC 2026 Section 6.5.1 either. Again, RFC 2026 says "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". This doesn't allow ADs to put limitations on the mechanism of bringing the dispute to their attention. > Either way, this prevents me from processing your complaint under the > Internet Standards Process. No, it doesn't. See above. > Fourth, your email to the TLS WG list (thus per definition a Contribution) > contains additional instructions that you are attempting to force I replied by quoting "IETF participants have impersonal discussions." > onto the > Internet Standards Process that are not codified in any RFCs: At this point the AD continued by quoting my request for transparency: "For transparency, please carry out all discussion of this matter on the relevant public mailing list ([email protected]), including, but not limited to, any discussions of this matter among IESG members, IAB members, agents of IETF Administration LLC, etc." The AD is claiming that my transparency request lacks authority from RFCs. Most readers will understand this as claiming that my transparency request lacks authority from IETF. Both parts of this are incorrect. IETF LLC says that IETF operates with "extreme transparency". RFC 2026 says that "Each of the organizations involved in the development and approval of Internet Standards shall publicly announce, and shall maintain a publicly accessible record of, every activity in which it engages, to the extent that the activity represents the prosecution of any part of the Internet Standards Process". More specific language in RFC 2026 requires records of "complete and accurate minutes of meetings" (my complaint here is that IESG members are violating the word "complete") and records of "all written contributions from participants that pertain to the organization's standards-related activity" (my complaint here is that IESG members are hiding their email on this topic). These RFC 2026 requirements, like another requirement that I commented upon above, are not overridden by generic language in RFC 2026 saying that appeals bodies can define their appeals procedures. They are also not overridden by whatever might be said in RFC 3710, which describes IESG: RFC 3710 is an Informational RFC, not an IETF policy. For discussion of TLS WG activity in particular, the obvious place for these records is the TLS mailing list. Burying the records in some place that's theoretically public but hard to find is not a reasonable interpretation of "publicly accessible" and is certainly not "extreme transparency". > You have been notified that this is inappropriate before, by the IETF > Executive Director: > https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/ I hadn't seen that message before the AD linked to it---looks like it was buried on some obscure mailing list, which, again, is contrary to the point of transparency rules. Anyway, the contents of the message don't say what the AD claims they're saying, and in any event they're not relevant to "The Area Director(s) shall attempt to resolve the dispute". > By insisting on including this language, you are misleading participants > about their responsibilities and obligations under the Internet Standards > Process as set forth by the IETF (again via the Note Well that you > voluntarily comply to by sending messages to IETF mailing lists). See above. > You are > purposefully amplifying this misleading text with a "Thanks in advance" > modifier, that further exacerbates the misleading message by giving it a > false aura of authority. I have no idea how putting "Thanks in advance" after "Please ..." is conveying a "false aura of authority". > This is not appropriate use of the TLS WG mailing list. I've complained about an erroneous declaration of TLS WG consensus. The discussion of the complaint belongs on the TLS WG mailing list. > Summary > Your message to the TLS WG list on June 5 2025 does not constitute a valid > submitted Contribution or complaint under RFC 2026 Section 6.5.1, but you > can rectify this by sending a compliant email to the Area Director and/or > TLS WG mailing list. Again: RFC 2026 says "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". > Your unique personal process This is another point where I replied by quoting "IETF participants have impersonal discussions." > negatively affects the IETF Standards Process by confusing > participants in what they can and cannot do with the content of your > emails, including hyperlinks to off-site material that you sent to the > list. Hyperlinks appear all the time on IETF mailing lists. > They may further feel prohibited from discussing your email > content - in email threads or otherwise - by your disclaimers and > stipulations on how to behave. Vague comments about "stipulations on how to behave" aren't addressing what actually happened here. As noted above, I posted a complaint with a central diagram having two main items and various subitems; IESG posted a modified version of the document that destroyed this structure, instead showing a dozen main items. I complained about this. Someone then fixed that particular problem, but there wasn't even an apology, let alone assurance that such incidents won't recur. > They might also be discouraged from engagement for safety reasons "Safety reasons"? I asked what the AD was talking about here. The AD never answered. My best guess is that the AD has somehow acquired the notion that the dividing line between links that are safe to click on and links that aren't is the dividing line between links ending ".html" and links ending ".pdf". > and/or because following a discussion via attached PDF files is too > cumbersome. Regarding the oversimplified view of PDF as a bad thing, see above. Regarding "too cumbersome", it's up to individual participants to decide what they want to follow. Of course, IETF LLC agents in particular are under more stringent obligations, such as "The Area Director(s) shall attempt to resolve the dispute". > This in turn, might lead to a false sense of consensus in the WG. I responded as follows: "This unsubstantiated speculation about conceivable future events is not relevant to the complaint at hand, which is about an erroneous consensus call from mid-April 2025. Can you (and the other AD) please attempt to resolve the dispute, as required by RFC 2026?" There was no reply; the ADs continued to violate RFC 2026. > You are requested by me as Area Director to stop engaging in this > behaviour. I responded with the following questions: "I understand that you're asking me to stop linking to PDFs. To clarify, am I correctly understanding that 'request ... as Area Director' means 'demand', with a threat that you will use your position as AD to impose punishment for non-compliance? What exactly do you believe gives ADs authority to ban links to PDFs? [Then after a paragraph break:] Note that draft-connolly-tls-mlkem-key-agreement normatively cites NIST's ML-KEM standard---which is a PDF. Is that also banned now?" There was no answer. PDFs are so widely used for professional communication that the AD's anti-PDF narrative comes across as bizarre.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
