Tim, I appreciate your reply, but that seems to be backwards looking rather than forwards looking. That is, it looks and assumes static-RSA ciphersuites are acceptable, and thus the entropy risk to TLS is mitigated by client-random to this terrible TLS-server devices, and the issue to mitigate is the poor entropy on the server.
However, I don't think that aligns with what I was mentioning - that is, the expectation going forward of the use of forward-secure cryptography and ephemeral key exchanges, which do become more relevant to the quality of entropy. That is, negotiating an ECDHE_RSA exchange with terrible ECDHE key construction does not meaningfully improve the security of Mozilla users. I'm curious whether any use case can be brought forward that isn't "So that we can aid and support the proliferation of insecure devices into users everyday lives" - as surely that doesn't seem like a good outcome, both for Mozilla users and for society at large. Nor do I think the propose changes meaningfully mitigate the harm caused by them, despite the well-meaning attempt to do so. On Wed, Dec 13, 2017 at 12:40 PM, Tim Hollebeek via dev-security-policy < [email protected]> wrote: > 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:dev-security-policy@ > lists.mozilla.org> > 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. > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
