[TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

"D. J. Bernstein" <djb@cr.yp.to> Fri, 10 October 2025 10:48 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 57F33709725E for <tls@mail2.ietf.org>; Fri, 10 Oct 2025 03:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 cCIfMATTZ-OT for <tls@mail2.ietf.org>; Fri, 10 Oct 2025 03:48:37 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 9C7B570971FD for <tls@ietf.org>; Fri, 10 Oct 2025 03:48:11 -0700 (PDT)
Received: (qmail 2159005 invoked by uid 1010); 10 Oct 2025 10:48:11 -0000
Received: from unknown (unknown) by unknown with QMTP; 10 Oct 2025 10:48:11 -0000
Received: (qmail 99127 invoked by uid 1000); 10 Oct 2025 10:47:57 -0000
Date: Fri, 10 Oct 2025 10:47:57 -0000
Message-ID: <20251010104757.99125.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <CAMjbhoVG=Rvm2tMHmXCfmrn4=hj2aiKb_w7VYAbG5THcvs++eQ@mail.gmail.com>
Message-ID-Hash: 23ZL2RM7ZAFD77MPG7GSBUPMGV4KWIDT
X-Message-ID-Hash: 23ZL2RM7ZAFD77MPG7GSBUPMGV4KWIDT
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Working Group Last Call for Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
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/DFsHuVaNszf4yI2s1sQY9tdEdzU>
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>

Bas Westerbaan writes:
> Setting aside the question of use cases for a moment, let me note that no
> one even bothered to ask IANA to assign codepoints for any hybrid not
> already listed in this I-D.

It seems that practically all of the real-world PQ usage in TLS is
specifically of the first option in the spec (X25519MLKEM768). See,
e.g., https://www.netmeister.org/blog/pqc-use-2025-03.html.

Removing the other options (SecP256r1MLKEM768 and SecP384r1MLKEM1024)
from the spec would certainly resolve my concerns regarding the security
risks of including those options in the spec.

However, if those options remain, then they should be accompanied by
X25519MLKEM1024 and X448MLKEM1024, so that implementors selecting
ML-KEM-1024 aren't _forced_ by the spec into a poor curve choice.
Adding these two options is a very easy change to the spec.

> I see no reason to hold up this document now:
> we can always publish a follow-up later on.

"Kicking the can down the road, saying that these options can be added
by another spec later, would not address this sub-concern. An
implementor looking for the lowest-risk post-quantum option in _this_
spec is forced into a poor ECC choice; _this_ spec should fix that."

---D. J. Bernstein


===== NOTICES REGARDING IETF =====

It has come to my attention that IETF LLC believes that anyone filing a
comment, objection, or appeal is engaging in a copyright giveaway by
default, for example allowing IETF LLC to feed that material into AI
systems for manipulation. Specifically, IETF LLC views any such material
as a "Contribution", and believes that WG chairs, IESG, and other IETF
LLC agents are free to modify the material "unless explicitly disallowed
in the notices contained in a Contribution (in the form specified by the
Legend Instructions)". I am hereby explicitly disallowing such
modifications. Regarding "form", my understanding is that "Legend
Instructions" currently refers to the portion of

    https://web.archive.org/web/20250306221446/https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf

saying that the situation that "the Contributor does not wish to allow
modifications nor to allow publication as an RFC" must be expressed in
the following form: "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 expression hereby applies to this message.

I'm fine with redistribution of copies of this message. There are no
confidentiality restrictions on this message. The issue here is with
modifications, not with dissemination.

For other people concerned about what IETF LLC is doing: Feel free to
copy these notices into your own messages. If you're preparing text for
an IETF standard, it's legitimate for IETF LLC to insist on being
allowed to modify the text; but if you're just filing comments then
there's no reason for this.