OpenDNS (a free DNS service) has
decided to
adopt
DNSCurve to secure its traffic. Some background might be helpful
here: DNS, of course, is susceptible to a variety of forgery attacks,
which is why the IETF has spent approximately 10 trillion man hours
developing
DNSSEC. There's a
fair amount of dissatisfaction with DNSSEC (I'm not that thrilled with
it either) and Dan Bernstein has developed an alternative called
DNSCurve.
At a very high level, the approaches stack up like this:
- DNSSEC is an object security system. Each DNS
zone has an asymmetric (public/private) key pair which is used
to sign the records in the zone.
- DNSCurve is a channel security system. Each DNS
server has a Diffie-Hellman (actually ECDH) key pair.
When a client connects to the server, it does an ECDH key
exchange and the shared key is used to authenticate
traffic between the client and server.
The primary argument for DNSCurve seems to be performance: DNSCurve has better
performance than DNSSEC in two respects: the packets are smaller
and under certain conditions the load on the server is lower.
These properties are related but not identical. The packets are
smaller partly because DNSSEC replaces the digital signature with a
symmetric integrity check. These can be a lot smaller than
digital signatures using RSA (and a fair bit smaller than even
the smallest digital signatures). Second, because DNSCurve
uses elliptic curve cryptography, the keys that need to
be carried in packets are smaller. (This is mostly relevant in
packets which carry the key for a zone rather than packets
which carry other data).
The packet size argument is straightforward. The load argument
is more complicated. As I noted above, DNSCurve uses elliptic curve
cryptography, which is faster and has smaller keys than RSA (the basic
algorithm used by by DNSEC). This means that it's inherently faster to
set up a DNSCurve association than it is to sign a DNSSEC record using
RSA. In addition, DNSCurve has a mechanism for the client and server
to cache the DH shared secret. The upshot of this is that
it's substantially cheaper to authenticate a new DNS record with
DNSCurve than it is with DNSSEC.
In the worst case, it involves an ECDH operation.
In the best case, it just involves a symmetric crypto operation.
So, in this respect the performance of DNSCurve is superior.
However, this isn't really a heads-up comparison: in the DNSSEC
model, you sign the zone once whenever it changes (possibly using
a key thats kept offline) and then just send copies of it to
any requester, so no cryptographic operations are needed after
the initial signature. By contrast, because DNSCurve uses
a symmetric, rather than asymmetric, integrity mechanism,
the DNS server needs to compute that integrity check for each
new request. This means that while DNSCurve is faster if
you change your DNS data frequently and don't serve that
many requests, it's slower if you don't change it often but
serve a lot of requests.
In addition, it means that while DNSSEC signing can be done
offline with a key that is never on an Internet accessible machine,
DNSCurve requires that the private key to the zone be kept
on the DNS server, thus potentially exposing it to theft if
the server is compromised. By contrast, if DNSSEC is used in
an offline signing mode, then compromise of the server does not
enable forgery attacks.
Where DNSCurve has a major
advantage is if your server provides dynamic responses
(e.g., for DNS load balancing), in which case offline signing
isn't that useful and the performance advantage of DNSCurve
is most significant.
It's also worth noting that the use of faster algorithms isn't
an inherent advantage of DNSCurve. DNSSEC (like all relatively
modern COMSEC protocols) supports multiple algorithms and there
have been proposals to add ECC (see, for instance,
draft-hoffman-dnssec-ecdsa). An ECDSA-enabled DNSSEC would still be
slower than DNSCurve if run in a dynamic environment, but
performance would be a lot closer and how much slower would
depend on how many repeat requests you got from the same client;
if each client only makes one request, then performance would
be more or less equivalent. The packet size of ECC DNSSEC would be
a little worse, but probably not enough worse to make a big
difference.
This isn't to say that there aren't other factors to consider
(see the DNSCurve site for
the other arguments in favor of DNSCurve). However, the performance
argument doesn't seem to me to be dispositive, since which
solution is faster depends on your deployment model and assumptions
about the client environment.