DNS forgery

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 computerTo: 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 administratorTo: 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 administratorTo: 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.

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.

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.

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.