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

Sophie Schmieg <sschmieg@google.com> Thu, 19 February 2026 18:19 UTC

Return-Path: <sschmieg@google.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 5F47AB9FB2C8 for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 10:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 wVI7SQS4FlUZ for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 10:19:45 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 78762B9FB2BF for <tls@ietf.org>; Thu, 19 Feb 2026 10:19:45 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-48371d2f661so3015e9.1 for <tls@ietf.org>; Thu, 19 Feb 2026 10:19:45 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1771525184; cv=none; d=google.com; s=arc-20240605; b=bGwAlwCoB4J2yDut2EjyoWhPVTvWNJXCPPiYv0M0Q/8T9JdULgu40dMFENQzZVQuUd /CXUk/oCGcNj+DO6G/W3EefW9YnNuCFMPogiyhk9Fqec1mAbrf7WWUkTsouBoYWsC6dd WDKDroNlo5VCukLELADd7NoFO4qjVuDzw9NVx8g7sbBDdeXQO2zZcijWlHTn6jGPwI+B 24kMc4e8fCWRch7Y9mzIhtiGFb443xZVq7cHVOruC8pYqbCbsXCmZvDQLfJG9MtdVCHe hB44VeYyKVlC7f7PO34WT/e6KBLvUhK+nNsCB23B3TEmomc7A5JtZj0Dz4FRNKYsMoUe agog==
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=/hS+z5+euvorkDdrhgH7zw8oV4yDzEJQxO6jsBy5gOs=; fh=tgW5riayxzQHqwnYF8kN4WSTdGnK1IHjbU2V5JJGiCc=; b=i7R3KrZOY0+0Z36Gd8agu+abF/jwRHr53y59Pl1txiozcQbGDv7j9VtEYOIHNqoLBp HdRveoC4+ZT6zgRMUhISaac4U+yUv+Zt0SZs2EK/EmNfLp+fve8llzqPkjurB/3ghndt UsQNablJK1/+6rDnSJ6sBIFnYkyFvzYhh66fVaS4Ypq5ijRJzS3wjVDtX4p4hzLYO8hz cxnUrhgoXQI+h5Yo6DkfTtwCHpwXhvGO8I6i8VfIqHrOBNhfxHBJOr5ucCihSdAzAGgF uhWHpekr0gMdV5F0DnPT3+h426HJmdjBmhbMP0I9jK3+yk6CRPEft0shzowQzstrQoXW 2Wfg==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771525184; x=1772129984; 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=/hS+z5+euvorkDdrhgH7zw8oV4yDzEJQxO6jsBy5gOs=; b=Q87zjMlHcOzBRF/CLTCgS0G4PO4VHsdg6mHql8MSIavyWrrFTJADWBHWRUl8CZ/OdC 6TqQCcZ/7ddDTW1bLdcq2cKbnXKoyenfTdMlq/TUNj0zwoUrA3EEG2sM6AIWwDy969hu 9r25IYDBRQ/Eq/5bG3KazEEo8UvHiKFreI3VEXlZfYT5XKemUZs/cWblBuuuM1r4Bwiu 5gQqBzju3QLD1oJAm2G2We5miW27ahx6hYtgzxNYuzw1XWqdvk8LGhiLjNQFBQ0fQEAn zfsJKmbdvN/RIBsMoIxlAOs7l/u/OgXfPiNB881n1ADvBtIN+d4O5AXgx4LBBMSjXM5I hnaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771525184; x=1772129984; 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=/hS+z5+euvorkDdrhgH7zw8oV4yDzEJQxO6jsBy5gOs=; b=hInVEEI4ZbPv2YjQRJvW9VUq08oMxl3X/x98i9nIgSgoEKvm7LsMU7VP+GlB5b+lUK lSMJ6aaU0zaPp5VYFhLKP6mgAVq4j/M+BCmDTKz0NSs13EZZQve/pnEPgxYwQEd7L4GF Gtjr5AM4Bvtz0cbHtrv9pX6245KV3EZRelhWNg7Gq6j9ZhOZ0fKexwBeE5ft9Kt5wlqO 3w+hOlkhv3T0d0MfGUFxX67IkS0Z+sbWKDKWV3T97sZ32SoPvrAM8jznCD5POgcRSyX8 klNnzJQ4f1AikYI535wEwzn21UQczkg+T5FCq5EvThQOicdkQjewEAFQJje/GL35eSUU s54A==
X-Forwarded-Encrypted: i=1; AJvYcCXO861MbDfM/XA84ptsh9GJ6kHLo6zWQj2BXuJP2Tr2DMx/7KhPAf76O3V7sQnrPiLhjBI=@ietf.org
X-Gm-Message-State: AOJu0YyhF1GqXyQH3kVtPuropx6jGuKPn+n78Wr2jtNYK97pJRLgSU3d pLZwM2sL2a6v4fpycEZU3OP0kkhyIGKcFeqvS/PUWNQjTLg4sCJEFUH/gMcnXy2fOrNVbLKy7e3 c3Ea3IUZnbg/1pmosi7q4Zim7YsMd3FhAAmyT8zQI
X-Gm-Gg: AZuq6aKjvNO+qOz6vw0+HF0yyGydU1auf7D431UJcrLRPW1C3NKy/LA96573nRg3e2V fY5w2piXGZ9gFyU30IZG5jgnNHG07O7Q/pCfLWuuSar7zRXcttiDFvTJWb6SAn0dSsnxfAtkH3d b9zyTESda7Cm2X+tsbi6c4erM1GzWqdGimnBQZOu5aMxKCaHlhLvWPNqlFxGBUgXqmGOomRZZ7L 7pO3NHNu/Rwm+VgvNR381klBYLfedvGBpwPY13CjZiwVsMY+VpOrdHeNgD8JYfvOw5M5HZNfEdf Iqw6JErAcEKzvm4Qx3auvubBfFdydRIP53qckgZkznuDXurvgjUR5b4+1sGe2mQLF2zNMA==
X-Received: by 2002:a05:600c:6d5a:b0:480:4a7b:228 with SMTP id 5b1f17b1804b1-483a3ec2fe8mr15335e9.1.1771525183904; Thu, 19 Feb 2026 10:19:43 -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>
In-Reply-To: <CAP9y87SbkdzigkP+t=YMv9kp59XhaC_eCWz8=FU+64-6Daq=og@mail.gmail.com>
From: Sophie Schmieg <sschmieg@google.com>
Date: Thu, 19 Feb 2026 10:19:32 -0800
X-Gm-Features: AaiRm51RarP-ByEsWXqs0jyVYdkNamM7GR8vDNZTJEjzGsi4VYJ1V-QM8EODJ9U
Message-ID: <CAEEbLAaMEFYAe-w+G0PSpzub3JD3P0mJiuZGfhkzFDUFd3ufWQ@mail.gmail.com>
To: sanketh <me@snkth.com>
Content-Type: multipart/alternative; boundary="0000000000004ce798064b315962"
Message-ID-Hash: 4LFTG2CFFVKH4U2CS4QD3RURPTPMYV6D
X-Message-ID-Hash: 4LFTG2CFFVKH4U2CS4QD3RURPTPMYV6D
X-MailFrom: sschmieg@google.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] 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/7nYoPVx1A5EF9DlAN1-pVleu4Iw>
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>

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