[lamps] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

[John Mattsson <[e-mail]>]

Hi,

I quickly looked at what the current document says about SUF-CMA. I don't think my previous comments about SUF-CMA has been addressed. So based on that not ready.

1. ML-DSA as standardized by NIST in FIPS 204 provides SUF-CMA security. If any of the combinations lower the security of ML-DSA to just EUF-CMA this need to be stated clearly already in the abstract and in Section 7, not hidden away in the security considerations. The current abstract says that Composite ML-DSA is best practice and provides extra protection. But SUF-CMA _is_ best practice (EdDSA, ML-DSA, SLH-DSA). It was ages ago since anybody standardized an EUF-CMA only signature algorithm and lowering ML-DSA from SUF-CMA to EUF-CMA cannot be described as just "extra protection".

2. "Composite ML-DSA only achieves SUF security if both components are SUF secure, which is not a useful property"

- I do not understand what is meant with this. I suggest removing "which is not a useful property". SUF-CMA is useful. We know that users and protocol designers typically assume that all signatures are SUF-CMA. EUF-CMA signatures has led to practical vulnerabilities. I think IETF should follow similar guidelines as NIST [1] “Standards and guidelines should be chosen to minimize the demands on users and implementers as well as the adverse consequences of human mistakes and equipment failures.”

- Also I don't think this is true if both components are randomized or hedged. This needs to be clearly explained. My understanding is that there are deployments of hedged EdDSA and in the future people might register new Composite ML-DSA algorithms.

3. [2] "applications that require SUF security to be maintained even in the event that ML-DSA is broken SHOULD use it in composite with Ed25519 or Ed448."

I am quite sure Composite ML-DSA does not provides SUF-CMA in the event ML-DSA is broken.

----

The following section:

    mldsaSeed = Random(32)
    (mldsaPK, mldsaSK) = ML-DSA.KeyGen(mldsaSeed)

should mandate that FIPS 204 is followed. Random() cannot be any random function, according to FIPS 204 it MUST be an NIST approved RBG. Also, ML-DSA.KeyGen() does not take seed as an input, ML-DSA.KeyGen_internal (𝜉) does, this need to somehow be changed/explained.

---

[1] NIST Cryptographic Standards and Guidelines Development Process
https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.7977.pdf

Cheers,
John

From: Russ Housley <[e-mail]>
Date: Monday, 22 September 2025 at 17:53
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [lamps] Re: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)
As part of this WG Last Call, be aware that this IPR disclosure was submitted four years ago:
https://datatracker.ietf.org/ipr/4761/

Russ



On Sep 22, 2025, at 11:50 AM, Russ Housley via Datatracker <[e-mail]> wrote:


Subject: WG Last Call: draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)

This message starts a 2-week WG Last Call for this document.

Abstract:
  This document defines combinations of ML-DSA [FIPS.204] in hybrid
  with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA,
  Ed25519, and Ed448.  These combinations are tailored to meet security
  best practices and regulatory guidelines.  Composite ML-DSA is
  applicable in any application that uses X.509 or PKIX data structures
  that accept ML-DSA, but where the operator wants extra protection
  against breaks or catastrophic bugs in ML-DSA.

File can be retrieved from:
https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping [e-mail]
in copy. Objections should be motivated and suggestions to resolve them are
highly appreciated.

Authors, and WG participants in general, are reminded again of the
Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
[1]. Appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
any. Sanctions available for application to violators of IETF IPR Policy can
be found at [3].

Thank you.

[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/