Re: [TLS] ML-KEM key agreement for TLS 1.3
"D. J. Bernstein" <djb@cr.yp.to> Thu, 07 March 2024 21:40 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 BD9A2C14F6BC for <tls@ietfa.amsl.com>; Thu, 7 Mar 2024 13:40:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.204
X-Spam-Level:
X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 kXM9KxKzGskF for <tls@ietfa.amsl.com>; Thu, 7 Mar 2024 13:40:30 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 7EA11C14F69B for <tls@ietf.org>; Thu, 7 Mar 2024 13:40:30 -0800 (PST)
Received: (qmail 16285 invoked by uid 1010); 7 Mar 2024 21:40:29 -0000
Received: from unknown (unknown) by unknown with QMTP; 7 Mar 2024 21:40:29 -0000
Received: (qmail 1971698 invoked by uid 1000); 7 Mar 2024 21:40:22 -0000
Date: Thu, 07 Mar 2024 21:40:22 -0000
Message-ID: <20240307214022.1971696.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: <CAMjbhoX4+dUaB7xSyr=BMqhv8MY4USHBmMOCVHKWB98hEFDn8A@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lCZtJ-b5ssFlKfIbXtCX2pWJBQY>
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: Thu, 07 Mar 2024 21:40:34 -0000
Bas Westerbaan writes: > We think it's worth it now, but of course we're not going to keep > hybrids around when the CRQC arrives. I think this comment illustrates an important ambiguity in the "CRQC" terminology. Consider the scenario described in the following paragraph from https://blog.cr.yp.to/20240102-hybrid.html: Concretely, think about a demo showing that spending a billion dollars on quantum computation can break a thousand X25519 keys. Yikes! We should be aiming for much higher security than that! We don't even want a billion-dollar attack to be able to break _one_ key! Users who care about the security of their data will be happy that we deployed post-quantum cryptography. But are the users going to say "Let's turn off X25519 and make each session a million dollars cheaper to attack"? I'm skeptical. I think users will need to see much cheaper attacks before agreeing that X25519 has negligible security value. It's easy to imagine the billion-dollar demo being important as an advertisement for the quantum-computer industry but having negligible impact on cryptography: * Hopefully we'll have upgraded essentially everything to post-quantum crypto before then. * It's completely unclear that the demo should or will prompt users to turn off hybrids. * On the attack side, presumably real attackers will have been carrying out quantum attacks before the public demo happens. For someone who understands what "CRQC" is supposed to mean: Is such a demo "cryptographically relevant"? Is the concept of relevance broad enough that Google's earlier demonstration of "quantum supremacy" also counts as "cryptographically relevant", so CRQCs are already here? ---D. J. Bernstein
- Re: [TLS] ML-KEM key agreement for TLS 1.3 Kris Kwiatkowski
- 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
- [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 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