I object to the proposal to publish draft-ietf-tls-mlkem-*. I have some
specific comments and objections that I would be happy to explain, but
procedurally it's clearly necessary as a baseline to resolve the problem
of persistent list censorship by the WG chairs. I'll focus on that here.
This censorship is a continuing assault against IETF's promise of
openness. The chairs had, for example, categorically barred me from
sending any messages to the mailing list at the time of issuing their
"second Working Group Last Call", a procedure with a short time limit.
The censorship was instigated by Paul Wouters. As context, the chairs
had issued a false claim of "consensus" to adopt the mlkem document,
despite seven TLS WG participants having raised unresolved objections to
adoption. I followed the official procedures to object to this claim of
consensus. This reached Wouters, who then posted a long-list of ad-hoc
excuses for ignoring dissent. I had, for example, used URLs, and he
claimed that URLs are bad; I had used a PDF, and he claimed that PDFs
are bad; I have spam protection, and he claimed that spam protection is
bad; et cetera. Here's his original wording:
https://web.archive.org/web/20250714002707/https://mailarchive.ietf.org/arch/msg/tls/eSW2K3Ql1jzMcN-Aj1EYCGOLu9o/
One of the excuses listed by Wouters is now the claimed excuse for the
censorship by the WG chairs. The excuse doesn't stand up to scrutiny.
It's clear that taking away this excuse would simply result in Wouters
and the WG chairs once again abusing their power and switching to
another excuse for ignoring dissent (e.g., claiming that archive.org
URLs are bad---see how I used an archive.org URL here?). I'm writing
this with all due respect to the censors.
To explain "doesn't stand up to scrutiny": IETF needs the ability to
modify text in IETF standards, but does _not_ need modification rights
for most documents distributed by IETF (such as typical messages sent to
IETF mailing lists, and typical Internet-Drafts). That's why RFC 5378
provides an official procedure to opt out of IETF modifications. This
procedure is exercised in various IETF documents such as RFC 5831. I'm
using the same procedure. For further quotes from and links to the
relevant IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.
RFC 5378 does _not_ give WG chairs or IESG any control over, or any
authority to retaliate against, people using the opt-out process---and
yet this retaliation is exactly what Wouters and the TLS WG chairs are
now doing, as a thinly veiled excuse for ignoring dissent. Meanwhile the
chairs have continued to allow more restrictive copyright boilerplate
(not following the official IETF text for opting out of modifications)
in, e.g., dozens of messages from Zscaler's Yaroslav Rosomakho, who had
written (inter alia) "I strongly support adoption of this document". I
suppose the chairs will now ask Rosomakho to stop doing that, but this
charade isn't going to hide what's actually going on here.
Can I stop opting out? Well, sure, I _could_ allow IETF management to
modify my text in any way it wants, publish the results, misattribute to
me things that I didn't write, remove credit for things I did write,
feed my text to AI engines for manipulation, and collect money for all
of this, without asking me for any further permission. But, again, the
opt-out excuse for censorship is just one of many excuses that Wouters
had listed in the first place, and it's not as if there's something
stopping Wouters and the chairs from making up further excuses.
RFC 3934 says that "any suspension of posting privileges is subject to
appeal, as described in RFC 2026". RFC 2026 appears to require the first
step to be to "discuss the matter with the Working Group's chair(s)". So
I'm hereby complaining to the WG chairs about the continuing pattern of
censorship described above. The foundation of this complaint is, again,
IETF's promise of openness; censoring dissent turns this promise into
fraud. I'm filing this complaint on list as per the transparency
requirements from Section 8 of RFC 2026.
---D. J. Bernstein
===== NOTICES =====
This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification.)
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
