On Fri, Dec 1, 2017 at 7:34 AM, Hubert Kario <hka...@redhat.com> wrote:
> > It does feel like again the argument is The CA/EE should say 'I won't do > X' > > so that a client won't accept a signature if the CA does X, except it > > doesn't change the security properties at all if the CA/EE does actually > do > > X, and the only places it does affect the security properties are either > > already addressed (e.g. digitalSignature EKU) or themselves not protected > > by the proposed mechanism. > > a). I think you're talking about Key Usage, not Extended Key Usage > b). digitalSignature is a Key Usage, not Extended Key Usage bit > c). Extended Key Usage has only one flag for use in TLS - serverAuth - > which > doesn't say anything about applicability of the key for SKE signature but > not > RSA key exchange > d). show me the clients that actually honour the Key Usage flags for TLS > in a > way that prevents use of certificate with rsaEncryption SPKI for RSA key > exchange > > so, yes, I'm afraid that you "must be missing something" > So while we started off in disagreement, it sounds like we have cycled back to the view that RSA-PSS-params, if present, should be memcmp() able (between SPKI and Signature and between Signature and Policy) So the only thing that we're debating here is whether or not expressing RSA-PSS in the SPKI (at all) is a good thing. The view in favor of this is: - Because CAs have made a complete mess of the existing rsaEncryption + KU , clients don't check KU for rsaEncryption (Notably, they do check KU for ECDSA because that's necessary to distinguish from ECDH) - If a certificate is encoded with rsaEncryption, it's possible for a server to use it both with TLS 1.2 RSA PKCS#1v1.5 ciphersuites and TLS 1.3 RSA-PSS ciphersuites - If used with TLS 1.2 RSA PKCS#1v1.5 ciphersuites, it's possible that the implementation may be buggy and subject to Bleichenbacher - And expressing (via the SPKI OID) is an 'effective' way to prevent that downgrade, which itself is only a risk if you're using a buggy implementation. Is that accurate? To offset that risk, the goal is to use the SPKI algorithm as the signal to 'do not downgrade algorithms' (in this case, from PSS to PKCS#1v1.5). This, despite the fact that SPKI parsing does not correctly work on any platform - Windows and NSS both apply DER-like BER parsers and do not strictly reject (Postel's principle, despite Postel-was-wrong) - macOS and iOS reject unrecognized SPKIs as weak keys - Android supports PSS-signatures but a provider for decoding said public keys is not provided by default Are there any other arguments in favor of the PSS-SPKI not captured here? I think that we agree on the substance of the PSS implementation - Must Be Memcmp-able - makes many of the client complexity concerns. The deployment complexity concerns are unavoidable - few clients support RSA-PSS in part because of the disaster than is RFC 4055 - but that's a deployment concern, not an implementation concern. As it relates to what changes this means for NSS: - Strictly enforcing (memcmp)ing the accepted parameters that NSS accepts - That means NSS should NOT support arbitrary salt lengths, as doing so adds flexibility at the cost of maintainability and security - This resolves the DER-like BER decoding - Strictly enforcing the KU for RSA-PSS (which it improperly enforces KUs on keys today already, but hopefully RSA-PSS has not been ruined) Is that correct? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
