[TLS] Re: [Last-Call] Re: Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

[Falko Strenzke <[e-mail]>]

Am 03.06.26 um 10:17 schrieb John Mattsson:
> Loganaden Velvindron wrote:
> >What are the security issues you see in this pr ?
> >_https://github.com/djmdjm/openssh-wip/pull/64_ 
> <https://github.com/djmdjm/openssh-wip/pull/64>
>
> The PR is based on draft-ietf-lamps-pq-composite-sigs [1]. As I wrote 
> previously:
>
> All modern signature schemes (RSA-PSS, EdDSA, LMS, XMSS, ML-DSA, 
> SLH-DSA, FN-DSA) avoid trivial attacks on strong unforgeability and 
> are widely believed to provide a high level of SUF-CMA security [2]. 
> The transition to PQC provides an excellent opportunity to phase out 
> signatures with trivial attacks on strong unforgeability. Malleable 
> signatures have enabled serious attacks in the past [3] and will 
> likely do so again if they continue to be used.
>
> Malleable signatures can undermine system integrity, auditability, and 
> provenance, and, in the worst case, may even enable replay attacks, 
> see [4]. This is also true for certificates. There is a significant 
> gap between what people think a certificate fingerprint represents and 
> what cryptography actually guarantees when a certificate is signed 
> with a malleable signature algorithm. With such signature algorithms, 
> a CA does not issue a single certificate; instead, it issues a set of 
> valid certificates, each with its own fingerprint.
>
As I pointed out before on this list, irrespectively of the correctness 
of this point, it is not relevant to the draft we are discussing here. 
ML-DSA-composite X.509 CA certificates are already standardised once 
draft-ietf-lamps-pq-composite-sigs becomes an RFC. The only relevant 
point in the discussion at hand can be whether TLS end-entity 
certificates with ML-DSA-composite keys introduce problems. Since EE 
certificates don't sign other certificates, I wonder what exactly you 
are referring to when you write about mismatching fingerprints. You 
should point out where in the TLS protocol such malleable fingerprints 
occur and why they are a problem, as this is the only point where the 
composite signatures performed by TLS EE certificates will occur.

Falko

> This mismatch has practical consequences. 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, some firewall 
> blocklists operate on fingerprints (e.g., “Block fingerprint X”), see 
> e.g., [5], and incident response workflows often rely on fingerprints 
> as unique identifiers when searching for the attacker across datasets. 
> In the presence of only EUF-CMA guarantees, these assumptions break 
> down, as the same underlying certificate can appear under many 
> fingerprints. Nation-state attackers are known to deliberately confuse 
> logging systems, evade signature-based detection, and introduce 
> ambiguity into forensic analysis, and they can be expected to exploit 
> signature malleability for these purposes as well.
>
>
> Some poorly designed composite signature constructions such as [1] not 
> only significantly reduce the security properties of ML‑DSA by 
> inheriting the malleability of ECDSA, but also introduce additional 
> malleability weaknesses. The composites in [1] also significantly 
> weaken the security of ML-DSA by failing to preserve its 
> beyond-unforgeability (BUFF) properties [6–7]. As shown in [8], 
> existential unforgeability alone does not capture the guarantees 
> required by real-world protocols, and the lack of beyond 
> unforgeability (BUFF) properties in traditional signature schemes has 
> enabled concrete attacks on deployed systems; see [6–7]. We note that 
> there exist signature combiners that preserve both SUF-CMA and BUFF 
> properties [9].
>
> [1] Composite ML-DSA for use in X.509 Public Key Infrastructure
>
> _https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs_ 
> <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs>
>
> [2] Digital signature schemes with strong existential unforgeability
>
> _https://pmc.ncbi.nlm.nih.gov/articles/PMC9925878/_ 
> <https://pmc.ncbi.nlm.nih.gov/articles/PMC9925878/>
>
> [3] Bitcoin Transaction Malleability and MtGox
>
> _https://link.springer.com/chapter/10.1007/978-3-319-11212-1_18_ 
> <https://link.springer.com/chapter/10.1007/978-3-319-11212-1_18>
>
> [4] OWASP, Signature Malleability
> _https://scs.owasp.org/SCWE/SCSVS-CRYPTO/SCWE-054/_ 
> <https://scs.owasp.org/SCWE/SCSVS-CRYPTO/SCWE-054/>
>
> [5] Secure Firewall - Blacklisted SSL Certificate Fingerprint
> _https://research.splunk.com/network/c43f7b49-2dab-4e76-892e-7f971c2f20f1/_ 
> <https://research.splunk.com/network/c43f7b49-2dab-4e76-892e-7f971c2f20f1/>
>
> [6] BUFFing signature schemes beyond unforgeability and the case of 
> post-quantum signatures
>
> _https://ieeexplore.ieee.org/document/9519420_ 
> <https://ieeexplore.ieee.org/document/9519420>
>
> [7] A Framework for Advanced Signature Notions
>
> _https://eprint.iacr.org/2025/960.pdf_ 
> <https://eprint.iacr.org/2025/960.pdf>
>
> [8] Seems Legit: Automated Analysis of Subtle Attacks on Protocols 
> that Use Signatures
>
> _https://eprint.iacr.org/2019/779.pdf_ 
> <https://eprint.iacr.org/2019/779.pdf>
>
> [9] Bird of Prey: Practical Signature Combiners Preserving Strong 
> Unforgeability
>
> _https://eprint.iacr.org/2025/1844.pdf_ 
> <https://eprint.iacr.org/2025/1844.pdf>
>
> ---
>
> Some comments on the PR conversation
>
> >Non-canonical S is also accepted
>
> 1. This implies that the Ed25519 implementation is based on old code 
> not compliant with RFC 8032 and retains known vulnerabilities. 
> Contrary to claims made on the TLS list, Ed25519 has not been "stable 
> since 2010." The original Ed25519 specification was vulnerable to 
> malleability attacks, and this vulnerability were addressed by CFRG in 
> RFC 8032 in 2017. The 2010 version should not be used.
>
> 2. Simply fixing this bug and bringing the implementation into 
> conformance with RFC 8032 does not address the malleability issues. 
> The new signature algorithms defined in 
> draft-ietf-lamps-pq-composite-sigs introduce a new malleability 
> vulnerability.
>
> >I don't think this matters for OpenSSH's use case since you aren't 
> building a cryptocurrency
>
> >yeah, we haven't cared about SUF-CMA previously because (like you said) 
> it's totally irrelevant to SSH
>
>
> That is incorrect. SSH signatures are general-purpose and are used in 
> a wide range of contexts outside of the SSH protocol. The new 
> algorithms defined in draft-ietf-lamps-pq-composite-sigs introduce a 
> malleability attack that is not present in EdDSA or ML-DSA, and they 
> eliminate the BUFF properties provided by ML-DSA. Both signature 
> malleability and the absence of BUFF properties have been the root 
> cause of serious attacks in the past.
>
> > but that crowd does incredibly dumb things with cryptography so I 
> can't entirely rule out downstream impact to them.
>
> I find this quite arrogant. Signatures should not be malleable, and no 
> standardized signature schemes are, except ECDSA, which was designed 
> by the NSA. Stating that people who do not except signatures to be 
> malleable are "incredibly dumb" is like saying that Bernstein is 
> incredibly dumb for not understanding how to use SHA-2 securely in 
> SPHINCS+. If anything is incredibly dumb, it is to standardize, 
> implement, and deploy new malleable signatures.
>
> ---
>
> I find the idea that ML-DSA is an NSA backdoor to be absurd, but if 
> that conspiracy theory is in any way a driving factor for this PR, it 
> is illogical to use Ed25519, whose security ultimately depends on 
> SHA-2, a hash function designed by the NSA. ML-DSA and SHA-3 were 
> primarily designed by European cryptographers.
>
> ---
>
> I am starting to think that /draft-ietf-lamps-pq-composite-sigs/ [1] 
> is one of the worst things to come out of the IETF in a very long time:
>
> - It is very poorly designed. It removes the BUFF properties of ML-DSA 
> and introduces a new malleability weakness. One would think the reason 
> to wait for FIPS 204 was to ensure that all security properties of 
> ML-DSA were preserved, but this is not the case. Composite signatures 
> are new cryptographic constructions and should be designed within CFRG.
>
> - The design goals were not security. The goal is shady business 
> practices of selling FIPS-validated RSA and ECDSA as 
> “quantum-resistant.” You can slap on ML-DSA reference code from 2017 
> and suddenly you have a “FIPS-validated” ML-DSA hybrid.
>
> - It is now the biggest obstacle to the urgent migration of roots of 
> trust in PKI and long-lived devices. If standalone ML-DSA is not 
> trusted, standalone SLH-DSA by Bernstein and others is an excellent 
> alternative for roots of trust.
>
> - It is a Trojan horse for well-designed composite and non-composite 
> hybrid schemes that could actually be deployed. It is consuming time 
> that could be spent on other approaches, while being so poorly 
> designed that it cannot be deployed. Ericsson will not support [1] in 
> any of our libraries, products, or services. We will use non-composite 
> hybrids signatures.
>
> Cheers,
>
> John Preuß Mattsson
>
>
> _______________________________________________
> TLS mailing list [e-mail]
> To unsubscribe send an email [e-mail]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
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>