On Thursday, 30 November 2017 21:49:42 CET Ryan Sleevi wrote: > On Thu, Nov 30, 2017 at 3:23 PM, Hubert Kario <hka...@redhat.com> wrote: > > On Thursday, 30 November 2017 18:46:12 CET Ryan Sleevi wrote: > > > On Thu, Nov 30, 2017 at 12:21 PM, Hubert Kario <hka...@redhat.com> > > > > wrote: > > > > if the certificate is usable with PKCS#1 v1.5 signatures, it makes it > > > > vulnerable to attacks like the Bleichenbacher, if it is not usable > > > > with > > > > PKCS#1 > > > > v1.5 it's not vulnerable in practice to such attacks > > > > > > A certificate does not produce signatures - a key does. > > > A certificate carries signatures, but only relevant to verifiers. > > > > and verifiers are who enforces if the signatures are sane > > and for verifiers only the certificate is visible, not private key > > and certificate for the user of the key is essentially a blob, not > > something > > he or she can edit, so it is a commitment (even for CA, as that self > > signed > > one is no longer in control of it) > > > > > Your reference to Bleichenbacher again makes it unclear if you're > > > expressing a concern about the protection of the private key or the > > > > quality > > > > > of the signatures, or whether you're conflating with ciphersuite > > > negotiation and encryption. > > > > key with rsaEncryption SPKI can be used for both signatures and > > encryption, > > key with RSA-PSS SPKI can't be used for encryption if at least one party > > is > > standards compliant > > > > and the only way the other party can tell if the key is a rsa or a rsa-pss > > key > > is by looking at the certificate > > > > so if the _private_ key is rsa or rsa-pss type is of purely philosophical > > concern > > Then I think this is an incredibly convoluted concern. > > If I'm understanding correctly - and I hope you can correct me if I'm not - > the view is that it is valuable to limit a public key via an unnecessary > complex encoding scheme so that it does not get used for encryption (in > what protocol? Obviously not X.509 - so presumably certificates) so that it > is robust against CCA like Bleichenbacher? > > It feels like I just spewed out words writing that out, because it does not > seem like it fits a consistent or coherent threat model, and so surely I > must be missing something.
I discussed it with Bob Relyea, Daiki Ueno, Nikos Mavrogiannopoulos and they see it as a valid concern and acceptable solution. My feeling of the discussion on the TLS WG mailing about the same topic was the same - that prohibiting use of key for RSA key exchange has value. (continued below) > 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" > > that's about RSA-PSS parameters in SPKI or about RSA-PSS OID in SPKI? > > Both! > > I think the 'correct' solution from a policy perspective, given these > constraints, is: > - rsaEncryption as SPKI is perfectly fine (and, indeed, the only one that > interoperates) > - I would even go as far as to say rsaEncryption as SPKI should be > *required*, as anything else is merely an expression of intent that only > matters if the private key control has been lost or confused that's your opinion, not the community consensus > - The policy itself should express that while the certificate may not > express the intent, any other use of the associated private key is a > fundamental trust violation, regardless of whether or not clients will > accept it (again, because it means you've lost control of the key / cannot > keep it constrained as you intended to) I have no problem with phrasing it primarily in terms of policy and allowing for that policy to be duplicated in CA's certificate SPKI > - If allowed, it should be fully absent or byte-for-byte identical to the > signature again, no problem > - rsaPSS as the signature > - It should have byte-for-byte encodings of the blessed forms for PSS + > SHA-256/384/512 no problem > - This means no salt size variability as an unnecessary complexity > that imposes decoding costs upon the client no problem > - It should be byte-for-byte matched with the SPKI if PSS-in-SPKI is > permitted and present of the issuing CA certificate, yes > - Any violation of that (tbsCert.signature / tbsCertList.signature != > issuer.SPKI) is misissuance. Regardless of whether a 4055 client would > accept/reject it that was my intent so I think we're done here - from what I can tell the only material change is that the variable salt length is disallowed and that the requirements are spelled out it terms of policy, not technical limitations -- 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
