COMSEC: February 2010 Archives


February 25, 2010

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.


February 6, 2010

For some reason, the silly idea of universal personal authentication for Internet users seems to have an undue appeal on tech executives. Here's Barbara Kiviat reporting on Microsoft's Craig Mundie:
What Mundie is proposing is to impose authentication. He draws an analogy to automobile use. If you want to drive a car, you have to have a license (not to mention an inspection, insurance, etc). If you do something bad with that car, like break a law, there is the chance that you will lose your license and be prevented from driving in the future. In other words, there is a legal and social process for imposing discipline. Mundie imagines three tiers of Internet ID: one for people, one for machines and one for programs (which often act as proxies for the other two).


Mundie pointed out that in the physical world we are implicitly comfortable with the notion that there are certain places we're not allowed to go without identifying ourselves. Are you allowed to walk down the street with no one knowing who you are? Absolutely. Are you allowed to walk into a bank vault and still not give your name? Hardly.

This is one of those ideas that comes up so often and initially seems like a natural analogy, but on closer inspection just starts to look confused.

First, a drivers license isn't principally a form of general purpose authentication but rather a permit from the state to drive. It has a biometric component in order to permit the police to determine that you're the actual holder of the permit and not someone who just has their license. Of course, because the license is so ubiquitous, it's widely used as a form of general ID, but if you do something to lose your license, the state will still issue you an identification card; indeed you can generally get an id card even if you're ineligible to drive. (Here's what California has to say). So, on the one hand Mundie says you don't have a right to complete anonymity (which I at least sort of agree with) and that his proposed Internet driver's license would serve as a form of ID and on the other hand, he suggests that you could lose your right to use the Internet for some unspecified set of misbehaviors. So, which is it, a permit or a form of ID?

Second, if it's a permit, under what conditions might it be revoked? Having your machine compromised? Failure to keep your software updated? If it's just for bad system hygiene then you're going to see a huge number of revocations. If it's for actual malfeasance then aren't you just going to revoke the licenses of people who would be in serious legal jeopardy in any case? Internet security problems come from two kinds of users: those who are genuinely malicious and those who are just careless. The problem with the first is finding them, not punishing them once you've done so. As for the second, revoking their right to use the Internet seems rather excessive.

On the other hand, if the idea is to just have a form of ID, then I don't really see why we need something government sponsored. Can't sites decide for themselves whether to to try to authenticate you?