Whither DNSCurve?

At the risk of having this blog begin to read like a FAQ, let me begin once again with the words, "folks have been asking me...".  So:

Folks have been asking me, what is DNSCurve and what's ISC's position on it given our long involvement in DNSSEC?  This is a reasonable thing to wonder about since both DNSSEC and DNSCurve concern themselves with the security of DNS.  However, they solve different problems, in spite of the similarity of their names.  In this article I'll try to explain what these technologies do and answer the question, "why would I want either one?"

DNSSEC is an Internet Standard meaning that it came from IETF, took years longer than it should have, was designed by committee, has some features that almost nobody now remembers the reason for, and lacks some features that almost everybody wishes it had.  So, it's a lot like IPv6 or IPSEC or anything else that's been through the standards process.  And yet, it works.

The problem statement for DNSSEC was: "how can we protect DNS content from third party modification?"  The first parties in this case are the the zone administrator who produces the primary zone content and the ultimate end user or application who consumes that content.  Third parties include Dan Kaminsky or anyone else who might bombard a client with spoofed replies attempting to guess transaction ID's and port numbers; secondary name server operators or hackers who break into those systems; recursive name server operators who may want to rewrite www.google.com to their own search page or to rewrite negative responses to point to their own advertising servers; firewall and IDS operators who might want to rewrite all answers containing profanity or pornography or other illicit content to point at a walled garden.  From DNSSEC's point of view, only the zone administrator should be able to produce content within the namespace of a zone. There are no exceptions.

The solution statement from DNSSEC is therefore: "add data authenticity as a function of the domain name system."

For DNSCurve, the problem statement is different so is its proposed solution. DNSCurve protects the channel between an authority nameserver (so, a primary or secondary nameserver for some zone) and the recursive nameserver.  This is the same channel that's protected by UDP port number randomization, and the only attack it protects against is Dan Kaminsky's spoofed flood attack. Noteworthy here is that DNSCurve was invented by the same person who invented UDP source port randomization -- Dan Bernstein.  DNSCurve also uses different math than DNSSEC, something called "elliptic curve cryptography" which is really interesting since the keys and signatures are so much smaller than those used in DNSSEC.  Bernstein has developed Curve25519 which is very fast. We'll need real crypto math people (of whom I am not one) to be Bernstein's second set of eyes on this but I'm betting that Curve25519 will turn out to be as good as it looks.

DNSCurve's solution statement is therefore: "let's do an even better job of protecting recursive nameservers against Dan Kaminsky, by using strong crypto rather than just random transaction ID's and random UDP port numbers."

ISC's Position

For myself, I remain puzzled by the existence of DNSCurve, because it solves a problem that I'm not having any more -- UDP source port randomization is good enough to take the Dan Kaminsky spoofed-flood class of attack completely off the table.  I'm also puzzled because DNSCurve completely fails to address problems I am still having, such as that a secondary nameserver might be hacked, or a recursive nameserver operator might redirect me to their search page instead of Google's or might redirect me to their advertising server rather than giving me correct negative answers, and a nation-state might redirect me to their walled garden if they think I'm trying to access something they don't want me to access.

I want provably correct DNS content to be universally available.  Not just for me but for the entire population of the Internet.  I want to stamp out all forms of DNS intermediation whether by recursive nameserver operators or nation-states or hackers.  Because DNSSEC can do this, ISC has invested a lot of time and money over the last dozen years helping to develop DNSSEC. Because DNSCurve does not do this, and because the problems DNSCurve actually does solve are pretty well solved by UDP source port randomization and will be entirely eradicated by DNSSEC, ISC is not investing in DNSCurve at all.

References:

DNSCurve Official Site

IETF Draft of DNSCurve

Share this

Comments

As far as I understand it, prof. Bernstein recommends everyone having their own cache and talk to primary secondary servers directly. This makes some sense from security point of view as it (together with DNSCurve) reduces the threat of non-authoritative answers which threat to me inherent to current DNS structure with public caches. Of course this might inflict load problems on these servers. From security perspective they are men-in-the-middle. I am also not sure about logical ability to provide authoritative NXDOMAIN answer. It seems as hard proverbial proof of "not being a camel". But I am not going to argue on these since I am not a security expert nor I have read all DNSSEC RFCs.

However, you have forgotten to mention that DNSCurve provides confidentiality which feature DNSSEC lacks.

Maybe ISC could at least consider using Curve25519 instead of RSA? Assuming it is secure, it is also much more efficient both size- and CPU-load-wise.

thanks for your feedback. you're right that the query name is crypted, but since it may already have been exposed in cleartext while following the delegation chain down from the root zone to the dnscurve zone, i don't think this is an important difference in feature levels. there's no way to truly and effectively hide the query names, since dns is an open system.

i share your confusion as to why public caching servers are even used. i just don't understand the success of google's opendns clone, nor the success of opendns itself, nor the reason why people use their ISP's recursives, ever.
recursive dns is just not that hard to do correctly, and takes very little resource. maybe ISC should provide a downloadable precompiled BIND for windows and mac that just does recursive dns (with validation) and blocks all attempts by dhcp to override "127.0.0.1" as the resolver address.

if bernstein's Curve25519 passes muster with the crypto community, then i'd expect IETF to adopt it as a crypto alg for DNSSEC, and to recommend it over RSA or SHA, for just the reasons you give. but that's a longish road. we don't love RSA or SHA -- none of us -- but they've had their tyres kicked pretty hard and pretty often by folks who really know crypto. Curve25519 needs the same before IETF would adopt it for DNSSEC, and ISC would need IETF to adopt it before we'd implement it.

Three remarks:

a) Importance of denial-of-existence

The root server operators report >95% of queries reaching the root are for non-existing domains. Most of these are a direct result of non-use of fully qualified domain names in small networks.

b) location of DNS functions

I'm also a proponent of performing important parts of DNS resolution "near the edges". DNSSEC has the nice property that you can do _verification_ on the stub resolver and/or the gateway to the public Internet (e.g. BB Access Router) while still making heavy use of installed recursive caching resolvers. Thus you don't have to fight ISPs that insist on you to use their resolvers, but you can verify that they operate faithfully, and you have the performance benefit of large caches.

c) crypto stuff

ECC isn't that new any more. In a recent Internet-Draft, David McGrew shows that 'mainstream' elliptic curve crypto operations (key agreement and signature) can be done without having to make use of optimizations for which patent claims exist, by giving step-by-step pointers to generally available academic publications for the whole Math. And btw: patents expire; the success of RSA *after* the expiry of the major patents was largely based on the adoption of standards for the use of RSA cryptography in Internet protocols *before* this has happened, so that enough implementations already had been deployed when use became feasible.

It is state of the art (and a meta-requirement for Internet Standards) to have algorithm agility built in protocols, i.e., the ability to support different basic algorithms and invoke their use by code points in the protocol (subject to policy); this way, whenever 'better' algorithms are invented and vetted by the cryptanalytic community, they can easily be plugged into the protocols, and algorithms that have become weak due to increase in computing power and resources and/or progress in abstract number theory and cryptanalysis, they can be phased out quickly.

There are well established and vetted ECC algorithms; ECDSA -- initially standardized internationally for the financial services market has now been adopted by major national and international standards bodies for general use, and this is most notably the case for NIST&NSA, which now can be seen shifting from the home-grown DSA (and RSA) to ECDSA. DNScurve (as it is 'branded') suffers from lack of crypto- agility; it is bound to a private algorithm that has not seen comparable review and acceptance in the crptographic community; this perhaps can be attributed to the style it has been explained (or not) and marketed (like a doctrine of salvation -- believe it as-is or be regarded as an enemy!) in the past.

% maybe ISC should provide a downloadable precompiled BIND for windows and mac that just does recursive dns (with validation) and blocks all attempts by dhcp to override "127.0.0.1" as the resolver address.

That would actually help. Non-technical folks don't know how (and ought not have to know how) to setup their own recursive resolver.

> UDP source port randomization is good enough to take the Dan Kaminsky spoofed-flood class of attack completely off the table.

If that is the case, why did you in that case write an RFC draft for 0x20 randomization? You must at some point believed that UDP port randomization didn't take Kaminsky off the table.

/Bayne

Oddly enough, I wrote a recent magazine article (Jan. 2010) pointing out how easy it is on Linux, Windows, and MacOS to install and use a local recursive nameserver, and the large number of advantages to doing so over ISP public recursive servers, OpenDNS, and Google Public DNS.

Specific details for one recursive server (Unbound) are provided, but solely for Linux. (The article appeared in a Linux magazine.)

Rick Moen
rick@linuxmafia.com

> If that is the case, why did you in that case write an RFC draft for 0x20
> randomization? You must at some point believed that UDP port
> randomization didn't take Kaminsky off the table.

0x20 is a very cool hack and it does add some safety, though less safety for shorter names. when Dagon and i proposed it, the community was still neck deep in the "DNS Summer of Fear" and we had no idea whether our math was right. i still think 0x20 is fun and i'm still asking for the DNS standard to be changed in one small way to support this optional behaviour. however, i'm not going to tell the ISC BIND team to turn it on by default unless IETF picks it up and makes it mandatory, which seems 0.0% likely.

> Oddly enough, I wrote a recent magazine article (Jan. 2010) pointing out
> how easy it is on Linux, Windows, and MacOS to install and use a local
> recursive nameserver, and the large number of advantages to doing so
> over ISP public recursive servers, OpenDNS, and Google Public DNS.

thanks for this. we need it for all platforms. recursive dns is simple and in my opinion it's best done close to the client, under the client's control.

> UDP source port randomization is good enough to take the Dan Kaminsky spoofed-flood class of attack completely off the table.

Didn't Evgeniy Polyakov demonstrate that it is STILL possible to poison a cache given enough time (~10Hrs)? IE: Check slide #9 on this presentation:

http://www.infoblox.com/library/Infoblox-F5-DNSSEC-Webinar/DNSSEC-webina...

Please clarify? I'm probably not the only one confused about such statement, i hope..

;)

Ten hours of Gigabit-speed flooding is not a practical attack.

> I want to stamp out all forms of DNS intermediation
> whether by recursive nameserver operators or nation-
> states or hackers.

Nation-state intermediation in states like China will continue unabated. The only DNS answers you can get are the ones vetted by the authorities, period. Whether they "authenticate" doesn't matter. It's a take-it-or-leave it proposition.

Western countries that silently tap communication channels on an ad hoc basis (w/ or w/o judicial checks) will also continue unabated. As SSL has shown, the certificate authorities willingly concede to governments' requests to sign "forged" keys.

Because governments can break this system, ipso facto criminals can to. This is because governments are susceptible to voluntary (special interests thru political and judicial channels) and involuntary (cracking) coercion themselves.

The DNSCurve virtue is specifically in not retrenching the hierarchical nature of DNS. DNSSEC will set in stone for the next 30+ years authentication of domain names using a technique for which we already have clear evidence of failure.

Admittedly DNSSEC is a fait accompli, however. But that's little comfort.

My ISP tries to hijack DNS queries for advertising purposes (NXDOMAIN), even if I don't have them set as "forwarders". I also know that they employ a product call "sandvine". I want to encrypt as much as I can. I sucks that one cannot trust their ISP to just provide connectivity and not mess with it.

Oh, and thanks for you 20+ years of work.

Getting both dnssec and dnscurve would be great. At the moment any end user dnssec doesn't validate and dnscurve would far more easily apply for protecting all (key management/rollover issues + users who haven't got caches make dnssec difficult to apply truly end-end and even then it hasn't reached saturation yet).

Dnscurve could fill that gap quickly but at the moment you have to choose dnscache with dnscurve or unbound with dnssec. And everyone would have to use Opendns or a slower ssh/ipsec.

At the moment dnscurve is best for end systems and caching resolvers with dnssec + ssh/dnscurve for the authoritys.

The crtiticism and lack of understanding of dnscurve by the isc is embarassing.

Dnssec should also learn very quickly how much more efficiency and dos prevention could be gained by analysing dnscurve.

Dnssec is a difficult task to get right with lots to consider, but they are quite far off the mark in many respects.

Both are really needed, dnssec for less secure servers and dnscurve for all (sniffed traffic jeopardising ssl and even the green bar etc.).

Roll on dnssecurv

why on earth would we need something like dnscurve now that the root has been signed and dnssec is finally got its legs? i don't buy your ease-of-use argument at all. maybe if everybody could spend at least half as much time deploying dnssec as arguing about dilutive and confusing half-solutions like dnscurve, we'd be done by now.

i want applications that are aware of dns security and can behave differently and better in the presence of signed authority data. i want to make SSL/TLS so trivial to do CA validation with that everybody uses it for everything. i want stub validation that ensures that my recursive dns server can't lie to me about google's address or send me to an ad server when i make a so-called "typo". dnssec makes all of that possible, and we all need to focus on global deployment.

once dnssec is globally deployed there will be nobody still arguing for dnscurve or anything else that only solves a small part of the end-to-end problem.

note-- i think dnssec is terribly ugly but i have come to terms with that and am pushing forward with it because i want what it can do for the world.

And how is the end user (joe bloggs) going to know he has the right keys at rollover and then there's Client DOS potentially making other attacks easier in more than one way/type.

"We'd be done by now"

So dnscurve was the problem that made it take over 10 years.
It wasn't dnscurve which if anything has educated dnssec about fast crypto and complements dnssec, though it is much simpler and easier to get correct quickly as there was less to concentrate on and less repurcussions with dnscurve.

"i want stub validation that ensures that my recursive dns server can't lie to me about google's address or send me to an ad server when i make a so-called "typo"."

I want that too but I also don't want attackers to be able to dos my clients. You will have and have had security problems with dnssec and I bet dnscurve would/will prevent many of those to come.

It's the dnssec camp getting on the high horse and isc being overly aggressive against dnscurve that's causing a large part of the problem. I understand many are saying dnscurve is a total replacement, which it isn't. Those people may want to control recursive responses which I hate after the phorm scandal.

It is arguable (not a brilliant argument) that the short comings and effectiveness of dnssec could make dnscurve a replacement in the real world (atleast at the moment).

Ideally dnscurve would complement dnsec or we'll get dnsseccurve or something.

I'm not in either camp and am just asking that you PLEASE stop fighting and think OPENLY and TOTALLY about the benefits to EVERYONE directly and indirectly.

Saying there's already lots to do would be a better position!

end user? the end user just wants his browser to work right. we can expect browser vendors to hide all details of DNS Security from the end user.

10 years? hardly. dnssec has taken 14 years so far. but confusion and dilution around dnscurve or similar proposals is only able to be responsible for post-root-signing delay, and bears no responsibility for the first 14 years of hell.

dnscurve is a very neat solution to a problem we're not going to have after dnssec is fully deployed. i don't get along well with djb but with stuff like dnscurve and udp port randomization there's no way anyone anywhere can fail to recognize the man's genius. i am not anti-djb nor anti-dnscurve, and neither is isc.

if what you want is last-hop (that's the recursive to the stub) protection, then please investigate tkey/tsig, and sig(0), and consider helping get those things deployed.

if what you want is server-to-server (that's authority to recursive) protection, then you have to treat the recursive operators as potential attackers, since they often want to redirect your google hits to their proxy, or remap "nxdomain" to their ad servers. dnscurve helps these guys but it does not help you since you're downstream of them. dnssec makes this kind of "dns lies" less practical, perhaps fully impractical.

if you really do still think that i, or isc, does not understand exactly where dnscurve fits in the Secure DNS ecosystem and data path, then drop me a note and set me straight, vixie@isc.org, or call me, +1 650 423 1301. we can then jointly or separately post a final summary here.

The thing I want to know is: with DNSSEC is it possible for the root signing authorities to allow overrides to the authenticity of domain owner provided data? This is the big problem with SSL and if this problem is now being built in into DNS and future DNS provided Cert data then I'm not for it. Why should we trust Verisign or any "partners" they may have? Or any other TLD registrar. And given the revenue model they have for selling certificates I don't believe they would subvert their own (or "partners") powers.

The time will come when the failures of SSL and Intermediate CAs is well known and I'd like to know if DNSSEC is working to fix this or just extend and maintain it.

I disagree with the ISC's point of view on DNSCurve: it can also provide authenticity just as well as DNSSEC - or even in pair with it.

In DNSCurve, the public key is provided by the upstream DNS server, and as long as you can trust this key you can trust the server's response just as well as a DNSSEC signed response.

Authenticity could be provided in two ways:

1. By starting from the root name servers (a resolving cache already has to know about the root servers, so it could know their keys should they support DNSCurve) and using DNSCurve all the way down to the target nameserver.
2. By authenticating the target's NS key (embedded in its name) as part of the DNSSEC signed response from the upstream name server.

The difference in the 2nd. case is that none of the Root/TLD's need to even support DNSCurve if the resolver cache can use DNSSEC on them and DNSCurve on the target NS, and the target NS doesn't need to buy any certificate to gain some authenticity.

Furthermore, to the DNSSEC problem statement of "recursive name server operators who may want to rewrite www.google.com to their own search page [...]", I'm wondering if DNSSEC could really help? A malicious cache could always pretend google.com DNS servers do not support DNSSEC, unless you force everyone to use DNSSEC. Is that the plan? Will we need to buy expensive certificates for every domain we want to use? That could also be an issue with most of the WiFI access point out there which *need* to fake DNS responses to get you to a sign-in page.

This isn't a fight between who is right and who is wrong or which standard is better than the other. Both DNSSEC and DNSCurve could be used together to secure the entire DNS system. I have to say though that I can't imagine in the foreseeable future DNSSEC being implemented across all DNS servers worldwide for the simple reason that most name owners out there won't want to purchase certificates for their names. DNSCurve, OTOH, could have a chance if it had some drive, as it requires very little to be implemented.