DNSCurve: an alternative to DNSSEC

The Domain Name System (DNS) has been with us for a long time, turning host and domain names into IP addresses. Along the way, numerous flaws have been found in the protocol, including last year's Kaminsky DNS flaw, which just added to the clamor to see DNS replaced. But, DNS still hasn't gone away, and doesn't look like it will anytime soon, at least partially because its replacement, DNSSEC, doesn't really resolve all of the problems, and it creates some of its own. A proposal by Daniel J. Bernstein (aka djb), called DNSCurve, has some interesting features that might make it a viable alternative to DNS and DNSSEC—perhaps one that can be widely adopted.

Bernstein, author of qmail and djbdns, has a reputation for creating secure software, but he tends to play by his own rules. Both qmail and djbdns use Bernstein's own monitoring and inetd replacement, rather than using the "standard" UNIX tools. But, his results are good, the security guarantee he offers for qmail (and a similar one for djbdns) have yet to be claimed—though some argue that is because Bernstein himself makes the final decisions as to what qualifies. One thing is clear, though, his djbdns did anticipate the Kaminsky flaw, and didn't need to be patched when most of the other DNS servers did.

In some ways, DNSCurve continues the Bernstein "maverick" trend. The fundamental difference between DNSCurve and DNSSEC is that the latter set out to ensure that there would be no cryptography necessary on each query. It does that by pre-computing signatures, which makes it vulnerable to replay attacks. Instead, DNSCurve embraces per-query encryption, but it does so by leveraging an encryption algorithm, called Elliptic Curve Cryptography (ECC), which is much faster than RSA.

Part of what makes ECC more efficient is that it can use much smaller keys than RSA (256 bits vs. 1024 or more bits) to give the equivalent level of security. In addition, the best known attacks on ECC haven't gotten any better in the nearly 25 years since it was introduced. In a recent presentation [PDF], Bernstein shows a benchmark of server side performance: "Using this software, a low-cost PC with a 2.4GHz Core 2 Quad CPU can encrypt and authenticate 50 billion packets/day to 500 million clients. [...] The total load on .com is 38 billion packets/day from 5 million clients.".

Bernstein uses a particular curve, Curve25519, for DNSCurve. It is based on a "convenient" prime, 2^255 - 19, which is where it gets its name. That curve is the subject of a paper [PDF] by Bernstein entitled "Curve25519: new Diffie-Hellman speed records". ECC is thought to be a patent minefield, but Bernstein disputes the idea that Curve25519 is covered by patents. As with so many of the newest technologies, though, patent problems are something to keep on eye on regarding DNSCurve.

DNSCurve also changes the way nameservers for domains are named. Instead of arbitrary hostnames, like ns3.lwn.net (an non-existent example), the ns3 portion would be changed to an encoding of the domain's public key. In that way, no additional packets need to be sent to handle the key exchange, as the normal DNS query sequence would provide that name.

A DNS query would consist of a message that contained the client's public key, along with the actual query, encrypted using the server's public key. The response would also be encrypted, this time using the client's public key. In both cases, the packets would be signed in such a way that each side could verify that the packet came from the right host.

The DNSCurve web site has a wealth of information about DNSCurve, and how it differs from DNSSEC. For the most part, it protects against various DNS-based attacks better than DNSSEC, but there are a few areas where DNSSEC is more secure. In particular, private keys on DNSSEC hosts cannot be compromised by an attacker gaining control of the DNS server—provided the administrator has removed the key from that server. Because DNSSEC pre-computes the encrypted data, the private key is not required to be installed on the server, in contrast to DNSCurve.

DNSCurve is just a part of Bernstein's effort to see the internet encrypt all of its traffic. His vision is that by using ECC and Curve25519 (or some other, efficient, but strong, encryption), there would be no plaintext traffic on the net. That vision is a sensible one, whether Bernstein's particular implementation ideas are adopted or not. Eventually, universal encryption of internet traffic is something we are very likely to see.