IETF Logo Mail Archive

[TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 10 April 2026 02:31 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4F80AD92D4E4 for <tls@mail2.ietf.org>; Thu, 9 Apr 2026 19:31:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775788291; bh=kkQLbwbIRSViVwHMduuEHleFPhuxmFfJfZJ3WdK+sY8=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To; b=DM+bJ1ZtjWBZQ4W8j4oBPtrNLiljc/UjPxIBtG5BW9n2dPfGu56R0BD47/hBYroHs L6lZezAG7gfmmjiSVg7w9BuWUmaXR+uIAm0IghBbYdBoSKC+gTXlIIr7feVyFSvXPk 0r1xXGBv99UzivM0Ebp0Xcf62Gl10UMgSNxEjPS8=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O-T4j9lqdEY for <tls@mail2.ietf.org>; Thu, 9 Apr 2026 19:31:31 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C78A0D92D4DE for <tls@ietf.org>; Thu, 9 Apr 2026 19:31:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1775788288; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=kkQLbwbIRSViVwHMduuEHleFPhuxmFfJfZJ3WdK+sY8=; b=oUHbCdj/3yAhwst3XbdKczbMuA42V27UFf6pWrrQtFySCiTPUc8i9h2oPzcbygP/4F7uM HU1oPzXanJx9R9+Es2g9QdKlVXTcI5UBpooQ6AcdtOsLsqe8k+UTwl1QQLZ1N5k2pNF1Src /pOkhO7xA329n+a686ZbNT55eDeU7rg=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id CD023937704; Fri, 10 Apr 2026 12:31:28 +1000 (AEST)
Date: Fri, 10 Apr 2026 12:31:28 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <adhhACDaq5fyzuS-@chardros.imrryr.org>
References: <16CF0FDA-7263-461A-9F2B-D37DBEAF5DD9@sn3rd.com> <25c8d414-e4c8-455b-bd64-28132615ba75@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <25c8d414-e4c8-455b-bd64-28132615ba75@cs.tcd.ie>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: FPM26TPBJBO37ZMNPM52KK24E4KX7OMO
X-Message-ID-Hash: FPM26TPBJBO37ZMNPM52KK24E4KX7OMO
X-MailFrom: ietf-dane@dukhovni.org
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
Reply-To: tls@ietf.org
Subject: [TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3
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/mzZXlwb6E4eMUzYbLRyfq-fJISc>
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, Apr 09, 2026 at 09:13:42PM +0100, Stephen Farrell wrote:

> As you might expect, I do not think this should be published
> at this time without there being guidance as to usage. From
> my POV the same goes for any RFC for any newish pure PQ.

To be honestly, I actually did not expect you to object at this time.
Unlike the case with key exchange, if ML-DSA is later compromised there
is no risk to the confidentiality or integrity of past connections.

The need for hybrids here is rather questionable, and the hybrid
signature landscape is much too diverse, with novel ad hoc encodings 
I am not inclined to implement.  My preference is to entirely skip
the hybrid (composite) signature algorithms as a unnecessary bridging
technology nobody will need.

> In contrast to KEMs, IMO the guidance for signatures in TLS would be
> to just not deploy them for now, but only to do experiments in case
> this is needed in future.

It seems that "future" will be with us quite soon, whether or not the
CRQCs that are motivating the accelarated deployment are delayed.  So
implementaitons need to get ready.

-- 
    Viktor.  🇺🇦 Слава Україні!

v2.40.3 | Report a Bug | By Email | System Status