As a coauthor of the LAMPS composite signature draft, let me explain the reasoning we did a more complicated structure:
* Doing this simple construction (signing the message separately by the two methods), it would require an implementation to hash the message twice (because the two signature algorithms will require distinct hashes. Even if they use the same hash function, ML-DSA logically prefixes the message with a fixed string, while RSA or ECDSA signatures do not. * We did not know the length of the messages being signed; it is potentially lengthy * Because of that, we decided to perform a fixed hash, and have each algorithm sign that hash (prefixed by some other stuff) The reason I mention this is to allow the IPsecME working group to decide whether the same constraints apply to you, and whether it would make sense to follow that, or to do something simpler. ________________________________ From: Falko Strenzke <[email protected]> Sent: Friday, July 25, 2025 5:10 AM To: Daniel Van Geest <[email protected]>; Jun Hu (Nokia) <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [IPsec] Re: comment on signature combiner / key reuse in draft-hu-ipsecme-pqt-hybrid-auth-02 With "parallel signatures" I meant to use a composite signature sign_A(key_A, M) || sign_B(key_B, M) instead of the LAMPS combiner. I didn't mean using non-composite (i.e., multiple certificates). Falko Am 25.07.25 um 10:03 schrieb Daniel Van Geest: I don't think it's plausible to provide support for parallel signature chains and then expect people to not use a chain individually. An advantage of parallel chains is that you can maintain a traditional algorithm chain for backwards compatibility with peers who haven't yet been upgraded to PQ. And similarly, when it's time to sunset traditional algorithm you can just stop using the traditional chain an only use the already-deployed PQ chain. Daniel On 2025-07-25 7:26 a.m., Jun Hu (Nokia) wrote: Thanks for your comment, just to clarify, there is no intention to and people should not reuse key between composite key and separate key; and I don’t expect people will actually do that in typical actual deployments; there is already some text in the security consideration of the draft regarding the key reuse, but I will make it more clear in next revision. From: Falko Strenzke <[email protected]><mailto:[email protected]> Sent: Thursday, July 24, 2025 5:52 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: comment on signature combiner / key reuse in draft-hu-ipsecme-pqt-hybrid-auth-02 I have a comment on the presentation of draft-hu-ipsecme-pqt-hybrid-auth-02 in the session today. On the slides<https://datatracker.ietf.org/meeting/123/materials/slides-123-ipsecme-post-quantum-traditional-hybrid-pki-authentication-in-ikev2-00#page=8> it says that it is intended to allow key-reuse among standalone and composite keys with the currently proposed LAMPS signature combiner<https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-sigs-07.html>. The reason that is given there is that the context parameter that is set should mitigate the security concerns in this case. I want to raise awareness that the signature combiner that you are using will exhibit a principal signature forgery vulnerability in the scenario where an attacker downgrades the composite key to a traditional-only key. In that case the forged message takes the specific form of the message representative M' in the LAMPS composite sig draft<https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-sigs-07.html#section-3.2-1>. The context parameter that is intended to be used by the authors doesn't prevent this. I don't understand enough about IPsec to say whether the described downgrade like this is possible. I suggest that the authors verify this. Generally, I recommend that the authors choose the signature combiner based on an evaluation of its security features. Even if it can be ruled out that the forged messages are meaningful protocol messages, there might be problems when a formal verification of the protocol is conducted. I don't think that this combiner is suitable for other protocols in general. The mere fact that its use entails further security analysis is reason enough to be careful in my view. Possibly, using straightforward parallel signatures is the better choice in your case. Falko -- MTG AG Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: [email protected]<mailto:[email protected]> 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> _______________________________________________ IPsec mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- MTG AG Dr. Falko Strenzke Phone: +49 6151 8000 24 E-Mail: [email protected]<mailto:[email protected]> 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>
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
