On Wednesday, 29 November 2017 21:59:39 CET Ryan Sleevi wrote: > On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario <hka...@redhat.com> wrote: > > > So are you stating you do not believe cross-algorithm attacks are > > > > relevant? > > > > No, I don't believe that cross-algorithm attacks from RSA-PSS to PKCS#1 > > v1.5 > > are likely. > > > > I do consider users of PKCS#1 v1.5 to be vulnerable to attacks that can be > > leveraged against both PKCS#1 v1.5 and RSA-PSS > > I'm really not sure how to parse your response. I'm not sure if your "No" > is your answer - as in you don't believe they're relevant - or "No" as you > disagreeing with my framing of the question and that "Yes", you do believe > they're relevant, despite them not being likely. > > I'm further not sure how to parse your remark about "users of PKCS#1 v1.5" > - as to whether you mean the signers or the verifiers.
if the certificate is usable with PKCS#1 v1.5 signatures, it makes it vulnerable to attacks like the Bleichenbacher, if it is not usable with PKCS#1 v1.5 it's not vulnerable in practice to such attacks > > > Sure. But why does that intention - which cannot be technically enforced > > > > RSA-PSS OID in SPKI does exactly that, what do you mean "cannot be > > technically > > enforced"? > > It does not do prevent such a signature from being created - that's what I > mean. now you're being silly the Mozilla policy doesn't prohibit the CA from making a service that will perform RSA private key operation on arbitrary strings either but we would still revoke trust from CA that would do such a thing, because just the fact that such a service _could_ have been used maliciously (to sign arbitrary certificates) is enough to distrust it! > If it doesn't prevent such a signature, and the act of signing weakens the > key itself, then such a constraint is pointless. > If it simply indicates to a client "Don't accept this signature", but the > act of signing weakens the key still, then such a constraint is pointless. > If it does not weaken the key, then indicating to the client such a > constraint is pointless, because any client that encounters such a > signature has proof that the CA has failed to abide by the policy of their > key - and if so, everything used with that key should be rightfully called > into question, and no 'damage mitigation' has been achieved. I don't think that it's the act of making the signature that weakens the key If I generate a certificate has RSA-PSS SPKI I won't be able to use it for PKCS#1 v1.5 signatures - no widely deployed server will use it like that and no widely deployed client will accept such use. So a chance that a key will be abused like that and will remain abused like that is negligible. and that's the whole point - defence in depth - to make it another hurdle to jump through if you want to do something stupid > > > and is itself related to the usage of the key, not the trust in the > > > signatures - need to be expressed in the certificate? > > > > If the certificates has SPKI with RSA-PSS id, that means exactly that - > > never > > trust PKCS#1 v1.5 signatures made with this key. > > Yes. And expressing that is pointless (see above). > > > > I disagree. I don't believe there's value in the expression of that from > > > the CA within the certificate, for the reasons I previously mentioned - > > > that intention can be subverted if the CA is willing to use SHA-1 or > > > SHA-256 when they declared they will not, or if the CA is not willing, > > > > then > > > > > it's introducing unnecessary complexity into the client ecosystem for > > > limited benefits. > > > > If the RSA-PSS parameters in SPKI say SHA-256, SHA-1 signature made with > > such > > certificates never was and never will be valid. So creating SHA-1 > > signatures > > is useless from point of view of legitimate CA. > > > > It's like having technically constrained CA limited to .com domain and > > issuing > > certificate for .org domain - no valid PKIX implementation will trust > > them. > > I understand - but I'm saying that what we're discussing fundamentally > relates to the key. > > If a CA was technically constrained to .com, said they would never issue > for something not .com, but then issued for .org, it's absolutely grounds > for concern. > If it doesn't matter whether a CA issues for .com or .org, and they simply > choose to only issue for .com, then it doesn't make sense to require > clients to support the CA's expression of intent if doing so introduces > security risk to clients (and it does) and complexity risk. so where's the bug that removes support for that in Firefox? Will we get it in before the next ESR? /s > > > The extent of which this provides value is to allow a CA who, bearing a > > > certificate whose public key is constrained to SHA-384, and upon being > > > presented a SHA-256 certificate signed by the associated private key, to > > > claim "That's not misissuance, because I said don't trust anything other > > > than SHA-384". The value of that statement is extremely questionable - > > > > the > > > > > fact that the CA used their private key to sign something which they now > > > disclaim is in and of itself problematic. > > > > even if that happened, what use would have such a certificate have? it > > wouldn't be accepted by any implementation that follows RFC 5756... > > > > also my intention was slightly different: "Don't trust anything different, > > because I will never use anything different". So if anything different > > shows > > up, that likely means key compromise (or failure in internal procedures). > > I understand your intent is to capture "Don't trust if I screw up". I'm > saying that the value of such a statement is non-existent for the > complexity required to support that statement, and that encountering > anything contrary to that statement, as you state, likely means key > compromise. > > You're focusing on "Well, we could reject that certificate" - I'm focusing > on "Yes, but they did something stupid with their key, and now we have to > question every certificate". so? you're arguing that machine readable CA policy is a _bad thing_ ? > Further, if that doing something stupid with > the key undermines the security of the key itself (e.g. through > cross-algorithm attacks), then it doesn't matter what the cert says - we > want to make sure they do what they do. so what is it? either it's "technically impossible" or "we want to make sure they do what they do" > Put differently yet again, I think there's no value in a CA saying "Don't > trust me if I can't protect my key" because it's already implied that we > don't trust a CA that can't protect its key. Further, the extent of which > it matters to the risk of clients - what happens if something is SHA-256 > signed rather than SHA-384 - is only a property of whether that signature > algorithm is itself weak, and if it is, clients themselves should be > disabling that algorithm, rather than requiring on the CA's attestations. > > Don't get me wrong, I'm supportive of restricting CA's ability to do > damage. I'm posing that either there's no ability to do damage (meaning the > cross-hash-algorithm usage is not a security risk) or that the damage has > already been done (by failing to control the key). This is very different > than something like nameConstraints or EKUs - this is about the key itself. > That's my point. you're missing one thing: we don't know if it truly, positively, absolutely isn't a problem it probably isn't but it's not a certainty (I can see the world black and white too!) > > even if we forbid RSA_PSS parameters (require them to be omitted) in SPKI > > but > > allow RSA-PSS OID in SPKI that still leaves the problem of variable salt > > length > > Yes. And I don't believe that supporting such a variable salt length is a > good idea compared to the complexity it introduces, and I believe that the > compatibility risk (with OpenSSL) has been significantly overstated as to > its practical impact, given the state of the ecosystem. "What a good point you're making Hubert! Please wait a moment while I look through certificates posted on https://scans.io/ looking for ones that use RSA-PSS signatures" "no problem, that would be appreciated" "Thank you for waiting, among the ones that are exposed on the Internet I found ~5 used on Azure (all signed with SHA-256 and 32byte salt), few (~20) that look like sip gateways (most signed with SHA-256 and 32byte salt, some with SHA-1 and 20 byte salt), and one that had SHA-384 signature and 48 byte long salt. I didn't find a single one that used salt length that was different than hash length." "ah, yes, you were right Ryan, it doesn't look like using rigid salt lengths would negatively impact already deployed environments, at least the most common ones" -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
