DNSCurve: Usable security for DNS

Internet packets are just like postcards; they're what postcards would be if the post office were millions of times faster. When your computer wants to know the IP address of www.softwarelivre.org, it drops a postcard in the mail to the softwarelivre.org administrator:

From: your computer
To: softwarelivre.org administrator

Where is www.softwarelivre.org?

When (and if) the administrator receives this postcard, he drops a postcard in the mail back to your computer:

From: softwarelivre.org administrator
To: your computer

www.softwarelivre.org has IP address 200.169.21.196.

This is the first step in downloading a web page. Your computer next makes an HTTP connection to 200.169.21.196 (by sending more postcards!) and eventually receives a web page from the server at that address.

If your computer instead receives a postcard saying

From: softwarelivre.org administrator
To: your computer

www.softwarelivre.org has IP address 157.22.245.20.

then it instead makes an HTTP connection to 157.22.245.20 and receives a web page from the server at that address. What your computer doesn't know is that this postcard is actually from an attacker, and that 157.22.245.20 is running the attacker's fake HTTP server, the attacker's fake SMTP server, etc. Anyone can toss into the mail a forged postcard that appears to be from someone else; anyone can toss into the Internet a forged packet that appears to be from someone else.

Attack details

Your computer isn't always listening for the address of www.softwarelivre.org. The attacker has to time his forgeries so that they arrive when your computer is listening. There are several standard ways for the attacker to do this:

Attack repeatedly, sending one forged packet after another. One of the forgeries will arrive at the right time.
Poke your computer to trigger a known lookup at a known time. See below for an example.
Attack caches a long time in advance. Your computer stores incoming DNS results in a cache and reuses those results for a while.
Easy, succeeds instantly: Sniff the network. The attacker sees your computer's outgoing DNS packets and immediately forges responses.

The attacker also has to win a race against the legitimate DNS response from the softwarelivre.org administrator: if your computer receives the legitimate DNS response before the forged DNS response then it stops listening and ignores the forged response. There are several standard ways for the attacker to win the race:

Deafen the legitimate DNS server, so that the DNS server never sees your computer's DNS query.
Mute the legitimate DNS server, so that your computer never sees the legitimate DNS response.
Poke-jab-jab-jab-jab-jab. See below for an example.
Easy, succeeds instantly, exactly as above: Sniff the network. The attacker sees your computer's outgoing DNS packets before the legitimate server does, and easily forges a response that arrives first.

Here is a typical example of a non-sniffing attack that can be carried out reliably from anywhere in the world. The attacker sets up a web page superdupersecuritytools.net, including an inline image from www.softwarelivre.org. You, the victim, hear about superdupersecuritytools.net and ask your browser to view superdupersecuritytools.net. The attacker sees the HTTP request, sends the web page to your computer ("poke"), and a moment later sends a forged DNS response ("jab"), or a series of forged DNS responses; the attacker also floods the legitimate DNS server's network, deafening and muting that server. Your computer receives the web page, sees that it has to download an inline image from softwarelivre.org, issues a DNS query for www.softwarelivre.org, receives the forged www.softwarelivre.org address, and stores the forged address for later use.

How does randomization help?

Your computer's DNS query packet contains a 16-bit ID. The DNS specification, RFC 1035, says "This identifier is copied [to the] reply and can be used by the requester to match up replies to outstanding queries."

The cache can, for example, have a table of 65536 current requests, where the first request uses ID 1, the second request uses ID 2, etc. When the cache receives a DNS response with ID 31415, it checks that the response is giving information about the 31415th name in the table, and discards the response otherwise.

In the non-sniffing attack example above, the victim's computer generates a DNS query with ID n for superdupersecuritytools.net to the superdupersecuritytools.net DNS server: i.e., to the attacker. A moment later the victim's computer generates a DNS query with ID n+1 for www.softwarelivre.org. In the meantime the attacker, having seen n, has generated DNS forgeries with ID n+1.

A more recent idea is to generate "random" IDs. Your computer can use any good stream cipher (for example, AES-CTR, running at about 10 cycles/byte) to expand a short secret key into a long sequence of "random" numbers. The output is very hard to predict: the attacker will have no idea what the next ID will be, even after seeing the entire sequence of previous IDs.

One can generate a random 16-bit ID and a random 16-bit UDP port number for each outgoing query. This UDP-port-randomization feature was implemented and advertised in djbdns since 1999, and in PowerDNS since 2006. In July 2008 an "emergency" upgrade (New York Times headline: "WITH SECURITY AT RISK, A PUSH TO PATCH THE WEB") added the same feature to BIND, Microsoft DNS, Nominum CNS, most Cisco products, etc.

More recently some DNS implementations have started advertising extra randomization from "0x20" (slight complication, a few extra bits of randomization, some reliability problems), "query repetition" (considerable complication, adequate randomization, more reliability problems, some efficiency problems), et al. It is clear that enough randomization effort would be able to stop all blind forgeries.

Unfortunately, randomization cannot stop sniffing attackers. Sniffing instantly destroys all of the "security" provided by ID randomization, port randomization, 0x20, and query repetition.

How does HTTPS help?

HTTPS says that it defends you against fake web sites. The softwarelivre.org administrator sets up HTTPS, and then you connect to https://www.softwarelivre.org instead of http://www.softwarelivre.org. Suppose the attacker forges a DNS response. Your computer will connect to the attacker's web server. Thanks to HTTPS, your browser is then supposed to warn you about an "invalid certificate" and avoid showing you the fake web pages. Unfortunately, HTTPS still doesn't show you the correct web page!

In other words, HTTPS can protect the integrity of web pages, but it does nothing to protect the availability of web pages. By forging DNS responses the attacker has sabotaged your HTTPS connections.

HTTPS also has usability problems that have prevented it from being deployed for the vast majority of web pages. By forging DNS responses the attacker has seized control of most web pages you see (HTTP) and sabotaged the rest (HTTPS).

How does DNSSEC help?

DNSSEC says that it defends you against DNS forgeries. The softwarelivre.org administrator uses public-key cryptography to sign his DNS records. If the attacker forges a DNS response, your computer will see that the forgery is not accompanied by a valid signature, and will throw the forged DNS information away, so you won't see the fake web pages. Unfortunately, DNSSEC never receives the correct DNS information, so you never see the correct web page!

Does this mean that DNSSEC is functionally equivalent to HTTPS? No. Deploying HTTPS provides some protection against attackers forging DNS packets and against attackers forging HTTP packets, while deploying DNSSEC provides only protection against attackers forging DNS packets. Here's the picture:

System Impact of DNS forgery Impact of HTTP forgery Impact of best attack

DNS+HTTP Fake web pages Fake web pages Fake web pages

DNSSEC+HTTP Denial of service Fake web pages Fake web pages

DNS+HTTPS Denial of service Denial of service Denial of service

DNSSEC+HTTPS Denial of service Denial of service Denial of service

The same picture appears for applications other than HTTP. Without application-level cryptography, the attacker can provide fake data; DNSSEC doesn't make a difference. With application-level cryptography, the attacker is limited to denying service; again, DNSSEC doesn't make a difference. This is why many security experts and other commentators have concluded that DNSSEC is fundamentally useless.

How does DNSCurve help?

DNSCurve is like DNSSEC in that it uses public-key cryptography to detect DNS forgeries. However, DNSCurve's forgery defense is stronger than DNSSEC's forgery defense in two important ways. First, DNSCurve's cryptographic choices are much more conservative than DNSSEC's cryptographic choices:

DNSSEC normally uses 1024-bit RSA to detect forgeries. 1024-bit RSA is already breakable by large companies and botnets but has not yet been broken by academic teams.
DNSCurve uses 255-bit elliptic-curve cryptography to detect forgeries. 255-bit elliptic-curve cryptography is billions of times harder to break than 1024-bit RSA by current cryptanalytic algorithms.

Second, DNSCurve protects every packet. If an attacker forges a DNS packet, DNSCurve immediately detects the forgery, throws it away, and continues waiting for the legitimate packet, so the correct data gets through. An attacker can still deny service by attacking subsequent protocols such as HTTP, but DNSCurve is part of a larger project to add similar protection to all Internet protocols. An attacker can also deny service by flooding the network, but this consumes many more of the attacker's resources than merely sending a few forged packets; DNSCurve drastically reduces the total amount of damage that an attacker can do.

DNSCurve is also much more efficient, much easier to implement, and much easier to deploy than previous cryptographic Internet protocols.

Version

This is version 2009.06.24 of the forgery.html web page.