On Wed, Dec 13, 2017 at 11:06 AM, Tim Hollebeek via dev-security-policy < 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 https://lists.mozilla.org/listinfo/dev-security-policy
