Re: [TLS] ML-KEM key agreement for TLS 1.3
"D. J. Bernstein" <djb@cr.yp.to> Fri, 15 March 2024 15:21 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8F0C14F68A for <tls@ietfa.amsl.com>; Fri, 15 Mar 2024 08:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaHhHqaMTNcD for <tls@ietfa.amsl.com>; Fri, 15 Mar 2024 08:21:32 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 100D5C14F603 for <tls@ietf.org>; Fri, 15 Mar 2024 08:21:31 -0700 (PDT)
Received: (qmail 22852 invoked by uid 1010); 15 Mar 2024 15:21:30 -0000
Received: from unknown (unknown) by unknown with QMTP; 15 Mar 2024 15:21:30 -0000
Received: (qmail 251777 invoked by uid 1000); 15 Mar 2024 15:21:18 -0000
Date: Fri, 15 Mar 2024 15:21:18 -0000
Message-ID: <20240315152118.251775.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: <CABcZeBOSfroYBgSiVLaVnQOLtuiYR6pEwSuhd0+VQdzBrAugWA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/oF2rxfe7LigmWvY4gX5L6EHEzPs>
Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2024 15:21:36 -0000
Eric Rescorla writes: > It's of course worth noting that a CRQC might be very far in the > future and we might get better PQ algorithms by that point, in which > case we'd never deploy pure ML-KEM. There are already various lattice KEMs that outperform Kyber, the most recent being https://eprint.iacr.org/2023/1298. So there are at least two obvious scenarios where deploying pure Kyber doesn't make sense: * Scenario 1: Continued advances in lattice attacks publicly break Kyber, in which case pure Kyber will (hopefully!) never have been deployed. * Scenario 2: Lattice cryptanalysis eventually stabilizes and people switch to any of the more efficient lattice KEMs, in which case pure Kyber won't be a security problem but also won't be a sensible investment of IETF time. Is there an argument that Kyber will simultaneously avoid both of these scenarios? People are supposed to trust lattice cryptanalysis enough to be sure Kyber will survive, while also being sure that all of the more efficient lattice KEMs will be broken? This sounds fragile. Another interesting scenario to consider is Scenario 3: Quantum attacks are demonstrated, but not with low enough cost to make users think that it's a good idea to give up on hybrids. Meanwhile the elephant in the room, a problem for both pure Kyber and hybrid Kyber, is Scenario 0: Kyber deployment is slow, tentative, and perhaps ultimately aborted, because Kyber is in a patent minefield. Part of the minefield is two patents where it seems that NIST's buyouts will finally activate this year, but there are further patents that threaten Kyber, as illustrated by Yunlei Zhao in https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/m/F63mixuWBAAJ saying "Kyber is covered by our patents". That was almost two years ago. I haven't heard reports of Zhao asking for money yet, but I also haven't seen an analysis explaining why Zhao is wrong. ---D. J. Bernstein
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Kris Kwiatkowski
- [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 D. J. Bernstein
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Andrey Jivsov
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Eric Rescorla
- Re: [TLS] ML-KEM key agreement for TLS 1.3 John Mattsson
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Ilari Liusvaara
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 D. J. Bernstein
- Re: [TLS] ML-KEM key agreement for TLS 1.3 John Mattsson
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Eric Rescorla
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Watson Ladd
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Orie Steele
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Bas Westerbaan
- Re: [TLS] ML-KEM key agreement for TLS 1.3 John Mattsson
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Rob Sayre
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Dennis Jackson
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Dennis Jackson
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Eric Rescorla
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Salz, Rich
- Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS … Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] ML-KEM key agreement for TLS 1.3 D. J. Bernstein
- Re: [TLS] ML-KEM key agreement for TLS 1.3 John Mattsson
- Re: [TLS] ML-KEM key agreement for TLS 1.3 D. J. Bernstein
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Rebecca Guthrie
- Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS … Eric Rescorla
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS … Eric Rescorla
- Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS … Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS … Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Dennis Jackson
- Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS … Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Eric Rescorla
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Sofía Celi
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 David A. Cooper
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 D. J. Bernstein
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Bas Westerbaan
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Eric Rescorla
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Deirdre Connolly
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Sophie Schmieg
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Stephen Farrell
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Watson Ladd
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Loganaden Velvindron
- Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS … Blumenthal, Uri - 0553 - MITLL