
OpenDNS launches DNSCrypt: secure DNS - kjw
http://www.opendns.com/technology/dnscrypt/
======
trotsky
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.

~~~
tptacek
Confidentiality isn't the killer feature/flaw here; integrity is.

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)

~~~
FaceKicker
> 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.

I'm sure I'm missing something here.

~~~
tptacek
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.

~~~
FaceKicker
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?

~~~
tptacek
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".

~~~
mike-cardwell

      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:

    
    
      gpg --auto-key-locate pka -ear mike.cardwell@example.com
    

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.

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.

------
sudonim
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?

------
peterwwillis
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.

~~~
piotrSikora
So you're saying that unencrypted DNS traffic is more secure than DNS traffic
encrypted using questionable algorithms?

~~~
peterwwillis
You have a weird way of reading. I don't see where I said that. Can you quote
it for me?

~~~
SoftwareMaven
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."

~~~
peterwwillis
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.

------
aidenn0
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.

~~~
tptacek
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.

~~~
aidenn0
"The day 1 benefit of having a secure channel between browsers and resolver
servers probably addresses 60% of the DNS security problem in reality"

Don't most users use their ISP's DNS servers, making hijacking between the
browser and resolvers nearly impossible?

~~~
tptacek
No, because the existing standard DNS protocol is terribly insecure.

Also, because it's insecure, you can't productively opt on to a more secure
provider.

------
sp332
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.

~~~
JoshTriplett
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.)

------
dsl
It also has the option to tunnel your DNS over TCP/443, avoiding all the dumb
things wifi hotspots try to do with your DNS.

~~~
tptacek
If you're going to run DNS over TLS, you probably don't need DNSCurve anymore.

~~~
dsl
It's not TLS.

~~~
tptacek
It should be!

~~~
SoftwareMaven
(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)?

~~~
tptacek
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.

~~~
makomk
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.

~~~
tptacek
Last objection first:

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.

------
ecaron
While the blog only links to the Mac client, they do have a DNSCrypt proxy
that appears fairly complete and should be a good compliment to any *nix
system: <http://shared.opendns.com/dnscrypt/packages/dnscrypt-proxy/>

------
pclark
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.)

~~~
dsl
Check the "DNSCrypt over TCP" box and see if it starts working. If so,
something on your network is intercepting DNS queries.

------
MikeCapone
What kind of performance hit would this give, if any?

~~~
dkokelley
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.

------
webwanderings
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?

~~~
e1ven
They're really unrelated.

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.

~~~
mkup
_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)

~~~
marshray
Or perform MitM on the raw IP packets without modifying the IP addresses at
all. (Like your ISP or any other router along the path.)

