> 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. >
As I pointed out, it can be demonstrated that quality ECDHE exchanges can happen assuming a stateful DPRNG with a decent starting entropy corpus. Beyond that, I should point out, I'm not talking about legacy devices already in market. I'm not sure the community fully understands how much hot-off-the-presses stuff (at least the stuff in the cheap, and so selected by the marketplace) is really really set up for failure in terms of security. What I want to emphasize is that I don't believe policy here will make things better. In fact, there are real dangers that it gets worse. It would be an egregiously bad decision -- but in the eyes of a budding device software stack developer -- to just implement an RSA key pair generation alg in Javascript and rely upon the browser to build the key set that will form the raw private key and the CSR. That's definitely not secure or better. Assuming you lock javascript to the point that large integer primitives and operations are unavailable outside secure mode, these people will just stand up an HTTP endpoint that spits out newly generated random RSA or EC key pair to feed to the device. And it'll be unsigned and not even protected by HTTPS, unless required, and then they'll do the bare minimum. The device reference design space is improving and is becoming more security conscious but you're YEARS away from anything resembling best practice. I just don't believe anything Mozilla or anyone else outside that world can do will speed it along. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
