You are falling into the classic trap of "this dosent solve every problem so we cannot permit it to solve any problem" that has held back security for decades.
DNSSEC is real, it is deployable and stuff is capable of supporting it, and it does solve very real issues. That counts.
My point is, of course, that DNSSEC creates more serious problems than it solves. If you think my argument is "DNSSEC isn't perfect and we should wait for perfection", you haven't read what I'm saying carefully enough.
Your single registrar becomes your ca (who you already have to trust isnt hijacking your domain and issuing certs for it), not (potentially) every ca on earth.
You can validate dns responses to be at least as real as the root dns servers claim.
Nonpinned certs gain a lot better gaurentees against random CAs. (google cant pin every cert in chrome)
It does not solve the problem of "what if the dns roots are lying to you", but as ca world cert aquisition is tied to that very same issue, neither does normal TLS.
No matter what you are stuck trusting that dns roots arn't being evil in the case of unpinned cert.
At least with DNSSEC you arnt stuck additionally trusting every CA on earth in the case an attacker can mitm, but dosent control said tld.
They can not, however, subvert the root zone any more. Not since it was singed in 2010.
What I do is to point out that with today's domain validated model, it would make a lot more sense to restrict the validation path to only includes authoritative information about the domain, and to do so in a way that is cryptographically secure.
The fact here is that Verisign can sign anything, today. They can not, however, impact the validation chain that DANE provides.
There are also many millions of use cases where .com does not matter at all.
Name an important domain, and let's see what world government controls its DNSSEC keys.
If you'd like, I will name an important domain with a trivial use case: skatteverket.se. It it the agency responsible not only of taxes but of nearly all personal data: marriages, deaths, everything. They have stringent security requirements for this, and to their users their security is infinitely more important than that of, say Facebook for example.
In what way would their adoption of DNSSEC cede control of anything to the NSA, or to anyone?
I think we can be done now, don't you?
You asked for a domain, any domain, and was prepared to show how Verisign could exercise their control over .com and somehow affect the validation path that DANE provides. At least that's what how I understood you. It's not always clear.
You seem to argue that susceptibility to state level actors is a counterargument to the standard, so I gave one of the few examples I know of who really need to protect against such adversaries.
Apparently my example was somehow a bad one. Take one of the big banks instead then? What could happen to swedbank.se if they signed their delegation with their TLD?
Or why don't you provide an example instead, and show in what way signing it would cede control to the NSA, or to anyone else?
* Every .COM
* Every .CO.UK
* Every .COM.AU
* Every .IO
* Every .ORG
Your response:
* The Swedish tax authority's site.
Again, there are millions of use cases where .com doesn't matter.
You alluded to some control that some large entity (which I only assume to be Verisign) exercise over every important domain. I take it that was never the case?
(Expecting users to read URIs was always a losing tactic, but surely everyone knows that now with IDNs.)
The level of tampering required for the NSA to fake DNSSEC replies is very evident if you have the cert pinned, and very hard to deny.
As things stand, its very easy to deny it was the NSA when anyone and their dog can have access to a CA cert.
They absolutely do, which is why we have things like key pinning.
I can set up DNSSEC and DANE today, everyone who cares gets an alternative validation path to me, and the Internet is safer because of it.
You can set up DNSSEC and DANE today, but thankfully no browser gives a shit. Key pinning, however, will not only protect you, but will also get the CA that actually coughs up a forged cert for your site locked out of Chrome and Firefox.
Maybe I'm just using the wrong terms, but as far as I can see the number of sites pinned in Firefox is tiny: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... and there is no process for getting sites added to that list.
Could you give the address for the form where I can get my site pinned in Chrome?
You explicitly replied to a post about wanting something better than"trust-on-first-use" and said key pinning solved that problem, so I assumed there was another way. I don't understand what your post was trying to say if there isn't.
Is there some way that HPKP is able to work around the first visit problem?
But apart from the difficulty NSA will have actually isolating your first use to intercept it, the point of HPKP is that they have to get everyone's first use, because when a browser sees a broken pin, it doesn't just go "oh, whatever, pop up an error and move on"; it also gets to freak out and report the broken pin.
With widely deployed HPKP, every hit to a site being MITM'd by someone with a compromised CA is an opportunity for that CA to be forever burned, simply because someone who already had the right cert pinned will trigger an alert.
There is just no way the NSA is going to risk it except in very very specific circumstances they can easily control, (exactly the same situation as HPKP) because, they too will be forever burned, except now they cant just switch to one of hundreds of other CAs, they have burned the root keys to a tld. This will be obvious, this will be screamed about from the rooftops, the key will be rotated + a ton greater scrutiny applied to the process.
Its not like browsers and other people pinning certs are just going to shrug their shoulders and say "aw shucks, i guess we wont worry about it"
The CA cannot automatically detect when a domain has been hijacked, it will issue the certs.
In this situation (with either the present DNS world, or dnscrypt), agencies are frankly 100% as unaccountable as they would be under DNSSEC world, because they still control the TLDs.
DNSCrypt does as little as DNSSEC to fix this issue. Pinning and certificate transparency can help detect under either scenario however.
Another concern in DNSCrypt is how does it handle the MITM problem between DNS servers? Trust on first sight is a lousy unscalable model (what if keys change, what if the badguys are already there before first contact) that is way more vulnerable than DNSSEC to forged replies.