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/ <729298a9-2417-4e51-89c5-c20200b5cea3> On Thu, Feb 19, 2026 at 9:57 AM sanketh <[email protected] <aa661400-9b43-4a90-b399-51286d5eed31>> wrote: I support the adoption of this draft. -sanketh On Thu, Feb 19, 2026 at 7:32 AM David Adrian <[email protected] <0cad9302-84cf-4924-8892-5b0b56de1c9a>> 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] <a947c6b5-0348-4559-a3d4-ac715e48aa35>> 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/ <66493e31-66d2-4dac-8982-b21c00736f20> 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 <aab90727-dd51-4167-b88e-44fc596abc0d> URLs are bad---see how I used an archive.org <8275eb42-779d-4f3b-80d1-a626d040f814> 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 <0aa0e270-3411-4f7d-a897-61afde64b769>. 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] <431448c0-c1d5-49a7-8bcd-c9f556d93511> To unsubscribe send an email to [email protected] <d57a947d-9f94-42ee-b75f-ab8aa653eccc> _______________________________________________ TLS mailing list -- [email protected] <bf250532-852d-4540-b77c-6bb83cf7127b> To unsubscribe send an email to [email protected] <f0e4510d-cfef-45bc-924e-1e906db35109> _______________________________________________ TLS mailing list -- [email protected] <05c2fb42-55bb-4f99-89f1-75724eb1dbbb> To unsubscribe send an email to [email protected] <e124a004-dd8d-4ba5-b206-ab9efda5a329> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected] <d8756123-26a7-41da-9aaf-9c13d50fc940>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
