On 9/11/16, Patrick Figel <[email protected]> wrote: > 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.
ok - fair enough >>> 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.) Which sounds a bit like the argument against IPv6, except in this case CT logging all by itself enables interested parties to audit CA behavior in near realtime. >>> 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'm sure it won't, but what's your guess for the lead-in time? A year? Just how much time should CAs be allowed to implement something like this? ... assuming that it can be made a mandatory item. > I think that's a > conversation that should be separate from the question of whether > encryption should be part of the domain validation process. Fine w/ me. >>> ... 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, To be clear - I'm not suggesting a domain validation process. I'm _asking_ if there's a way to do it without using clear-text protocols. If there isn't, or it's too complicated/error-prone/whatever then ok > realizing that they now need to deploy DNSSEC is DNSSEC that hard to do or is it just that you just don't agree it does anything useful? > 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. I used to think http wasn't all that bad for most things, then I read about http://www.informationweek.com/mobile/mobile-business/verizon-wireless-embroiled-in-tracking-controversy/d/d-id/1317044 so yeah, http isn't all that good. > (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!") I certainly think Mozilla can do a better job than they have, but solving web security for everyone? Not gonna happen. But maybe there's a better way to do domain validation.. What? dunno. What I am sure of is that this list has a lot of smart people on it that know crypto much better than I ever will, so I'm bringing up the question - is there a better/safer way to do it? If no, well at least I asked. My other issue is CT logging. I'm not holding my breath waiting for CT, but I am hoping CT logging can be made mandatory for all CAs in a year or 18 months. Is that too much to hope for? >> 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/ Interesting. It's going to take me more than a quick read-thru to process & I don't want to take that much time before hitting "send" Thanks, Lee _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
