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]
