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

[Mike Ounsworth <[e-mail]>]

Hi John,

Thank you for the review. Very helpful!
You are correct that we had not adequately addressed your comments. Here is
a commit that attempts to do so:

https://github.com/lamps-wg/draft-composite-sigs/pull/279/commits/4aa11ecd1bb1af0508d4b9b7ff29095277e9bcb1

Responding to your points:

1. Whether the composite is strengthening or weakening is a matter of
perspective; if you start with RSA_PKCS#1v1.5 and you turn it into
Composite-MLDSA-RSA_PKCS#1v1.5, then you are strengthenining, or at least
not weakening. Yes, of course if you start with ML-DSA and turn that into a
Composite, then you have degraded SUF to EUF. I agree with that.

The abstract does not get into that level of detail, so I will not include
mention of EUF-CMA vs SUF-CMA there, but I have added it to the section "##
Composite Design Philosophy". Hopefully that is sufficient.


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

I was thinking about this from the perspective that one of the algorithms
is compromised, in which case the composite loses its SUF security, but I
suppose it is useful to also think about SUF security in the case that
neither component is compromised. I will adjust the text.

Good catch on ML-DSA.KeyGen(mldsaSeed) vs ML-DSA.KeyGen_internal(mldsaSeed)

On Wed, 24 Sept 2025 at 01:15, John Mattsson <john.mattsson=
[e-mail]> wrote:

> 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/
>
>
>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>