Thank you for your input, Andrew. I would like to contribute some minor 
corrections, and a little of my own perspective.

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

Wouters is not an AD. As mentioned in another email, you can find the list of 
ADs on https://datatracker.ietf.org/group/sec/about/

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

To the best of my knowledge, ECC encryption is not, and has never been used by 
TLS in any capacity (although I welcome corrections!) As far as I’m aware 
elliptic curves have only ever been used for key exchange. Furthermore, 
draft-ietf-tls-mlkem does not propose deploying ML-KEM without ECDH, it only 
specifies the way to do so. An intention to propose non-hybrid PQC would be one 
which changes the Recommended: N to a Recommended: Y in the IANA registry.

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

BCP 9 does inarguably exist in RFC 3934: "Like all other WG chair decisions, 
any suspension of posting privileges is subject to appeal, as described in RFC 
2026 [RFC2026].”. In fact, the RFC2026 reference is precisely and specifically 
to BCP 9.

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

It is worth also including the end of that sentence, "a more precise account 
was provided subsequently."

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

Whether it prevents one from reading or responding to his technical arguments 
is not relevant to the moderation decision you are contesting.

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

No one has accused anyone of criminal behaviour, as far as I’m aware, although 
again I welcome corrections. Publishing a blog post urging action is not 
criminal, nor is highlighting such to the mailing list. Further, although not 
relevant to your appeal, I do want to clarify: those supporting the draft are 
not ‘for solo ML-KEM.’ The draft is to specify the method to do solo ML-KEM, in 
contrast to having unstandardised third-party implementations. A vote ‘for solo 
ML-KEM’ would be with respect to the IANA registry, not with respect to a 
specification for how to do it. I believe this has previously been made clear 
in the TLS WG with others referencing the many places solo ML-KEM has been 
implemented *without* a standard from from the TLS WG, which is a situation we 
likely want to avoid insofar as possible.

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

My understanding, and from what I gather, yours (as described in your 
background section and referenced in section IV), is that the footnote was the 
reason for moderation. The ML-DSA Last Call is both a separate document and not 
(afaik) referenced in his footnote so it is not likely to be relevant to your 
appeal.

Cheers,
Kevin

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to