IETF Logo Mail Archive

[TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

sanketh <me@snkth.com> Thu, 19 February 2026 18:40 UTC

Return-Path: <sanketh@snkth.com>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5D2D3B9FE0C0 for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 10:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=snkth.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAcSC5PW4y2d for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 10:40:02 -0800 (PST)
Received: from mail-yx1-xb12d.google.com (mail-yx1-xb12d.google.com [IPv6:2607:f8b0:4864:20::b12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7B424B9FE0B9 for <tls@ietf.org>; Thu, 19 Feb 2026 10:40:02 -0800 (PST)
Received: by mail-yx1-xb12d.google.com with SMTP id 956f58d0204a3-649c070ef3bso1255366d50.3 for <tls@ietf.org>; Thu, 19 Feb 2026 10:40:02 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1771526401; cv=none; d=google.com; s=arc-20240605; b=BBtHKGoCfvVymfc5IKOm3HY5dVb/cGCIkkPpJ6q6jBVyjcHIttVPnpa0MpobuMfFsH C5zFGsoqYTsIWMG1ZPcz4VKCterYcL2hyb6NNidKeq214M5LYM4/EVeV4aXUj4yJJFpj RGSD9xELBesYAOwPQXQTYK1Mw/+FgSVD8adnmJAfs/1ekQzUh3FG60F64CX6U5IORkIC Bz1eW1GZm1Xjt4cshE1DmvMdONDsp0A2nIQGR96oSaPxs4i0nxQ9I/GB77lTG4eJ7Enn brql1Eb+FyYWqVzeGpfshJW6X/ln/nDeu1Vs9LYYGwJzijfvyHglPU6xgPRzZix0zceD vfrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=GwwDpUzW/F4m3l8Ib1+BKEycCNE37ff9dlg+PeAmx00=; fh=rzl8rlc3ee9vc3LN4t5MwbWs1wNNg3PrOJh5pUQ08iU=; b=Irsrmt5ggqtS+YDeohgFd4A2d5vGV83urBFvYgku5z4GfWOdkXAtC7WJNTAyyy2ee+ tindS9/POGP1eB/IPY01Xus8gPJst8/Dq4abhkiw5wYVYrLmVzMPCb1IdQysSE3BWtn7 9fA5nA48guM0Y/WL+ABIYtUX7hUsCR/l5iLEwA29idVmaPViJO/1AsHQFefiLW84XeRJ H0/PwXwB3rvDbhNzBJvgXCpa4iebhNQZwUIUAyKiz/QN3SeqPQJDDZhq/kC/Xp5wth/8 7iW6Xtsr2Z8gNiZX01hxGVt+TXxBS6unNHsWkIG/p+0Kv+MT4Oxe8aYNjIJJGsFaTHKc iL5Q==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snkth.com; s=google; t=1771526401; x=1772131201; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GwwDpUzW/F4m3l8Ib1+BKEycCNE37ff9dlg+PeAmx00=; b=ZiBsdz7II4xwi1TRFWtvHISQY0eGgfRjgYcEY85kwVfFwQ/ILc22D2VoLbjaTgnh1B 8NeyxFCvW0M/ST+ASrqkFiD0WyqiRwb4jxKJOZiu9kNrLfhJUBmMtbgDZAs2yoV3W+j3 bYrnvAfOX9biIelSewq0ABAApfsZkfT+G5z/w+0K3OelokRrfSFpayR7Sj/zkmv4uSav BYWoVayQ7fEyIJKhmawNYMS/Djq8A2EzKlxySl7AyiJbsnNTNhB0cPxBtwWgu1MaMCjr q5cQymZ7fww7A9syNkZkUB9y5i0PfcDE8TaLFFCSJPvngJ0gMx5iIu20CntA7HhZpjAp er/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771526401; x=1772131201; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GwwDpUzW/F4m3l8Ib1+BKEycCNE37ff9dlg+PeAmx00=; b=j3iuKlQ+GD8uHkBYtAtl9XhaJIxSCV0ujU33fZRaeU/E0Jm2YkJA/HccWhoXPEnmk4 GjhXzKMBAQNRKQu2y+t4OsQ15skAGvZCSb+JujPQlidRxstS3ymgN7wFN+lkmK6qqbIj r0riMReJCEbq/+w1kd6gd/xL4D+gnPe2k4sgpJbqKprxHCc2+EUKqr+zJsYfKSM/K8BZ B7QiET2GqPsuLFZVCwcwsZ3JgXwVRdgxNe7TfX/f5ud/jLuefoyYJVnAKhEoX3aFo9Z4 kV3aE2KJQsLS+UrEdyH6Wtk72GObCmj3JD8FqMRK2PP4R/20nswHdP0DLLgsQh7imoun KYBw==
X-Gm-Message-State: AOJu0Yy05wwH4tEAXUcYwB7Gj+Tut3d1PMI41N2xYYFxPs9V3OpzV6bw 4JZUvaG9V1B24xnwhpHAzVqwqzrH6PjYsy3USyYiCs9xvIkF+tFn6ST4bPRzf6R5/PW/B3f90Zf i7KYFvVdy0Y8uL3GzhKss/mqyTv1o8p6QUUeEf3XrGw==
X-Gm-Gg: AZuq6aK2HOHlsuFzycRXKUPx7hng2zYCIJyI7gAofQgNQc+8olcHTzKpfEZfd5b4J6x cqflsF41lAShnWJyX3QFUPcdbAcPT3e9vhHcxlkGmD1H5UOJxoEzUEhmbzl5lPpZEJUExOz2xpM aZNaQ/Z3lEiEqDmeff5a92jwawE5SuhLTE4sFsrp290+Gx4BCr7VIoe+L4ZNDexQAmyNHaxPLhn cU8PaZRWvbkB+R0Y7zCLbGTBGhsGSdYlpxARXTnJBih+kQ1Do07NRuBU3r1KiAXUyCTyXEdR2ov QXnahkDZnUtSAKcGcelJtNC5C4/kGIIyR2lX3Ba1iQ==
X-Received: by 2002:a05:690e:140b:b0:64a:db29:5e7c with SMTP id 956f58d0204a3-64c1979cea2mr18717573d50.10.1771526401448; Thu, 19 Feb 2026 10:40:01 -0800 (PST)
MIME-Version: 1.0
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com> <20260218194044.1135896.qmail@cr.yp.to> <CACf5n7-HB6JxuMoxNM19Hfuy=j+=w_rb2a9+xcOpt9hqabarsw@mail.gmail.com> <CAP9y87SbkdzigkP+t=YMv9kp59XhaC_eCWz8=FU+64-6Daq=og@mail.gmail.com> <CAEEbLAaMEFYAe-w+G0PSpzub3JD3P0mJiuZGfhkzFDUFd3ufWQ@mail.gmail.com> <BN0P110MB14192E51C0D256A4A23C7D03906BA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN0P110MB14192E51C0D256A4A23C7D03906BA@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM>
From: sanketh <me@snkth.com>
Date: Thu, 19 Feb 2026 10:39:50 -0800
X-Gm-Features: AZwV_QjXHTVCfdkfap6eiTUxaQFhnuPmn4_nZ3aulZQ42Ch_iUGjCmO8cW42ciU
Message-ID: <CAP9y87TPH=RAqjOrmyFC_dPmvzpn0gUURUU3V4GbeqMN=xVwow@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary="000000000000de706b064b31a164"
Message-ID-Hash: 7E6NY5LBFTC2BJ3P2O4DS3NUYMJZLI44
X-Message-ID-Hash: 7E6NY5LBFTC2BJ3P2O4DS3NUYMJZLI44
X-MailFrom: sanketh@snkth.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXT] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-qeZZb3j4m2qtWwPo8otf3Zeeh0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

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 <
uri@ll.mit.edu> 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 <me@snkth.com> wrote:
>
> I support the adoption of this draft.
>
> -sanketh
>
> On Thu, Feb 19, 2026 at 7:32 AM David Adrian <davadria@umich.edu> 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 <djb@cr.yp.to> 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 -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>
>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto |
> sschmieg@google.com
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

v2.40.1 | Report a Bug | By Email | System Status