Recently in DNS Category

ICANN is deferring yet again approval of the (useless) .xxx domain:

A global Internet oversight agency on Friday deferred a decision until June on whether to create a ".xxx" Internet suffix as an online red-light district.

The board of the Internet Corporation for Assigned Names and Numbers, or ICANN, initiated a 70-day process of consultations on a domain that could help parents block access to porn sites. Use of the ".xxx" suffix would be voluntary, though, and would not keep such content entirely away from minors.

...

ICM Registry LLC first proposed the ".xxx" domain in 2000, and ICANN has rejected it three times already since then. But an outside panel last month questioned the board's latest rejection in 2007, prompting the board to reopen the bid.

"There's a lot of complex issues," ICANN CEO Rod Beckstrom said, without elaborating.

I wish he would elaborate, since I have no idea what the complex issues are. As far as I know, here's the situation: There are a large number of adult-oriented sites that currently live in .com, .net, etc. Those sites have a high profile and aren't going to suddenly abandon their existing domain names. As long as there are a large number of non-.xxx adult domains, then it's not a very useful criterion for filtering software to use, so I doubt it will be of any use in protecting children from pornography. Since I don't see any indication that adult domains will really be restricted to .xxx then the public good of the proposed new domain seems relatively limited. On the other hand, the harm seems fairly limited as well, especially as the general takeup of new GTLDs seems to be limited at best. (Note that this applies more or less equally to any other proposed new GTLD). I realize that there are people who think that there are important forces pushing in one direction (ICM's desire to sell new domain names) or another (silly worries that .xxx will somehow legitimize pornography), but as far as I can tell it's just a no-op.

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.

Richard Barnes pointed me to the joint ICANN/VeriSign presentation from RIPE 59 (today in Lisbon) on their plans for rolling out signing of the root zone. For those who aren't up on DNSSEC, each TLD (.com, .net, .us, etc.) will sign the domains under it, but the design calls for the information for each of those domains to be signed as well at the root of the tree. There's some question about how important this really is from a technical perspective but the DNSSEC community seems convinced (wrongly in my opinion) that it's essential, so it's socially important even if not technically important.

Anyway, Richard pointed out something interesting to me: they plan to roll over the root Zone Signing Key (ZSK) four times a year (see slide 19) which doesn't really make sense to me. Actually, the whole key rollover scheme doesn't make much sense to me.

It might be helpful to start with a little background. The way things are going to work is this: ICANN is going to have a long-lived (2-5 years) Key Signing Key (KSK). The public half of this key will be built into people's resolvers. But the KSK will not be used to directly sign any user data. Rather, it will be used to sign a short-lived (3 months) ZSK [held by VeriSign] which will be used to sign the data. Because the relying party (i.e., your computer) knows the KSK, it can verify any new ZSK without having to get it directly.

Why are they doing this? As far as I can tell the rationale is as follows:

• The security of RSA key pairs is directly connected to key length, which is also the length of the signature that the key pair produces.
• Space in DNS packets is limited.

The combination of these two factors means that if you want to use longer (higher security) key pairs to sign zone data, you start running into size limitations in the packet. That's perfectly understandable, but why does having two keys help. The idea here is that you have a big (2048-bit) and a short (1024-bit) ZSK. But because the ZSK is changed frequently, you don't need as strong a key and can still get good security. I wasn't able to find a good description of this in the DNSSEC documents, but Wikipedia came through:

Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for each. First, there are Key Signing Keys (KSK) which are used to sign other DNSKEY records and the DS records. Second, there are Zone Signing Keys (ZSK) which are used to sign RRSIG and NSEC/NSEC3 records. Since the ZSKs are under complete control and use by one particular DNS zone, they can be switched more easily and more often. As a result, ZSKs can be much shorter than KSKs and still offer the same level of protection, but reducing the size of the RRSIG/NSEC/NSEC3 records.

The only problem with this reasoning is that it's almost completely wrong, as can be seen by doing some simple calculations. Let's say we have a key with lifespan one year that requires C computations to break. An attacker buys enough hardware to do C computations in two months and then is able to use the key to forge signatures for the next 10 months (I'll try to write about keys used for confidentiality at some later point.) If we think about a series of keys, they will be vulnerable 10/12 of the time. Now, let's say that we halve the lifespan of the key to 6 months, which shortens the window of vulnerability to 4 months per key, or 2/3 of the time. But if the attacker just buys 2C compute power, he can break the key in 1 month, at which we're back to having the keys vulnerable 10/12 of the time. If we generalize this computation, we can see that if we increase the frequency of key changes by a factor of X, we also increase the attacker's workload by a factor of X.

More concretely, if we originally intended to change keys every 4 years and instead we change them every quarter, this is a factor of 16 (4 bits) improvement in security. Opinions vary about the strength of asymmetric keys, but if we assume that 1024-bit RSA keys have a strength of about 72 bits [*] then this increases the effective strength to around 76 bits, which is somewhere in the neighborhood of 1100 bit RSA keys, a pretty negligible security advantage and nowhere near the strength of a 2048 bit RSA key (> 100 bits of security). It's certainly not correct that this offers the "same level of protection".

The more general lesson here is that changing keys rapidly is nearly useless as a method of preventing analytic attacks. It's almost never practical to change keys frequently enough to have a significant impact on the attacker's required level of effort. If you're that close to the edge of a successful attack, what you need is a stronger key, not to change your weak keys more frequently. In the specific case of DNSSEC, just expanding the size of the packet by 10 bytes or so would have as much if not more security impact at a far lower system complexity cost.

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.

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.

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.

Joe Hall has a followup on the Kentucky domain names case (see here for background).

What's the upshot of all of this? To me, it's pretty scary: A state government moved to order seizure of domain names that it found were illegal "devices" and a judge issued an order demanding the transfer of these domain names before any hearing or opportunity to protest. The state has so far successfully argued that domain names are property and devices used for illegal gambling within Kentucky and that the 141 Domain Names defendants must identify themselves to have standing to contest the seizure and forfeiture. The last shoe to drop is that Judge Wingate, as part of his order from yesterday, ordered the state to rescind any forfeiture for gambling sites that block Kentucky gamers using geographical blocking methods (the wording was, essentially: Defendants who install a "software or device [...] which has the capability to block and deny access to [the defendant's] online gambling sites [...] from any users or consumers within the [...] Commonwealth [of Kentucky] and reasonably establishes to the [state] or this Court that such geographical blocks are operational, shall be relieved from the effects of the Seizure Order and from any further proceedings [in this action.]").

I'm no lawyer, but I find this whole thing really puzzling. I've got a simple question, though: is it in general true that courts in State X can serve orders on an entity located in State Y and actually have them enforced? As an example, say I'm a gambling outfit located in Nevada and I use a mail drop (non-government for simplicity) located in California, could a court in Kentucky force the mail drop to redirect all my mail to Kentucky?

[Terence] Spies alerted me to this story about the state of Kentucky trying to take control of 141 domain names in an effort to block Internet gambling:

FRANKFORT -- Kentucky is commandeering 141 domain names of Internet gambling sites in a novel legal move to crack down on the unregulated industry.

Franklin Circuit Judge Thomas Wingate ordered the names transferred to the state last week, Gov. Steve Beshear announced Monday.

Sites affected include such names as caribbeangold.com and sportsbook.com.

If officials get their way at a Sept. 25 forfeiture hearing, the state will control the domain names and can ask Web registrars to block access to the sites, said Justice and Public Safety Secretary J. Michael Brown.

Putting aside for a moment one's opinion of trying to stop Internet gambling, this seems like a seriously problematic operating theory. Sportsbook isn't located in Kentucky (it seems to be based in Malta) and sportsbook.com is registered with Network Solutions, which is based in Herndon, VA. As far as I can tell, the only relationship that they have with Kentucky is that they let people from Kentucky gamble on their site. If we're operating on that basis, then what's to stop the city of Grano, North Dakota, population 9, from deciding that Google is violating some local ordinance and seizing google.com. Sure, maybe they're operating on some bogus pretext and Google will eventually prevail, but in the meantime all your searches turn up businesses in North Dakota. This doesn't really seem viable.

Of course, you could argue that Sportsbook could just not do business with everyone in Kentucky, but this is impractical for two reasons. First, geolocation technology isn't really good enough for Sportsbook to determine for absolute certain where every potential user is. Second, even if they could be sure, it's not really practical for every domain holder to know the laws of every potential jurisdiction their customers might come from—it's entirely possible I'm violating the laws of Grano right now.

If you want to actually have a working Internet, then, you really need to arrange matters so there's not a semi-infinite set of attackers who can trivially bring down anyone's domain.

ICANN has announced plans to expand the pool of TLDs:

"The potential here is huge. It represents a whole new way for people to express themselves on the Net," said Dr Twomey. "It's a massive increase in the 'real estate' of the Internet."

Presently, users have a limited range of 21 top level domains to choose from -- names that we are all familiar with like .com, .org, .info.

This proposal allows applicants for new names to self-select their domain name so that choices are most appropriate for their customers or potentially the most marketable. It is expected that applicants will apply for targeted community strings such as (the existing) .travel for the travel industry and .cat for the Catalan community (as well as generic strings like .brandname or .yournamehere). There are already interested consortiums wanting to establish city-based top level domain, like .nyc (for New York City), .berlin and .paris.

I'm having some trouble seeing the value of this proposal. As I've mentioned earlier, there has been remarkably little uptake of the non big 7 gTLDs, with .com being the elephant in the room. What reason is there to believe that .brandname is going to have any more uptake? So, it doesn't make much sense to say that this increases the "real estate" of the Internet.

Even if that weren't true, the structure of the DNS more or less negates the idea that creating more TLDs somehow creates more "real estate". One could easily create exactly the same amount of real estate by inventing a single new TLD, e.g., .tld which implements whatever policies you intended to promulgate for new TLDs. This would have essentially the same effect except that the names are a bit longer. Moreover, we effectively have all that real estate, since any existing DNS zone could instantiate exactly these policies: nothing in the DNS structure stops me from setting up tld.educatedguesswork.org.

That's not to say that this is necessarily a bad idea, but the arguments I've heard so far aren't very convincing.

I wrote before about a US court blocking access to Wikileaks. The Judge dropped the order and then the bank dropped the lawsuit. Turns out that this wasn't the only such incident, though. Treasury blacklisted Steve Marshall's travel agency and forced his registrar to disable his domain for allegedly helping Americans travel to Cuba:

"I came to work in the morning, and we had no reservations at all," Mr. Marshall said on the phone from the Canary Islands. "We thought it was a technical problem."

It turned out, though, that Mr. Marshall's Web sites had been put on a Treasury Department blacklist and, as a consequence, his American domain name registrar, eNom Inc., had disabled them. Mr. Marshall said eNom told him it did so after a call from the Treasury Department; the company, based in Bellevue, Wash., says it learned that the sites were on the blacklist through a blog.

Either way, there is no dispute that eNom shut down Mr. Marshall's sites without notifying him and has refused to release the domain names to him. In effect, Mr. Marshall said, eNom has taken his property and interfered with his business. He has slowly rebuilt his Web business over the last several months, and now many of the same sites operate with the suffix .net rather than .com, through a European registrar. His servers, he said, have been in the Bahamas all along.

...

A Treasury spokesman, John Rankin, referred a caller to a press release issued in December 2004, almost three years before eNom acted. It said Mr. Marshall's company had helped Americans evade restrictions on travel to Cuba and was "a generator of resources that the Cuban regime uses to oppress its people." It added that American companies must not only stop doing business with the company but also freeze its assets, meaning that eNom did exactly what it was legally required to do.

The situation here is much like that with Wikileaks. Both eNom (his direct registrar) and VeriSign (the registry for .com), so the US government can clearly force them to do stuff (I'm not passing judgement on the law here, just talking about power). Even if eNom were outside the US, USG could just force VeriSign to redirect the domain somewhere else. In fact, all three of the big TLDs (.com, .net, and .org are operated by organizations based in the US. That said, plenty of the ccTLDs are operated outside the US; .cu looks pretty safe. Obviously, in principle USG could lean on ICANN to reassign one of the ccTLDs, but it's hard to believe that ICANN's legitimacy could survive doing it.

Once we get past the question of what USG can or can't do, there's the question of what's smart. Obviously, the USG can make the lives of people they don't like miserable if they use .com but that just gives anyone who thinks they might piss of the government incentive to choose another TLD. So, you'd expect to see a new equilibrium where people who worry about this move their domains outside the US the same way that people do banking offshore, which is bad for any registrar or registry which operates in the US and not clearly any better for USG in the long term.