Subject: [TLS] Re: Composite ML-DSA
From: John Mattsson <[email-masked]>
To: TLS List <[email-masked]>
Date: Thu, 16 Apr 2026 17:31:44 +0000
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>

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.

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.

Cheers,
John Preuß Mattsson