ICANN’s Security and Stability Advisory Committee issued its long-overdue review of Site Finder, and concluded that not only should such services not be allowed, but that existing industry standards should be rewritten to prevent them.
According to Steve Crocker, chair of the SSAC and the report’s nominal author, the report recommends: One – don’t do this kind of thing. Two – in places where they’re already doing this kind of thing, roll it back.
Site Finder, introduced last September, intercepted misspelled domain name lookups in .com and .net and, in cases where a browser was making the request, sent users to a page of links and advertising, rather than an error message.
The service, which was roundly criticized by technologists, was expected to make VeriSign $13m of revenue this year, but was reluctantly turned off after two weeks when ICANN said it was a risk to the stability of the internet.
Crocker said that the existing Internet Engineering Task Force domain name system technical standards should be cleaned up to clarify that so-called wildcard systems such as Site Finder are not permitted in top-level domains.
The DNS standards (or, in IETF lingo, RFCs) permit the use of wildcards in DNS servers, but Crocker said: It was always intended to be used in very narrow contexts. Not, he said, in major top-level domains.
The report also says that such registry services should be subject to lengthy notice and analysis before they are introduced. Public notice of Site Finder’s imminent arrival comprised just articles published by ComputerWire and the Wall Street Journal.
The main criticism of Site Finder is that while its service only applies to the web, all internet DNS lookups are affected by it. This interferes with applications that rely on consistent error reporting, the report says.
This created substantial and destabilizing effects, the report says. The oft-touted example is of spam filters that do DNS lookups to spot spoofed From: addresses. Crocker said it also interfered with porn filters in Tennessee schools.
It also meant that when somebody mistyped the domain in the To: field of an email, VeriSign would receive data about the sender and intended recipient. The company said it would not store that data, but privacy advocates were still concerned.
Crocker said that he has no reason not to trust VeriSign’s claim, but said that it could set a precedent where other, less trustworthy, parties could feel it is acceptable to intercept and store email data in the same way.
Information about e-mail senders and recipients entered VeriSign’s computers… If another registry operator chose to implement a similar service, it is possible that this information, as well as the content of the message itself, could be accepted and stored, the SSAC report says.
VeriSign on Friday said that SSAC’s findings are built on shaky ground. Tom Galvin, VP of government relations, said: We are surprised that nine months after they began the review, they still have not presented any data to back up their claims.
We are not surprised by the outcome, considering key members explained their views even before they held hearings on Site Finder, Galvin said. ICANN told VeriSign to turn Site Finder off based on SSAC’s preliminary review last October.
VeriSign recently named Crocker and several other members of the SSAC as co-conspirators in its lawsuit against ICANN, which it is suing because of alleged interference with Site Finder and other services.
The firm, which does have a seat on the 18-person committee, says these conspirators helped kill Site Finder off for competitive reasons. The company needs to show a conspiracy to have its antitrust charges against ICANN stick.
While the SSAC report was widely expected to come down heavily on VeriSign, it is somewhat unexpected that it recommends that the DNS RFCs retroactively prohibit Site Finder, and that existing wildcard services should be turned off.
There are about 15 TLDs, including .museum and .tv, that are already services similar to Site Finder. In the case of .museum, the wildcard service is actually specifically permitted by the registry’s contract with ICANN.
The report should draw a line under the involvement of SSAC, which was established in 2001 following the 9/11 terrorist attacks. Three of its recommendations are directed at ICANN, the fourth at the IETF.
The report is seven months late, having been scheduled to be published in November last year. Crocker said he takes sole responsibility for its tardiness. It was a matter of resources, he said. Eventually, a writer had to be hired to produce the 85-page document, he said.
