[TLS] Re: ML-DSA in TLS

"D. J. Bernstein" <djb@cr.yp.to> Sat, 16 November 2024 08:57 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 91207C151096 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2024 00:57:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, 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 W8mqSivrgKb6 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2024 00:57:14 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 3E399C14F749 for <tls@ietf.org>; Sat, 16 Nov 2024 00:57:13 -0800 (PST)
Received: (qmail 13972 invoked by uid 1010); 16 Nov 2024 08:57:12 -0000
Received: from unknown (unknown) by unknown with QMTP; 16 Nov 2024 08:57:12 -0000
Received: (qmail 138620 invoked by uid 1000); 16 Nov 2024 08:57:03 -0000
Date: Sat, 16 Nov 2024 08:57:03 -0000
Message-ID: <20241116085703.138618.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: <CACsn0c=mT-19uB35R0FGxa_eyOeKVq=vY1AzSh78M18Ss_f3Gw@mail.gmail.com>
Message-ID-Hash: FGXYGFHS2NSCGDQ27ATXZRGUF3IEWDE2
X-Message-ID-Hash: FGXYGFHS2NSCGDQ27ATXZRGUF3IEWDE2
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: ML-DSA in TLS
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/77uUYhGJYNVQIp9heMY9bkbKbaA>
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>

Watson Ladd writes:
> Authentication is not like encryption.

I presume that you're alluding to the following process: if the PQ
signature system is broken, we revert to ECC signatures, and then the
attacker doesn't benefit from forging the no-longer-accepted signatures
(whereas we can't stop attackers from breaking previous ciphertexts).

This process leaves computers completely exposed until they've reverted
to ECC. Sure, some environments are fast to make changes, but some
aren't. For comparison, using ECC+PQ in the first place avoids this
security failure, and will make many people less hesitant to upgrade.

The revert-in-case-of-disaster process also leaves computers completely
exposed to PQ attacks that haven't come to the public's attention yet.
Out of the 69 round-1 submissions to NIST, 33 have been publicly broken
by now (see https://cr.yp.to/papers.html#pqsrc) with some of the
attacks not published for years; is it so hard to imagine that
large-scale attackers found some attacks before the public did?

More broadly, conflating "no attacks have been published" with "no
attacks are being carried out" is unjustified, an extreme form of
availability bias. Occasionally there are leaks from attackers
illustrating how much damage this mistake has done. Example:

   https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html

---D. J. Bernstein