[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 16:02 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 BAF8570CCE0C for <tls@mail2.ietf.org>; Fri, 10 Oct 2025 09:02:14 -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 aGaO6sQTJsQL for <tls@mail2.ietf.org>; Fri, 10 Oct 2025 09:02:13 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id AA76670CCE07 for <tls@ietf.org>; Fri, 10 Oct 2025 09:02:13 -0700 (PDT)
Received: (qmail 2166007 invoked by uid 1010); 10 Oct 2025 16:02:06 -0000
Received: from unknown (unknown) by unknown with QMTP; 10 Oct 2025 16:02:06 -0000
Received: (qmail 115876 invoked by uid 1000); 10 Oct 2025 16:01:56 -0000
Date: Fri, 10 Oct 2025 16:01:56 -0000
Message-ID: <20251010160156.115874.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: <CH8PR21MB5484275C3BC970292001CA5B8CEFA@CH8PR21MB5484.namprd21.prod.outlook.com>
Message-ID-Hash: BGZLXDIYDT662BQQ2TE4MYIVGJINVYNZ
X-Message-ID-Hash: BGZLXDIYDT662BQQ2TE4MYIVGJINVYNZ
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/3mwoIU4BI2WxrQfsy9ACSdpqcM0>
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>

Andrei Popov writes:
> There are regulatory requirements that require NIST curves, whether
> one likes them or not.

Can you please point to the "regulatory requirements" you have in mind,
and explain why you believe that the requirements prohibit X25519MLKEM*?

Some reasons that I'm skeptical that there's an important issue here:

    * Reportedly >80% of TLS is already using X25519.

    * Reportedly ~40% of clients and ~30% of servers already implement
      the X25519MLKEM768 option in this draft, while ~0% implement the
      other options in this draft.

    * My understanding is that NIST now approves hybrids of _anything_
      (as an "OtherInput" inside a hash) with ML-KEM, although I haven't
      checked the details here.

Sources:

    https://mailarchive.ietf.org/arch/msg/tls/lWh_uimMIgQ6SMV_BSkJDh34eQM/
    https://mailarchive.ietf.org/arch/msg/tls/vWAEg7E3jeLZjLABVaMVLR0flX4/
    https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption
    https://www.netmeister.org/blog/pqc-use-2025-03.html
    https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-227.pdf

---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.