DNSCurve: Usable security for DNS
DNS forgeryInternet 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:
When (and if) the administrator receives this postcard, he drops a postcard in the mail back to your computer:
This is the first step in downloading a web page. Your computer next makes an HTTP connection to 126.96.36.199 (by sending more postcards!) and eventually receives a web page from the server at that address.
If your computer instead receives a postcard saying
then it instead makes an HTTP connection to 188.8.131.52 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 184.108.40.206 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 detailsYour 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:
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:
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:
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:
DNSCurve is also much more efficient, much easier to implement, and much easier to deploy than previous cryptographic Internet protocols.
VersionThis is version 2009.06.24 of the forgery.html web page.