On Friday, 1 December 2017 16:33:10 CET Jakob Bohm via dev-security-policy wrote: > On 01/12/2017 16:23, Hubert Kario wrote: > > On Friday, 1 December 2017 15:33:30 CET Ryan Sleevi wrote: > >> 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? > > > > yes > > > >> 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 > > > > rejecting what you do not understand (iOS, Android) is completely valid > > and > > expected behaviour - e.g. NSS server still won't use (at all) RSA-PSS keys > > imported from PKCS#12 file... > > > >> - Windows and NSS both apply DER-like BER parsers and do not strictly > >> > >> reject (Postel's principle, despite Postel-was-wrong) > > > > NSS did till very recently reject them, OpenSSL 1.0.2 still rejects them > > (probably even 1.1.0), are you certain that Windows doesn't reject > > certificates with SPKI with RSA-PSS OID? I mean, you _need_ additional > > code to know that the public key for OID rsaEncryption and rsassaPss is > > formatted in one and the same way... If you don't don't have that code, > > it looks like completely different key type (think EdDSA or ECDSA for > > RSA-only > > implementation) > > > >> - 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? > > > > there is a remote chance that RSA-PSS with non-zero salts is strictly more > > secure (unforgeable) than PKCS#1 v1.5, but for the sake of argument let's > > say that what you said is the primary and only argument for RSA-PSS OID > > in SPKI > > > > so no, there aren't other arguments > > > >> 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 > > Depending on the prevalence of non-public CAs (not listed in public > indexes) based on openssl (this would be a smallish company thing more > than a big enterprise thing), it might be useful to have *two* fixed > salt lengths for each combination of hash algorithm and RSA key length: > > 1. The salt length=hash length case previously suggested. > > 2. The salt length=largest permitted by RSA key length and hash length > (OpenSSL default). > > Each of these could still be defined in a memcmp-able way.
the problem is that then you need to multiply that by at least sensible RSA key sizes (2048, 3072, 4096) and that makes it a long list rather quick combined that with the fact that I haven't seen a single certificate like that on an IPv4 accessible server, while I did see good 3 to 4 dozen that match salt lengh == hash length, I think we can safely say that OpenSSL in its default configuration is not commonly used with rsa-pss signatures in internal CA deployments -- 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
