Re:Universal DNSSEC: Secure DNS for Every Domain
by tptacek on Tuesday November 10, 2015 @03:52PM
(#10542396)
Targets don't have to cry foul. Broken pins can be reported automatically. People on the Chrome and Mozilla security teams can monitor them. It's not like this is an abstract point: it's already happened!
I'm not sure what you're trying to say about "state actors" and HPKP. No matter what happens: the NSA will control the DNS. We all stipulate that they control CAs. DNSSEC does nothing to change this (it actually ratifies it), but HPKP does.
Re:Universal DNSSEC: Secure DNS for Every Domain
by ynik on Tuesday November 10, 2015 @03:42PM
(#10542331)
> Fundamentally, if you control a domain you can get a CA-signed certificate for any label under it.
It's worse than that. All an attacker needs to do is passively monitor the target domain's emails, and he can get a valid CA-signed certificate. If the attacker can only monitor some networks, not all globally: no problem, since the attacker gets to choose which CA the email gets sent from!
* DNS TLD operator trust is replacing CA trust. This is specious off the bat since so many CAs rely on the DNS for verifying the origin of a request. Fundamentally, if you control a domain you can get a CA-signed certificate for any label under it. In other words certificate trust is already, implicitly, DNS trust. Even HPKP+HSTS won't save you when the adversary is a state actor and controls DNS, controls a CA, and controls the network.
If you think most targets will cry foul and invoke the Internet Death Penalty upon detecting a violated CA, you're dreaming. Most targets don't even know what a certficate is.
I would be looking for an entirely different trust framework rather than muttering about two that are nearly congruent.
* Server-based validation is a problem. Why? Whether it's a locally running validating recursive resolver, or a validating library you link to your own software, or 8.8.8.8, in every case you're choosing to trust someone else's code and the mechanism by which you invoke it. The only absolute way to resolve this issue is audit/write the validation code yourself.
I.e., this isn't an emergent property of DNSSEC, it's just browser authors being lazy. (See also: lack of SRV record support in HTTP/2).
* DNSSEC doesn't help _me_ with _my_ security issues. Well, for that kind of universal claim we only need one counterexample to make it false. I'm happy to provide one: distribution and validation of my SSH host keys.