[TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt

"D. J. Bernstein" <djb@cr.yp.to> Mon, 04 November 2024 17:29 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 0CDFDC1DA1DD for <tls@ietfa.amsl.com>; Mon, 4 Nov 2024 09:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.905
X-Spam-Level:
X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, RCVD_IN_DNSWL_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_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 bXbpRnwMnr8r for <tls@ietfa.amsl.com>; Mon, 4 Nov 2024 09:29:44 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id D3505C1DA2F8 for <tls@ietf.org>; Mon, 4 Nov 2024 09:29:43 -0800 (PST)
Received: (qmail 3382 invoked by uid 1010); 4 Nov 2024 17:29:42 -0000
Received: from unknown (unknown) by unknown with QMTP; 4 Nov 2024 17:29:42 -0000
Received: (qmail 395505 invoked by uid 1000); 4 Nov 2024 17:29:28 -0000
Date: Mon, 04 Nov 2024 17:29:28 -0000
Message-ID: <20241104172928.395503.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: <LO2P123MB7051227463A7583A1E6C023DBC502@LO2P123MB7051.GBRP123.PROD.OUTLOOK.COM>
Message-ID-Hash: KLAR32ZLRDTGSPNWHOL226UVLADUEJ66
X-Message-ID-Hash: KLAR32ZLRDTGSPNWHOL226UVLADUEJ66
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: New Version Notification for draft-tls-reddy-slhdsa-00.txt
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/QfWRVmhMHQK9ZMWrLDb-yXFl2s4>
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>

Speaking for myself, not on behalf of the SPHINCS+ team (or other teams
potentially relevant here).

Peter C writes:
> Under realistic network conditions, TLS handshakes with full SLH-DSA
> certificate chains seem to be about 5-10 times slower than traditional
> certificate chains and, in some cases, can take on the order of
> seconds.

For, e.g., sphincsf128shake256simple, a quad-core 3GHz Intel Skylake
from 2015 handles 85 signatures per second and 1300 verifications per
second. (Source: dividing 12 billion cycles/second by the cycle counts
given in https://bench.cr.yp.to/results-sign/amd64-samba.html.)

Sure, one can come up with scenarios where this isn't fast enough or
where 17KB for a signature is a problem. But there are also environments
where these costs are negligible compared to the transmission and
processing of user data.

> not recommended for use in signature_algorithms

People deploying TLS can do the performance measurements for themselves
and decide whether high confidence in security is affordable for their
applications. Shouldn't speed be given lower weight than security in
decisions of what to recommend?

If the answer is that all decisions will be made by the scenarios most
sensitive to speed, so being less affordable than Dilithium (ML-DSA) is
fatal, then shouldn't Dilithium be analogously excluded, given that
Dilithium is less affordable than KEMs for typical authentication tasks?
The point here isn't just that Dilithium is outperformed by Kyber;
consider the fact that a few hundred Dilithium signatures plus a public
key cost more than a few hundred McEliece ciphertexts plus a public key.

Conversely, if the answer is that we should skip all of these signature
systems for TLS server keys and consider them only for CA keys, then
shouldn't claims about signature affordability start with data regarding
how many signatures CAs are doing?

---D. J. Bernstein