As I’m sure you’re aware, RSA key generation is far, far more reliant on the quality of the random number generation and the prime selection algorithm than TLS is dependent on randomness. In fact it’s the combination of poor randomness with attempts to reduce the cost of RSA key generation that has and will continue to cause problems.
While the number of bits in the key pair is an important security parameter, the number of potential primes and their distribution has historically not gotten as much attention as it should. This is why there have been a number of high profile breaches due to poor RSA key generation, but as far as I know, no known attacks due to the use of randomness elsewhere in the TLS protocol. This is because TLS, like most secure protocols, has enough of gap between secure and insecure that small deviations from ideal behavior don’t break the entire protocol. RSA has a well-earned reputation for finickiness and fragility. It doesn’t help that RSA key generation has a sort of birthday paradoxy feel to it, given that if any two key pairs share a prime number, it’s just a matter of time before someone uses Euclid’s algorithm in order to find it. There are PLENTY of possible primes of the appropriate size so that this should never happen, but it’s been seen to happen. I would be shocked if we’ve seen the last major security breach based on poor RSA key generation by resource constrained devices. Given that there exist IETF approved alternatives that could help with that problem, they’re worth considering. I’ve been spending a lot of time recently looking at the state of the IoT world, and it’s not good. -Tim From: Ryan Sleevi [mailto:[email protected]] Sent: Wednesday, December 13, 2017 9:52 AM To: Tim Hollebeek <[email protected]> Cc: [email protected] Subject: Re: CA generated keys On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy <[email protected] <mailto:[email protected]> > wrote: Wayne, For TLS/SSL certificates, I think PKCS #12 delivery of the key and certificate at the same time should be allowed, and I have no problem with a requirement to delete the key after delivery. I also think server side generation along the lines of RFC 7030 (EST) section 4.4 should be allowed. I realize RFC 7030 is about client certificates, but in a world with lots of tiny communicating devices that interface with people via web browsers, there are lots of highly resource constrained devices with poor access to randomness out there running web servers. And I think we are heading quickly towards that world. Tightening up the requirements to allow specific, approved mechanisms is fine. We don't want people doing random things that might not be secure. Tim, I'm afraid that the use case to justify this change seems to be inherently flawed and insecure. I'm hoping you can correct my misunderstanding, if I am doing so. As I understand it, the motivation for this is to support devices with insecure random number generators that might be otherwise incapable of generating secure keys. The logic goes that by having the CAs generate these keys, we end up with better security - fewer keys leaking. Yet I would challenge that assertion, and instead suggest that CAs generating keys for these devices inherently makes the system less secure. As you know, CAs are already on the hook to evaluate keys against known weak sets and reject them. There is absent a formal definition of this in the BRs, other than calling out illustrative examples such as Debian-generated keys (which share the flaw you mention), or, in more recent discussions, the ROCA-affected keys. Or, for the academic take, https://factorable.net/weakkeys12.extended.pdf , or the research at https://crocs.fi.muni.cz/public/papers/usenix2016 that itself appears to have lead to ROCA being detected. Quite simply, the population you're targeting - "tiny communication devices ... with poor access to randomness" - are inherently insecure in a TLS world. TLS itself depends on entropy, especially for the ephemeral key exchange ciphersuites required for use in HTTP/2 or TLS 1.3, and so such devices do not somehow become 'more' secure by having the CA generate the key, but then negotiate poor TLS ciphersuites. More importantly, the change you propose would have the incidental effect of making it more difficult to detect such devices and work with vendors to replace or repair them. This seems to overall make Mozilla users less secure, and the ecosystem less secure. I realize that there is somewhat a conflict - we're today requiring that CDNs and vendors can generate these keys (thus masking off the poor entropy from detection), while not allowing the CA to participate - but I think that's consistent with a viewpoint that the CA should not actively facilitate insecurity, which I fear your proposal would. Thus, I would suggest that the current status quo - a prohibition against CA generated keys - is positive for the SSL/TLS ecosystem in particular, and any such devices that struggle with randomness should be dismantled and replaced, rather than encouraged and proliferated.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
