On Wed, Nov 29, 2017 at 7:55 AM, Hubert Kario via dev-security-policy < [email protected]> wrote: > > > > The fact that this new NSS implementation does not properly validate the > > well-formedness of these signatures is somewhat in conflict with your > > statement: > > ""it turned out to be a problem because a). it was the 90's, b). > everybody > > did > > it like that, c). everybody assumed (not test) that security software was > > written, well, securely...""" > > > > So are we to conclude that this is still a problem because everybody > > assumes, but does not test, that NSS is written, well, securely? > > I definitely do not assume that, I just do not consider the issues we > suspect > to be there and issues we know about (and plan to fix in near future) to be > blockers for shipping it, because RSA-PSS is in its infancy on the public > 'net. > > I do think that they need to be resolved before TLS 1.3 is in its final > state > though. >
My hope is that we'd prioritize bugs that affect security (SHA-1 in MGF1) and stability (RSA-PSS laxness), especially if they're identified prior to/within days of shipping. > > > This is similarly an example of a policy 'requiring' X, but this is not > > required through code or, with your proposed policy, required through > > policy. > > requirement that the certificates be DER encoded is part of X.509 standard, > it's implicit > And yet it's so frequently been messed up that an entire section of mozilla::pkix workarounds to address this. The goal of policy is to learn from the mistakes of the past, to better inform the future. the policy doesn't state that the byte is 8 bits long or that 'a' is encoded > using big endian octet of decimal value 97 either... > You're correct - but if CAs were frequently messing this up, or requirements within similar sections, then I would just as ardently advocate we include such in the policy. > 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). 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) > > 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? 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 and is itself related to the usage of the key, not the trust in the signatures - need to be expressed in the certificate? I propose it doesn't - which is where the need to express that intention introduces significant, and unnecessary, complexity. > > 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. 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. The suggestion that it's somehow mitigated on the client because the client would accept it even if the CA screwed up and did it anyways belies the idea that the single most critical thing CAs must due is protect their private key and limit what they sign. 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). 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
