OpenDNS launches DNSCrypt: secure DNS
opendns.com
opendns.com
It seems OpenDNS is interested in this technology only as far as it deflects from people being interested in DNSSEC, an ietf standard. Why don't they care for DNSSEC? Because it either discourages or prevents DNS poisoning or hijacking (depending on how you set up your client) and Open's business model relies on hijacking NXDOMAIN DNS responses to serve ad filled pages.
DNSSEC is a design-by-committee debacle. It's a good thing to have options here.
I'm a broken record on DNSSEC on HN; a decent starting point might be:
http://news.ycombinator.com/item?id=2078488 (Goals of DNSSEC v. DNSCurve)
http://news.ycombinator.com/item?id=1523704 (Bunch of things I think are wrong with DNSSEC)
I initially posted "Authentication, too" in response to this, but then I reread the page and it says it doesn't provide authentication.
...in which case, I don't really understand this at all. What good is integrity if there's no authentication? Doesn't that mean an active network attacker can completely swap out the DNS response for a different one, but just can't modify it (short of creating a brand new one)? If that's the case, it seems completely useless. It claims to protect against man-in-the-middle attacks, but I don't understand how that's possible if there's no authentication.
I'm sure I'm missing something here.
You can't MITM a DNSCurve request, because it's encrypted and signed using a pair of static keys.
DNSCurve doesn't specify a key management scheme, but to the extent you want to call a bunch of web pages on Bernstein's site a "spec", it specifies "static keys". Static keys are a perfectly viable trust anchor scheme; like they say about routing, "if you can get away with it, the best protocol is static".
The trust anchor scheme SSH uses is "key continuity"
If you have a resolver which supports DNSSEC, you can run this command:
ssh -o "VerifyHostKeyDNS yes" grepular.com
There is also "VerifyHostKeyDNS ask", which just displays the result of the lookup, but still allows you to confirm the fingerprint.
DNSSEC allows you to do stuff like this because it secures the integrity of the record all the way from the authoratitive DNS server to the users resolver.
There's also DANE (still going through the standards process) which allows you to publish a fingerprint of your SSL certificate on a domain/port basis, in DNSSEC secured DNS. If you install a Firefox addon named "Extended DNSSEC Validator", visit https://grepular.com/ and click the lock button to the left of the address bar, you will notice it says:
"Domainname is secured by DNSSEC and the certificate is validated by CA and DNSSEC"
Another benefit that DNSSEC brings is with PKA records. I publish a record in the DNS which contains a URL to my public PGP key, and its fingerprint. You can automatically download my key and encrypt something using it by typing:
gpg --auto-key-locate pka -ear mike.cardwell@example.com
Of course, somebody could compromise my DNS server or the end users resolver. I'm not claiming that DNSSEC is a perfect solution. All I'm saying, is that the integrity that it provides to DNS lookups is massively valuable.
By the way, I wrote a long article about setting up DNSSEC on Monday: https://grepular.com/Understanding_DNSSEC
[edit] I forgot to mention the "Certificate Stapling" functionality built into Chrome now. https://dnssec.imperialviolet.org/ uses a self signed certificate, but Chrome users wont get any notification about that because of the tech described here: http://www.imperialviolet.org/2011/06/16/dnssecchrome.html
[edit2] Another benefit I forgot to mention. I use third party DNS slaves for redundancy. Because I'm using DNSSEC, those third parties can't serve up different records to the ones I configured, either on purpose or because they've been compromised. Well, they could, but DNSSEC supporting resolvers would just SERVFAIL the modified responses.
"standards are great everyone should have some" snark aside, I guess it's nice to see someone really stepping forward and giving a crap about cryptographic authentication of DNS? the DNSSEC people don't seem to care that much and are perfectly willing to move at glacial speeds on implementation ...
* failed architecturally twice before reaching its current state (it is being, as Richard Stallman would put it, debugged into existence)
* required signin from multiple huge corporations to begin deployment, so much so that some (well known) DNSSEC proponents have unironically proposed alternate privately run roots just to get things kickstarted
* requires the maximum amount of re-education from DNS operators everywhere, being as it is a standard that imposes even greater levels of config complexity than HTTPS/TLS, but on a DNS record by DNS record basis
* is effectively a no-op in the current DNS architecture, where your desktop doesn't run a bona fide cache but instead delegates that task to a cache server (the thing you call a "DNS Server" in your Internet configuration, but which on reflection turns out to be something no Internet host actually needs if they're willing to run their own cache) --- because it only protects server-to-server traffic, and architecturally can't protect stub-to-server traffic.
* Will require upgrades to every "sockets"-style program ever written to properly function.
If a magic wand existed that could dispel any of these issues, I assure you that the IETF working group would wave that wand right away.
It improves my security and privacy without any cost I can perceive. So why not.
Considering it took me a while to understand the value to me, I wonder if it can be packaged in such a way to get broader adoption from the public. Will you have to bundle it with McAfee Internet Security for Mom & Pop to end up using it?
edit I didn't notice libnacl is provided, so I assume a good chunk of the crypto work is done by this. My comments were probably too harsh. But I would still like to see a professional look over the rest of their code to make sure there's no glaring problems.
Luckily, the library they're using (NaCl) is part of a project led by djb, thus we can assume it's going to be competently written and reviewed by him. I hadn't seen this so this makes me feel better about the crypto part of their project.
That would be the "don't bother encrypting that which is not authenticated"? ISTR a free DNS resolver company (I think it was OpenDNS) doing a MitM on my friend's Google searches when he used them.
Or are you just against anyone deploying new crypto protocols?
And tptacek's corollary: "If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong" http://chargen.matasano.com/chargen/2009/7/22/if-youre-typin...
I bet every cryptographer in the world, other than Bruce Schneier and Ron Rivest, hears that all the damn time.
No wonder so few of them ever release any code.
But if you don't see the difference between inventing a new cryptographic hash function to improve on SHA-2 and what OpenDNS is doing with DNS then you ought not pass judgment on everyone who attempts to add some useful security where there is none at all now.
But looking at the DNSCrypt code on github, there's no indication of who actually wrote it. It has no attribution, no source code comments. Haven't found a protocol document either.
The author(s) were certainly meticulous though. The #includes are categorized according to their standardization origin (posix, C, internal) and alphabetized within those categories.
And you may be right about (DJB circa 2011) developing a new secure hash function more reliably than a new protocol if you take away the requirement that it also perform significantly better than SHA-2.
The crypto under the hood is Curve25519. http://cr.yp.to/ecdh.html I haven't looked at the source, but the most likely library for them to use (curve25519-donna) was written by the guy who does crypto for Chrome.
Since DNSCrypt relies on a proxy written in C, you'd want that reviewed, and can hope for a "looks clean" from the usual vulnerability research suspects. But you should understand that the people who submit Metasploit modules and the people who do real cryptosystem review are for the most part disjoint sets.
However, since you won't touch OpenDNS' encrypted DNS, the only logical reason for that is you feel unreviewed, encrypted DNS is more risky than the current unencrypted DNS.
† That assumption is where things may break down, of course. If you are already using DNSSec, then the reading becomes "I trust DNSSec more than OpenDNS' unreviewed client."
Then again, DNSCurve does not seems to be bad at all. In fact, it seems rather good.
This is really only an improvement for open wifi, but then you can MITM the IP without having to hijack DNS.
On day one, it protects the desktops that opt into deployments provided by servers that opt into it.
But unlike with DNSSEC, which retains the DNS' architectural distinction between the stub resolver in your browser or OS and the cache server at your ISP, the same security protocol that secures the "last mile" with DNSCurve is also workable between servers. Most notably, deploying that secure option does not require the server to change its database.
The day 1 benefit of having a secure channel between browsers and resolver servers probably addresses 60% of the DNS security problem in reality --- that's not a small win, it's an immense win. But even in the long run, DNSCurve is a more workable path to secure name resolution than DNSSEC.
Don't most users use their ISP's DNS servers, making hijacking between the browser and resolvers nearly impossible?
Also, because it's insecure, you can't productively opt on to a more secure provider.
The advantage of DNSCurve over DNSSEC isn't really the ECC (DNSCurve's ECC is better than DNSSEC's crypto by a mile, but neither DNSSEC nor DNSCurve have known practical crypto attacks).
The advantage of DNSCurve is that its security model is much more realistic. Instead of trying to make every DNS record a secure document that can be verified in isolation, DNSCurve simply ensures that your browser can make a secure request do a DNS server somewhere (and, by implication, that the DNS server can itself make secure requests to other DNS servers, and on and on incrementally until the whole DNS is secure).
Think of it this way:
DNSSEC is what web security would be if it worked by signing web pages.
DNSCurve works roughly the way web security works now, with a drastically streamlined and (probably) improved crypto protocol.
The other downside is that I don't think there's any way to securely implement the second stage of that process where your DNS server makes secure requests to other DNS servers, because the root name servers don't support DNSCurve and are unlikely to for the foreseeable future.
The same chicken-egg problem is even more deeply embedded into DNSSEC, where, in order to provide any security, every DNS record you care about requires administrative intervention to upgrade to DNSSEC. DNSCurve is far easier for service providers to adopt than DNSSEC; its security model holds even if you just have it proxy to BIND.
Meanwhile, I think "trusting your upstream nameserver" is a bit of a red herring. The DNS security greybeard cabal absolutely does have stories to tell about poisoned servers, but the on-the-ground reality of DNS security attacks today isn't about compromised authority servers --- or, when it is, it's about attacks on authorities that no security protocol was ever going to address.
Candidly, I don't believe securing the DNS is really a goal worthy of a lot of effort. The HTTPS/TLS CA model as implemented today is broken, but we're a peer-to-peer validation scheme away from fixing that. Given the choice between DNSCurve and DNSSEC, the one that costs the least to implement (DNSCurve, by miles and miles) is a no-brainer; the fact that it actually does something on day one is just icing on the cake.
It works fine when I have the "use OpenDNS servers" box checked, but the moment I click the "use encrypted OpenDNS severs" box my internet connection doesn't resolve anything.
I tried to send them feedback but the form doesn't appear to submit. (Hardly reassuring.)
Also, you only need to "refresh" as often as your local machine's DNS cache clears.
Tor proxies your traffic through several random machines on the internet, so by the time it gets to the destination, no one knows who sent it.
This captures and relays your DNS queries to OpenDNS in a new way.
DNS queries are used to translate a site's name ( facebook.com ) into it's internet address - 123.456.789.
OpenDNS has run a service which did the translation for a long time, but when you ask them to translate, it passes through your ISP, so your ISP could, in theory, see what domain name you were asking about.
This has a way of encrypting the request, so that OpenDNS can answer the translation, without anyone but you being able to see what you asked for.
and without anyone being able to replace IP address of facebook.com with IP address of some MitM server (in the ISP network, for example)