On Wed, Nov 29, 2017 at 1:09 PM, Hubert Kario <[email protected]> wrote:
> > The extent of the argument for flexibility, so far, has been OpenSSL's > > behaviour to produce RSA-PSS signatures with a maximal salt length. These > > same clients are also incapable of parsing RSA-PSS SPKIs (that only came > > recently, AFAICT). > > yes, it can't handle RSA-PSS SPKI, but it can handle RSA-PSS in signatures, > and my understanding is that we want the same kind of limitations for > signatures and for SPKI - if only to limit the confusion > Correct, the behaviour of OpenSSL is to unfortunately take maximal advantage of the unnecessary complexity of RFC 4055. I do not feel that it is in the best interest of users or security to interoperate with that decision. > > This probability of encountering such signatures within > > the Web PKI itself is substantially lower, due to the many requirements > > around protection of keys and the ease (or more aptly, difficulty) in > > integrating such libraries with such systems - but even still, can be > > configured by the client (nominally, the value of -1 indicates saltLen == > > len(hash), while -2 indicates the maximal encoding) > > Web PKI, now - yes > But the problem is that Microsoft CAs (for Active Directory) default to > RSA- > PSS signatures, which means that Firefox cannot be deployed on such > internal > networks. > This does not help Firefox market share. > Let's be precise: My proposal does not change the status quo. It does not improve the situation as deployed, I readily admit, but it does not make the entire ecosystem worse because of it. Further, let's not conflate Microsoft CA generated certificates - which is what you're noting as the internal networks - with OpenSSL generated certificates - which have no such data as to the extent of the problem. Today's status quo: If you have deployed RSA-PSS certificates on your network, browsers such as Chrome or Firefox, and systems such as macOS or Android, do not accept such certificates. You need to replace such certificates. Tomorrow's status quo: If you have deployed RSA-PSS certificates on your network, and they do not reflect a sensible security configuration, browsers such as Chrome or Firefox, and systems such as macOS or Android, do not accept such certificates. You'd need to replace such certificates - but you would be able to do so with 'sensible' RSA-PSS configuration. > and I'm not saying that it is not possible to create signatures with > correct > salt lengths with old OpenSSL - but it is not the default, so any kind of > certificates that were created previously will likely use the default. > That in > turn means that it would require reprovisioning all certificates like that, > not a task that is easy at scale, welcome or with any benefit from the PoV > of > users. > Again, I think this is an extremely poor argument for introducing global complexity into the ecosystem, and known-dangerous anti-patterns into libraries such as NSS. That is, when I weigh the risk of a limited set of Enterprise users (which we know is limited, given the above constraints and the lack of prevalence of OpenSSL in the CA space), I do not feel that it is reasonable or responsible to suggest that we must accept undue complexity because they crapped the proverbial bed first by shipping a non-sensical configuration. > > 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. > > 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. 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. > > 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. > > > 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". 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. 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. > 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
