Hi John, Am 16.04.26 um 19:31 schrieb John Mattsson:
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.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.
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 [email protected] To unsubscribe send an email [email protected]
-- *MTG AG* Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: [email protected] 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 MildeThis 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>
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
