IETF Logo Mail Archive

[TLS] Re: Composite ML-DSA

Falko Strenzke <falko.strenzke@mtg.de> Fri, 17 April 2026 10:46 UTC

Return-Path: <falko.strenzke@mtg.de>
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 20C50DE2CCFB; Fri, 17 Apr 2026 03:46:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776422785; bh=h3Rr1hB6codDcYN3NziWRCZ7CPfSFc5+4VJqc/QQIq4=; h=Date:Subject:To:References:From:In-Reply-To; b=Rovo2tQTEQc5pH6wH4gKokOVC77tRfQAriLcg3crJ/tmBrplpCPxa4nLNy+dVIoU8 YBTZIX03Wc2ddpOErnQUfk+VrFtzk2g5fbW1sJKMzLbS+52aBkRs7G5Y5VerKMrnTI mKxd6qjGm6vm21ky5Jvkh579NuEcA+6X/fQ1k9ek=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=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 (2048-bit key) header.d=mtg.de
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 u2iRgktjPTuM; Fri, 17 Apr 2026 03:46:24 -0700 (PDT)
Received: from www.mtg.de (www.mtg.de [IPv6:2a02:b98:8:2::2]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (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 F1D72DE2CCF1; Fri, 17 Apr 2026 03:46:23 -0700 (PDT)
Received: from minka.mtg.de (minka [IPv6:2a02:b98:8:1:0:0:0:9]) by www.mtg.de (8.18.2/8.18.2) with ESMTPS id 63HAkHVd022264 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Fri, 17 Apr 2026 12:46:17 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mtg.de; s=mail201801; t=1776422777; bh=h3Rr1hB6codDcYN3NziWRCZ7CPfSFc5+4VJqc/QQIq4=; h=Date:Subject:To:References:From:In-Reply-To; b=paJ8yaJVLxP3CDs8BI1YVSyigShSh4e2aqi79TPesrcPKQze4UP/WDUOI+CMw7ZAz Xek3AfrjkulGgdt/mijezkjmpOvjhZmI3I5YpX35iJzvaYS0vUQjkRTXwS9+tahERJ tX3IIog78DPnpd726wh735U97yemuJADc3Dq2bEBSlHOmja4yQIbkyxF+V5EceHb81 eVMDZbmALskOmU1XHRv43i12QKGBP/6igGzR+lDegk1kvAxvTkyPPwPghr07DQGQeB F07A+dG/JKLtEK1rlBZjoIME036QDMI8Ha+qDoRpkMsuN5NQ0PxeGvwBhIXXTU0JXA ISEvmIzE7/MOg==
Received: from [10.8.0.100] (vpn-10-8-0-100 [10.8.0.100]) by minka.mtg.de (8.18.2/8.18.2) with ESMTPS id 63HAkG2Y011387 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Fri, 17 Apr 2026 12:46:16 +0200
Message-ID: <da9d1f70-f2fc-4035-a7a4-858e4ad0a07d@mtg.de>
Date: Fri, 17 Apr 2026 12:46:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, TLS List <tls@ietf.org>
References: <AS4PR07MB88250EF7936CDB2163D88C3089232@AS4PR07MB8825.eurprd07.prod.outlook.com>
Content-Language: de-DE, en-GB
From: Falko Strenzke <falko.strenzke@mtg.de>
Organization: MTG AG
In-Reply-To: <AS4PR07MB88250EF7936CDB2163D88C3089232@AS4PR07MB8825.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020801030601090109060207"
Message-ID-Hash: 55RIXCHAXCIALMAHOTJLQRK3O7Q7Z5SI
X-Message-ID-Hash: 55RIXCHAXCIALMAHOTJLQRK3O7Q7Z5SI
X-MailFrom: falko.strenzke@mtg.de
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: Composite ML-DSA
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/OqDxZ15uLi2sgKdQGoXmtfoptY0>
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>

Hi John,

Am 16.04.26 um 19:31 schrieb John Mattsson:
> Hi,
>
> While I recommend everybody to use X25519MLKEM768, I do not think TLS 
> should work on hybrid authentication. If hybrid authentication is 
> nevertheless worked on, the composite signatures in 
> draft-reddy-tls-composite-mldsa seem like the least suitable approach.
>
> Work on hybrid signatures in 2026 is a distraction delaying the urgent 
> migration to PQC signatures, particularly for PKI and long-lived 
> devices. I see little justification for placing less trust in ML-DSA 
> than in RSA or ECDSA (EdDSA is a good algorithm but is not widely used 
> in TLS). In fact, the sooner RSA and ECDSA can be replaced by ML-DSA 
> or SLH-DSA, the better. For those not yet ready to adopt ML-DSA, 
> standalone SLH-DSA is the way to go.
SLH-DSA doubles the signature size of public-key+signature for the 
lowest security level compared to ML-DSA. For the higher two levels it 
gets much worse. This is the reason why composites are relevant: if 
using them with ECC signatures, they have no measurable effect on the 
signature size compared to ML-DSA.
>
> All modern signature schemes (RSA-PSS, EdDSA, LMS, XMSS, ML-DSA, 
> SLH-DSA, FN-DSA) avoid trivial attacks on strong unforgeability and 
> provide a high level of SUF-CMA security. I do not think TLS should 
> introduce any new weak signature algorithms such as 
> draft-reddy-tls-composite-mldsa. draft-reddy-tls-composite-mldsa goes 
> against the principle in both US SP 800-227 and EU Roadmap for 
> transition to PQC which states that hybrids should preserve the 
> security properties of its components. The new cryptographic 
> algorithms in draft-reddy-tls-composite-mldsa (which has not been 
> vetted by CFRG) significantly weakens the security properties of 
> ML-DSA as they introduce trivial attacks on strong unforgeability.
>
> With the algorithms in draft-reddy-tls-composite-mldsa, a CA does not 
> issue a single certificate; instead, it issues a set of valid 
> certificates, each with its own fingerprint. This has practical 
> consequences for TLS. Logging, SIEM, and threat intelligence systems 
> often record events such as “Observed certificate fingerprint X 
> connecting to service Y,” implicitly treating the fingerprint as a 
> stable identifier. Similarly, blocklists often operate on fingerprints 
> (e.g., “Block fingerprint X”), and incident response workflows often 
> rely on fingerprints as unique identifiers when searching for the 
> attacker across datasets. In the presence of trivial attacks on strong 
> unforgeability, these assumptions break down, as the same underlying 
> certificate can appear under many fingerprints. I think standardizing 
> ECDSA with trivial attacks on strong unforgeability was a big mistake 
> that should not be repeated.

You are addressing the problem of lack of SUF-CMA in regard to 
signatures of certificates. The discussion here however is about TLS 
signatures. The case for certification path validation is already 
settled by defining ML-DSA-composite signatures for X.509. Once the RFC 
is out, this automatically applies to path validation in all X.509 
contexts, including TLS.

So what would be relevant for the discussion at hand are only SUF-CMA 
concerns with regard to TLS signatures, i.e. TLS server and client 
certificates featuring composite keys. If there was such a problem, I 
assume this should already be a known with regard to ECDSA.

Falko

>
> Cheers,
> John Preuß Mattsson
>
> _______________________________________________
> TLS mailing list --tls@ietf.org
> To unsubscribe send an email totls-leave@ietf.org
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: falko.strenzke@mtg.de
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>

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