Errata: I support the *publication* of this draft. I briefly hoped quantum entanglement enabled faster-than-light retractions. Alas, the universe and TLS 1.3 insist on forward secrecy.
-sanketh On Thu, Feb 19, 2026 at 10:30 AM Blumenthal, Uri - 0553 - MITLL < [email protected]> wrote: > > > I am with Sophie here, and support publication of this draft. > > > As it should be unsurprising, I support publication of this draft, after > having written a whole blog post on why the concerns about it are overblown > [1] > > [1] https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ > > On Thu, Feb 19, 2026 at 9:57 AM sanketh <[email protected]> wrote: > > I support the adoption of this draft. > > -sanketh > > On Thu, Feb 19, 2026 at 7:32 AM David Adrian <[email protected]> wrote: > > Hi Dan, > > > 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. > > It seems far more useful to post your objections on this thread, than it > does to discuss your posting situation, given that this is a WGLC. > > Could you please post your specific comments and objections? > > On Wed, Feb 18, 2026 at 2:42 PM D. J. Bernstein <[email protected]> wrote: > > 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] > > _______________________________________________ > 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] > > > > -- > > Sophie Schmieg | Information Security Engineer | ISE Crypto | > [email protected] > > _______________________________________________ > 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]
