Please take this thread off the TLS list. This kind of footnote/disclaimer appears in emails on many IETF lists and the policy question of what may and may not appear in emails to the IETF has nothing to do with TLS.
-Ekr On Thu, Jul 9, 2026 at 2:42 PM Andrew Lee <[email protected]> wrote: > Dear Roman and the rest of the IESG, > > I acknowledge receipt of your ruling, which, to be clear, denied the > appeal. > > Dr. Bernstein was moderated due to a derivative works footnote. Yet, > without any adverse consequence, the following messages were posted during > this WGLC: > > 1. Vodafone [1]: "The message and any attachment(s) are confidential, may > be legally privileged and are intended solely for the attention of the > addressee(s)... do not copy, disclose or use its contents for any purpose." > > 2. Thales [2]: "The information contained in this e-mail is confidential. > It is intended only for the stated addressee(s) and access to it by any > other person is unauthorised." > > 3. Accenture [3] > > 4. [4] > > These e-mails not only restrict derivative works, but also, all copying, > disclosure and use thereof, an unarguably broader claim than a derivative > works footnote. > > To be clear, I understand we all ignored these footnotes, as unilateral > agreements are unenforceable. > > Yet, none of these participants were moderated or even warned. > > The question I have... is why. > > Again, thank you again for accepting, reviewing and, later, denying the > appeal. > > May this clear case of selective enforcement remain on the record in > perpetuity. > > Best regards, > Andrew > > [1] https://mailarchive.ietf.org/arch/msg/tls/eGKYem8zmwks_44FxX1GOOOpg0I/ > [2] https://mailarchive.ietf.org/arch/msg/tls/wKdOceYeNBou-yaW_-7A2Hz4_Uc/ > [3] https://mailarchive.ietf.org/arch/msg/tls/PT-CI9AoRli8xO0FVwuWlrJX6Ng/ > [4] https://mailarchive.ietf.org/arch/msg/tls/7Pn9evR0667rS_0F79vIicqbhJw/ > > On Thu, Jul 9, 2026 at 10:12 AM IETF Chair <[email protected]> wrote: > >> 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
