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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 23 April 2026 04:59 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 74459E168DFC for <tls@mail2.ietf.org>; Wed, 22 Apr 2026 21:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776920399; bh=NkCMFEkfL/y6od7eMi5aH7lfKoZuZtO4KJCXZXCoMcQ=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To; b=SoouJlXhRQ/wGcHG7i05ASUPb2nx/GD+EzjhRggXDQCYpNGhbdEogUtnV/N5YA5Ib yUObAFksnYnYViHPEWGpFkF0QGg09qKlPH3FXcOUvobHQzO+7Pw1FEmsZc/FXDtSlj vDj+KCpSvocDJWA6NJFR6t+ezZWLY0mU+cjwSnJk=
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 GpLDW0t-vvjm for <tls@mail2.ietf.org>; Wed, 22 Apr 2026 21:59:59 -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) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id CC0E3E168DF7 for <tls@ietf.org>; Wed, 22 Apr 2026 21:59:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1776920389; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=NkCMFEkfL/y6od7eMi5aH7lfKoZuZtO4KJCXZXCoMcQ=; b=JihnCbM+/nxBs0H1VW5leKipjjsi/vCUpk6oAGSO87Ow8pGCc/fBWGm2xNnfTy/o7fI00 jEuri/G64T9IC3ShVDg9rbJSffX3IJ/sUo4swx1k5elcPguExhLT0l/aNcCW8aAwCtlzG6O QK5DK75MMXDf54SmuNSPrdAWRybqkfg=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 29BAF937704; Thu, 23 Apr 2026 14:59:49 +1000 (AEST)
Date: Thu, 23 Apr 2026 14:59:48 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <aemnRPav5Xw4_0ja@chardros.imrryr.org>
References: <CANm5x_OdZ5U0G+ctATQxPWRGMZxEVrC_1oi4vdeT4mAEZwXHrQ@mail.gmail.com> <B1335D87-5055-4F4C-9F02-9C4A0D3BE890@ll.mit.edu> <CANm5x_NchBKOpW=ovT9aGCU5wiYwqnQEnGV9N5CFLMpxZ-DT5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CANm5x_NchBKOpW=ovT9aGCU5wiYwqnQEnGV9N5CFLMpxZ-DT5g@mail.gmail.com>
Mail-Followup-To: <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 3XTSOPHKDDQXG73U4LKEMNONTFEZ2E3S
X-Message-ID-Hash: 3XTSOPHKDDQXG73U4LKEMNONTFEZ2E3S
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: [EXT] 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/YDQrV0HuNrnBAg2g80VGHMhdnQU>
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 23, 2026 at 06:00:40AM +0300, Nicola Tuveri wrote:

> More PQC signature algorithms with better trade offs will eventually go
> through NIST, and we could reuse the same composite construction easily and
> quickly if a CRQC has not appeared before that.
> 
> Even if it did appear, costs might still be a relevant factor, so the ECC
> part of the composite might not become meaningless immediately.

It is not easier to switch from a composite to another algorithm, than
it to switch from standalone ML-DSA to another algorithm, after all,
we've made sure that at all layers above the underlying crypto provider
these all look the same.

I continue to see no present value in composite signature in TLS, see
its potential introduction as a balkanisation opportunity and a
disservice to the ecosystem.  Composite signatures in TLS might perhaps
end up supported in some future OpenSSL release despite my reservations,
but not with my coöperation or enthusiasm to make it so.

-- 
    Viktor.  đŸ‡ºđŸ‡¦ Đ¡Đ»Đ°Đ²Đ° Đ£ĐºÑ€Đ°Ñ—Đ½Ñ–!