[TLS] Re: Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-11.txt

[tirumal reddy <[e-mail]>]

Hi Guilin,

Thanks, I agree with both comments; they are now fixed in PR
https://github.com/tireddy2/composite-mldsa/pull/17.

On SUF-CMA: it isn't about the traditional component being broken. A
composite is SUF-CMA only if every component is, and for instance, ECDSA
isn't, so some of those composites already fail SUF-CMA today.

On the second point: the text now has the attacker deriving the private key
from the traditional public key in the server's existing certificate and
becoming an on-path attacker. No certificate forgery or CA compromise is
required. I also  added another threat vector: an attacker that derives a
CA's private key can issue certificates for any name, which also affects a
server that has already moved to a composite certificate if a traditional
CA is still trusted by the client.

-Tiru

On Tue, 25 Aug 2026 at 12:09, Wang Guilin <[e-mail]> wrote:

> Thanks for the update.
>
>
>
> Read Section 5 (Security Considerations). The following two parts could be
> improved, I think.
>
>
>
> "However, composite signature schemes do not in general preserve strong
> unforgeability (SUF-CMA) once the traditional component algorithm is
> broken, for example due to the availability of CRQCs. "
>
>
>
> This description seems not really accurate, as composite signature schemes
> [I-D.ietf-lamps-pq-composite-sigs] do not preserve strong unforgeability
> (SUF-CMA) as long as either of the component signature algorithm is not
> SUF-CMA, not just in the case of "once the traditional component algorithm
> is broken".
>
>
>
> But I do agree on "This loss of SUF is inherent to the composite
> construction and does not impact TLS".
>
>
>
> Also, the following is just an attacking scenario for an adversary CRQC.
>
>
>
> "TLS clients that support both post-quantum and traditional-only signature
> algorithms are vulnerable to downgrade attacks. In such scenarios, an
> attacker with access to a CRQC could forge a traditional server certificate
> and impersonate the server. If the client continues to accept
> traditional-only certificates for backward compatibility, it remains
> exposed to this risk."
>
>
>
> In my understanding, a more natural and better hidden attack is to either
> compromise the server's private key or forge a valid signature w.r.t. the
> server's existing traditional public key certificate.
>
>
>
> Cheers,
>
>
>
> Guilin
>
>
>
> *From:* tirumal reddy <[e-mail]>
> *Sent:* Tuesday, 18 August 2026 9:18 pm
> *To:* <[e-mail]> <[e-mail]>
> *Subject:* [TLS] Fwd: New Version Notification for
> draft-reddy-tls-composite-mldsa-11.txt
>
>
>
> Hi all,
>
> We have published a revised version of the draft:
> https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa.
> This revision incorporates the feedback received from the WG. The main
> changes include adding the missing composite algorithm based on the
> selection criteria in the draft, clarifying why the loss of SUF-CMA
> security does not impact TLS authentication, and adding downgrade security
> considerations.
>
> Please take a look and let us know if there are any further comments or
> issues.
>
> Thanks,
> -Tiru
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Tue, 18 Aug 2026 at 18:19
> Subject: New Version Notification for
> draft-reddy-tls-composite-mldsa-11.txt
> To: Tirumaleswar Reddy.K <[e-mail]>, Daniel Van Geest <
> [e-mail]>, John Gray <[e-mail]>,
> Scott Fluhrer <[e-mail]>, Timothy Hollebeek <
> [e-mail]>
>
>
>
> A new version of Internet-Draft draft-reddy-tls-composite-mldsa-11.txt has
> been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:     draft-reddy-tls-composite-mldsa
> Revision: 11
> Title:    Use of Composite ML-DSA in TLS 1.3
> Date:     2026-08-18
> Group:    Individual Submission
> Pages:    16
> URL:
> https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-11.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
> HTML:
> https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-11.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-reddy-tls-composite-mldsa-11
>
> Abstract:
>
>    Compositing the post-quantum ML-DSA signature with traditional
>    signature algorithms provides protection against potential breaks or
>    critical bugs in ML-DSA or the ML-DSA implementation.  This document
>    specifies how such a composite signature can be formed using ML-DSA
>    with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide
>    authentication in TLS 1.3, including use in certificates.
>
>
>
> The IETF Secretariat
>
>