From: John Mattsson <john.mattsson@ericsson.com>
To: TLS List <tls@ietf.org>
Thread-Topic: [TLS] Re: Composite ML-DSA
Thread-Index: AQHczcWfnfWPRqPDq0qvGAgMYbhWoQ==
Date: Thu, 16 Apr 2026 17:31:44 +0000
Message-ID: 
 <AS4PR07MB88250EF7936CDB2163D88C3089232@AS4PR07MB8825.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?Windows-1252?Q?bbcfATgD3XJORhlH4p2ocYmCY7U11U2Xi1FbC0Ai9bNz1R/0Q8QOPSW9?=
 =?Windows-1252?Q?Bsj5vUijIHgc5aPTotMgj2ALTK2r5tcevf30C8dEHVQq1vcTlnvExSF9?=
 =?Windows-1252?Q?GoqlEhtjAlLHC23NViLH2v53Iw3LilIvpyhvU3OmMW3anzNOng22BPoJ?=
 =?Windows-1252?Q?p1Rqb0gMaBnJ2b3zmh53VYMOjmOHbw4EU3L4y0DjmX8L0Ko6v2v64jUH?=
 =?Windows-1252?Q?CEXlW8WvokTOQjLQOMXq55wUegzitf8S75YhXOC2prk+J2pb1u4BOYda?=
 =?Windows-1252?Q?tACjECk9d7nvPiZwxq6bvhpwzrKFAk+1cFg14BlRRjR0IBj3bddyCHe4?=
 =?Windows-1252?Q?pBQAKEPbL3hRMsn+A/5TEPZiq8r86cJKnC+5O1TEvKjcd4WNbCHYRzxw?=
 =?Windows-1252?Q?YBC5skWGY2Q9yXOyQm8xXeUHMTrLwK284T6bqYEI9QHt2Tw1dohTE76l?=
 =?Windows-1252?Q?bhymd86Sk/YjE5gcEsDKjZADJL23jj9IYXIvZlT25DqWvMq3zTSMbgQ/?=
 =?Windows-1252?Q?gyQnFeD+qir+De+F4nZdqtwvBOuRQctpRaA75mONvFmmREycMBX+Nlef?=
 =?Windows-1252?Q?wNBakYRMiD6NQf/6qlT8s6VPmCxM5KWhkUNPr04YaM9mitbcYojSRMf5?=
 =?Windows-1252?Q?ZLoEJ6VKKSC/NzWaSb0nRIsU37uOKM0tSGNSJJZcyz/MBoMr3dW1/DsL?=
 =?Windows-1252?Q?QBTvpihYdkzZgF/Xtkll5g1sClbEzacKZKpdOy9UkNt9OUKp0SxGISS0?=
 =?Windows-1252?Q?UMxZ8TtGJQZk1Oqf/MQbYDIyeKU/qGI+KHlLSmURMb8CzMhlnbZfPYgn?=
 =?Windows-1252?Q?VWeGKCYEyoOmLgDCf4LFDm5smrviLlenlKESv4NVzkGDg4xSCEHBmNQV?=
 =?Windows-1252?Q?Dwr/39EzxsM8aWlvNEBErjS+4dvyg9+oKeStXKQQBP9nmc2PR5B4jRLY?=
 =?Windows-1252?Q?Ib8KubG34t2fGt0aw6EZSA2ma6TulYo5KGZNNnDGzW8TRh3MQ6lCNCDl?=
 =?Windows-1252?Q?hsxmfctD3uAssJN+Oom2c4SIbX4RrHBs0mkR4qrlex5+0RPtzXK4basP?=
 =?Windows-1252?Q?tC/1jnjFAkZsauq+pUmGouUYdACUqmrZW81IYBZHl80I+sTzqgKbLlTn?=
 =?Windows-1252?Q?hJXmWlHGcE2qrShw65gumObnsnFLOHty6RWWji9vPP2/ZLBj0zCzGFZf?=
 =?Windows-1252?Q?lc0RMXBGmnvpx/QoYLUVOh16CJCweei3Fq0hUBgDH0HDp6+QYRH6l4aa?=
 =?Windows-1252?Q?6jDm69xjpaXVm5Zfh2IGsQMsrrIwwTyC4E1TIsZx2Efg/PwPv3vBtOlF?=
 =?Windows-1252?Q?2Vi5EjZtfYlcW/FWHFh8BygSR0bSCu3zKaCqV6KMeq2RdTzvN4mAwrtv?=
 =?Windows-1252?Q?QDBmpLHkIh7P2iLLxOcN69Cxp+edomfe4wojCgeAeTbOTPDsyL1ofX7v?=
 =?Windows-1252?Q?kboQF0GN0VZ2/uXjpmC6EtcoycDx0M2yl3kp1f/73L5x7/FpiBbhdd1L?=
 =?Windows-1252?Q?0ax4F0ARiQawKCc+JN5Q37C1ZJFbMLL1yNjy8Bh/JLEvBXrSsrlvkKNy?=
 =?Windows-1252?Q?f1DXU/sGbg5qnSWEJH64bTzdwL04RJZoodYxZn8UrFRKvd1cKMuZVE8W?=
 =?Windows-1252?Q?6DrJpbDbSXSoxXUcLQfv+h4OSdc5B+i7iex1GoEtfKkPHvqaH1lxiNce?=
 =?Windows-1252?Q?Xfh6lRLZRZD18iteMmUA+xvc26J+Ey4k/7C/1up8pglrLWPFdvlvb/zj?=
 =?Windows-1252?Q?1niMSLbkrcb+HQCvgXxzOK9NNayPiVebCkaUevQ4ZFYhcG0B8nSSXH2m?=
 =?Windows-1252?Q?mO7AoOX6mRrbLXU2OkXRE0yGzs1B0aYwrT4XRERdiGTIfvNGyQ3LrTuW?=
 =?Windows-1252?Q?5xGppDqS48VeBrXnqJRUNY70iQinJQBvlVY=3D?=
Content-Type: multipart/alternative;
	boundary="_000_AS4PR07MB88250EF7936CDB2163D88C3089232AS4PR07MB8825eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS4PR07MB8825.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 81aa6ddc-1d45-40d6-aa63-08de9bde07d2
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2026 17:31:44.9260
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 OSYT2IPJ3yOzmGS1BnVhmKfp6Rpxj+7SlCJo71Q8tI3ZFAwKvLYLeign6gdKU3UYdcNI6C7H8/Qk7FGR5S3C8AqXmfuZ/JbMa5y8L7KE2n0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMBPR07MB10685
Message-ID-Hash: 6UMWMZADS6PRVUUYJ2QUWLAENMNCDKXG
X-Message-ID-Hash: 6UMWMZADS6PRVUUYJ2QUWLAENMNCDKXG
X-MailFrom: john.mattsson@ericsson.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: =?utf-8?q?=5BTLS=5D_Re=3A_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/Wo9h9hhKZyqxkjYLDhjFpqvBaoU>
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>

--_000_AS4PR07MB88250EF7936CDB2163D88C3089232AS4PR07MB8825eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

While I recommend everybody to use X25519MLKEM768, I do not think TLS shoul=
d work on hybrid authentication. If hybrid authentication is nevertheless w=
orked 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 migr=
ation 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 so=
oner RSA and ECDSA can be replaced by ML-DSA or SLH-DSA, the better. For th=
ose not yet ready to adopt ML-DSA, standalone SLH-DSA is the way to go.

All modern signature schemes (RSA-PSS, EdDSA, LMS, XMSS, ML-DSA, SLH-DSA, F=
N-DSA) avoid trivial attacks on strong unforgeability and provide a high le=
vel of SUF-CMA security. I do not think TLS should introduce any new weak s=
ignature algorithms such as draft-reddy-tls-composite-mldsa. draft-reddy-tl=
s-composite-mldsa goes against the principle in both US SP 800-227 and EU R=
oadmap 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) signifi=
cantly 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 =93Obse=
rved certificate fingerprint X connecting to service Y,=94 implicitly treat=
ing the fingerprint as a stable identifier. Similarly, blocklists often ope=
rate on fingerprints (e.g., =93Block fingerprint X=94), and incident respon=
se workflows often rely on fingerprints as unique identifiers when searchin=
g for the attacker across datasets. In the presence of trivial attacks on s=
trong 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 shoul=
d not be repeated.

Cheers,
John Preu=DF Mattsson

--_000_AS4PR07MB88250EF7936CDB2163D88C3089232AS4PR07MB8825eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<span style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size:=
 12pt; color: rgb(0, 0, 0);">Hi,</span>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: =
12pt; color: rgb(0, 0, 0);">
While I recommend everybody to use X25519MLKEM768, I do not think TLS shoul=
d work on hybrid authentication. If hybrid authentication is nevertheless w=
orked on, the composite signatures in draft-reddy-tls-composite-mldsa seem =
like the least suitable approach.</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: =
12pt; color: rgb(0, 0, 0);">
Work on hybrid signatures in 2026 is a distraction delaying the urgent migr=
ation 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 repla=
ced by ML-DSA or SLH-DSA, the better. For those not yet ready to adopt ML-D=
SA, standalone SLH-DSA is the way to go.</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: =
12pt; color: rgb(0, 0, 0);">
All modern signature schemes (RSA-PSS, EdDSA, LMS, XMSS, ML-DSA, SLH-DSA, F=
N-DSA) avoid trivial attacks on strong unforgeability and provide a high le=
vel of SUF-CMA security. I do not think TLS should introduce any new weak s=
ignature algorithms such as draft-reddy-tls-composite-mldsa.
 draft-reddy-tls-composite-mldsa goes against the principle in both US SP 8=
00-227 and EU Roadmap for transition to PQC which states that hybrids shoul=
d 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 pro=
perties of ML-DSA as they introduce trivial attacks on strong unforgeabilit=
y.&nbsp;</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: =
12pt; color: rgb(0, 0, 0);">
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 =93Observed certificate fingerprint X =
connecting to service Y,=94 implicitly treating the fingerprint as a stable=
 identifier. Similarly, blocklists often operate on fingerprints (e.g., =93=
Block fingerprint X=94), 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 str=
ong unforgeability, these assumptions break down, as the same underlying ce=
rtificate can appear under many
 fingerprints. I think standardizing ECDSA with trivial attacks on strong u=
nforgeability was a big mistake that should not be repeated.</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: =
12pt; color: rgb(0, 0, 0);">
Cheers,</div>
<div style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: =
12pt; color: rgb(0, 0, 0);">
John Preu=DF Mattsson</div>
</body>
</html>

--_000_AS4PR07MB88250EF7936CDB2163D88C3089232AS4PR07MB8825eurp_--