On 11/09/16 22:05, Lee wrote: >> In order to spoof a CA's domain validation request, an attacker >> would need to be in a position to MitM the connection between the >> CA and the targeted domain. > > does dns hijacking or dns cache poisoning count as mitm?
I was mentioning this in order to demonstrate that opportunistic encryption (try HTTPS, if that fails, fall back to HTTP) does not help with this threat model. The specifics of how a MitM attack against the CA is being pulled off is not all that important. >> Option 2 is problematic because not all CAs log to CT at the >> moment. > > Why is that allowed? Because CT is relatively new. In fact, I don't think Mozilla is shipping a working CT implementation yet. Some might even question whether it's fair to ask CAs to implement CT logging when the majority of browser vendors haven't bothered yet (or have just recently begun to bother.) >> Both options do nothing to solve the problem of a domain owner >> losing the private key of their certificate (for example due to a >> hack, data loss, or just a domain transfer). >> >> You might be thinking of an option 3 - just connect to port 443, >> see if the domain has a valid certificate, and use HTTPS if >> available. This sounds great in theory, but since the attacker >> would need to be able to MitM the connection in the first place in >> order to spoof the validation request, they could simply intercept >> this request and force validation on port 80. >> >> All in all I think this would do more harm than good. Adding >> complexity to the DV process means slower HTTPS adoption in >> general. I'd rather see a "good enough" DV process ... > > if it isn't obvious by now, I'd say that any process that doesn't > include continuous monitoring isn't "good enough" If you're arguing in favor of mandatory CT logging for CAs, I'm with you - I just don't think it's going to happen immediately. I think that's a conversation that should be separate from the question of whether encryption should be part of the domain validation process. >> ... and HTTPS everywhere when the alternative is a >> perfect-in-theory DV process where HTTPS is available only for >> sites that can deploy all these things competently. > > If the site admins aren't competent they're going to get pwned, so > why do I care if they're doing https instead of http? Or look at it > from a different angle - if it's that hard for sites to do it > correctly then [Mozilla? CAs? somebody] can come up with a checklist > of what to look for in a hosting provider that does do it right. It > seems like most everybody is moving to "the cloud" anyway, so > requiring site admins to be competent doesn't seem all that onerous a > requirement. I'm not worried about incompetent admins that get owned, I'm worried about admins taking a look at the domain validation process you're suggesting, realizing that they now need to deploy DNSSEC or that they might brick their domain if they lose their private key because they suddenly can't get another certificate without having a valid certificate, and then just figuring that sticking with HTTP actually doesn't sound that bad. (Not to be snarky, but this argument sounds a bit like "So what? Mozilla can just solve web security for everyone, and then we can have safe CAs!") > Where is the opposition to DNSSEC? I was going to say that I'm also > lurking on the dns ops mailing list, but I don't think I can call > what I'm doing on m.d.s.p now lurking :) > > Yes, DNSSEC is complicated & difficult to do right, but opposition > to DNSSEC in general? I'm not seeing it & any CA that can't or won't > do DNSSEC shouldn't be in the Mozilla root store. I've found [1] to be a good summary of arguments against DNSSEC. [1]: http://sockpuppet.org/blog/2015/01/15/against-dnssec/ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
