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

[Falko Strenzke <[e-mail]>]

Hi Mike,


you are right, it is not actionable. I don't know the justification, 
this is why I can't provide the text. It was just a suggestion to add 
the justification in the view of the new observations (at least for me 
they are new, and parts of the solutions for X.509 and CMS came from 
others on the list).


Falko


Am 29.09.25 um 16:58 schrieb Mike Ounsworth:
> Hi Falko,
>
> This is not actionable feedback. If you would like to see some text 
> changed, can you please suggest the new text?
>
> ---
>
> *Mike* Ounsworth
>
>
>
> ------------------------------------------------------------------------
> *From:* Falko Strenzke
> *Sent:* Monday, September 29, 2025 1:28 AM
> *To:* Mike Ounsworth
> *Cc:* Peter C; John Mattsson; Russ Housley; LAMPS WG; 
> [e-mail]; LAMPS Chairs
> *Subject:* [EXTERNAL] Re: [lamps] Re: WG Last Call: 
> draft-ietf-lamps-pq-composite-sigs-08 (Ends 2025-10-06)
>
> Hi Mike
>
> Am 29.09.25 um 08:02 schrieb Mike Ounsworth:
>
>     Hi Falko.
>
>     First, we added the prefix at your request. Now you're saying that
>     it makes the construction weaker?
>
> My comments are not at all related to the prefix. The prefix was 
> intended as a means of damage limitation from my point of view, and I 
> still hold it clearly fulfils that.
>
> I think I have made it clear multiple times on this list that I see 
> the whole combiner construction as problematic and why. I don't think 
> at the stage where the draft is now it makes sense to revisit this topic.
>
>
>     Second, I clearly missed the point of your first comment, and your
>     message here does not make any sense to me. Maybe it's easier if
>     you suggest the text that you think should be in the draft?
>
> Unfortunately, I can't. But from my side there is no need to account 
> for my suggestions if a solution is not apparent.
>
> Best regards,
> Falko
>
>
>
>     -Mike
>
>     On Mon, Sep 29, 2025, 00:55 Falko Strenzke <[e-mail]>
>     wrote:
>
>         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 to [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
>                 <https://www.google.com/maps/search/Dolivostr.+11+-+64293+Darmstadt,+Germany?entry=gmail&source=g>
>                 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
>         <https://www.google.com/maps/search/Dolivostr.+11+-+64293+Darmstadt,+Germany?entry=gmail&source=g>
>         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>
>
> /Any email and files/attachments transmitted with it are intended 
> solely for the use of the individual or entity to whom they are 
> addressed. If this message has been sent to you in error, you must not 
> copy, distribute or disclose of the information it contains. _Please 
> notify Entrust immediately and delete the message from your system._/
>
>
> _______________________________________________
> 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>