[TLS] Re: ML-DSA in TLS

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 29 October 2024 09:33 UTC

Return-Path: <ilariliusvaara@welho.com>
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 64C9FC151071 for <tls@ietfa.amsl.com>; Tue, 29 Oct 2024 02:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 yNYVSXqp_15q for <tls@ietfa.amsl.com>; Tue, 29 Oct 2024 02:32:59 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5573FC14F700 for <tls@ietf.org>; Tue, 29 Oct 2024 02:32:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 1BAB167EB5 for <tls@ietf.org>; Tue, 29 Oct 2024 11:32:55 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id yAhB0cU2ze13 for <tls@ietf.org>; Tue, 29 Oct 2024 11:32:54 +0200 (EET)
Received: from LK-Perkele-VII2 (87-92-153-79.rev.dnainternet.fi [87.92.153.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DD50072 for <tls@ietf.org>; Tue, 29 Oct 2024 11:32:53 +0200 (EET)
Date: Tue, 29 Oct 2024 11:32:53 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <ZyCrxf16oxrJ9JNr@LK-Perkele-VII2.locald>
References: <CAMjbhoUFkL=UT0Pt2xjPLm998=j1ef+wdm0WO14_W7OJDJ-hOg@mail.gmail.com> <784782c7-54c1-4bff-ac80-43588ae5ab5b@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <784782c7-54c1-4bff-ac80-43588ae5ab5b@cs.tcd.ie>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: YZ4XBPWTKGBMOUGLVWVRBJ6HUTRNQZ4H
X-Message-ID-Hash: YZ4XBPWTKGBMOUGLVWVRBJ6HUTRNQZ4H
X-MailFrom: ilariliusvaara@welho.com
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/6yfCfPGwuODFs9QYhvbv2VZS7yw>
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>

On Thu, Oct 24, 2024 at 12:39:28PM +0100, Stephen Farrell wrote:
> 
> 
> On 23/10/2024 18:29, Bas Westerbaan wrote:
> > 
> > Unless I overlooked something, we don't have a draft out to assign a
> > SignatureAlgorithm to ML-DSA for use in TLS.

Nitpick: SignatureScheme. :-)

(SignatureAlgorithm is from TLS 1.2.)


> I don't think a gap in the set of documentation is
> anywhere near a good reason to add things to TLS.

For Post-Quantum authentication in TLS, ML-DSA is currently pretty
much the only option:

- PSKs have serious scaling issues.
- SLH-DSA signature size causes performance issues.
- Composite/Hybrid signatures do not seem to be even close to ready.


Also, ML-DSA-87 is in CNSA 2.0, so barring a major surprise, with that
algorithm it is when, not if it is added.

I think the reason here for searching for existing draft is to avoid
duplicate work.


> I also agree with ekr that there's absolutely no real
> rush here, despite what seems like vendor enthusiasm
> for shiny new things.

I don't think ML-DSA is shiny (despite being new).

The rule of thumb in cryptography about shiny things is that unless you
are into crypto research, stay away.


On the other side, why wait? I do not see any open issues that would
require research or experimentation to resolve. And historically PKI
transitions have been very slow, so one needs plenty of time-to-CRQC.

The impression I got from looking CNSA 2.0 specification was that
the timelines looked pretty tight.




-Ilari