So ECHDE is an interesting point that I had not considered, but as Matt noted, the quality of randomness in the devices does generally improve with time. It tends to be the initial bootstrapping where things go horribly wrong.
A couple years ago I was actually on the opposite side of this issue, so it’s very easy for me to see both sides. I just don’t see it as useful to categorically rule out something that can provide a significant security benefit in some circumstances. -Tim As an unrelated but funny aside, I once heard about a expensive, high assurance device with a embedded bi-stable circuit for producing high quality hardware random numbers. As part of a rigorous validation and review process in order to guarantee product quality, the instability was noticed and corrected late in the development process, and final testing showed that the output of the key generator was completely free of any pesky one bits that might interfere with the purity of all zero keys. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Wednesday, December 13, 2017 11:11 AM To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CA generated keys 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 <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > 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:r...@sleevi.com <mailto:r...@sleevi.com> ] Sent: Wednesday, December 13, 2017 9:52 AM To: Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > Cc: mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: CA generated keys On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> <mailto:dev-security-policy@lists.mozilla.org <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 dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
