[TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call
Andrew Lee <andrew@joseon.com> Thu, 02 July 2026 18:21 UTC
Return-Path: <andrew@joseon.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 208A810CD6EDC for <tls@mail2.ietf.org>; Thu, 2 Jul 2026 11:21:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783016504; bh=ivzUWjaZQWSpmUaL3M5sjxxfeZESunmViUondjDr0fM=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=rmYVwHTtA2uBAruSWwetgr80eUF+yLbc+z/1OD7JWi3oLqzJHbEux/xqaLgLGyoWn EhR3cLD85c+7UwKT/Sa6Ugyqs2GSvrAwmEropWOzACTmQd2QcF0x+CHLO9DLA/8sg8 hNqt1MjMNFxxUvkNZEsk1sxy9xiVyGsr5wkTTQ/w=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=joseon-com.20251104.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM6LZXVw_b2s for <tls@mail2.ietf.org>; Thu, 2 Jul 2026 11:21:43 -0700 (PDT)
Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1FA8E10CD5CB9 for <tls@ietf.org>; Thu, 2 Jul 2026 11:17:58 -0700 (PDT)
Received: by mail-oo1-xc32.google.com with SMTP id 006d021491bc7-69d8f70cb0cso1460847eaf.0 for <tls@ietf.org>; Thu, 02 Jul 2026 11:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joseon-com.20251104.gappssmtp.com; s=20251104; t=1783016277; x=1783621077; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:from:to:cc:subject:date:message-id:reply-to :content-type; bh=iezhiT5/q6tEIGGH4icZ21otyBB63ZFS3kJ8+/2Knj0=; b=aqFKtYDYn+kF653SJGCyxsO7q2sTRu5PgrnjN715/NRFLlSvn21TVMvH4SnjhpGq3D YvY8UMJO/hjmengIfCmVlwC3WUQjgx8gRTUblzzyKNXhYRbl+9wW+9i9oMjKRPChDJcg NvRixHfe39EVJ2DaDrLpFQhnqxMz2Wzxv6GTNSJHB1aPDDzOhFMAjLADHESoVEbRtoIB BqijWj36KLAdAFnDWJl8xC0vZNS6B1WcGmYC0957kLq4AO3tNTl7B2D0WqXymtLMggSr bAxETH3l6+yknq+PXEEP7osnw1SoYuZ/El1NjdQ81TC8pVJAxUBSAT9TL3TfCuXaYFBR CAaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783016277; x=1783621077; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=iezhiT5/q6tEIGGH4icZ21otyBB63ZFS3kJ8+/2Knj0=; b=b6f55fpZGjZYSopaQ/mfpW9Zn1KYpFj6rtnEuiq4ExfsImeqOIw70TNHfs3Rz+Y2va e2xyBPxmbmbZ2hC5tULCKVs1YqkMIUlCJDTfGeyypVJL+eqU6VVxwpDP5INIcMAf6LcB kJyAX+pvVyrrvM1zgYcf4aSuVxMtsZYCSVDR0o6u5ZuJkBTwlNoUNubnzJHiie0BrxFX 6bskTU5bHaQt6uCg+8tBOzrru0qLuE1ZILpQq1Slc5D9FFYRxFFYGXbDXmzvO7S2wv6N JmkwZfXcPe77Rz/rdUaCcP/ewTbJpNSoElfA5Ir16tan5g1q0aku/CZ0QgKv1l/zgu9h dySQ==
X-Forwarded-Encrypted: i=1; AFNElJ9fAWJ+BI+V8W1z9E8xv6cG1PqCZ/QuPV7RHRT6rr33EOikKuYDSU5wjEeie4MaEOgeCAo=@ietf.org
X-Gm-Message-State: AOJu0YyVzeu8k8W4at4MjqbXJoMfu0L6dymupP9STqdvztEycwllNZ/q fTl2UNhOAgKwp2CZi8F0RtfzjaXwEMfb2VZZ979V7olzF6Njug61hLroD9dk+iKefmI=
X-Gm-Gg: AfdE7cmBnBy6aKp/O5p0UnNJAE6X+zWZ2E+NFsvDj3pzC/xo0tikvQWAEMMLJrtjssv ts6ofFbRZ7WeQ2LwB7CGqTwmY92QICMVdh6bZAv0hB7+8Y62bVAWQ0tYcaI0sQ79Mq5Umfp1FkI RC0vVZDdE8GKGyLE1nT781izE1CZ4asgG2JMJ2GjzNYY6pFUbz9xvwMDyD2y9nLVTwINjP0t1hV 9lqWY8HD0LH5AH69csXbNhB4Bhtzm49uABLb1k54CxC2Z0zUaOcTnPMLiciEbmYMP3tkBwwiHL6 UXCnRNv0kHj2KmyQ0uyk6BQNKqfpU6b+PWE1jLKHXOs1g1ed4cO1tDenkheu708GdI93qosH3nG q3Sl2RB9lbSrwEN34x3KUISI7Ar6Wv0UPRnmDjfvNs46BZ2q7Rbsk02DJYVCYetZ/TwdirspFwn hToMPBDORKP1dPhcm6YQUxSWL/R4IGqKUG47ovcLFy1wEe9R3JdADqCCM=
X-Received: by 2002:a4a:e918:0:b0:6a1:63cc:97f4 with SMTP id 006d021491bc7-6a30d88a1e2mr4069075eaf.34.1783016277205; Thu, 02 Jul 2026 11:17:57 -0700 (PDT)
Received: from smtpclient.apple ([192.69.242.2]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-6a3103cddefsm2434392eaf.13.2026.07.02.11.17.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2026 11:17:56 -0700 (PDT)
From: Andrew Lee <andrew@joseon.com>
Message-Id: <CD6B2426-6EDA-46B9-A1AC-085F0774B1CA@joseon.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_58FC674D-0A45-4BDB-9ED9-09B216255851"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3818.100.11.1.3\))
Date: Thu, 02 Jul 2026 11:17:45 -0700
In-Reply-To: <CAP7zK5ZwSQ69uv32cFgGs1p_RM-Ku8=mXEjAzdtM=nM3sRbJSA@mail.gmail.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
References: <CACSbMK=PaaZkfZcT2c4pVggdTuw2Ha5jpOqRpyTCyu_J6-mEOg@mail.gmail.com> <CAP7zK5ZwSQ69uv32cFgGs1p_RM-Ku8=mXEjAzdtM=nM3sRbJSA@mail.gmail.com>
X-Mailer: Apple Mail (2.3818.100.11.1.3)
Message-ID-Hash: LYXKAUAIAGCBDARIBDWREAQC4RTKWX7W
X-Message-ID-Hash: LYXKAUAIAGCBDARIBDWREAQC4RTKWX7W
X-MailFrom: andrew@joseon.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: iesg@ietf.org, TLS List <tls@ietf.org>, sec-ads@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dpKzlJ8iae3W_FHIhpUhVJzfGw4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
Thank you for the clarification, IAB Chair Dhody. I note that this response to the IAB's message is, somehow, not on behalf of the IAB. I appreciate and accept the clarification on the IAB's specific language and also want to clarify that I didn't say they used the word "misrepresented." They specifically said, as you mentioned, "initial characterization of the adoption call did not accurately describe the record." I think others can decide whether there's any meaningful distinction between that and what I wrote. The real question before the IESG remains to be answered. The IAB identified WGLC as the venue for Dr. Bernstein's technical objections, and the chairs have restricted his ability to participate in that venue during a vote with time limit. Whether the moderation is theoretically permissible doesn't resolve whether it's compatible with the IAB's own guidance. Rob, thank you for the link to your draft. This is the exact scenario you warned about and demonstrates great foresight relating to policy and the fairness of its outcome. Best, Andrew > On Jul 2, 2026, at 10:53 AM, Dhruv Dhody <dd@dhruvdhody.com> wrote: > > I am not speaking on behalf of the IAB, but wanted to clarify for the list what the IAB’s 30 June appeal <https://datatracker.ietf.org/group/iab/appeals/artifact/310> response says. This is not intended to take a position on matters currently before the IESG. > > Regarding the discussion of Working Group Last Call and moderation: the IAB stated that “those are properly addressed through the WG’s ongoing process, including Working Group Last Call” and that it “considers these the appropriate venues for resolution of the substantive disagreements about the document’s content”. That statement identifies the venue in which technical objections are to be addressed. Working Group Last Call is part of the WG’s ongoing process, operating under the IETF’s normal procedures governing WG conduct, including mailing list moderation. > > The current appeal also states that the IAB found the responsible AD “misrepresented the record”, which requires two clarifications. > > First, the responsible AD in the IAB appeal response was the AD responsible for the adoption call at that time, not the current responsible AD for the TLS WG. > > Second, the appeal quotes only part of the relevant sentence. The IAB response states that the AD’s “initial characterization of the adoption call did not accurately describe the record, and that a more precise account was provided subsequently.” The IAB then noted that it “encourages chairs and ADs to take care in how participant responses are summarized.” The IAB’s observation concerned the initial characterization of the adoption call, for which a more precise account was subsequently provided. The IAB response does not state that the AD had “misrepresented the record,” nor did it make any finding of a “pattern of unreliable process administration on this matter.” > > - Dhruv > > > > > > On Wed, Jul 1, 2026 at 12:23 AM Andrew Lee <andrew@joseon.com <mailto:andrew@joseon.com>> wrote: >> Dear members of the IESG, >> >> On or about June 30, 2026, the IAB published its response to Dr. Bernstein's appeal concerning draft-ietf-tls-mlkem. The IAB denied the appeal but stated that Dr. Bernstein's technical objections "are properly addressed through the WG's ongoing process, including Working Group Last Call," and identified WGLC as "the appropriate venue for resolution of the substantive disagreements about the document's content." >> >> Two days earlier, on or about June 28, the TLS chairs placed Dr. Bernstein under a 30 day moderation period. His messages now require chair approval and may be delayed up to two business days. The WG Last Call for draft-ietf-tls-mlkem-08 ends on July 8. >> >> 1. The IAB told Dr. Bernstein to make his case during WGLC. >> 2. The chairs are preventing him from doing so. >> 3. _These two actions directly contradict each other._ >> >> I am independently appealing the moderation pursuant to RFC 9945 Section 4.1 and RFC 2026 Section 6.5. To be clear, I am not writing on behalf of Dr. Bernstein or at his or anyone's request. I am writing because this contradiction represents a procedural failure that affects every participant in the TLS Working Group, and perhaps the entire IETF, and I have an obligation as a participant to raise it. >> >> I am requesting that the full IESG handle this appeal directly, as neither Security AD can serve as a neutral adjudicator. AD Cooley has publicly prejudged the matter by stating on-list, unprompted and before any appeal was filed: "I have seen no bias from my chairs." She further instructed a participant not to raise the issue of chair bias again on the list, foreclosing scrutiny of the very question she would be required to adjudicate under RFC 9945 Section 4.1. AD Wouters refused for months to address the substance of Dr. Bernstein's original complaint on this same dispute, was identified as having instigated the prior moderation actions, and was required to recuse himself when the matter reached the IESG in October 2025. Both ADs are compromised. The situation is functionally equivalent to one where the responsible AD "cannot be determined or is not assigned" under RFC 9945 Section 4.1. >> >> >> I. Background >> >> Dr. Bernstein is one of the most prominent technical cryptographers, and also, a critic of draft-ietf-tls-mlkem, which proposes deploying PQ cryptography without the protection of existing ECC encryption. He argues this creates serious security risks, while presenting both research, proofs of concepts and other facts. There are also those that disagree. >> >> This is a legitimate technical debate. >> >> AD Cooley clarified on-list that the moderation is "not for the technical content, but for the footnote which contains a derivative rights statement," referring to a copyright notice Dr. Bernstein appends to his emails. >> >> This is the Nth time Dr. Bernstein has been moderated for 30 days, so regularly, that we may be able to forego crond and use their timings instead. >> >> >> II. The cited authority is invalid >> >> The moderation notice cites "BCP9 / RFC3934 Section 2." This citation is wrong in two independent respects. BCP 9 is RFC 2026, not RFC 3934. These are separate documents. Additionally, RFC 3934 was obsoleted by RFC 9945 upon publication in February 2026. When this was raised on-list, AD Cooley asserted that RFC 9945 "is not in effect" yet. The RFC Editor records contradict this. The moderation was imposed under authority that no longer exists. >> >> >> III. The responsible AD has already been found to have misrepresented the record by the IAB >> >> In the same June 30 IAB response, the IAB noted that the responsible AD's "initial characterization of the adoption call did not accurately describe the record." This is a formal finding by the IAB that the AD misrepresented facts in a prior proceeding involving the same parties, the same document, and the same underlying dispute. It establishes a documented pattern of unreliable process administration on this matter. >> >> >> IV. A footnote does not constitute disruption >> >> The derivative works notice appears at the bottom of Dr. Bernstein's emails, after the substantive content. It prevents no one from reading or responding to his technical arguments. Whether the notice conforms to IETF intellectual property policy is a legitimate disagreement between Dr. Bernstein and the IESG. Using that disagreement as grounds to silence him during a WG Last Call is grossly disproportionate to the alleged disruption and raises serious questions about whether the true target is his technical position rather than his footnote. >> >> >> V. Selective enforcement >> >> During this same WG Last Call, other participants accused Dr. Bernstein of orchestrating a coordinated campaign. No warning or moderation followed. Participants who are for solo ML-KEM sling disrespect. Participants who are for solo ML-KEM have accused others of criminal behavior on the TLS list without consequence. NSA employees posted to the list for the first and only time to express support for the solo ML-KEM draft. No concern was raised about coordination in that instance. By contrast, when participants arrived through Dr. Bernstein's public call for involvement, which is expressly permitted under IETF rules stating that "There is no membership in the IETF" and "Anyone can participate," it was characterized as disruptive. >> >> This is precisely the pattern RFC 9945 Section 6 was written to prevent: "the potential abuse of the moderation procedures by moderators, working group chairs, and potentially others that could lead to censorship of legitimate participation." >> >> >> VI. Minority positions are protected under IETF policy >> >> RFC 9945 Section 1.2 states that "viewpoints outside the rough consensus are not in and of themselves disruptive." Dr. Bernstein holds a substantive technical position shared by, what the WG chairs and ADs consider to be, a minority of TLS WG participants. Fourteen participants filed objections during the, separate, ML-DSA WG Last Call for example. Suppressing this position through moderation, regardless of the procedural pretext, violates the policy the IETF adopted four months ago. >> >> >> VII. Requested relief >> >> 1. Lift Dr. Bernstein's moderation immediately, or at minimum ensure his messages are released without delay for the remainder of the WG Last Call ending July 8. >> 2. Clarify whether the substantive protections of RFC 9945, specifically Sections 1.2 and 6, are in effect during the transition period. >> >> I am a participant in the TLS Working Group and have contributed to the current WG Last Call for draft-ietf-tls-mlkem-08. Any person may raise a moderation disagreement under RFC 9945 Section 4.1. >> >> Respectfully submitted, >> Andrew
- [TLS] Appeal Under RFC 9945 Section 4.1: Moderati… Andrew Lee
- [TLS] Re: Appeal Under RFC 9945 Section 4.1: Mode… Peter C
- [TLS] Re: Appeal Under RFC 9945 Section 4.1: Mode… Kevin Milner
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Dhruv Dhody
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Andrew Lee
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Nathanael Ritz
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Livingood, Jason
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Nathanael Ritz
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Andrew Lee
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Nathanael Ritz
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Andrew Lee
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Nathanael Ritz
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Eric Rescorla
- [TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.… Muhammad Usama Sardar
- [TLS] Re: [EXTERNAL] Re: Re: [iesg] Appeal Under … Livingood, Jason
- [TLS] Re: Appeal Under RFC 9945 Section 4.1: Mode… IETF Chair
- [TLS] Re: Appeal Under RFC 9945 Section 4.1: Mode… Rob Sayre
- [TLS] Re: Appeal Under RFC 9945 Section 4.1: Mode… IETF Chair
- [TLS] Re: Appeal Under RFC 9945 Section 4.1: Mode… Andrew Lee
- [TLS] Re: Appeal Under RFC 9945 Section 4.1: Mode… Eric Rescorla
- [TLS] [iesg] Re: Re: Appeal Under RFC 9945 Sectio… IETF Chair
- [TLS] Re: [iesg] Re: Re: Appeal Under RFC 9945 Se… Ken Kubota