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

Nico Williams <nico@cryptonector.com> Tue, 24 February 2026 05:41 UTC

Return-Path: <nico@cryptonector.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 C7BB7BCD3BC7 for <tls@mail2.ietf.org>; Mon, 23 Feb 2026 21:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cryptonector.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 EaXnOeJoZter for <tls@mail2.ietf.org>; Mon, 23 Feb 2026 21:41:57 -0800 (PST)
Received: from firebrick.ash.relay.mailchannels.net (firebrick.ash.relay.mailchannels.net [23.83.222.59]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4471ABCD3BBB for <tls@ietf.org>; Mon, 23 Feb 2026 21:41:57 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D282C442482; Tue, 24 Feb 2026 05:41:49 +0000 (UTC)
Received: from pdx1-sub0-mail-a257.dreamhost.com (trex-green-6.trex.outbound.svc.cluster.local [100.104.34.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6FD8F441D0F; Tue, 24 Feb 2026 05:41:49 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1771911709; b=PK3we5h019s2B5fyI6jDbLREQ3xd35bCg/mvMusnlVsW5VdctgBPdpDxiZEt+WSdncfQOH RpXOLowPJo28lOA8w6y6VN+WJeq6L/ah1IV7ui1YlcnJJ5OPrn55Ykv7lo2BPPuXnreLuk ER3vs1bgZcOI5RoZm6fK0uti0MGJAk08Hki3VTZ86eROIUwW0pbJGUMw1pR63gZRp2MR33 H06HfDsi5SxB74+d0P8ukdQWL6l5htxrykqrN78pFo/s79AMAoe2olrK3F36jUvTB/C4jW CPvSOxWm43z9E0WkJ78QFnlDwDOyOB1/Xq9yOIIMmgtnWOVQrzwcEpK703KmLw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1771911709; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xMGCahzl0tUBONtFDnKwKjP3XSpAvUXnQFZzj0q3bTA=; b=NOvyUgmwGPVfbxL2tBrVXfXKBLXt9sKZJkKWXhWiiHeegl8ES5KWuQ6Opz2EhvJxaLcRJe 9ymN3xtYWq4cPVynkR8OXe1qQFKMpa+geGc4f5/B5QrhsOLVdCNEgMX2vKnHv3UQTbkvRP yF374h4brltcCtNBfc9gLQvIPHLf4FrHycEUsNNK5MUqD0RM1qAYz5r63bNvszmVxfulQQ V4gWFTaaOULU1qoGjYfjJkMuSnawAPI3PS2f6CebU6jWIClf7JwZT4pvOMi+35jFiiRIK0 39PEXo6oJjcVNeUVKjBQdxO1NQ7llIXqkAsYVLBR2NVaMCDnuxhM+YrYY+ZT1w==
ARC-Authentication-Results: i=1; rspamd-7f65b64645-jdc4w; auth=pass smtp.auth=dreamhost smtp.mailfrom=nico@cryptonector.com
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Harmony-Grain: 659ca9061b0145d4_1771911709685_846413317
X-MC-Loop-Signature: 1771911709685:2478471958
X-MC-Ingress-Time: 1771911709685
Received: from pdx1-sub0-mail-a257.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.104.34.8 (trex/7.1.3); Tue, 24 Feb 2026 05:41:49 +0000
Received: from ubby (unknown [75.81.95.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a257.dreamhost.com (Postfix) with ESMTPSA id 4fKmn85mgyzyqm; Mon, 23 Feb 2026 21:41:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cryptonector.com; s=dreamhost; t=1771911709; bh=xMGCahzl0tUBONtFDnKwKjP3XSpAvUXnQFZzj0q3bTA=; h=Date:From:To:Cc:Subject:Content-Type; b=eUfRKPR/W/qD3HKmY5oRz6Qve5geOT9562Q/cjv7nO/MwJY6Txi6DvlMBGRec42aT /1K+4m54PUkukXNoVs9Q5U2/K5vOgGJ/w6/xpg0jE5wKeDa6ViyIkIPun8GyFNmQN0 EUOD1RxbHnp79MGs4OCxJ7W/+bOcLNJcoKKRNFbmIyVG8RznjGZG25FCQ2GAajk1Uc UyNDsvdRU0sNEsyD/H4PC8KdVdZpbwKZk1ucKxABWLtqlawvNk082PO0F2lCg8eoFL IQlji5QYtVkDd0VNNkfe/F6uwHw/jWfvpPPXlzsMI5jLogX9w/wZyGUuXVN0psjfvF zu8KUOxv1nrbw==
Date: Mon, 23 Feb 2026 23:41:46 -0600
From: Nico Williams <nico@cryptonector.com>
To: Nadim Kobeissi <nadim@symbolic.software>
Message-ID: <aZ06GtQiOXopSyaJ@ubby>
References: <850d1216-8b24-45e3-95ef-3a6899deaf73@redhat.com> <9D4FF0D5-3858-473E-AD4D-9463662F083E@symbolic.software>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <9D4FF0D5-3858-473E-AD4D-9463662F083E@symbolic.software>
Message-ID-Hash: MXMCY2XU6PFEQLWS56Y62BA3FMXFBJ3B
X-Message-ID-Hash: MXMCY2XU6PFEQLWS56Y62BA3FMXFBJ3B
X-MailFrom: nico@cryptonector.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: Robert Relyea <rrelyea=40redhat.com@dmarc.ietf.org>, tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-07 (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/Kgn5HHne45zgRYz-L-gJc9PIYMM>
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>

On Tue, Feb 24, 2026 at 06:05:56AM +0100, Nadim Kobeissi wrote:
> Robert writes:
> > I also know that I have customers that, despite our recommendations
> > will want to 'pure' ML-KEM.
> 
> If Cisco or Red Hat or whoever has big customers, or if some
> government passes a regulation, that asks for TLS 1.3 to incorporate
> Triple-DES as its symmetric cipher, then should the IETF be passing
> drafts that accommodate this?
> 
> If the answer is no, then why on Earth would we pass this draft here,
> since it clearly breaks existing, studied, proven and deployed
> compositional security guarantees? Because Red Hat has a big client?
> Because some government asked for it?

The answer lies in the relevant codepoint registries having registration
policies less onerous than Protocol Action.  The relevant one is
Specification Required, where "specification" need not be an RFC.  The
codepoints are registered, and the specification exists, therefore: the
ship has sailed.

This happened because long ago the IETF didn't want to be in the
business of saying yes to some and no to other cryptographic algorithms
from various the governments around the world.

Now here we are and it's all :suprise-pikachu: that that decision
amounts to saying "yes" to all those cryptographic algorithms from all
the governments around the world.  Well, yes, that was the point.  If
the IETF had kept these registries' policies as Protocol Action then we
would definitely be able to say "no" to pure PQ ciphersuites, but then
we'd be very uncomfortable telling some governments no, we'd get accused
of having preferences (e.g., for the U.S. against Russia, or whatever),
and... yeah we wouldn't like it, and soon we'd make the change to
Specification Required.

Basically: what you, DJB, and others want can't be had.  The relevant
choice was made long ago.  It's too late to change this now, and
honestly the IETF almost certainly does not want to change it because
going back will inject too much international and domesting politics
into the organization.

Nico
--