Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11

[Tomas Gustavsson <[e-mail]>]

Are you present in x9 Tim? I hope it has been debated there as well.
It would indeed be good with harmonization between standards bodies in this important topic. Bloat is also one of the biggest causes of vulnerabiliies.

Cheers,
Tomas


________________________________
From: Tim Hollebeek <[e-mail]>
Sent: Tuesday, February 13, 2024 9:41:22 pm
To: Tomas Gustavsson <[e-mail]>; Jan Klaußner <[e-mail]>; Blumenthal, Uri - 0553 - MITLL <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11

If a CA is considering using such a solution, they should be aware that it has already been debated by IETF and found lacking:

https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/

Anyone attempting to use a “backwards compatible” dual signature model needs to think very carefully about downgrade attacks.

-Tim

From: Spasm <[e-mail]> On Behalf Of Tomas Gustavsson
Sent: Tuesday, February 13, 2024 11:09 AM
To: Jan Klaußner <[e-mail]>; Blumenthal, Uri - 0553 - MITLL <[e-mail]>; [e-mail]
Subject: Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11



> Hypothetical case: you used ML-DSA for your certificate chain now and 3

> years later its broken. Now somebody comes with a document with your

> signature (that he forged) saying you owe him 1000€. Its hard to prove

> him wrong that in this case. Using composites he would be forced to also

> present the second signature that he can not forge.



I don't like this example. This forgery would likely not be valid in any jurisdiction today. Just as with physical signatures there is a lot more to it. Shouldn't i.e. eIDAS define what is required for (qualified) signature creation and validation, much as it does today. We give such legislators tools to use of course, be it composites or multiple signatures, or just single signatures depending on the risk assumed for different use cases.

I'm more afraid of my digital id that I use to login and sign on-line transactions (banking) be broken. In this case the sender application and receiver is part of the same eco system playing by the same rules. It's a complex risk/benefit analysis for sure.



A CA may choose to use a backwards compatible hybrid solution. I.e. X.509 alternative keys/sigs as discussed in X9.146 draft (who knows where that will move, but may as well bring it up as another standardization organization working on hybrids).



Cheers,

Tomas



________________________________
From: Spasm <[e-mail]<mailto:[e-mail]>> on behalf of Jan Klaußner <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 13, 2024 4:22 PM
To: Blumenthal, Uri - 0553 - MITLL <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] [EXT] [EXTERNAL] draft-ounsworth-pq-composite-sigs-11

Hi Uri, answers inline br Jan Am 12. 02. 24 um 19: 38 schrieb Blumenthal, Uri - 0553 - MITLL: > I disagree in 2 points: > > 1. ) "[. . . ] The only use case for multiple signatures that I see is non-repudiation of documents [. . ]" > >

Hi Uri,



answers inline



br Jan



Am 12.02.24 um 19:38 schrieb Blumenthal, Uri - 0553 - MITLL:

> I disagree in 2 points:

>

> 1.) "[...] The only use case for multiple signatures that I see is non-repudiation of documents [..]"

>

> It also covers weak (root) keys due to bugs nicely. Imagine a TSP produced its RSA root keys using the vulnerable secure elements affected by the ROCA attack. Until you exchanged all certificates, smart cards and informed users valuable time passes, not to speak of costs and reputation. And chances of implementation bugs are much higher for the upcoming algorithms. Composites would give a second floor also in this case beyond the question if the algorithm holds.

>

> In short, I don’t think the above is reasonable. And it places bets on correctness of Classic algorithms implementations – which IMHO is a risky bet.



Can you elaborate on why it is not reasonable?



And why do you think composites relies on the correctness of classic

algorithm implementations? (I interpreted your sentence that way,

correct me if I am wrong).

Composites try to distribute the risk of implementation faults and

algorithm weaknesses on two independent pillars. It allows failures in

both of them since failing of both at the same time is much more unikely.



>

> 2."[...] Multiple signatures address it nicely. [...]"

>

> Multiple signatures would mean also multiple PKIs that need to be operated separately, which is a non-negligible cost factor, let alone keeping them in sync. Also handling these multiple signatures in applications needs to be tought of. What is a user supposed to think if one signature of the same signer fails and the other succeeds? I think its no obvious. This needs to be handled in all applications out there which will be also error prone. Composites have in my view the advantage that, in order to support them, they need to be implemented in only a few components/crypto libs by people who are sensitive of security.

>

> Composite signatures have no advantage over multiple ones in this context. The policy that governs the receiver will rule, and it trivially straightforward:

> The policy states whether a subset of the signatures (separate, or parts of composite), or the entire set must verify for the overall validation to succeed;

> That receiver policy may state that only certain signatures (e.g., made with ML-DSA) are “valuable”, and others can be ignored – in which case it doesn’t matter how much the sender is beating his chest demanding that all the provided signatures are validated.

> If signatures are composite – it would force the PKI to support multiple algorithms,  which (a) at least some CA may not want, and (b) would create additional unnecessary attack surfaces to worry about. But for those PKI/CA that want to support multiple algorithms, multiple signatures would not pose a problem. Thus, a clear win.

For authentication I agree, the receiver can do what he wants, its his

risk.



For non-repudiation it is quite important for the signer to tell at

signing time under which conditions he accepts obligations arising from

his signature. This is also true for a CA. Therefore a receiver should

better check both signatures to be safe he can make such a claim later

if needed.



Hypothetical case: you used ML-DSA for your certificate chain now and 3

years later its broken. Now somebody comes with a document with your

signature (that he forged) saying you owe him 1000€. Its hard to prove

him wrong that in this case. Using composites he would be forced to also

present the second signature that he can not forge.



To spin this scenario even further, if an attacker can forge CA

signatures, he can completely make up your signing certificate. So even

for a CA it would be better to use composites in order to avoid such

issues. Even multiple signatures on documents would not help here,

because where it is enforced that you need to sign twice?



If CAs decide against it, its their business risk, but nobody forces

them with this draft. But a CA failing in this would also damage the

whole ecosystem, hence the recommendations from ANSSI and BSI.



As for the attack surface, I think handling multiple sgnatures in

application along with all the certificate stuff poses a greater risk of

misconfiguration, misuse, condusion and ignorance on the user side that

will exceed that of composites.



With composites, all applications can handle this as long as the crypto

lib understands the OID, which is a small attack surface that is quite

controlable.



And repeating myself, operating multiple PKIs for the same purpose is a

quite relevant cost factor.



>

>

>

>

>

>

>

> Am 09.02.24 um 20:51 schrieb Blumenthal, Uri - 0553 - MITLL:

> For asynchronous protocols (CMS, code signing, etc.) there are much

> stronger arguments for hybrid signatures

>

> Could someone walk me though a code-signing scenario that

> needs hybrid signature algs? I can see wanting both kinds

> of sig, but not why those can't be separate.

>

> I don't think there's any valid scenario or use case for hybrid/combined signatures vs. multiple separate signatures.

>

> The only use case for multiple signatures that I see is non-repudiation of documents created at date X that could require validation at date Y >> X, with a potential of CRQC falsifying a signature sometime between X and Y. Multiple signatures address it nicely.

>

>

>

>

>

>

> _______________________________________________

> Spasm mailing list

> [e-mail]<mailto:[e-mail]>

> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$>

>

>



_______________________________________________

Spasm mailing list

[e-mail]<mailto:[e-mail]>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!BjbSd3t9V7AnTp3tuV-82YaK!3Sf65v2jtKFwe44v240wELSdCuElQvFyY47oDJn_lQXbZpYEngvdrAXHdVOJPuwbfNjclGymViRHSUao6rc0JHjb$>