Crocker to speak at second gTLD collisions summit

ICANN chair Steve Crocker is among a packed line-up of speakers for an event on Tuesday that will address the potential security risks of name collisions in the new gTLD program.
It’s the second TLD Security Forum, which are organized by new gTLD applicants unhappy with ICANN’s proposal to delay hundreds of “uncalculated risk” applied-for gTLDs.
The first event, held in August, was notable for statements playing down the risk from the likes of Google and Digicert.
While Crocker is scheduled to speak on Tuesday, anyone expecting insight into the ICANN board’s thinking on name collisions is likely to be disappointed.
The title of his talk is “The Current State of DNSSEC Deployment”, which isn’t directly relevant to the issue.
Crocker, due to conflicts of interest protections, is also not a member of ICANN’s New gTLD Program Committee, which is tasked with making decisions about the collision problem.
While Crocker’s views may wind up remaining private, we can’t say the same for Amy Mushahwar and Dan Jaffe, representing the Association of National Advertisers, both of whom are also speaking.
The ANA is firmly in the Verisign camp on this issue, claiming that gTLD name collisions create unacceptable security risks for organizations on the internet.
Also on the line-up for Tuesday are Laureen Kapin of the US Federal Trade Commission and Gabriel Rottman of the American Civil Liberties Union, both of whom could bring new perspectives to the debate.
The TLD Security Forum begins at 9am at the Washington Hilton and Heights Meeting Center in Washington, DC. It’s free to attend and will be webcast for those unable to show up in person.

.CLUB offers solution to name collision risks

.CLUB Domains has come up with a simple workaround for its applied-for .club gTLD being categorized as risky by ICANN.
The company wants to reserve the top 50 .club domains that currently see DNS root traffic, so that if and when .club goes live the impact on organizations that use .club internally will be greatly reduced.
It’s not a wholly original idea, but .CLUB seems to be unique at the moment in that it actually knows what those 50 strings are, having commissioned an Interisle Consulting report of its proposed gTLD.
You’ll recall that Interisle is the company that ICANN commissioned to quantify the name collisions problem in the first place.
Its report is what ICANN used to categorize all applied-for gTLD strings into low, high and “uncalculated” risks, putting .club into the uncalculated category, delaying it by months.
(Interisle was at pains to point out in its report for .CLUB that it is not making any recommendations, interpreting the data, or advocating any solutions. Still, nice work if you can get it.)
By reserving the top 50 clashes — presumably in such a way that they will continue to return error responses after .club is delegated — .CLUB says .club would slip into ICANN’s definition of a low-risk string.
In a letter to ICANN (pdf) sent today, .CLUB chief technology officer Dirk Bhagat wrote:

blocking the 50 SLD strings from registration would prevent 52,647 out of the 89,533 queries from a potential collision (58.88%). After blocking the top 50 strings as SLD strings, only 36,886 (41.12%) queries remain, which is 12,114 fewer invalid queries at the root than .engineering, which ICANN classified as a low risk gTLD.

He adds that a further chunk of remaining SLDs are random strings that appear to have been created by Google’s Chrome browser and, many say, pose no risk of name collisions, reducing the risk further.
It’s hard to argue with the logic there, other than to say that ICANN’s categorization system itself has already come in for heavy criticism for drawing unjustified, arbitrary lines.
The list of domains .CLUB proposes to block is pretty interesting, including some strings that appear to be trademarks, the names of likely .club registrants, or potentially premium names.

Verisign targets bank claims in name collisions fight

Verisign has rubbished the Commonwealth Bank of Australia’s claim that its dot-brand gTLD, .cba, is safe.
In a lengthy letter to ICANN today, Verisign senior vice president Pat Kane said that, contrary to CBA’s claims, the bank is only responsible for about 6% of the traffic .cba sees at the root.
It’s the latest volley in the ongoing fight about the security risks of name collisions — the scenario where an applied-for gTLD string is already in broad use on internal networks.
CBA’s application for .cba has been categorized as “uncalculated risk” by ICANN, meaning it faces more reviews and three to six months of delay while its risk profile is assessed.
But in a letter to ICANN last month, CBA said “the cause of the name collision is primarily from CBA internal systems” and “it is within the CBA realm of control to detect and remediate said systems”.
The bank was basically claiming that its own computers use DNS requests for .cba already, and that leakage of those requests onto the internet was responsible for its relatively high risk profile.
At the time we doubted that CBA had access to the data needed to draw this conclusion and Verisign said today that a new study of its own “shows without a doubt that CBA’s initial conclusions are incorrect”.
Since the publication of Interisle Consulting’s independent review into root server error traffic — which led to all applied-for strings being split into risk categories — Verisign has evidently been carrying out its own study.
While Interisle used data collected from almost all of the DNS root servers, Verisign’s seven-week study only looked at data gathered from the A-root and J-root, which it manages.
According to Verisign, .cba gets roughly 10,000 root server queries per day — 504,000 in total over the study window — and hardly any of them come from the bank itself.
Most appear to be from residential apartment complexes in Chiba, Japan, where network admins seem to have borrowed the local airport code — also CBA — to address local devices.
About 80% of the requests seen come from devices using DNS Service Discovery services such as Bonjour, Verisign said.
Bonjour is an Apple-created technology that allows computers to use DNS to automatically discover other LAN-connected devices such as printers and cameras, making home networking a bit simpler.
Another source of the .cba traffic is McAfee’s antivirus software, made by Intel, which Verisign said uses DNS to check whether code is virus-free before executing it.
While error traffic for .cba was seen from 170 countries, Verisign said that Japan — notable for not being Australia — was the biggest source, with almost 400,000 queries (79% of the total). It said:

Our measurement study reveals evidence of a substantial Internet-connected infrastructure in Japan that lies beneath the surface of the public-facing internet, which appears to rely on the non-resolution of the string .CBA.
This infrastructure appear hierarchical and seems to include municipal and private administrative and service networks associated with electronic resource management for office and residential building facilities, as well as consumer devices.

One apartment block in Chiba is is responsible for almost 5% of the daily .cba queries — about 500 per day on average — according to Verisign’s letter, though there were 63 notable sources in total.
ICANN’s proposal for reducing the risk of these name collisions causing problems would require CBA, as the registry, to hunt down and warn organizations of .cba’s impending delegation.
Verisign reiterates the point made by RIPE NCC last month: this would be quite difficult to carry out.
But it does seem that Verisign has done a pretty good job tracking down the organizations that would be affected by .cba being delegated.
The question that Verisign’s letter and presentation does not address is: what would happen to these networks if .cba was delegated?
If .cba is delegated, what will McAfee’s antivirus software do? Will it crash the user’s computer? Will it allow unsafe code to run? Will it cause false positives, blocking users from legitimate content?
Or will it simply fail gracefully, causing no security problems whatsoever?
Likewise, what happens when Bonjour expects .cba to not exist and it suddenly does? Do Apple computers start leaking data about the devices on their local network to unintended third parties?
Or does it, again, cause no security problems whatsoever?
Without satisfactory answers to those questions, maybe name collisions could be introduced by ICANN with little to no effect, meaning the “risk” isn’t really a risk at all.
Answering those questions will of course take time, which means delay, which is not something most applicants want to hear right now.
Verisign’s study targeted CBA because CBA singled itself out by claiming to be responsible for the .cba error traffic, not because CBA is a client of rival registry Afilias.
The bank can probably thank Verisign for its study, which may turn out to be quite handy.
Still, it would be interesting to see Verisign conduct a similar study on, say, .windows (Microsoft), .cloud (Symantec) or .bank (Financial Services Roundtable), which are among the 35 gTLDs with “uncalculated” risk profiles that Verisign promised to provide back-end registry services for before it decided that new gTLDs were dangerous.
You can read Verisign’s letter and presentation here. I’ve rotated the PDF to make the presentation more readable here.

ICANN’s name collision plan “creates risk of abuse”

One of ICANN’s proposed methods of reducing the risk of name collisions in new gTLDs actually may create its own “significant risk for abuse”, according to RIPE NCC.
Asking registry operators to send a notification to the owner of IP address blocks that have done look-ups of their TLD before it is delegated risks creating a “backlash” against ICANN and registry operators, RIPE said.
Earlier this month, ICANN said that for the 80% of applied-for strings that are categorized as low risk, “the registry operator will notify the point of contacts of the IP addresses that issue DNS requests for an un-delegated TLD or names under it.”
The proposal is intended to reduce the risk of harms caused by the collision of new gTLDs and matching names that are already in use on internal networks.
For example, if the company given .web discovers that .web already receives queries from 100 different IP blocks, it will have to look up the owners of those blocks with the Regional Internet Registries and send them each an email telling them than .web is about to hit the internet.
RIPE is the RIR for Europe, responsible for allocating IP addresses in the region, so its view on how effective a mitigation plan this is cannot be easily shrugged off.
Chief scientist Daniel Karrenberg told ICANN today that the complexity of the DNS, with its layers of recursive name servers and such, makes the approach pointless:

The notifications will not be effective because they will typically not reach the party that is potentially at risk.

In addition, it will be trivial for mischief-makers to create floods of useless notifications by conducting deliberately erroneous DNS queries for target TLDs, he said:

anyone can cause the registry operator to send an arbitrary amount of mandatory notifications to any holder of IP address space. It will be highly impractical to detect such attacks or find their source by technical means. On the other hand there are quite a number of motivations for such an attack directed at the recipient or the sender of the notifications. The backlash towards the registry operator, ICANN and other parties in the chain will be even more severe once the volume increases and when it turns out that the notifications are for “non-existing” queries.

With a suitably large botnet, it’s easy to see how an attacker could generate the need for many thousands of mandatory notifications.
If the registry has a manual notification process, such a flood would effectively DDoS the registry’s ability to send the notices, potentially delaying the gTLD.
Even if the process were to be automated, you can imagine how IP address block owners (network admins at ISPs and hosting companies, for example) would respond to receiving notifications, each of which creates work, from hundred of affected gTLD operators.
It’s an interesting view, and one that affected new gTLD applicants (which is most of them) will no doubt point to in their own comments on the name collisions mitigation plan.

Bank takes blame for gTLD name collision

The Commonwealth Bank of Australia, which has applied for the new gTLD .cba, has told ICANN that its own systems are to blame for most of the error traffic the string sees at the DNS root.
The company wants ICANN to downgrade its gTLD application to “low risk” from its current delay-laden “uncalculated” status, saying that it can remediate the problem itself.
Since the publication of Interisle Consulting’s name collisions report, CBA said it has discovered that its own systems “make extensive use of ‘.cba’ as a strictly internal domain.”
Leakage is the reason Interisle’s analysis of root error traffic saw so many occurrences of .cba, the bank claims:

As the cause of the name collision is primarily from CBA internal systems and associated certificate use, it is within the CBA realm of control to detect and remediate said systems and internal certificate use.

One has to wonder how CBA can be so confident based merely on an “internal investigation”, apparently without access to the same extensive and highly restricted data set Interisle used.
There are many uses of the string CBA and there can be no guarantees that CBA is the only organization spewing internal DNS queries out onto the internet.
CBA’s comment is however notable for being an example of a bank that is so unconcerned about the potential risks of name collision that it’s happy to let ICANN delegate its dot-brand without additional review.
This will surely help those who are skeptical about Interisle’s report and ICANN’s response to it.

Artemis plans name collision conference next week

Artemis Internet, the NCC Group subsidiary applying for .secure, is to run a day-long conference devoted to the topic of new gTLD name collisions in San Francisco next week.
Google, PayPal and DigiCert are already lined up to speak at the event, and Artemis says it expects 60 to 70 people, many of them from major new gTLD applicants, to show up.
The free-to-attend TLD Security Forum will discuss the recent Interisle Consulting report into name collisions, which compared the problem in some cases to the Millennium Bug and recommended extreme caution when approving new gTLDs.
Brad Hill, head of ecosystem security at PayPal, will speak to “Paypal’s Concerns and Recommendations on new TLDs”, according to the agenda.
That’s notable because PayPal is usually positioned as being aligned with the other side of the debate — it’s the only company to date Verisign has been able to quote from when it tries to show support for its own concerns about name collisions.
The Interisle report led to ICANN recommending months of delay for hundreds of new gTLD strings — basically every string that already gets more daily root server error traffic than legitimate queries for .sj, the existing TLD with the fewest look-ups.
The New TLD Applicants Group issued its own commentary on these recommendations, apparently drafted by Artemis CTO Alex Stamos, earlier this week, calling for all strings except .home and .corp to be treated as low risk.
NTAG also said in its report that it has been discussing with SSL certificate authorities ways to potentially speed up risk-mitigation for the related problem of internal name certificate collisions, so it’s also notable that DigiCert’s Dan Timpson is slated to speak at the Forum.
The event may be webcast for those unable to attend in person, according to Artemis. If it is, DI will be “there”.
—
On the same topic, ICANN yesterday published a video interview with DNS inventor Paul Mockapetris, in which he recounted some name collision anecdotes from the Mesolithic period of the internet. It’s well worth a watch.