March 5, 2008

More on the perils of a US registrar

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.

Posted by ekr at 9:27 PM | Comments (1)

February 25, 2008

Network Solutions name locking suit

Blake Ramsdell alerted me to this lawsuit over Network Solutions whois domain locking policy:
LOS ANGELES, Feb. 25 /PRNewswire/ -- Network Solutions has forced millions of people to buy Internet domain names from them instead of cheaper competitors through a scheme that's netted the firm millions of dollars, a federal class action lawsuit filed today by Kabateck Brown Kellner, LLP states. ICANN, whose policies facilitate the scheme, is also named in the suit, filed in U.S. District Court, Central District of California.

...

Whenever someone searches for the availability of a domain name through Network Solutions' website, the company immediately registers the name for itself, preventing other companies from selling it and forcing consumers to pay Network Solutions' expensive fees.

If a consumer were to go to another, cheaper site to register the name, they would find the name is "unavailable." Consumers are never informed that inquiring as to a name's availability through Network Solutions results in the company holding a monopoly on selling that name.

I'm not too surprised to see someone suing NSI over this, but what's interesting is that they're suing ICANN. Based on ICANN's contract with NSI, it looks like ICANN can promulgate rules that would forbid NSI from doing this name locking trick (though it would require the creation of a "Consensus Policy"). But that doesn't necessarily mean that you can sue ICANN to require them to promulgate such a policy—or rather that you can prevail.

Posted by ekr at 10:04 PM | Comments (1)

February 20, 2008

Wikileaks shut down

Cayman bank Julius Baer Bank and Trust has convinced a federal judge to shut down DNS service for wikileaks.org.
On Friday, Judge Jeffrey S. White of Federal District Court in San Francisco granted a permanent injunction ordering Dynadot, the site's domain name registrar, to disable the Wikileaks.org domain name. The order had the effect of locking the front door to the site -- a largely ineffectual action that kept back doors to the site, and several copies of it, available to sophisticated Web users who knew where to look.

Domain registrars like Dynadot, Register.com and GoDaddy .com provide domain names -- the Web addresses users type into browsers -- to Web site operators for a monthly fee. Judge White ordered Dynadot to disable the Wikileaks.org address and "lock" it to prevent the organization from transferring the name to another registrar.

The feebleness of the action suggests that the bank, and the judge, did not understand how the domain system works, or how quickly Web communities will move to counter actions they see as hostile to free speech online.

The site itself could still be accessed at its Internet Protocol address (http://88.80.13.160/) -- the unique number that specifies a Web site's location on the Internet. Wikileaks also maintained "mirror sites," or copies usually produced to ensure against failures and this kind of legal action. Some sites were registered in Belgium (http://wikileaks.be/), Germany (http://wikileaks.de) and the Christmas Islands (http://wikileaks.cx) through domain registrars other than Dynadot, and so were not affected by the injunction.

There's also a mirror at cryptome.

For those of you who don't know how this all works, there's registries, who actually run the domain name (.org in this case) and then there are registrars, who actually deal with the customers. Any given top level domain typically has multiple registrars that service it, all of whom populate the same database, operated by the registry. So, the locking thing stops Wikileaks from transferring their domain to another registrar who would then reactivate it.

OK, so this order controls the registrar. But can Wikileaks just go to the registry and get them to move it to some other registrar, locking notwithstanding? In this case, Wikileaks is under .org, which is run by the Public Interest Registry. Operationally, the PIR is run by Afilias. Both of these are based in the US, so presumably the injunction could be expanded to include them as well. On the other hand, as the article notes, there are plenty of registries with no US connection and the only way for a US judge to take down them domains under them would be to go after ICANN, which, despite complaints about the US running the DNS seems pretty unlikely.

As you may be gathering at this point, this is all pretty pointless. It's basically impossible to censor stuff like this once it gets out. We're seeing the first level of countermeasure here, but even if by some miracle the judge managed to shut down every domain name serving the contraband material (and since the decision loop for spreading those domain names is a lot faster than your average judge's decision making process), people can just move to IP addresses published by some other means (like other people's web sites). And there are about three levels of escalation up from there, all of which are progressively harder to censor.

It will be interesting to see if JBBT goes after cryptome.org, though.

Posted by ekr at 9:42 PM | Comments (0)

January 9, 2008

A cheap anti-frontrunning countermeasure: digested WHOIS

The reason that front running works at all is that WHOIS leaks the name of the domain you're looking to the WHOIS service operator and in this case the operator is the adversary, thus giving them an opportunity to get ahead of you. The usual answer to this problem is to create a set of policies that treat WHOIS queries as sensitive information (see ICANN's study on front running). One could, for instance, require the WHOIS operator to treat WHOIS queries as private.

However, there's a cheap, compatible, technical hack that substantially increases the difficulty of front running attacks without any new policies: allow WHOIS searches on hashes of domain names. The way this would work is that the WHOIS operator would create a parallel tree of phony domain name registrations in WHOIS. For instance, if I registered example.org, then they would also create an entry for SHA-1(example.org)=20116dfd6774a9e7b32eddfea3f6cb094e38fc3f.org (we might need to register a new TLD to make this work and guarantee no collisions) and populate it with the record for example.org. Then, I could locally compute the hash for each domain name I wanted to check on and easily verify its existence or nonexistence.

Other properties:

You still might need ICANN or someone like them to force the operators to do this, since it's not clearly in their interest. On the other hand, direct cost to them is so low that it's hard to really object to on difficulty grounds.

Technical Note 1: This problem is related to private information retrieval but is dramatically easier because we don't care about the server knowing what record we fetched if it exists, only if it doesn't exist. Actually, we only care if the record exists. We don't need the record itself, which makes the problem yet easier.

Technical Note 2: It would be nice to have a solution that didn't allow dictionary attack. The best solutions I know use Bloom filters.

Note that the hash solution isn't technically constant size in the number of registered names either—the required hash size for any given false negative probability depends on the number of registered names. However, since 160 bits is so small people just think of this as constant size.

Posted by ekr at 8:34 AM | Comments (5)

NSI accused of front running

Domain Name News reports that Network Solutions is engaging in front running of domain names—when a user uses WHOIS to check on the availability of the name, NSI grabs the domain:
A story is developing regarding domain name registrar Network Solutions front running domains. According to multiple sources on DomainState.com, it appears that domains searched via NSI are being purchased by the registrar thereby preventing a registrant from purchasing it at any other registrar other than NSI. As an example, a random domain which DNN searches such as HowDoesThisDomainTasteTaste.com can be seen in this whois search to now be unavailable to register at other registrars but at NSI it can be purchased

The whois contact now says : 

    Registrant: Make this info private
    This Domain is available at NetworkSolutions.com
    13681 Sunrise Valley Drive, Suite 300
    HERNDON, VA 20171
    US

The domains are likely being purchased and held in NSI ownership until the potential registrant comes back to purchase the name through NSI. If the purchase is not made at NSI within 5 days, NSI uses the same 5 day grace period that domain tasting operations use and they delete the domain. Once a search for a domain is conducted at NSI the domain name is registered and only available to be purchased by a registrant at NSI. It is not clear if NSI has increased prices on domains that have received multiple whois searches and that they are front running.

Obviously, even if NSI isn't increasing prices, customers don't really want to be locked into NSI. NSI's defense? They're doing it to protect customers:

"I'd like to clarify what we are doing. In response to customer concerns about Domain Name Front Running (domains being registered by someone else just after they have conducted a domain name search), we have implemented a security measure to protect our customers. The measure will kick in when a customer searches for an available domain name at our website, but decides not to purchase the name immediately after conducting the search.

After the search ends, we will put the domain name on reserve. During this reservation period, the name is not active and we do not monetize the traffic on these domains. If a customer searches for the domain again during the next 4 days at networksolutions.com, the domain will be available to register. If the domain name is not purchased within 4 days, it will be released back to the registry and will be generally available for registration.

This protection measure provides our customers the opportunity to register domains they have previously searched without the fear that the name will be already taken through Front Running.

You are correct that we are trying to take an arrow out of the quiver of the tasters. As you know, domain tasters are the largest Front Runners. Due to no fault of registrars, Front Runners purchase search data from Internet Service Providers and/or registries and then taste those names. Some folks may not agree with our approach, but we are trying to prevent this malicious activity from impacting our customers."

I don't really understand how this is a defense against front running. Say that I search for example.com and I find it's not taken but I decide not to purchase it. Someone else is monitoring that whois and decides to purchase the name. WHOIS is unauthenticated, so they can buy it just as well as I can, they just have to go through NSI. I see how this is to NSI's benefit, but how is it to mine? I suppose one could argue that NSI is more expensive than other registrars, so forcing them to go through NSI sort of deters attackers, but that seems like a pretty crude instrument. Other than that, I don't see that this is a useful safeguard.

Posted by ekr at 7:37 AM | Comments (1)

March 31, 2007

So what if Uncle Sam signs the DNSSEC root?

There's currently a fair amount of angst about DHS's desire to control the root key for DNSSEC:
The US Department of Homeland Security (DHS), which was created after the attacks on September 11, 2001 as a kind of overriding department, wants to have the key to sign the DNS root zone solidly in the hands of the US government. This ultimate master key would then allow authorities to track DNS Security Extensions (DNSSec) all the way back to the servers that represent the name system's root zone on the Internet. The "key-signing key" signs the zone key, which is held by VeriSign. At the meeting of the Internet Corporation for Assigned Names and Numbers (ICANN) in Lisbon, Bernard Turcotte, president of the Canadian Internet Registration Authority (CIRA) drew everyone's attention to this proposal as a representative of the national top-level domain registries (ccTLDs).

(See for instance this /. thread:

"At an ICANN meeting in Lisbon, the US Department of Homeland Security made it clear that it has requested the master key for the DNS root zone. The key will play an important role in the new DNSSec security extension, because it will make spoofing IP-addresses impossible. By forcing the IANA to hand out a copy of the master key, the US government will be the only institution that is able to spoof IP addresses and be able to break into computers connected to the Internet without much effort [As usual, people on /. seem a little confused about how the Internet works. Needless to say, being able to spoof DNSSEC doesn't let you spoof IPs, nor is being able to spoof DNS queries that much use in breaking into people's computers these days. -- EKR]. There's a further complication, of course, because even 'if the IANA retains the key ... the US government still reserves the right to oversee ICANN/IANA. If the keys are then handed over to ICANN/IANA, there would be even less of an incentive [for the U.S.] to give up this role as a monitor. As a result, the DHS's demands will probably only heat up the debate about US dominance of the control of Internet resources.'"

This is all kind of scary sounding, but it's really a lot less of a big deal than it's made out to be. The basic thing you need to remember is that DNS is a hierarchical system and that DNSSEC follows the hierarchy. Thus, the key in question signs the root zone (or rather the key for the root zone) which just contains the name servers and the keys for the TLDs (.com, .org, .net, .us, etc. The information for your domain (or at least the key for your domain if you had one) would be signed by those keys. So, for instance, they key for educatedguesswork.org would be signed by the key for .org, which itself would be signed by the root zone key.

So, let's say that DHS wanted to forge the address (A) record for educatedguesswork.org. They'd have to sign a fake root zone with a new key for .org and make a parallel tree all the way down to educatedguesswork.org. Since those fake records will end up in people's DNS caches this is not likely to go entirely unnoticed if it happens at all often. Moreover, it's not clear exactly what use spoofing records for someone else's domain would do for you. Because of the slow deployment of DNSSEC and end-to-end IPsec applications which want cryptographic authentication of Internet peers use TLS and X.509 certificates. If you manage to reroute DNS, all that happens is that they get to the wrong host and then the TLS certificate check fails. Now, you can certainly argue that people are lax about certificate errors, but you should expect them to be even more lax about DNSSEC errors, especially since most people aren't prepared to validate DNSSEC at all.

In theory, of course, controlling the root zone signing key means that DHS could completely hijack some large section of the domain space. They'd get court orders or otherwise compel some fraction of the root servers to point to their new parallel zone and sign the records with the top-level key. But of course as soon as this got out, people would most likely program their verifiers to ignore signatures from that key and use whatever zone data was in effect before DHS got involved. And of course why bother with anything so technical? The data in the DNS just reflects whatever assignments ICANN and IANA have made. Both organizations are located in the US, so if DHS wants to hijack some zone, they just force ICANN/IANA to reassign the zone and then whoever does the signatures would presumably sign the new data. Of course, you could say people wouldn't accept this, but then why would you believe that they would accept signatures that didn't reflect ICANN/IANA's assignments?

None of this is to say that DHS controlling the root zone wouldn't be symbolically badly received, but that's mostly what it would be, symbolic.

Posted by ekr at 9:25 PM | Comments (7)

March 30, 2007

.xxx really really dead?

ICANN has decided not to issue .xxx. Stuart Lawley from ICM does not look that happy about it:

ICANN Board member Susan Crawford is also unhappy:

"No centralized authority should set itself up as the arbiter of what people may do together online," Ms. Crawford said in a statement to the board, adding that political pressures played an undue role. "This is not a technical stability and security question."

I mostly agree that this isn't a technical stability question. As far as the DNS is concerned, there's nothing special about the string .xxx, after all. As far as security goes, the only way in which this would be special would be if ICANN intended to monitor that ICM was enforcing the somewhat vague conditions that were proposed for the domain. That's easily fixed by not doing so. That said, the bit about "no centralized authority" being an "arbiter of what people may do together online" is a bit hard to understand, since that's more or less ICANN's reason for existence. Once we've decided that we're going to issue more TLDS and we're not going to do it in a mechanical fashion (first come/first served, auction, etc.), you're pretty much left with some sort of centralized arbiter, which is what ICANN is. This isn't to say that one can't object to the decisions ICANN has made or the way it makes them, but that's different from having a principled objection to them making such decisions in the first place (not that one can't object to that as well...)

Posted by ekr at 11:46 PM

February 8, 2007

Hackers attack DNS, nobody notices

On Tuesday, some hackers mounted a pretty significant distributed denial of service attack on several of the root DNS servers (the ones who serve the records for the top level domains). You can see the attack pretty dramaticall in the following figure which shows unanswered queries for the past seven days on G:

According to this report the attackers managed to seriously degrade service on three of the roots:

WASHINGTON — Hackers briefly overwhelmed at least three of the 13 computers that help manage global computer traffic Tuesday in one of the most significant attacks against the Internet since 2002.

Experts said the unusually powerful attacks lasted as long as 12 hours but passed largely unnoticed by most computer users, a testament to the resiliency of the Internet. Behind the scenes, computer scientists worldwide raced to cope with enormous volumes of data that threatened to saturate some of the Internet's most vital pipelines.

A few points are worth mentioning here. First, there are actually significantly more than 13 servers because a substantial number of them are anycasted, meaning that you talk to a different server (with the same IP address) depending on where you are in the network. So, you need to DoS more than 13 machines in order to actually bring down all DNS service.

Second, despite losing a significant fraction of the root server capacity, most people didn't really notice. There are two main reasons for this. The first is that DNS uses a lot of caching. The roots only hand out the addresses of the servers for the TLDs (e.g., com, org, etc.) and resolving nameservers cache. Since most domain names are drawn from a relatively small number of TLDs, your resolving nameserver will have the TLD servers in cache and so doesn't need to get to the root. So, even if the roots were totally down, people would mostly continue to get service until their caches started to expire which takes hours to days. The second reason is that all the roots are interchangeable and the resolving servers will keep trying until one works, so the end result is really more a slowdown than a loss of service. This sort of slowdown gets lost in the ordinary net hiccups people experience and just tolerate.

Posted by ekr at 9:50 PM | Comments (1)

January 20, 2007

Curse you, cached broken DNS configuration

A DNS configuration glitch in the transfer of my domain registration from OpenSRS to Dreamhost has temporarily hosed email to rtfm.com. I've fixed the problem, but not before a bunch of nameservers picked up the wrong data and stuffed it in their caches. It will take hours/days for everyone's cache to expire. I believe that mail sent to me will just be queued and eventually delivered, but if you experience an error, try again on Monday.

Posted by ekr at 5:39 PM

January 7, 2007

.xxx back from the dead?

The Free Speech Association 1 reports that ICANN is re-considering the creation of the .xxx domain. As I've said before, I don't much care whether .xxx gets created or not, but it's worth checking out the proposed terms, which include all kinds of obligations for the operator to enforce content restrictions, including:

Registry Operator will prohibit child pornography, including practices that appeal to pedophiles or suggest the presence of child pornography on the site.
This seems pretty vague. The definition of what child pornography is varies quite a bit depending on which country (and even within states in the US). What set of rules are to be applied? Even within the set of things which clearly aren't child pornography, what does "practices that appeal to pedophiles". Does that include "barely-legal" type material?" If it turns out that pedophiles like kittens, will cuteoverload.xxx be out of bounds?

Registry Operator/IFFOR will impose and enforce best practices obligations including standards to:
a. Prohibit misuse of personal information
b. Require accurate meta-tagging
c. Ensure clear and accurate consumer disclosures
d. Protect IP rights
e. Prohibit use of malicious codes and technologies (i.e. spoofing)
f. Prohibit fraudulent, anonymous, or unsolicited commercial emails
g. Prohibit use of malicious redialers, credit card fraud, and/or unauthenticated use of credit cards
Section (d) is particularly interesting. If I use my .xxx domain name to download stuff from then ICM might take away my .xxx domain name?

3. Registry Operator will (i) promote the principles set forth in the United Nations Declaration of Human Rights related to free expression and (ii) prohibit child pornography as defined in the United Nations Convention on the Rights of the Child ("UNCRC")
For references, here's what the UNDHR says about free expression:
Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.
What exactly is ICM expected to do to promote these principles? Give money to the ACLU?

The whole thing is pretty long on principles and short on details.Not really surprising, since that's a pretty good description otf the notion that you can divide the Internet into adult content on one side and non-adult on the other.

1 The trade association of the adult film industry. Nice euphemism, eh?

Posted by ekr at 9:14 PM | Comments (1)