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

[Falko Strenzke <[e-mail]>]

Hi Mike,

no, I fear not at all. First of all, WNS is not a security notion that 
can be fulfilled by the combiner, as the proposed text claims. At best, 
WNS can be achieved by an application using the combiner. The combiner 
will output a validly signed new message, i.e. existential forgery, if 
the ML-DSA signature is removed and the ML-DSA key is certified itself. 
The combiner has no mechanism build in to detect the artifact during 
verification; and obviously can't, since the forged message will be 
handled by the verification routine for a component algorithm. For WNS 
it is up to the application to detect that the forgery (what you refer 
to as "artifact" in the draft) and not to let it surface on the 
application layer.

Next, the new text says that protocols like X.509 certificates and CRLs 
achieve SNS with the proposed combiner. This is a misunderstanding: I 
wrote that a straightforward parallel combiner, i.e., one that does not 
alter the message, would achieve that with X.509. The combiner specified 
in the draft breaks this property by altering the message – at least 
under consideration of cross-algorithm and cross-protocol attacks. I was 
asking to explain how this weakening is justified. The only possible 
answer I can think of is that the effects of the proposed combiner to 
CMS are the reason. Note, however, that we learned, that in CMS SNS 
could be achieved with a straightforward parallel combiner as well by 
including the signingCertificate attribute, as Russ pointed out. Through 
the proposed construction in the draft, also here, SNS cannot never be 
reached any more, even with this extension.

Best regards,
Falko

Am 27.09.25 um 17:12 schrieb Mike Ounsworth:
> Hi Falko,
>
> Thank you for these observations.
>
> I have made a few tweaks to the Security Considerations to reflect 
> these observations. Does that properly capture your comments?
>
> https://github.com/lamps-wg/draft-composite-sigs/pull/279/commits/e5f0183d0900d3b2bde471bcc8f347d0abde4542
>
> On Wed, 24 Sept 2025 at 09:33, Falko Strenzke <[e-mail]> 
> wrote:
>
>     In this context I want to contribute the following observations:
>
>     ## Strong Non-Separability for X.509 and CMS
>
>     I claim that Strong Non-Separability (SNS) is naturally fulfilled
>     for X.509 certificates and CRLs by a straightforward parallel
>     combiner. This is due to the fact that both these data structures
>     contain the signature algorithm identifier within the signed data.
>     RFC 5280 requires these signature algorithm identifiers within 
>     the signed data to be equal to their copy outside the signed data
>     [1]. This means that a stripping attack is naturally prevented
>     since removing one signature requires changing the signed
>     algorithm identifier and thus invalidates the remaining signature.
>
>     It should be noted that the chosen construction in the draft thus,
>     for the case of X.509 when component keys are reused as standalone
>     keys, unnecessarily weakens the security features since an
>     attacker can, through a stripping attack, produce new validly
>     signed artifacts, namely by rendering the signed data as M'. This
>     amounts to a violation of EUF-CMA under consideration of
>     cross-algorithm attacks (composite and component algorithm).
>     Whereas the straightforward parallel combiner doesn't allow this
>     or any other kind of stripping attack.
>
>     For CMS the case is different, as there is no mechanism that
>     naturally prevents stripping attacks. Here it would be possible to
>     achieve SNS by specifying a new Signed Attribute that contains the
>     signature algorithm identifier and is made a mandatory Signed
>     Attribute in a protocol.
>
>     ## Preservation of the SUF-CMA property
>
>     Regarding the preservation of the SUF-CMA property of both
>     component algorithms by the composite algorithm, note that
>     - for X.509 certificates, this is fulfilled by the requirement of
>     the unique serial number in RFC 5280. As a result, the same data
>     will never be signed twice by a legitimate signer. Since the
>     relevant attack works by recombining the component signatures of
>     two different composite signatures over the *same* data, the
>     attack is not possible.
>     - in X.509 CRLs, there is not unnecessarily a unique serial number
>     contained. But the thisUpdate field will in all realistic cases
>     differ between two CRLs.
>
>     Thus for X.509 certificates and CRLs, I argue that preservation of
>     the SUF-CMA property is always fulfilled under realistic conditions.
>
>     For CMS, the preservation of the SUF-CMA property could be
>     achieved for applications that produce signed messages with a
>     frequency in a domain sufficiently smaller than 1/s, namely by
>     making the already existing *Signing Time* Signed Attribute
>     mandatory. This attribute contains the signing time with an
>     accuracy of seconds. Alternatively, to robustly achieve this
>     security property, a new *Nonce* Signed Attribute could be
>     specified for CMS.
>
>
>     I suggest that these observations be taken into account in the
>     security considerations. It should become clear why the specific
>     construction was chosen despite the fact that it is – according to
>     my arguments above – only degrading the security properties of the
>     important X.509 use case.
>
>     Falko
>
>     [1] RFC 5280.
>     https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.1.2,
>     https://www.rfc-editor.org/rfc/rfc5280.html#section-5.1.1.2
>
>     [2] RFC 5652. https://tools.ietf.org/html/rfc5652
>
>     Am 24.09.25 um 13:33 schrieb Mike Ounsworth:
>>     Thanks John and Peter C. I agree that without the randomizer,
>>     Composite ML-DSA does not give SUF in the case of compromise of
>>     ML-DSA. I think Peter is right that I wrote this text several
>>     versions ago when we had a randomizer inside the pre-hash PH(r ||
>>     M), and I think I have not revisited this text since. Thank you
>>     Peter also for the comment about non-separability. I will do a
>>     pass over this text and post a new version; probably on the weekend.
>>
>>     https://github.com/lamps-wg/draft-composite-sigs/issues/275
>>
>>     On Wed, 24 Sept 2025 at 05:12, Peter C
>>     <Peter.C=[e-mail]> wrote:
>>
>>         Hi,
>>
>>         I had a comment about the non-separability discussion in
>>         section 10.2.  The draft says:
>>
>>             [W]e want to consider a modified version of the EUF-CMA game
>>
>>             where the attacker has access to either a signing oracle
>>         over the
>>
>>             two component algorithms in isolation […] and attempts to
>>
>>             fraudulently present them as a composite, or where the
>>         attacker
>>
>>             has access to a composite signing oracle and then attempts to
>>
>>             split the signature back into components […].
>>
>>         The first case (attacker constructing a composite signature
>>         from individual components) is indistinguishable from the
>>         situation where a legitimate signer stores the component
>>         private keys in separate cryptographic modules (as mentioned
>>         in section 4.1). Weak non-separability only allows a verifier
>>         to detect the second case (attacker splitting a composite
>>         signature into its individual components).
>>
>>         I’d suggest re-writing the non-separability discussion so
>>         that it only considers splitting attacks and perhaps
>>         expanding the key reuse section so that it is clearer that
>>         the risk is from **verifier** reuse of component public keys
>>         in other contexts.
>>
>>         Peter
>>
>>         *From:*Russ Housley <[e-mail]>
>>         *Sent:* 22 September 2025 16:52
>>         *To:* [e-mail]
>>         *Cc:* [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]
>>
>>
>>     _______________________________________________
>>     Spasm 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>
>
-- 

*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>