On Wednesday, 29 November 2017 17:00:58 CET Ryan Sleevi wrote: > On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > Because I do not consider making the salt length rigid (one value allowed > > for > > every hash) to be of any value. If it is not rigid, it would be silly to > > provide a correct encoding for every single possible valid encoding. > > I do not consider making the salt length flexible to be of any value. > Further, I point to the past issues with respect to flexibility - and to > the many CVEs across a wide spectrum of clients, including NSS, with > respect to decoding signature parameters, that such flexibility will be > actively detrimental both to the implementation within Mozilla products and > to the implementation within the broader Web PKI community. > > 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 > 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. 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. > > > 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 > > > and > > > RSA-PSS signatures with the same key? > > > > depends on the circumstances > > > > > > I consider RSA-PSS to be strictly more secure than PKCS#1 v1.5. > > > > So if one already uses PKCS#1 v1.5 and adds RSA-PSS, it doesn't increase > > the > > security of the system, but it doesn't decrease it either. > > 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 > If it is, then it either theorhetically or practically weakens the security > of the system. > If it's not, then there's no need to afford the flexibility. > > > if one does use rsa-pss only (or has such intention), then use of pkcs#1 > > v1.5 > > with such key would lower the security of the system. > > 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"? > 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. > I propose it doesn't > - which is where the need to express that intention introduces significant, > and unnecessary, complexity. I really don't think we're on the same page here... > > > 2) Do you believe it represents a security risk to mix hash algorithms > > > within RSA-PSS signatures with the same key? > > > > like I said before, the problem is not that the key can be used with > > sha-384 > > and sha-512 at the same time - that I don't see as a risk, at least not > > now > > Again, cross-algorithm attacks. > > > Use of the key with sha-1 and sha-384 at the same time, yes, I do, and I > > don't > > think this should be allowed. > > But that's not a risk to the key - that's a risk being proposed in which > the client accepts SHA-1. > > > Now, one may expect that SHA-256 will go the way of SHA-1, then having > > ability > > say "I won't use SHA-256", even when it is allowed by both policy and code > > is > > a value-add. > > 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. > 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). > This is why I have such a fundamental problem with the policy proposal, and > would rather see such restrictions be placed on the key and its operations > (for which a SHA-256 signature from a SHA-384 key is an act of active > misissuance, regardless if the client accepts it) than upon the certificate > (which can easily be subverted) I see those limitations as being placed on a particular public key - though spelling it out in policy is probably good idea > . Similarly, the notion that the need for > such flexibility in the signatures accepted is to support a half-complete > notion of backwards compatibility, or to allow signers the flexibility they > want to set their security policy, is to ignore the complexity being > imposed upon client implementations, and the number of bugs that have > resulted from having to support signer-friendly options rather than > verifier-friendly limitations. 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 -- 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
