[TLS] Re: Composite ML-DSA

[John Mattsson <[e-mail]>]

Hi Falko,


Sorry for the late reply; I missed your email. Bernstein kindly reminded me.


>You are addressing the problem of lack of SUF-CMA in regard to signatures of certificates. The discussion here however is about TLS signatures.


I don't think that is correct, the discussion here is to quote draft-reddy-tls-composite-mldsa: "authentication in TLS 1.3 via the "signature_algorithms" and "signature_algorithms_cert" extensions"


>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.


That is not correct. The TLS WG and TLS libraries are not required to support everything defined in the ITU-T X.509 ecosystem, including new cryptographic algorithms designed by LAMPS. And without registration in the TLS SignatureScheme registry, support for ML-DSA composite signatures in TLS certificate chains cannot be negotiated.


>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.


I disagree with that. draft-reddy-tls-composite-mldsa proposes registering algorithms for use in signature_algorithms_cert, so certificates are very much relevant to this discussion. Furthermore, since one stated objective of draft-reddy-tls-composite-mldsa is to address implementation issues in ML-DSA, it is equally relevant to examine whether it may introduce implementation issues in TLS systems. The vulnerabilities I describe also apply to ECDSA. In my view, standardizing ECDSA with a malleability vulnerability was a mistake that should not be repeated. NIST, which standardized ECDSA, seems to agrees with that. In [1] NIST writes:


"all of NIST’s current and planned PQC standards for general-purpose signatures — target the more robust security definition of strong unforgeability with respect to an adaptive chosen message attack (SUF-CMA)."


Cheers,
John Preuß Mattsson


[1] https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8610.pdf <2a32f25a-0e43-44e1-b12e-bdb4839fdc1a>



From: Falko Strenzke <[e-mail]>
Date: Friday, 17 April 2026 at 12:46
To: John Mattsson <john.mattsson=[e-mail]>; TLS List <[e-mail]>
Subject: [TLS] Re: Composite ML-DSA



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 -- [e-mail] <c4fbd7a4-6cd5-4b4c-81b2-ce6be84f3b9a> To unsubscribe send an email to [e-mail] <d4ae9b22-3430-4673-b22c-d6176e414a0e> 
--

MTG AG
Dr. Falko Strenzke

Phone:
[phone]

E-Mail:
[e-mail] <8defc910-7f6b-49a2-9f07-5ca2a460dbf2>

Web:
mtg.de <728f1a6d-c8aa-4170-a028-7a0555144252> 
________________________________________
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 <margin-top: 0px; margin-bottom: 0px;>