If DNS is the phone book of the Internet, DNSSEC is the unspoofable caller ID. DNSSEC ensures that a website’s traffic is safely directed to the correct servers, so that a connection to a website is not intercepted by a man-in-the-middle.
No, it doesn't. DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates. DNSSEC is far less valuable than its proponents would like you to believe, and it comes at a significant cost to Internet trust: its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
It's understandable that Cloudflare would jump on DNSSEC: the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast. DNSSEC is an opportunity for a company like Cloudflare to make the case that they should manage your infrastructure, not you; the more features like DNSSEC Cloudflare can find, the more market share they'll acquire.
But make no mistake: DNSSEC isn't about helping you with your security issues.
...its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
ISTM this could at least be a transparency win, for average users. If trust went by TLD, we'd know that e.g. using "bit.ly" required trusting the Libyan domain admins. With CAs now, we just get a pile of CAs pre-installed with our OS or browser, and a bit of knowledgeable clicking is required in order to determine which CAs are trusted for any particular transaction. [EDIT: and in a sense, we are still trusting the Libyan domain admins.]
Whether one views the combination of CAs and TLD registrars that we have now as "defense in depth" or "more links in a chain" sort of depends on your threat model. Personally I'm more worried about identity thieves than oppressive governments, but others might have different concerns.
This may not offset the other problems you've identified.
With key-pinning and standard TLS, we get transparency, a consequence for CAs who are subverted, and an Internet trust system that remains formally decoupled from government control. Even if 95% of users don't use browsers that reliably enforce pins, the 5% that do constitute a multi- million- node CA-forgery detection system. One, by the way, that is probably already working today (CT also has some wins here).
With DNSSEC, we get the knowledge that a .LY domain probably has TLS keys controlled by Libya, and, if we're very savvy, the knowledge that .IO keys are controlled by GCHQ. We don't get consequences (you can't take .IO away from its owners, and Google simply isn't going to move from .COM, which is controlled by NSA), and we only get pinning's security with many more years of effort that haven't yet been sunk into DANE.
I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
Not "controlled by Lybia" of course, but "controlled the domain owner, as specified by the TLD", but you knew that already.
And not all ccTLDs are controlled by that country's authorities, they are normally delegated to other organizations which in some cases may not even be under their jurisdiction.
There's also no movement of control to "governments". The entity that controls the TLD has authority over DNS, today, and the one with authority over DNS are in full control over DLV TLS certificates, today. Any pinning and transparency checks would work unimpeded in a DNSSEC world.
DNSSEC just makes it much harder to improperly get an TLS certificate. Today you just need to annouce their AS for a while, or cache spoof any of the hundreds of CAs. No CA has ever been dropped for signing a certificate by the rules. The only reason we don't see that more is because it's apparently even easier to bribe or force a CA to give them out. NSA certainly doesn't need to attack anything to get certificates issued, today.
Any CCTLD that isn't today controlled by a government is one government action away from being controlled by that government; in practice, they won't even have to do that: they'll just use their authority to subvert the ostensibly- but- not- really independent operators.
I agree that governments control the DNS today.
The problem is that DNS does not in turn control Internet cryptography, and DNSSEC's primary use case is to change that.
> The problem is that DNS does not in turn control Internet cryptography,
That's a strange thing to say. DNS is pretty much the only thing that controls Internet cryptography. The number of non-domain validated certificates is vanishingly small.
If someone hijacks DNS to send Google.com requests to their own server, the browser will throw a TLS cert error, no? But if DNS and authentication are the same thing, then hijacked DNS would not throw an error anymore.
thats not the point OP was trying to make, the cert is issued via control of the domain, get control of the domain somehow, most any CA will happily issue you a cert for it.
I suppose that's easy bordering on trivial for an attacker of sufficient skill. At least it used to be. Is that no longer the case?
If there is a blacklist in place, absolutely each and every one of the hundreds of CAs need to adhere to it. One mistake or one exception and I could still get a misissued certificate just as easily as ten years ago.
Google can probably get it revoked very quickly, but we all know how well that works in practice. The only saving grace for the CA system is key pinning, and that's the only reason all those corrupt and/or incompentent CAs were exposed lately. But key pinning is not enough in itself. It is complementary to your certificate validation path(s).
> I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
I remain impressed that people who were at best ambivalent about the NSA and Snowden revelations, and other US Gov misdeeds, would use the fear of government control as their primary argument against DNSSEC.
Those folks are right about DNSSEC, of course. Their hemming and hawing about the NSA, Snowden, and the US government, I think history will judge harshly.
I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
Is this me? I was, and am still, quite concerned about many of Snowden's revelations. I'm not as concerned about "passive" NSA vuln research as e.g. EFF are, although active sabotage of standards and deployed infrastructure has got to stop. I don't intend in this thread to rationalize anything, only to find out more about DNSSEC. For instance, why couldn't DNSSEC be used in addition to other methods such as TLS and DNSCrypt? I appreciate your insight in this area, but it's not clear that DDOS amplification (which, if it could be avoided by anyone, could be avoided by CF with their long experience in packet dropping) is enough of an issue to prevent even trying something like this.
Exactly. And not to mention that we used elliptic curves (so the keys are shorter) and neutered ANY queries (so you can't aggregate records to generate a large DNS response). The net effect it using the CloudFlare DNSSEC implementation for DDoS gets you little to no amplification factor. And that's before the clever things we do around forcing TCP when we expect abuse, etc. Critcize us for many things, but for not thinking through how to mitigate the DDoS risk shouldn't be one of them.
There's one legitimate complaint here ("governments control TLDs"), and one observation masquerading as a complaint ("CloudFlare want more business"), against a background of really sloppy thinking. Let's pick it apart:
* 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.
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.
> 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!
> DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates.
That is just an implementation detail is it not? My understanding is that there is nothing stopping a user (or more likely, the suppler of the user's OS) from setting up a local DNS server which verifies DNSSEC records.
> its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
Those governments can already get fraudulent certs issued to them either by directly coercing a CA located within their jurisdiction, exploiting a vulnerability in one of the hundreds of CAs worldwide, or by temporarily falsifying the records of the target domain to trick an unsuspecting CA. The difference with DNSSEC+DANE is that governments can only impersonate domains under TLDs that they control. No longer can Iran impersonate google.com by hacking a Belgium CA.
I'm not going to defend all of the implementation details of DNSSEC. Suffice to say, mistakes were made, but the concept is sound.
(a) Users are actively discouraged against setting up full resolvers on their desktops, (b) browser vendors (at least at Apple, Mozilla, and Google) had experimental support for DNSSEC that has now been withdrawn, (c) if we get to stipulate that end-users will install additional security software of our choosing, we can do way better than DNSSEC!
So no, I don't concede that this is simply an "implementation detail".
Governments can't simply subvert CAs anymore, because of key pinning. If they do that, there's a very good chance they'll get caught, and when they get caught their CA gets restrictions imposed by the browser vendors, or removed altogether.
There are no meaningful consequences for the hard-to-detect forgeries DNSSEC enables NSA/GCHQ to make. Google can't simply restrict .COM, or switch to another domain. Google Mail just has to live with the security/privacy policies of all the TLDs it operates on, forever, with no recourse.
Hypotheticly, lets say an intelligence agency/whoever keeps hijacking domains and then getting CAs to issue certs for them.
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.
The problem of "asshole controls the TLD" is not solvable via ANY protocol. That dosen't mean DNSSEC is worthless, or handing over the keys of the internet to the government or miscellaneous hyperventilating.
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.
Sorry, that's simply not true. Assholes control TLDs today, and they do not get to easily bypass Gmail TLS.
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.
you can do exactly the same things to check DANE-validated connections as you can for tradition ca validated ones. So on that front its as least as good as the CA model. The real advantages of dnssec+dane are:
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.
I'm lost in your argument. Help me understand: if I'm reliant on key pinning and cert transparency, which exists for TLS CAs but not for DNSSEC, what exactly is DNSSEC doing for me? Why is it interesting that I only depend on one untrustworthy (and irrevocable) CA?
You might not want to carry that argument any further, since Verisign, which I presume you mean, is the single biggest CA today. They can sign anything.
They can not, however, subvert the root zone any more. Not since it was singed in 2010.
DNSSEC advocates fetishize the security of the root zone, but are conspicuously silent about the trustworthiness of the DNS domains that really matter: .COM, &c.
Since you replied to my comment, I just want to point out that I am not an "advocate" for DNSSEC, neither do I "fetishize" the security of anything.
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.
It is a bit tiresome to write in this thread, with constant insinuations like "those who control .com control every domain" and "key pinning hasn't been dependent on trust-on-first-use for ages", but which are never spelled out. I'm not sure there are any further insights to gain.
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?
In a thread about user privacy and government control, I asked you for an example of a domain whose TLD might have some influence over how secure it would be post-DNSSEC. You provided the domain of a government agency.
This thread is about the usefulness of DNSSEC. If you have another agenda than please be explicit about it so that we can have a fruitful conversation.
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?
Ofcourse Verisign controls .com. That was never in question.
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?
This is just one reason why I'd love to see the creation of many thousands more TLDs. The importance of ".com" was always a temporarily contrived contingent condition, a false scarcity perpetuated in the seeking of rent. The sooner that's over the better.
(Expecting users to read URIs was always a losing tactic, but surely everyone knows that now with IDNs.)
How is that relevant to DNSSEC? Key pinning works indepedently of how you validate your certificates (against public CAs, against DANE, or a combination of both).
Key pinning only works for players large enough to get pins in the client software itself. I can not do that, the best I have available is trust-on-first-use, which would carry a giant usability problem for the end user.
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.
That hasn't been true for ages, and, in fact, wasn't even true when you had to had to ask Google to add pins: many of the people that had pins were tiny.
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.
Ok so I'm searching trying to work out how to get the cert for my blog pinned in Chrome or Firefox so that readers of my blog can detect the NSA MITMing them even on the first visit, but I'm not finding anything.
My understanding is that HPKP can't protect you on the first visit to a site since the browser doesn't know anything about it before it connects to the site for the first time.
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?
All of TLS is already to some extent trust-on-first-use because of SSL-stripping.
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.
What do you think would happen under a DNSSEC-DANE TLS world if that started being detected via the same mechanism?
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"
Except this greatly weakens key pinning because now anyone that controls a CA cert can get you on first visit from a new browser/profile/cleared private data/device.
Key pinning is not a panacea either, it just makes browser/OS vendors another authority to be compromised and subverted.
While a healthy dose of cynicism is appropriate with-respect-to government control of TLDs, in the western world they are still at least nominally accountable to their constituents. Wholesale forgery is not likely to go over well with them, most importantly not with large tech companies. Targeted one-off forgeries would be easier to get away with, but they are also still perfectly doable today.
That's a hand-waving argument. It basically says there's not much point in being concerned about communications security because someone who owns up your endpoint can bypass it anyways.
Thankfully, the article you linked links to its sources... which don't back up the claims it makes. From the link it uses to say that DNSSEC doesn't help end users against spoofing:
"Although DNSSEC solves many of the security problems with DNS, it is not widely used because of the large cost of transitioning from DNS. However, where available, DNSSEC protects against the DNS attacks in Cafe Crack and should be used by Internet users."
Almost the exact OPPOSITE of the claim.
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
DNSSEC client support is much more widely deployed and activated on servers, but implementations exist for end-user OSes, and that hop of security is clearly the goal here. It's just that no consumer OS turns on support by default, because server-side deployment numbers are so low. And the packages that do exist are a royal PITA to install (in the OSX case) or configure (in the desktop Linux case). (Side note - still no DNSSEC for desktop Windows, according to my latest Google search.)
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
There is a difference between the way TCP/IP works when sites like HowStuffWorks describe it, and the way it works in the real world.
In the real world, when you type a site name into your browser bar, your browser invokes a stub resolver to send a DNS query to a DNS recursive cache server, which is virtually never running on your local machine.
So, however it's supposed to work in theory, in practice there is DNS traffic running between your machine and some server somewhere on the Internet (perhaps very far away on the Internet if you use OpenDNS or Google DNS), and DNSSEC does not protect those queries. They're flying around the network in plaintext protected only by a 16 bit plaintext query ID and somewhat less than 16 bits of entropy in source ports, if you're lucky.
I'm pretty sure I can speak reliably for what that article I linked to claims.
On most desktop Linuces I've dealt with, the "stub resolver" is dnsmasq, which is quite full-featured and DNSSEC-capable... except that distributions don't enable the feature or distribute a trust anchor. But there aren't any deep structural problems preventing them from flipping the switch [1] - not like, say, the deep coupling between layer 3 and layer 4 that killed SCTP and other TCP/UDP alternatives in practice.
[1] For example, this configuration change is all that's required to enable DNSSEC on Gentoo, and would probably also work on Ubuntu and Fedora: https://wiki.gentoo.org/wiki/Dnsmasq#DNSSEC
Linux is a test case. If you can get Linux to use DNSSEC without cooperation from intermediate routers and caches, then it's just single-organization engineering work - Apple and Microsoft would need to write DNSSEC-capable client implementations (which Microsoft already has for Windows Server) and deploy them. This is an OS feature like any other OS feature.
The obstacles to changing to IPv6, or to making any changes whatsoever to TCP, just aren't there.
Because it takes non-zero work, and doesn't add much value on top of SSL/TLS, which got wide deployment first.
As far as I understand, IPSec + DNSSEC gets similar security guarantees to SSL/TLS without identity certification, so once you have one there isn't any real economic incentive to put massive effort into developing the other.
Collectively thousands of words have been written on this topic within HN - and there are stark divisions between those who oppose DNSSEC and those who believe DNSSEC is a helpful and useful method of adding a layer of security to the Internet.
We don't agree. We won't agree.
Meanwhile, those of us who want to see DNSSEC more widely deployed applaud this move by CloudFlare because it both makes deployment simpler for many people and also advances the usage of stronger crypto (ECDSA) within DNSSEC.
SMTP email is simply. not. secure. If you need your messages to be protected from world governments, don't rely on SMTP for your security.
There's an argument that DNSSEC might make a marginal dent in protecting email from for-profit criminal enterprises. I don't believe it will, but let's stipulate that it does. It accomplishes that by setting up a new PKI whose roots are de jure controlled by the Five Eyes governments. How can that possibly be worth the gain?
I don't know about you, but I'd be VERY happy about a world where the established mail protocol (wether we like it or not) is not passively eavesdroppable (STARTTLS being enough here) and where active attacks are hard, noisy and provable (enter DNSSEC+DANE).
How would exactly have Tunisia stripped STARTTLS [0] if mail servers did DNSSEC+DANE to get pinned TLS certificates?
At least with respect to web security, even people in Tunisia can avoid Tunisian intercept just by not using Tunisian services. But virtually no one can avoid .COM.
DNSCrypt, which is far better and less costly than DNSSEC and does not cede to the US Government control over TLS keys, was proposed and deployed by a Cloudflare competitor. So, no.
> and does not cede to the US Government control over TLS keys
Hold on. This is actively conflating DNSSEC and DANE.
I know your point that the "main feature" of DNSSEC is enabling DANE, and I respect that. But the two domains are still distinct: DNS security and the PKI built on top of that.
DNSCrypt only addresses DNS security, so it should be compared to pure DNSSEC, which obviously does not "cede to the US Government control over TLS keys".
I don't agree with you. The top-down PKI DNSSEC expresses is inextricable from the DNS lookup security it attempts to provide. That DNSCrypt does a better job of solving lookup security without resorting to a government-controlled PKI is germane.
Filo: How do you feel about pushing for enabling DNSCrypt on your DNS servers, and working with the folks at Mozilla to make sure Firefox supports it? ;)
I don't understand your question. I'm asking if they can consider supporting it and help browser vendors (i.e. Firefox) support the client side of DNSCrypt.
Can you at least give me credit for not saying "EXTRA! EXTRA! INTERNET'S LARGEST DDOS PROTECTION SERVICE SUPPORTS DEPLOYMENT OF INTERNET'S WORST DDOS AMPLIFIER"? :)
AFAIK DNSCrypt (as the name suggests) encrypts transfer of DNS data between client & server whereas DNSSEC authenticates (to some level) the validity of DNS data, but does not encrypt it.
That's not entirely true. DNSCrypt also aims for end-to-end security. The real difference is that DNSSEC is a top-down protocol that doesn't work until every link between your browser and the DNS roots agree, and DNSCrypt is a bottom-up protocol that provides value even if just a few people use it.
OpenDNS isn't a competitor in any way. They provide recursive DNS, not authoritative DNS. CloudFlare provides authoritative DNS, not recursive. Simplistically: Their customers are web surfers, ours are websites. We've partnered with them on multiple initiatives, supported their technical work, and I consider David Ulevitch, their founder and CEO, a personal friend.
We are basically friends with OpenDNS. Complementary products, not competitors. Now that they are owned by Cisco, there is some competition (on premise network hardware vs. what CloudFlare offers), but that wouldn't prevent us from using a good open source tool they develop.
Yeah, but unless its something like Incapsula that functions as a direct replacement ... its not really competitive with Cloudflare's value proposition.
You don't use Cloudflare as a DNS provider. Their value proposition [imho] is as a CDN/WAF.
I was genuinely hoping someone like Sucuri or Incapsula had picked it up.
We don't provide split horizon DNS, that's correct. That is easily resolved for more orgs by running our own internal DNS if you need that.
http://www.datanyze.com/market-share/DNS/ claims we have 42% of the top 1M domains using our DNS. I'm not sure I actually believe that number, but a lot of people use us for their DNS.
Problem with DNSCrypt is that it also does not solve meaningful problem. Governments can subvert DNSCrypt in exactly same way as they can subvert DNSSEC. Additionally, DNSCrypt offers no way to verify that the returned RRs realy come from authoritative server and weren't modified (by another DNS server) in transit.
One additional feature that DNSCrypt has over DNSSEC is that it encrypts queries and responses and thus has some privacy value, on the other hand there probably is nothing privacy-sensitive in DNS queries and responses that will not get leaked by IP addresses and SNI anyway.
No. DNSCrypt doesn't set out, on day one, to thwart NSA's ability to hijack DNS records. DNSCrypt's day-one job is to prevent coffee-shop attackers from MITMing your stub resolver, a job DNSSEC is actually incapable of doing.
DNSSEC solves no meaningful problems on day 1. DNSCrypt solves one meaningful problem on day 1. Long term, if DNSCrypt is deployed widely, it will grow to solve more of the NSA problem, as end-to-end chains of DNSCrypt-protected DNS links are deployed connecting clients to authority servers. But over the long term, DNSSEC's problems don't get any better at all.
DNSSEC attempts to guarantee that domain names are resolved to correct IP addresses. However, DNS resolution is just one aspect of securely communicating on the internet. DNSSEC does not fully secure a domain:
- Once DNS resolution is complete, DNSSEC does not ensure the confidentiality or integrity of communication between a client and the destination IP.
- No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability.
HTTPS guarantees the confidentiality and integrity of communication between client and server, and web browsers have rigorous and evolving HTTPS enforcement policies."
"Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if you can't trust your registrar, then get a new registrar.
DNSSec doesn't prevent MITM attacks. It absolutely prevents DNS spoofing. But there are other ways of inserting yourself into a traffic flow than just DNS spoofing."
^"No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability"
-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.
With a non-validating stub resolver you'll have no idea if DNSSEC is being used at all, much less if DNSSEC fails and it falls back to plain DNS. And most OSes up to this point use non-validating stub resolvers.
From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS.
I just pulled up http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked!
If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.
On a [EDIT:] 2.5yo chromebook and on a moto e (total value, new, unsubsidized, of both devices: $250) that site doesn't load, with "ERR_NAME_NOT_RESOLVED". You can't hold dnssec responsible for your choice of broke-ass old-n-busted clients. What other security system would be held to that standard?
I'm using Android 5.0 and Windows 7. If those are broke-ass old-n-busted clients, screw modern technology.
Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.
Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved.
Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working.
So it only works reliably when it's broken. What a fantastic security system.
None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.
Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.
Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.
> At this point we should choose our own recursive DNS provider
Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures.
If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.
DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates.
I have heard that both CeroWRT and OpenWRT support DNSSEC validation. There's also DNSSEC-trigger with Unbound for local DNSSEC validation. Maybe someone on here knows more, but I believe this directly addresses this issue. DNSSEC also is completely orthogonal to things like dprive which encrypt DNS queries. I'm not that familiar with DNSCurve but I believe it functions similar to dprive.
its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
I think you're referring to DANE, and DANE is not intended to replace the CA system, but instead augment it. See my article on this here: http://metafarce.com/adventures-in-dane/. DANE simply provides another means to verify the authenticty of a TLS cert, it doesn't replace the CA system, and having multiple methods for ensuring cert integrity is a net positive for the Internet.
The foundations of our CA system are not sound. Any compromised CA threatens sites secured by all CAs. In addition to specifying a hash of a site's TLS cert, DANE allows a site operator to lock down their trust anchor to the single CA they use.
I also don't get the signing Internet cryptographic trust over to the world governments thing. Please explain how you reach this conclusion. I've deployed DANE on a .com, and I never gave any private keys to anyone. I only needed to provide a hash of my TLS cert to my DNS provider. Granted my DNS provider could change the hash to something else, or redirect my site to somewhere else. Also, the TLD operator for .com could redirect my NS records to somewhere else as well, and then sign it with the TLD's ZSK. But they can already do that without DNSSEC, and I would notice this pretty quickly and attribute the attack to them.
the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast.
This is where I will agree with you. DNSSEC is tough and complicated to deploy. However, this does not mean it has no value. If companies like Cloudflare make it easier to deploy DNSSEC then that is a net win for Internet security.
DNSSEC isn't about helping you with your security issues.
I really like being able to trust what DNS servers tell me. That's an immediate benefit to me and my security.
"its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs."
Exactly! A rare time when we couldn't agree more. I've taken shit on various forums when saying something similar but it's quite obvious when you look at its structure and where the trust is.
EDIT to Add: I'm bookmarking your writeup on DNSSEC. Great summary of the issues. :)
"DNSSEC isn't about helping you with your security issues."
My understatnding of history as I experienced it is that the resurgence of interest in DNSSEC was due to publicized cache poisoning of shared DNS caches circa 2008.
I run my own local cache on the loopback. I run my own root and other zones. I also use DNSCurve.
Recently there was another one of these DNSSEC advertisement posts from this same company about DNSSEC on the HN front page. (Surprise. How unusual.)
I asked a simple question: What benefit would DNSSEC offer someone like me?
While I did not get any straight answers, I did get blasted with walls of text from some guy working for a domain name registrar.
Perhaps it is not only companies selling consulting and DNS appliances, e.g., on government contracts, that are behind DNSSEC. Maybe it extends to the entire "DNS industry", e.g., people "selling" (renting) domainnames to users. For readers who are unaware, Cloudflare is in this "DNS industry". Their customers must hand over control of their DNS to Cloudflare. Cloudflare's entire approach to "security" depends on this.
DNSSEC is generally a PITA to set up and maintain. This makes it the perfect "service" to sell. If you like to generalize, you could argue this is true for any sufficiently complex networking component. The more complex the set up and management for users, the easier it is to sell them services.
I am an ordinary user who happens to enjoy setting up and managing my own DNS, making databases of IP addresses and even making my own domainnames, so I need a lot of convincing to be interested in something like DNSSEC, managed by third parties.
DNSSEC, as advertised, is a system that focuses on some mythical "validation" of DNS data.
Who decides what DNS data is "valid"?
Does DNSSEC require a "web of trust" model like the CA system?
If yes, why should we trust these third parties more than the endpoint we're trying to reach?
How much will users have to pay to be "validated" in such a system?
If some third party(s) controls what is and what is not "valid" DNS data can they more easily "disable" certain domains?
I could go on.
By contrast, a system for encrypting DNS packets is something I find more interesting and useful. I can set it up without too much effort and I control it. No need for third parties. Once more, it costs me nothing. There is no built-in idea of "web of trust" and I do not need to "purchase" a "valid" dommainname to begin using it.
But I am just a dumb user so what do I know? Go get your DNSSEC, right away.
* The server/nameserver must have DNSSEC configured properly
(CloudFlare have solved this for their customers)
* Your client's DNS resolving server must support DNSSEC properly
(which they might not, depends on the user's network)
* Your client's stub resolver must verify all DNSSEC records
(most do not currently)
If any of the above fail, you will not have any indication whatsoever and you will be using regular DNS.
The only time that a user will ever know if DNSSEC is working (for them) is if the server/nameserver are configured correctly, your client's dns resolver supports DNSSEC, your client's stub resolver verifies requests, and then the user tries to look up a known-invalid domain and it gives them a resolving error. Otherwise, they will never know if DNSSEC is in use.
Oh, and you can still MITM the data connection between the client and server even if DNSSEC works.
DNS is often the weakest link in the chain and well worth hardening if you're doing proactive sec. Combined with DNSCrypt it can be a pretty robust setup. My only problem with DNS hardening is zero-knowledge problems. See https://en.wikipedia.org/wiki/Zero-knowledge_proof It is possible to encrypt DNS queries, but tricky for end points to deny knowledge of having requested it, and so we have zero-knowledge proof issues.
This is great news for those of us who want to see DNSSEC more widely deployed for three reasons:
1. CloudFlare already hosts the DNS for millions of domains. This is now making it VERY easy for those who use CloudFlare to sign their domains with DNSSEC.
2. Because of the competition within the DNS hosting / operator space, this move by CloudFlare will hopefully motivate the other large DNS operators to simplify their own user experience for DNSSEC.
3. For those of us who want to see stronger crypto within DNSSEC, this move by CloudFlare advances the use of an elliptic curve algorithm. Yes, ECDSA has its issues, but by getting it out there: a) it gets people looking at EC algorithms; and b) it gets software providers realizing they need to have their user interfaces adaptable to incorporate more DNSSEC algorithms. (I.e. to realize the list is NOT fixed and will grow over time.)
This draft needs to be approved through the IETF working groups - and then deployed on both the signing and validation sides of DNSSEC. This will take quite some time and so we need to start as soon as we can.
Comcast published TLSA records the other day. So when people like myself who have enabled TLSA in Postfix send email to Comcast users, the SMTP connection is guaranteed to be both encrypted, and the SSL cert validated.
I am not sure if Clouflare would advocate this use case, but quick DNS is actually a crucial part of a quick loading site, and it is surprisingly hard to get reasonably priced high performance DNS. I have been using Cloudflare just for DNS for my hobby site and it has been working great.
No, it doesn't. DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates. DNSSEC is far less valuable than its proponents would like you to believe, and it comes at a significant cost to Internet trust: its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
It's understandable that Cloudflare would jump on DNSSEC: the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast. DNSSEC is an opportunity for a company like Cloudflare to make the case that they should manage your infrastructure, not you; the more features like DNSSEC Cloudflare can find, the more market share they'll acquire.
But make no mistake: DNSSEC isn't about helping you with your security issues.
Obligatory: http://sockpuppet.org/blog/2015/01/15/against-dnssec/