Why bother securing your DNS from eavesdropping when an eavesdropper can easily tell what sites you're visiting based on your other IP traffic?
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.
> Confidentiality isn't the killer feature/flaw here; integrity is.
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.
DNSCrypt is a DNSCurve implementation. DNSCurve is manually keyed; "the administrator publishes the server's public key along with the server's address", which is effectively shorthand for "static keying is left as an exercise for the reader".
You can't MITM a DNSCurve request, because it's encrypted and signed using a pair of static keys.
Signed using a pair of static keys? So...it is authenticated then? Or are they more like SSH keys/self-signed certs where you just trust the key belongs to who you think you're talking to the first time?
SSH is an authenticated protocol. The trust anchor scheme SSH uses is "key continuity". The same model has been proposed as a replacement for TLS CA certs.
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"
There is also RFC4255 which allows people to publish fingerprints of their SSH server public key in DNSSEC secured "SSHFP" RRs.
If you have a resolver which supports DNSSEC, you can run this command:
ssh -o "VerifyHostKeyDNS yes" grepular.com
You wont be prompted to verify the fingerprint as usual, because OpenSSH will already have done that verification using the DNS. You also know for sure that grepular.com has resolved to the correct IP address.
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"
This is because I'm following the latest draft of the DANE protocol. Will be nice when the spec is finalised and browser support becomes native. I don't like that any CA can currently generate a cert for my domain.
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:
Replacing "example.com" with "grepular.com". Because I also have DNSSEC set up on my domain, if you have a DNSSEC supporting resolver, you know that the fingerprint you've received hasn't been tampered with on the way.
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.
[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.
You're not thinking this through; there has to be a trust anchor somewhere, be it a config file with a known-good server key, or a CA signature, or a "this is the first time I've seen this pubkey, accept it forever?" dialog.
In your protocol, any server can read that message and encrypt a valid-looking response.
Oops. I deleted my response because I saw you replied and addressed the authentication issue. Apparently I wasn't fast enough. :)
The trust anchor is the --provider-key command line parameter. Any server that has the corresponding private key can encrypt a valid response. (and to be clear, its not my protocol.)
the only thing better than one way to authenticate DNS queries is N ways to authenticate DNS queries!
"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 ...
That's not a fair summary of what's happening at all. DNSSEC advocates would certainly like to accelerate DNSSEC adoption. Unfortunately, they've fallen into a design that:
* 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.
I've been using DNSCrypt over the past few weeks as a beta tester. I'm pleased that it doesn't have any noticeable decrease in speed while browsing the web.
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?
So a vendor/service provider makes a custom proxy for DNS record encryption and breaks the first rule of cryptography. Granted, they're basing it on DNSCurve so at least a few other people have looked at the design, but the implementation is custom... I wouldn't touch this with a 50 foot pole until a dozen PhDs vet 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.
Try reading the description of the crypto, it might make you feel better: http://dnscurve.org/crypto.html Basically it follows NSA recommendations for public-key crypto and uses an algorithm developed by Daniel J. Bernstein which adds even more guarantees. So it's not like they're starting from scratch here.
The problem isn't whether or not they're using a strong crypto algorithm as much as who implemented it and whether there was intense peer-review or not. Anybody can try to implement an algorithm, but most will probably screw something up, which is [one part of] why the first rule of cryptography is: don't do your own cryptography.
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.
You are confused. They didn't invent a new cryptographic system, just implemented it. Just in the same way Internet Explorer didn't invent SSL, they just dropped in a library.
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.
Thanks for pointing this out, I didn't see NaCl and who it was written by; I thought maybe they wrote their own version of Curve25519. I'm still wary of the implementation until an expert looks over it, though.
Just so you know, there are very, very few experts competent to evaluate the DNSCurve cryptosystem.
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.
Yes, this is part of why I reacted the way I did. I'm looking for an 'expert' to review it, not an average infosec nerd who groks C. I just wish my friends who did crypto knew how to program =(
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?
They hear it because it's really, really hard to do good crypto. As a rather impressive example, nearly all of the submissions to the NIST's SHA-3 hash competition have holes in them. https://ehash.iaik.tugraz.at/wiki/The_SHA-3_Zoo These are big names and serious, multi-year projects, and they still fail. Bruce Schneier's "skein" hash is one of the few that haven't been cracked (yet).
Yes, and Rivest's MD-6 dropped out at the first round and DJ Bernstein's (HINT HINT) CubeHash algorithm on the second round of the SHA-3 competition.
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.
Actually, Daniel Bernstein is far more likely to come up with a new secure hash core that withstands real world attacks than anyone is to come up with a new crypto protocol that will survive adversaries. TLS had the best peer review any publicly known crypto system ever got, and it's been a litany of failures.
But this DNSCrypt proposal is specifically claiming to be a "slight variation" on DJB's DNSCurve protocol and curve25519. It uses his NaCl library for implementation too.
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.
I'm not actually sticking up for DNSCrypt; they reached out to me awhile ago but I kind of stiffed them for review time --- it's been an especially busy month.
Yeah. I'm not one thing or another on it yet either. It's just kind of like a spaceship lands from planet OpenDNS and a CDROM rolled out containing the source for a new OpenBSD daemon (without the horns).
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.
In general, unencrypted traffic of any kind can have advantages over badly encrypted traffic: at least you know the unencrypted traffic has no security, and you can treat it accordingly. Badly encrypted traffic gives a false sense of security.
It's actually a pretty reasonable way to read it (it's the way I read it as well). You are obviously using DNS now, and since almost all DNS traffic today is unencrypted, it is a reason assumption to believe your traffic is currently unencrypted†.
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."
This 'logical conclusion' assumes I would make a comparison between two completely different use cases: wanting to encrypt my dns traffic and not wanting to encrypt my dns traffic. Saying one is better than the other is stupid because they're completely different things.
Do they really claim that the last-mile is the most insecure part of DNS? They specifically mention the kaminsky attack, which was best used against DNS servers, not individual PCs.
This is really only an improvement for open wifi, but then you can MITM the IP without having to hijack DNS.
DNSCurve is a proposal for a solution to cache poisoning (which is a problem that dates back to the mid-90's) that admits to incremental deployment.
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.
I think this could actually break a few things. For example, Netgear routers intercept DNS requests for routerlogin.net and return their own internal admin IP. It's a very useful feature, and it works no matter what DNS service you use.
That shouldn't work, and breaking it represents a useful feature. Use a sensible local DNS root, not a well-known one like .net. (Does some standard reserved namespace exist for the local network, instead of the various non-standard ones like .home or .lan? RFC2606 only reserves .invalid, .test, .example, and .localhost, none of which work for this purpose.)
(Serious questions) What benefit does TLS provide over the elliptical-curve cryptography it uses? Would it be possible for somebody to filter the DNS queries by identifying the use of elliptical-curve cryptography instead of TLS (obviously they couldn't read them, but could they stop them)?
None. The advantage to DNSCurve is that it's optimized for the DNS service model (it's tighter and faster). The advantage to TLS is that you already have it.
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.
Of course, the downside of DNSCurve is that you have to trust your upstream name server completely because they have the ability to arbitrarily tamper with the responses they send. This is quite convenient for OpenDNS - they do things like redirecting requests for non-existent domains to search pages with ads that make them money.
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.
I installed this on Mac 10.7.2, previously using Google DNS.
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.)
I doubt much, if any. While DNS requests are relatively light, there may be several requests that need to resolve for a single page request. The crypto DNSCrypt looks to be using will use public keys to share a symmetric key, so after the first transaction both sides will have a symmetric key. Symmetric key encryption and decryption should be imperceptibly fast.
Also, you only need to "refresh" as often as your local machine's DNS cache clears.
Whoaa...I am not very technical, but the first question that comes to mind is, what would be a difference between this and what Tor attempts to accomplish?
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.
My ISP can see which IP addresses I connect to and can perform a reverse lookup. I don't think the privacy angle has any value. I suppose a shared host could serve multiple sites, but then simple packet snooping would reveal which hostname I am requesting.
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.