On Wed, Dec 13, 2017 at 1:24 PM, Matthew Hardeman <[email protected]> wrote:
> As I pointed out, it can be demonstrated that quality ECDHE exchanges can > happen assuming a stateful DPRNG with a decent starting entropy corpus. > Agreed - but that's also true for the devices Tim is mentioning. Which I guess is the point I was trying to make - if this can be 'fixed' relatively easily for the use case Tim was bringing up, what other use cases are there? The current policy serves a purpose, and although that purpose is not high in value nor technically rigorous, it serves as an external check. And yes, I realize the profound irony in me making such a comment in this thread while simultaneously arguing against EV in a parallel thread, on the basis that the purpose EV serves is not high in value nor technically rigorous - but I am having trouble, unlike in the EV thread, understanding what harm is caused by the current policy, or what possible things that are beneficial are prevented. I don't think we'll see significant security benefit in some circumstances - I think we'll see the appearances of, but not the manifestation - so I'm trying to understand why we'd want to introduce that risk? I also say this knowing how uninteroperable the existing key delivery mechanisms are (PKCS#12 = minefield), and how terrible the cryptographic protection of those are. Combine that with CAs repeated failure to correctly implement the specs that are less ambiguous, and I'm worried about a proliferation of private keys flying around - as some CAs do for their other, non-TLS certificates. So I see a lot of potential harm in the ecosystem, and question the benefit, especially when, as you note, this can be mitigated rather significantly by developers not shoveling crap out the door. If developers who view "time to market" as more important than "Internet safety" can't get their toys, I ... don't lose much sleep. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
