[TLS] Re: [iesg] Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call

Nathanael Ritz <nathanritz@gmail.com> Thu, 02 July 2026 19:53 UTC

Return-Path: <nathanritz@gmail.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 E892110CF276C for <tls@mail2.ietf.org>; Thu, 2 Jul 2026 12:53:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783022025; bh=hZsTPbJVCUe20PVSyb47kE/D53Gb7H3rXhCJsSq7lmU=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=EZ7P+Dw2I39uNsFXehpDBgV7VSuUrfX7QNvi69mRIJeEqeANqtaSVWpruRqhSaPRM Ka5PmO0kVT94n4ansa0UASsaUBabZk/OrCXlvD59rtZSlQiTmjxG7olhmVeBtnytQu Ka7h74QqL53/ED3K3QmlfAURYjnd+QNaAjQE+ytg=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 cQdUWLeMU5i2 for <tls@mail2.ietf.org>; Thu, 2 Jul 2026 12:53:45 -0700 (PDT)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 9EF4010CF25F2 for <tls@ietf.org>; Thu, 2 Jul 2026 12:52:11 -0700 (PDT)
Received: by mail-pg1-x52c.google.com with SMTP id 41be03b00d2f7-c8894387780so1212643a12.2 for <tls@ietf.org>; Thu, 02 Jul 2026 12:52:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1783021925; cv=none; d=google.com; s=arc-20260327; b=iksCKsoza8grRHzCsk4aEAKD7j6SrcbO9SaB7FAwO7TQRkg61dfbwf6xfhBWaP2SdB i9FDztX0vVXsgOGzly4CJvjR1rlnuNcXJHHyfIVGNLUiQFEZERvWhrS8eMCORDKRJ0Us b8um7kown77yweXxxKaPCtwrOzZOyzV/rzOd6/JzioHUCp5YhBahLIQ1tMNdmMiBumUb gVfAB16gAFT3fMcFrj1/yy5cFk42RAeNayRaNINhj++QJ2xReYDY0YS1EgJWswd2khpZ wSXrWeom3cp2nT7JJDGBL3BCBgJzpgYGU/+WQQ4yRrUN0ZDCIBot1ZaneDh6O85Nvqc8 p4Eg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=hZsTPbJVCUe20PVSyb47kE/D53Gb7H3rXhCJsSq7lmU=; fh=Y86zOL9sWghlDzH7qHqt/H7vfX2kfjzIEqHvTPMJej4=; b=Be2pb/hgqBYKp32oDrAH0dLHmkS7QYRWEncl/tlXeU6q7zaA2Slgei0CwRruqSSRBp 2OjgOE6EYtgjIUD+CtPw5C/0YQG2UEXa49M5W7niHgBZ5tAv0Gb2Iik5LDRe62B9NiTx uSQx3jrXyr0zeU+OgPpoGAHlqYgA/QQLOrZiA/6FMzAN70njdeYZVuPKndTTgM13QP++ 6WgH1IFxVOYh9UTxyO7R7TstbXrqduVjf0FNEjgT9yZPEGeCuPa1VM8aNgHehbBwLFJQ Q3T+UrOUanzfBPb9MkM/lMOPHFfiUVD+U4g5OBgtEtIFQGggD/atB74PELWwyiGClVR6 LUNg==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783021925; x=1783626725; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=hZsTPbJVCUe20PVSyb47kE/D53Gb7H3rXhCJsSq7lmU=; b=XbhdLAHfcT2nntQsucte4quRaN0r39s+SuzeAe65/iEvy2EUOrLSrZN7P8Q0Bfw4XD nrJTV1oRZ3UIu36yaWetOTe2X7Q9WgrMZESaDtA0VgMOPDlwXutLAM5Bu89fvtmFi0bQ 3b3Ir/l0NJVAv5b1LMusjeawvW3Om0D/FXMlDn5qgPh8zpDTmFWeODFJ2F1YZbhubhg3 2xM5UDFnd2/cMpecxazqBwp+yrCgUSVAStxIUvRtVvGvtZmh7FkLvdDz8A6fEbdFROPe GVL8QWGGu0NNir2kDmfqF3ZU+W8fGFCv1vVSHNUxswpIKQJE8XL/ndtvU+KMtc9ub+tP xPaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783021925; x=1783626725; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=hZsTPbJVCUe20PVSyb47kE/D53Gb7H3rXhCJsSq7lmU=; b=Yhxo7LiSvwal1TH0PSahq9Pw1e3NkrdhZHgozOsL8/F4l4/hI2R3c9JjjG7s8BX42g 1mJ9jbZhq/7UxEZTWFsoG9959GKOphaCftiALyRKBJV2RyqOGuof1T747i81AXy6BF4P 8KJa+VIpByXBRDLBwnHcR9hDC+GDRJsMM3KKk9CQqmggNNiCXaZG0tt1QAyT3UYRobI8 zXJgCT9IsgSzdBcKVuJz654+3oRSN3NOx5Ch/PDKF88xn+6SMHMap0w8yp7F/AYu42Z/ SbceJBxZEBqta+QvvgYDjefKRrHofEZsBOh/epXdG0KQlfIHjPa4m4jLvCysm9C+nHe1 EZfg==
X-Forwarded-Encrypted: i=1; AFNElJ88BaDjvv/rX10njU9BU9TTvdSTg6pCgMsnFwZaUK2oo1E9yj96gIwyO8tT2FmLgY1RWtg=@ietf.org
X-Gm-Message-State: AOJu0YxaG2YWrknpOMn8NaFCTFxp1W991KlByxLRb+zPcXQdKnKtn1Sk xszKCDF1I0Rp/A5XEaLUG2f0AM5w+iFEWOn8t5g5xfzEYerzP0YUeZQiqpDvPVgX/cK9iZFqon0 UZu2kq8qUCtxf5L21Q7OmNfY/W38IrX8=
X-Gm-Gg: AfdE7cmZEHc6qsU+87W8fd/u9O8ZGOMWpBm9OE7v8bmis09h7tTRks/ak9iOyZ7ticK opCNrzp1Jj15rl9LDRlAa3VvA+UgIt1uBtSkYf3myQNygRvd/JFvOL+Qa/OOsHZA+wk9kom1wLS BZE5yWWlgnMbm0kgtgAoQj2v3ccEdRzaNChIVZVMj3l5tJipZvGKf1JB+VaXuo/AVtqP95m15fs JmF0BCHMZf+yhZdCvvZo9Jl5NGzJVg9TrQdTMxv522Yb0/Eh0pw3pSYyvRM/lt1x8PWsIwr
X-Received: by 2002:a05:6a21:4c81:b0:3bf:80b8:9c8a with SMTP id adf61e73a8af0-3bff4038b28mr7765709637.6.1783021924809; Thu, 02 Jul 2026 12:52:04 -0700 (PDT)
MIME-Version: 1.0
References: <CACSbMK=PaaZkfZcT2c4pVggdTuw2Ha5jpOqRpyTCyu_J6-mEOg@mail.gmail.com> <CAP7zK5ZwSQ69uv32cFgGs1p_RM-Ku8=mXEjAzdtM=nM3sRbJSA@mail.gmail.com> <CD6B2426-6EDA-46B9-A1AC-085F0774B1CA@joseon.com>
In-Reply-To: <CD6B2426-6EDA-46B9-A1AC-085F0774B1CA@joseon.com>
From: Nathanael Ritz <nathanritz@gmail.com>
Date: Thu, 02 Jul 2026 13:51:53 -0600
X-Gm-Features: AVVi8CffiktXXjKuUSo-SNcUfRhGdDR64bx_vcKIpIACfEI0KconWsfdhgABx6A
Message-ID: <CAHxYnaNPi3j26tvxX2rgfBNWVUuM2-RU24UPVoj7ZrNOrMF5jQ@mail.gmail.com>
To: Andrew Lee <andrew@joseon.com>
Content-Type: multipart/alternative; boundary="000000000000747ec10655a62479"
Message-ID-Hash: UDYBLSID6MKZENHMZVQTW2YRWHBYWJKN
X-Message-ID-Hash: UDYBLSID6MKZENHMZVQTW2YRWHBYWJKN
X-MailFrom: nathanritz@gmail.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: Dhruv Dhody <dd@dhruvdhody.com>, 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/PSh9gR4IJ0Svp3M-nDUqaeCCIHE>
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>

Hi,

I have comments to share in this thread.

Comments are offered below with [NR]:

On Thu, 2 Jul 2026 at 12:25, Andrew Lee <andrew@joseon.com> wrote:

> 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.
>

[NR] The immediate upfront statement offered by Dhruv, disclaiming their
own personal statements so that they are understood as apart from anything
representative of the IAB as a whole, is exactly the "somehow" you seem to
be pointedly asking about. Many individuals wear many "hats". Dhruv's
direct and upfront clarification that their words should not be
misconstrued as representing the IAB as a whole, followed by your reply,
"Thank you ... IAB Chair Dhody," seems to me to completely disregard that
norm and the courtesy.


> 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.
>

[NR] Indeed. The English language is full of ambiguity.


>
> 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
>

Sincerely,
Nathanael


>
> 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> 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 mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>