[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

"D. J. Bernstein" <djb@cr.yp.to> Thu, 03 April 2025 16:19 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 589B216FE39F for <tls@mail2.ietf.org>; Thu, 3 Apr 2025 09:19:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.097
X-Spam-Level:
X-Spam-Status: No, score=-4.097 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, URIBL_SBL_A=0.1] 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 jct9NPpGq1GJ for <tls@mail2.ietf.org>; Thu, 3 Apr 2025 09:19:12 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 221F116FE399 for <tls@ietf.org>; Thu, 3 Apr 2025 09:19:11 -0700 (PDT)
Received: (qmail 21053 invoked by uid 1010); 3 Apr 2025 16:19:11 -0000
Received: from unknown (unknown) by unknown with QMTP; 3 Apr 2025 16:19:11 -0000
Received: (qmail 81869 invoked by uid 1000); 3 Apr 2025 16:18:57 -0000
Date: Thu, 03 Apr 2025 16:18:57 -0000
Message-ID: <20250403161857.81867.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: <PA6PR08MB10707BBF82063DD6A1779F5BED3AF2@PA6PR08MB10707.eurprd08.prod.outlook.com>
Message-ID-Hash: WBS5CJAQHIY26XJAWT3LHNALDMZXGVG5
X-Message-ID-Hash: WBS5CJAQHIY26XJAWT3LHNALDMZXGVG5
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: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.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/YNSu6ZO5e0JMJ1cRlnxh6oIjyZg>
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>

Yaakov Stein writes:
> Any IPR that can be asserted against Kyber can be asserted against
> already adopted hybrid methods incorporating Kyber.

I agree. I think the chairs have caused some confusion by highlighting
patent issues in the call for adoption---was it not already obvious that
the hybrid issue was the most important one to highlight?

On the other hand, patents also seem relevant to a preliminary step that
has been skipped here, namely identifying why the proposal is claimed to
be adding something important. The draft's motivation sentence consists
of rearranging buzzwords without answering the question:

    Having a fully post-quantum (not hybrid) key agreement option for TLS
    1.3 is necessary for migrating beyond hybrids and for users that need
    to be fully post-quantum.

https://www.schneier.com/wp-content/uploads/2016/02/paper-ipsec.pdf
explained a long time ago how "adding features, options, and additional
flexibility to satisfy various factions within the committee"---rather
than focusing on security---tends to damage security. This was finally
taken into account in TLS 1.3, which removed many TLS 1.2 options. So
there should be an explanation of why the currently proposed option has
security benefits outweighing the costs of extra options. Yes, there's a
quantum threat to be handled, but a non-hybrid Kyber draft isn't doing
any better at that than the existing hybrid Kyber. If the claim is that
adding a no-seatbelts option will improve applicability, then this claim
should be backed up by an applicability analysis; but an applicability
analysis certainly shouldn't ignore known patents.

> If anything, one may attempt to argue that hybrids do not implement
> NIST's MLKEM scheme
> and are thus not covered by the NIST licenses.

Hmmm. I'd think that such an argument would have to be backed up by a
pointer to license text that would allow _some_ types of applications of
ML-KEM, while excluding others, and in particular excluding hybrids.
I've looked at

    https://web.archive.org/web/20240331123147/https://csrc.nist.gov/csrc/media/Projects/post-quantum-cryptography/documents/selected-algos-2022/nist-pqc-license-summary-and-excerpts.pdf

and don't see how any of the text there would support such an argument.

NIST hasn't posted the complete signed licenses, and it's certainly
possible that there's something problematic hidden there, but this isn't
an argument against hybrids: hidden text could just as easily be a
problem for non-hybrids.

---D. J. Bernstein