In principle, I support Mr. Sleevi's position, practically I lean toward Mr. Thayer's and Mr. Hollebeek's position.
Sitting on my desk are not less than 3 reference designs. At least two of them have decent hardware RNG capabilities. What's noteworthy is the garbage software stack, kernel support, etc. for that hardware. The FAEs for these run the gamut from "I'm ashamed of the reference software we're crippling this fantastic design with" all the way to "Here, just use this library for random." (It's a PRNG with a static seed. And a bad PRNG alg at that.) Access to this kind of hardware requires a devil's bargain in which you sign away your right to detail these kinds of things. That's the case here. What I can say is that fresh new reference designs being incorporated into consumer products today certainly don't make things any easier for anyone hurrying to bring a product to market. At least not if they want security. Having said that, some practical thoughts: It's mostly a linux kernel universe on these devices. Even in cases where the kernel isn't plumbed through to the hw rng generation, as a function of increasing run-time and actual sporadic use, the entropy pool improves to a tolerable level with time. The trouble arises from the fact that key generation tends to be a new device setup and on boarding procedure and thus executes in a predictable manner on a pretty precisely predictable timing. Thus, these keys tend to be generated before a sufficient entropy pool exists. Regarding the security of a device with poor original entropy and its appropriateness in TLS, I would point out that a deterministic pseudo-random number generator is perfectly acceptable for cryptographic purposes as long as there is a sufficient initial random seed. In the absence of a better source, the limited entropic data that is available could be combined with a value deterministically derived from, for example, the well engineered generated-off-device private key. This can all be trivially implemented in user space and by developers with less familiarity with interacting with proprietary devices on various hardware busses, special random generation processor opcodes, etc, etc. It is naive to believe that you will timely become aware of the various permutations of the weak keys. It is naive to believe that policy making it hard to get certificates for those devices will cause those devices to be timely replaced. These SCADA devices caught up in the ROCA mess - did they actually replace those devices, update the software with an off-platform key generator, or just front them with a reverse proxy? I'm betting it was the second or third of those options. And that's for professional gear deployed in presumably large commercial environments. On Wed, Dec 13, 2017 at 10:52 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
