Hi! A response to this appeal from the IESG has been posted at https://datatracker.ietf.org/group/iesg/appeals/artifact/315.
Regards, Roman Danyliw (as IETF Chair, for the IESG) -----Original Message----- From: IETF Chair <[email protected]> Sent: Thursday, July 2, 2026 1:14 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [TLS] Re: Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call Hi! With this email, I am confirming that the IESG has received and accepted your appeal. Regards, Roman Danyliw (as IETF Chair, for the IESG) From: Andrew Lee <[email protected]> Sent: Tuesday, June 30, 2026 2:49 PM To: [email protected] Cc: TLS List <[email protected]>; [email protected] Subject: [TLS] Appeal Under RFC 9945 Section 4.1: Moderation of D. J. Bernstein During WG Last Call Dear members of the IESG, On or about June 30, 2026= the IAB published its response to Dr. Bernstein's appeal concerning d=aft-ietf-tls-mlkem. The IAB denied the appeal but stated that Dr. Bernstei='s technical objections "are properly addressed through the WG=;s ongoing process, including Working Group Last Call," and identifie= WGLC as "the appropriate venue for resolution of the substantive dis=greements about the document's content." Two days earlier,=on or about June 28, the TLS chairs placed Dr. Bernstein under a 30 day mo=eration 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 WG=C. 2. The chairs are preventing him from doing so. 3. _These two act=ons directly contradict each other._ I am independently appealing t=e 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&=39;s request. I am writing because this contradiction represents a procedu=al failure that affects every participant in the TLS Working Group, and pe=haps the entire IETF, and I have an obligation as a participant to raise i=. I am requesting that the full IESG handle this appeal directly, a= neither Security AD can serve as a neutral adjudicator. AD Cooley has pub=icly prejudged the matter by stating on-list, unprompted and before any ap=eal 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 a=judicate under RFC 9945 Section 4.1. AD Wouters refused for months to addr=ss the substance of Dr. Bernstein's original complaint on this same di=pute, was identified as having instigated the prior moderation actions, an= was required to recuse himself when the matter reached the IESG in Octobe= 2025. Both ADs are compromised. The situation is functionally equivalent =o one where the responsible AD "cannot be determined or is not assign=d" under RFC 9945 Section 4.1. I. Background Dr. Be=nstein is one of the most prominent technical cryptographers, and also, a =ritic of draft-ietf-tls-mlkem, which proposes deploying PQ cryptography wi=hout the protection of existing ECC encryption. He argues this creates ser=ous security risks, while presenting both research, proofs of concepts and=other facts. There are also those that disagree. This is a leg=timate technical debate. AD Cooley clarified on-list that the moder=tion is "not for the technical content, but for the footnote which co=tains a derivative rights statement," referring to a copyright notice=Dr. Bernstein appends to his emails. This is the Nth time Dr. Berns=ein has been moderated for 30 days, so regularly, that we may be able to f=rego crond and use their timings instead. II. The cited authori=y is invalid The moderation notice cites "BCP9 / RFC3934 Secti=n 2." This citation is wrong in two independent respects. BCP 9 is RF= 2026, not RFC 3934. These are separate documents. Additionally, RFC 3934 =as obsoleted by RFC 9945 upon publication in February 2026. When this was =aised on-list, AD Cooley asserted that RFC 9945 "is not in effect&quo=; yet. The RFC Editor records contradict this. The moderation was imposed =nder authority that no longer exists. III. The responsible AD h=s already been found to have misrepresented the record by the IAB I= the same June 30 IAB response, the IAB noted that the responsible AD'= "initial characterization of the adoption call did not accurately de=cribe the record." This is a formal finding by the IAB that the AD mi=represented facts in a prior proceeding involving the same parties, the sa=e document, and the same underlying dispute. It establishes a documented p=ttern of unreliable process administration on this matter. IV. = footnote does not constitute disruption The derivative works notic= appears at the bottom of Dr. Bernstein's emails, after the substantiv= content. It prevents no one from reading or responding to his technical a=guments. Whether the notice conforms to IETF intellectual property policy =s a legitimate disagreement between Dr. Bernstein and the IESG. Using that=disagreement as grounds to silence him during a WG Last Call is grossly di=proportionate 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 ca=paign. No warning or moderation followed. Participants who are for solo ML=KEM sling disrespect. Participants who are for solo ML-KEM have accused ot=ers of criminal behavior on the TLS list without consequence. NSA employee= 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 instan=e. By contrast, when participants arrived through Dr. Bernstein's publ=c call for involvement, which is expressly permitted under IETF rules stat=ng that "There is no membership in the IETF" and "Anyone ca= participate," it was characterized as disruptive. This is pre=isely the pattern RFC 9945 Section 6 was written to prevent: "the pot=ntial abuse of the moderation procedures by moderators, working group chai=s, and potentially others that could lead to censorship of legitimate part=cipation." VI. Minority positions are protected under IETF=policy RFC 9945 Section 1.2 states that "viewpoints outside th= rough consensus are not in and of themselves disruptive." Dr. Bernst=in holds a substantive technical position shared by, what the WG chairs an= ADs consider to be, a minority of TLS WG participants. Fourteen participa=ts 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. =II. Requested relief 1. Lift Dr. Bernstein's moderation immedia=ely, or at minimum ensure his messages are released without delay for the =emainder of the WG Last Call ending July 8. 2. Clarify whether the subs=antive protections of RFC 9945, specifically Sections 1.2 and 6, are in ef=ect during the transition period. I am a participant in the TLS Wor=ing Group and have contributed to the current WG Last Call for draft-ietf-=ls-mlkem-08. Any person may raise a moderation disagreement under RFC 9945=Section 4.1. Respectfully submitted, Andrew _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
