DNS: January 2009 Archives


January 21, 2009

I've written before about Kentucky's attempt to seize a bunch of domain names from gambling sites. They prevailed at the trial level and were able to take control of the names, but just lost at the appellate level. From the Register article:
The lower-court ruling rested on Franklin County Circuit Judge Thomas Wingate's highly specious finding that internet casino domain names constitute "gambling devices" that are subject to the state's anti-gambling statutes. Tuesday's decision disabused Wingate of that notion in no uncertain terms.

"Suffice it to say that given the exhaustive argument both in brief and oral form as to the nature of an internet domain name, it stretches credulity to conclude that a series of numbers, or internet address, can be said to constitute a machine or any mechanical or other device ... designed and manufactured primarily for use in connection with gambling," they stated. "We are thus convinced that the trial court clearly erred in concluding that the domain names can be construed to be gambling devices subject to forfeiture under" Kentucky law.

(Decision here. BTW, can you believe that in 2008 they're still distributing documents as scans turned into PDFs? Clearly this was sourced on a computer, so what's the problem?)

While I agree that it doesn't make a lot of sense to view domain names as a gambling "device", I'm not sure that this is quite as broad a ruling as I would have liked. As far as I can tell, this is just a ruling that this particular Kentucky law is inapplicable, but it's not clear what would stop Kentucky from passing a law explicitly giving them the right to seize domain names used in gambling, which would put us right back where we started. The problem here isn't so much the overreach of the particular Kentucky law, but rather with the potential for a situation where every political unit has joint universal jurisdiction over DNS entries just because the owners of the domain names exchange traffic with people in that political unit. It's understandable that the court didn't want to address that when it could find on narrower grounds, but presumably we'll eventually run into a case where the applicability of the local laws is clearer and we'll have to take the major jurisdictional issue head-on.

Thanks to Hovav Shacham and Danny McPherson for pointing me to this ruling.


January 18, 2009

Sorry it took me so long to get back to this topic. In previous posts I started talking about the possibility of replacing DNSSEC with certificates. Obviously, this can be done technically, but is it a good idea? The basic argument here (advanced by Paul Vixie but also others) is that putting keys in the DNSSEC would better than the existing X.509 infrastructure.

From a cryptographic perspective, this is probably not true: DNSSEC uses generally the same cryptographic techniques as X.509, including supporting MD5 (though it's marked as non-recommended). It may actually be weaker: one potential defense against collision attacks with X.509 is to randomize the serial number, but it's not clear to me that there's something as simple with DNSSEC RRSIG RRs though presumably you could insert a random-looking record if you really wanted to. Cryptographic security isn't the main argument, though. Rather, the idea is that DNSSEC would be more secure for non-cryptographic reasons.

I can see two basic arguments for why DNSSEC would be more secure, one quasi-technical and one administrative. The quasi-technical argument is that there is a smaller surface area for attack. Because a Web client (this is more or less generally true, but Web is the most important case) will accept a certificate from any CA on the trust anchor list, the attacker just needs to find the CA with the weakest procedures and get a certificate from that CA. This works even if the target site already has a certificate from some other CA, because the client has no way of knowing that. By contrast, at least in theory only one registrar is allowed to authorize changes to your domain, the attacker needs to target that registrar. That said, domain name thefts have occurred in the past, and so it's not clear how good a job the registrars actually do. Moreover, it wouldn't be that hard to import this sort of semantics into X.509; the CAs would need to coordinate with the registrars to verify the user's identity, but that's not impossible. Another possibility would be to have a first-come-first-served type system where CA X wouldn't issue certificates for a domain if CA Y had already done so without some sort of enhanced verification. Obviously, this is imperfect, but it would at least make hijacking of popular domains difficult.

The second argument is purely administrative, namely dissatisfaction with CA operational practices. Here's Vixie: "frankly i'm a little worried about nondeployability of X.509 now that i see what the CA's are doing operationally when they start to feel margin pressure and need to keep volume up + costs down." That said, it's not clear that registrar procedures will be any better (again, there have been DNS name thefts as well), and it's quite possible that they would be worse. Note that in some cases, such as GoDaddy, they're actually the same people. Moreover, there needs to be some coordination between the registrars and the registries, and that's a new opportunity for a point of failure. Anyway, this seems to me to be an open question.

The most difficult problem with this plan seems to be deployment. So far, DNSSEC deployment has been extremely minimal. Until it's more or less ubiquitous, users and clients need to continue trusting X.509 certificates, so adding DNSSEC-based certificates to the mix marginally increases the attack surface area, making the situation worse (though only slightly), not better. And as usual, this is a collective action problem: as long as clients trust X.509 certs there's not a lot of value to server operators to transition to DNSSEC-based certificates, which, of course, means that there's not a lot of incentive for clients (or more likely implementors) to start trusting them either. It's not really clear how to get past this hurdle in the near future.


January 6, 2009

So, I promised to write about the security issues of DNSSEC versus certificates but I realized that it helps to have a sense of how the DNS registration system works, so this post is about that. I'll get back to the topic soon, I promise.

The important thing to remember is that DNS is a distributed system, where authority can be delegated. So, when I want to get the address of www.educatedguesswork.org, something like the following happens:

  1. Go to the root servers and ask who is responsible for .org. The answer turns out to be a bunch of servers operated by Afilias.
  2. Go to one of the Afilias servers and ask who is responsible for educatedguesswork.org. The answer turns out to be a bunch of servers operated by Dreamhost.
  3. Go to one of the Dreamhost servers and ask for the record for www.educatedguesswork.org
[Technical note: I'm massively oversimplifying here, but this is close enough to give the big picture.] If I'm an attacker and I want to hijack traffic to www.educatedguesswork.org, I can manipulate any of these records. Let's ignoring tampering with the records for .org, which is probably a bigger job. First, I can arrange to have the Afilias servers point to somewhere other than Dreamhost for educatedguesswork.org, i.e., to some server I control and which will give out any result I want. Alternately, I can have the Dreamhost servers give out a different address for www.educatedguesswork.org. Either of these will direct traffic where I want it.

What's often surprising (and confusing) to people is that there are potentially at least three different organizations involved here. Two of these are obvious:

  • The registry (Afilias), who is responsible for the whole top level domain (.org).
  • The DNS server operator (Dreamhost) who actually serves the records for my zone.

The third is less obvious: many (most?) users don't deal directly with the registries. Rather, they deal with a registrar which stores their domain name data and then transmits updates to the registry. In my case, Dreamhost is also my registrar (or at least is frontending for my registrar), but there's no logical connection between the two functions it's performing. Indeed, back in the old days people often ran their own DNS servers but they still had to deal with a registrar. Dreamhost is just providing one-stop shopping. Any registry may be served by multiple registrars, but any given domain is associated with a single registrar. A user can transfer their domain between registrars (though not registries, since those are defined by the delegation structure), but it's a bit of a pain, since the registrars obviously want to keep your business.

So, ignoring tampering with the DNS protocol itself (remember, DNSSEC is supposed to secure that), you could imagine trying to attack any of these entities: you could try to convince the DNS server operator to change the victim's records, the registrar to point to a server of your choice, or the registry to hand the records over to a different registry which you could control somehow. If you could manage to do any of these, you could arrange to serve up any records you wanted with the result that traffic got redirected to you rather than the owner of the domain.

Obviously, the victim has an account with both the registrar and the DNS server operator, so you can mount all the standard attacks on the account, login system, password recovery system, etc. For instance, Dreamhost's password recovery feature is of the classic "email confirmation" type. Remember: the operators are not in the business of making your life miserable, but rather of providing service. This makes it hard for them to enforce really rigid recovery policies. You might imagine, of course, that you could have an arrangement with your registrar/operator where you told them that they needed to enforce a much stricter policy, but I don't know if anyone does that now. I do imagine that Google's registrar would think twice before accepting my emailed request to my request for password recovery, but I doubt that would apply to requests for educatedguesswork.org. You can also use ordinary social engineering mechanisms to do fraudulent transfers of a domain name to yourself. This sort of thing has actually happened. Finally, you could imagine fraudulently moving a domain from one registrar to another and then changing the information. This has happened as well, though there are mechanisms you can use (e.g., "registrar locking") to protect your domain from this to some extent.

While I've been primarily talking about addresses above, it should be clear that more or less everything I've just said applies just as well to keying material (public keys, certificates), stored in the DNS. Next: comparing DNS to the certificate infrastructure.