NTAG rubbishes new gTLD collision risk report

The New gTLD Applicants Group has slated Interisle Consulting’s report into the risk of new gTLDs causing security problems on the internet, saying the problem is “overstated”.
The group, which represents applicants for hundreds of gTLDs and has a non-voting role in ICANN’s GNSO, called on ICANN to reclassify hundreds of “Uncalculated” risk strings as “Low” risk, meaning they would not face as substantial a delay before or uncertainty about their eventual delegation.
But NTAG said it “agreed” that the high-risk .corp and .home “should be delayed while further studies are conducted”. The current ICANN proposal is actually to reject both of these strings.
NTAG was responding to ICANN’s proposal earlier this month to delay 523 applications (for 279 strings) by three to six months while further studies are carried out.
The proposal was based on Interisle’s study of DNS root server logs, which showed many millions of daily queries for gTLDs that currently do not exist but have been applied for.
The worry is that delegating those strings would cause problems such as downtime or data leakage, where sensitive information intended for a recipient on the same local network would be sent instead to a new gTLD registry or one of its (possibly malicious) registrants.
NTAG reckons the risk presented by Interisle has been overblown, and it presented a point-by-point analysis of its own. It called for everything except .corp and .home to be categorized “Low” risk, saying:

We recognize that a small number of applied for names may possibly pose a risk to current operations, but we believe very strongly that there is no quantitative basis for holding back strings that pose less measurable threat than almost all existing TLDs today. This is why we urge the board to proceed with the applications classified as “Unknown Risk” using the mitigations recommended by staff for “Low Risk” strings. We believe the 80% of strings classified as “Low Risk” should proceed immediately with no additional mitigations.

The group pointed to a recent analysis by Verisign (which, contrarily, was trying to show that new gTLDs should be delayed) which included data about previous new gTLD delegations.
That report (pdf) said that .xxx was seeing 4,018 look-ups per million queries at the DNS root (PPM) before it was delegated. The number for .asia was 2,708.
If you exclude .corp and .home, both of those PPM numbers are multiples larger than the equivalent measures of query volume for every applied-for gTLD today, also according to Verisign’s data.
NTAG said:

None of these strings pose any more risk than .xxx, .asia and other currently operating TLDs.
…
the least “dangerous” current gTLD on the chart, .sx, had 331 queries per million in 2006. This is a higher density of NXDOMAIN queries than all but five proposed new TLDs. 4 Again, .sx was launched successfully in 2012 with none of the problems predicted in these reports.

Verisign’s report, which sought to provide a more qualitative risk analysis based on some data-supported guesses about where the error traffic is coming from and why, anticipated this interpretation.
Verisign said:

This could indicate that there is nothing to worry about when adding new TLDs, because there was no global failure of DNS when this was done before. Alternately, one might conclude that traffic volumes are not the only indicator of risk, and the semantic meaning of strings might also play a role. We posit that in some cases, those strings with semantic meanings, and which are in common use (such as in speech, writing, etc.) pose a greater risk for naming collision.

The company spent most of its report making somewhat tenuous correlations between its data (such as a relatively large number of requests for .medical from Japanese IP addresses) and speculative impacts (such as “undiagnosed system failures” at “a healthcare provider in Japan”).
NTAG, by contrast, is playing down the potential for negative outcomes, saying that in many cases the risks introduced by new gTLDs are no different from collision risks at the second level in existing TLDs.

Just as the NTAG would not ask ICANN to halt .com registrations while a twelve month study is performed on these problems, we believe there is no reason to introduce a delay in diversifying the Internet’s namespace due to these concerns.

While it stopped short of alleging shenanigans this time around, NTAG also suggested that future studies of root server error traffic could be gamed if botnets were engaged to crapflood the roots.
Its own mitigation plan, which addresses Interisle’s specific concerns, says that most of the reasons that non-existent TLDs are being looked up are either not a problem or can be easily mitigated.
For example, it says that queries for .youtube that arrived in the form of a request for “www.youtube” are probably browser typos and that there’s no risk for users if they’re taken to the YouTube dot-brand instead of youtube.com.
In another example, it points out that requests for “.cisco” or “.toshiba” without any second-level domains won’t resolve anyway, if dotless domains are banned in those TLDs. (NTAG, which has influential members in favor of dotless domains, stopped short of asking for a blanket ban.)
The Interisle report, and ICANN’s proposal to deal with it, are open for public comment until September 17. NTAG’s response is remarkably quick off the mark, for guessable reasons.

Verisign confirms .gov downtime, blames algorithm

Verisign this morning confirmed yesterday’s reports that the .gov top-level domain went down for some internet users due to a DNSSEC problem, which it said was related to an algorithm change.
In a posting to various mailing lists, Verisign principal engineer Duane Wessels said:

On the morning of August 14, a relatively small number of networks may have experienced an operational disruption related to the signing of the .gov zone. In preparation for a previously announced algorithm rollover, a software defect resulted in publishing the .gov zone signed only with DNSSEC algorithm 8 keys rather than with both algorithm 7 and 8. As a result .gov name resolution may have failed for validating recursive name servers. Upon discovery of the issue, Verisign took prompt action to restore the valid zone.
Verisign plans to proceed with the previously announced .gov algorithm rollover at the end of the month with the zone being signed with both algorithms for a period of approximately 10 days.

This clarifies that the problem was slightly different to what had been assumed yesterday.
It was related to change of the cryptographic algorithm used to create .gov’s DNSSEC keys, a relatively rare event, rather than a scheduled key rollover, which is a rather more frequent occurrence.
The problem would only have made .gov domains (and consequently web sites, email, etc) inaccessible for users of networks where DNSSEC validation is strictly enforced, which is quite small.
The US ISP with the strongest support for DNSSEC is Comcast. Since turning on its validators it has reported dozens of instances of DNSSEC failing — mostly in second-level .gov domains, where DNSSEC is mandated by US policy.
On two other occasions Comcast has blogged about the whole .gov TLD failing DNSSEC validation due to problems keeping keys up to date.
The general problem is widespread enough, and the impact severe enough, that Comcast has had to create an entirely new technology to prevent borked key rollovers making web sites go dark for its customers.
Called Negative Trust Anchors, it’s basically a Band-Aid that allows the ISP to deliberately ignore DNSSEC on a given domain while it waits for that domain’s owner to sort out its key problem.
The technology was created following the widely reported nasa.gov outage last year.
It’s really little wonder that so few organizations are interested in deploying DNSSEC today.
Yesterday’s .gov problem may have been minor, lasting only an hour or two, but had the affected TLD been .com, and had DNSSEC deployment been more widespread, everyone on the planet would have noticed.
Under ICANN contract, DNSSEC is mandatory for new gTLDs at the top level, but not the second level.

Reports: .gov fails due to DNSSEC error

The .gov top-level domain suffered a DNSSEC problem today and was unavailable to some internet users, according to reports.
According to mailing lists and the SANS Internet Storm Center, it appeared that .gov rolled one of its DNSSEC keys without telling the root zone about the update.
This meant that anyone whose DNS servers do strict DNSSEC validation — a relatively small number of networks — would have been unable to access .gov web sites, email and other resources.
As a matter of policy, all second-level .gov domains have to be DNSSEC-signed.
The problem was corrected quite quickly — looks like within an hour or two — but as SANS noted, caching issues may prolong the impact.
Both .gov and the root zone are managed by Verisign, which isn’t on the best of terms with the US government at the moment.

First string confusion decisions handed down, Verisign loses against .tvs

The International Centre for Dispute Resolution has started delivering its decisions in new gTLD String Confusion Objections, and we can report that Verisign has lost at least one case.
ICDR expert Stephen Strick delivered a brief, five-page ruling in the case of Verisign vs. T V Sundram Iyengar & Sons yesterday, ruling that .tvs is not confusingly similar to .tv.
TVS is a $6-billion-a-year, 100-year-old Indian conglomerate, while .tv is the ccTLD for Tuvalu, which Verisign manages because of its similarity of meaning to “television”.
It’s impossible to glean from the decision (pdf) what Verisign’s argument comprised. The summary is just two sentences long.
But TVS, in response, appears to have relied to an extent on the “DuPont factors” a 13-point test for trademark confusion that came out of a 1973 case in the US.
That’s the same precedent that has been found relevant in many Legal Rights Objections in cases handled by WIPO.
The “discussion and reasons for determination” section of the .tvs decision, in which Strick found that confusion was possible but not “probable”, amounts to just four sentences.
Here’s almost all of it. Emphasis in original:

in order for the Objector to prevail, Objector must prove that the co-existence of the two TLDs in question would probably result in user confusion. Given the analysis of the thirteen factors cited by Applicant derived from the DuPont case cited above, I find that Objector has failed to meet its burden of proof regarding the probability of such confusion. I note that while the co-existence of the two TLDs that are the subject of this proceeding may result in confusion by users, Objector has failed to meet its burden of proof to establish the likelihood or probability that users will be confused.
In considering parties’ arguments, I was persuaded, in part, by Applicant’s arguments relating to the commercial impression of the TVS TLD, including the proof offered by Applicant as to the longevity of the TVS brand, the limited nature of the gTLD’s intended use, the dissimilarity of the goods or services associated respectively with the two strings, ie TVS’s association with automobile products, the fact that TVS’s brand is associated with capital letters (whereas Objector’s .tv is in lower case), the fact that TVS is well known and associated with its companys’ [sic] brands, the lengthy market interface and the long historical co-existence of TVs and tv without evidence of confusion in the marketplace.

The geeks among you will no doubt be screaming at your screen right now: “WTF? He thought CASE was relevant?”
Yes, apparently the fact that the TVS trademark is in upper case makes a difference, despite the fact that the DNS is completely case-insensitive. Bit of a head-scratcher.
I understand several more decisions have also been sent to applicants and objectors, but they’re not yet pubicly available.
The ICDR’s web site for new gTLD decisions has been down for several days, returning 404 errors.

Donuts, Uniregistry and Famous Four respond to ICANN’s new gTLD security bombshell

Following the shock news this morning that ICANN wants to delay hundreds of new gTLD applications due to potential security risks, we pinged a few of the biggest applicants for their initial reactions.
Donuts, Uniregistry and Famous Four Media, which combined are responsible for over a fifth of all applications, have all responded so far, so we’re printing their statements here in full.
As a reminder, two reports published by ICANN today a) strongly warn against delegating so-called “dotless” domains and b) present significant evidence that “internal name collisions” are a real and present danger to the security and stability of many private networks.
ICANN, in response to the internal name collision issue, proposed to delay 20% of all new gTLD applications for three to six more months while more research is carried out.
It also wants to ask new gTLD registries to conduct outreach to internet users potentially affected by their delegated gTLD strings.
Of the three, Donuts seems most upset. It sent us the following statement:

One has to wonder about the timing of these reports and the motivations behind them. Donuts believes, and our own research confirms satisfactorily to us, that dotless domains and name collision are not threatening to the stability and security of the domain name system.
Name collisions, such as the NxD (in the technical parlance) collisions studied in this report, happen every day in .com, yet the study did not quantify those and Verisign does not block those names from being registered.
We’re concerned about false impressions being deliberately created and believe the reports are commercially or competitively motivated.
There is little reason to pre-empt dotless domains now when there are ICANN processes in place to evaluate them in due course. We don’t believe that ICANN resources need to be deployed at this point on understanding the potential innovations of possible uses nor any security harms.
We also think that name collision is an overstated issue. Rather than take the overdone step of halting or delaying these TLDs, if the issue really is such a concern, it would be wiser to focus on the second-level names where a conflict could occur.
As the NTIA recently wrote, Verisign’s inconsistencies on technical issues are very troubling. These issues have been thoroughly studied for some time. It’s far past due to conclude this eight-year process an move to delegation

As I haven’t previously heard any reason to doubt Interisle Consulting’s impartiality or question its motivation in writing the name collisions report I asked Donuts for clarification, but the company declined to elaborate.
Interisle has been working with ICANN for some time on various technical studies and is also one of the new gTLD program’s independent evaluators, responsible for registry services evaluations.
Uniregistry CEO Frank Schilling was also unhappy with the report. He sent the following statement:

We are deeply dismayed by this new report, both by its substance and its timing. On the substance, the concerns addressed by the report relate, primarily if not solely, to solvable problems created by third-parties using the DNS in non-standard ways. We expect that any problems will be addressed quickly by the companies and individuals that caused them in the first place.
On ICANN’s timing, it is, come just as the first new gTLDs are prepared to launch, very late and, quite obviously, highly disruptive to the long-standing business plans of the companies that relied on ICANN’s guidebook and stated timelines. Uniregistry believes that the best approach is to move forward with the launch of all new gTLDs on the existing schedule.

Finally, Famous Four Media is slightly more relaxed about the situation, judging by the statement it sent us:

Famous Four Media’s primary concern is the security and stability of the Internet. Since this is in the interest of all parties involved in the new gTLD program from registries to registrants and all in between Famous Four Media welcomes these proposals.
Whilst the latest report, and the consequent ICANN proposals, will inevitably cause delays and additional costs in the launches of new gTLDs, Famous Four Media does not believe it will impact its go-to-market plans significantly. The majority of our TLD strings are considered “low risk” and see this in a very positive light although other applicants might not afford to be as sanguine.

According to the DI PRO New gTLD Application Tracker, which has been updated with the risk levels ICANN says each applied-for gTLD poses, 18 of Famous Four’s 60 original applications are in the riskiest two categories, compared to 23 of Uniregistry’s 54 and 102 of Donuts’ of 307.

New gTLDs are the new Y2K: .corp and .home are doomed and everything else is delayed

The proposed gTLDs .home and .corp create risks to the internet comparable to the Millennium Bug, which terrorized a burgeoning internet at the turn of the century, and should be rejected.
Meanwhile, every other gTLD that has been applied for in the current round could be delayed by months in order to mitigate the risks they pose to internet users.
These are the conclusions ICANN has drawn from Interisle Consulting’s independent study into the problems that could be caused when new gTLDs clash with widely-used internal naming systems.
The extensive study, which drew on 8TB of traffic data provided by 11 of the 13 DNS root server operators, is 197 pages long and absolutely fascinating. It was published by ICANN today.
As Interisle CEO Lyman Chapin reported at the ICANN meeting in Durban a few weeks ago, the large majority of TLDs that have been applied for in the current round already receive large amounts of error traffic:

Of the 1,409 distinct applied-for TLD strings, 1,367 appeared at least once in the 2013 DITL [Day In the Life of the Internet] data with the string at the TLD position.

We’ve previously reported on the volume of queries new gTLDs get, such as the fact that .home gets half a billion hits a day and that 3% of all requests were for strings that have been applied for in the current round.
The extra value in Interisle’s report comes when it starts to figure out how many end points are making these requests, and how many second-level domains they’re looking for.
These are vitally important factors for assessing the scale of the risk of each TLD.
Again, .home and .corp appear to be the most dangerous.
Interisle capped the number of second-level domains it counted in the 2013 data at 100,000 per TLD per root server — 1,100,000 domains in total — and .home was the only TLD string to hit this cap.
Cisco Systems’ proposed .cisco TLD came close, failing to hit the cap in only one of the 11 root servers providing data, while .box and .iinet (both also used widely on home routers) hit the cap on at least one root server.
The lowest count of second-level domains of the 35 listed in the report came from .hsbc, the bank brand, but even that number was a not-inconsiderable 2,000.
Why are these requests being made?
Surprisingly, interactions between a security feature in Google’s own Chrome browser and common residential routers appear to be the biggest cause of queries for non-existent TLDs.
That issue, which impacts mainly .home, accounts for about 46% of the requests counted, according to the report.
In second place, with 15% of the queries, are requests for real domain names that appear to have had a non-existent TLD — again, usually .home — appended by a residential router or cable modem.
Apparent typos — where a user enters a URL but forgets to type the TLD — were a relatively small percentage of requests, coming in at under 1% of queries.
The study also found that bad requests come from many thousands of sources. This table compares the number of requests to the number of sources.
[table id=14 /]
The “Count” column is the number, in thousands, of requests for each TLD string. The “Prefix Count ” column refers to the number of sources providing this traffic, counted by the /24 IP address block (each of which is up to 256 potential hosts).
As you can see, there’s not necessarily a correlation between the number of requests a TLD gets and the number of people making the requests — .google gets queried by more sources than the others, but it’s only ranked 24 in terms of overall query volume, for example.
Interisle concluded from all this that .corp and .home are simply too dangerous to delegate, comparing the problem to the year 2000 bug, where a global effort was required to make sure software could support the four-digit dating scheme required by the turn of the century.
Here’s what the report says about .corp:

users could be taken to the wrong web site (and possibly be exposed to phishing attacks) or told that web sites do not exist when they do, depending on how the .corp TLD is resolved. A corporate mail system might attempt to deliver email to the wrong server, and this could expose sensitive or confidential information to someone who was not supposed to receive it. In essence, everything deployed in the private network would need to be checked.
There are no easy solutions to these problems. In an ideal world, the operators of these private networks would get a timely notification of the new TLD’s delegation and then take action to address these issues. That seems very improbable. Even if ICANN generated sufficient publicity about the new TLD’s delegation, there is no guarantee that this will come to the attention of the management or operators of the private networks that could be jeopardized by the delegation.
…
It seems reasonable to estimate that the amount of effort involved might be comparable to a wholesale renumbering of the internal network or the Y2K problem.

It notes that applied-for TLDs such as .site, .office, .group and .inc appear to be used in similar ways to .home and .corp, but do not appear to present as broad a risk.
To be clear, the risk we’re talking about here isn’t just people typing the wrong things into browsers, it’s about the infrastructure on many thousands of private networks starting to make the wrong security assumptions about domain names.
ICANN, in response, has outlined a series of measures sure to infuriate many gTLD applicants, but which are consistent with its goal to protect the security and stability of the internet.
They’re also consistent with some of the recommendations put forward by Verisign over the last few months in its campaign to show that new gTLDs pose huge risks.
First, .corp and .home are dead. These two strings have been categorized “high risk” by ICANN, which said:

Given the risk level presented by these strings, ICANN proposes not to delegate either one until such time that an applicant can demonstrate that its proposed string should be classified as low risk

Given the Y2K-scale effort required to mitigate the risks, and the fact that the eventual pay-off wouldn’t compensate for the work, I feel fairly confident in saying the two strings will never be delegated.
Another 80% of the applied-for strings have been categorized “low risk”. ICANN has published a spreadsheet explaining which string falls into which category. Low risk does not mean they get off scot-free, however.
First, all registries for low-risk strings will not be allowed to activate any domain names in their gTLD for 120 days after contract signing.
Second, for 30 days after a gTLD is delegated the new registries will have to reach out to the owners of each IP address that attempts to query names in that gTLD, to try to mitigate the risk of internal name collisions.
This, as applicants will no doubt quickly argue, is going to place them under a massive cost burden.
But their outlook is considerably brighter than that of the remaining 20% of applications, which are categorized as “uncalculated risk” and face a further three to six months of delay while ICANN conducts further studies into whether they’re each “high” or “low” risk strings.
In other words, the new gTLD program is about to see its biggest shake-up since the GAC delivered its Advice in Beijing, adding potentially millions in costs and delays for applicants.
ICANN’s proposed mitigation efforts are now open for public comment.
One has to wonder why the hell ICANN didn’t do this study two years ago.

Senators slate NTIA, to demand answers on new gTLD security

Did Verisign get to the US Congress? That’s the intriguing question emerging from a new Senate appropriations bill.
In notes attached to the bill, the Senate Appropriations Committee delivers a brief but scathing assessment of the National Telecommunication and Information Administration’s performance on ICANN’s Governmental Advisory Committee.
It says it believes the NTIA has “not been a strong advocate for U.S. companies and consumers”.
The notes would order the agency to appear before the committee within 30 days to defend the “security” aspects of new gTLDs and “urges greater participation and advocacy within the GAC”.
While the NTIA had a low-profile presence at the just-finished Durban meeting, it would be difficult to name many other governments that participate or advocate more on the GAC.
This raises an eyebrow. Which interests, in the eyes of the committee, is the NTIA not sufficiently defending?
Given the references to intellectual property, suspicions immediately fall on usual suspects such as the Association of National Advertisers, which is worried about cybersquatting and associated risks.
The ANA successfully lobbied for an ultimately fruitless Congressional hearing in late 2011, following its campaign of outrage against the new gTLD program.
It’s mellowed somewhat since, but still has fierce concerns. Judging by comments its representatives made in Durban last week, it has shifted its focus to different security issues and is now aligned with Verisign.
Verisign, particularly given the bill’s reference to “security, stability and resiliency” and the company’s campaign to raise questions about the potential security risks of new gTLDs, is also a suspect.
“Security, stability and resiliency” is standard ICANN language, with its own acronym (SSR), rolled out frequently during last week’s debates about Verisign’s security concerns. It’s unlikely to have come from anyone not intimately involved in the ICANN community.
And what of Amazon? The timing might not fit, but there’s been an outcry, shared by almost everyone in the ICANN community, about the GAC’s objection last week to the .amazon gTLD application.
The NTIA mysteriously acquiesced to the .amazon objection — arguably harming the interests of a major US corporation — largely it seems in order to play nice with other GAC members.
Here’s everything the notes to “Departments of Commerce and Justice, and Science, and related agencies appropriations Bill, 2014” (pdf) say about ICANN:

ICANN — NTIA represents the United States on the Internet Corporation for Assigned Names and Numbers [ICANN] Governmental Advisory Committee [GAC], and represents the interests of the Nation in protecting its companies, consumers, and intellectual property as the Internet becomes an increasingly important component of commerce. The GAC is structured to provide advice to the ICANN Board on the public policy aspects of the broad range of issues pending before ICANN, and NTIA must be an active supporter for the interests of the Nation. The Committee is concerned that the Department of Commerce, through NTIA, has not been a strong advocate for U.S. companies and consumers and urges greater participation and advocacy within the GAC and any other mechanisms within ICANN in which NTIA is a participant.
NTIA has a duty to ensure that decisions related to ICANN are made in the Nation’s interest, are accountable and transparent, and preserve the security, stability, and resiliency of the Internet for consumers, business, and the U.S. Government. The Committee instructs the NTIA to assess and report to the Committee within 30 days on the adequacy of NTIA’s and ICANN’s compliance with the Affirmation of Commitments, and whether NTIA’s assessment of ICANN will have in place the necessary security elements to protect stakeholders as ICANN moves forward with expanding the number of top level Internet domain names available.

While the bill is just a bill at this stage, it seems to be a strong indication that anti-gTLD lobbyists are hard at work on Capitol Hill, and working on members of diverse committees.

“Risky” gTLDs could be sacrificed to avoid delay

Google and other members of the New gTLD Applicant Group are happy to let ICANN put their applications on hold in response to security concerns raised by Verisign.
During the ICANN 46 Public Forum in Durban on Thursday, NTAG’s Alex Stamos — CTO of .secure applicant Artemis — said that agreement had been reached that about half a dozen applications could be delayed:

NTAG has consensus that we are willing to allow these small numbers of TLDs that have a significant real risk to be delayed until technical implementations can be put in place. There’s going to be no objection from the NTAG on that.

While he didn’t name the strings, he was referring to gTLDs such as .home and .corp, which were highlighted earlier in the week as having large amounts of error traffic at the DNS root.
There’s a worry, originally expressed by Verisign in April and independent consultant Interisle this week, that collisions between new gTLDs and widely-used internal network names will lead to data leakage and other security problems.
Google’s Jordyn Buchanan also took the mic at the Public Forum to say that Google will gladly put its uncontested application for .ads — which Interisle says gets over 5 million root queries a day — on hold until any security problems are mitigated.
Two members of the board described Stamos’ proposal as “reasonable”.
Both Stamos and ICANN CEO Fadi Chehade indirectly criticised Verisign for the PR campaign it has recently built around its new gTLD security concerns, which has led to somewhat one-sided articles in the tech press and mainstream media such as the Washington Post.
Stamos said:

What we do object to is the use of the risk posed by a small, tiny, tiny fraction — my personal guess would be six, seven, eight possible name spaces that have any real impact — to then tar the entire project with a big brush. For contracted parties to go out to the Washington Post and plant stories about the 911 system not working because new TLDs are turned on is completely irresponsible and is clearly not about fixing the internet but is about undermining the internet and undermining new gTLDs.

Later, in response to comments on the same topic from the Association of National Advertisers, which suggested that emergency services could fail if new gTLDs go live, Chehade said:

Creating an unnecessary alarm is equally irresponsible… as publicly responsible members of one community, let’s measure how much alarm we raise. And in the trademark case, with all due respect it ended up, frankly, not looking good for anyone at the end.

That’s a reference to the ANA’s original campaign against new gTLDs, which wound up producing not much more than a lot of column inches about an utterly pointless Congressional hearing in late 2011.
Chehade and the ANA representative this time agreed publicly to work together on better terms.

Verisign lays out ‘buy once’ IDN gTLD plans

Verisign has finally clarified how it proposes to let existing registrants of internationalized domain names grab the matching domains in its 12 forthcoming IDN gTLDs.
The company has applied for transliterations of .com in nine non-Latin scripts and .net in three, but its applications were light on details about existing registrants’ rights.
But today Verisign senior vice president Pat Kane outlined precisely how name allocations will be handled.
At first glance it sounds like good news for existing IDN registrants, particularly domainers whose investments in IDN .com and .net domains are about to become much more valuable.
If you already own a .com domain that is an IDN at the second level, you will have exclusive rights to that IDN string in all other .com transliterations, but not .net transliterations.
That works the other way around too: if you own the IDN .net domain, you get the matching second level in all of Verisign’s .net transliterations.
Owning the Chinese word for “beer” in Latin .com would not give you rights to the Thai word for “beer” in the Thai transliteration of .com, but you could buy the Chinese equivalent.
The rules seem to apply to future registrations too.
You could register the Hebrew for “beer” in the Hebrew transliteration of .com and you would also get the exclusive right to that Hebrew string in Latin .com.
There would be no obligation, and you wouldn’t lose your right to register matching domains if you chose not to immediately exercise it, Kane said. He wrote:

Two primary objectives in our strategy to implement new IDN gTLDs are, where feasible, to avoid costs to consumers and businesses from purely defensive registrations in these new TLDs, as well as to avoid end-user confusion.

It all sounds pretty fair to me, based on Kane’s blog post.
There’s a hint that trademark rights protection mechanisms may complicate matters, which has apparently been discussed in a letter to ICANN, but if it’s been published anywhere I’ve been unable to find a copy.

Verisign steps up anti-gTLD campaign with attack on ICANN’s war chest

Verisign wants ICANN to publish a list of all the reasons it might be sued over the new gTLD program, claiming security and stability risks might be one of them.
In the latest salvo fired in its war against new gTLDs, the company now suggests that the $115 million “risk fund” surplus that ICANN has accumulated is for fending off lawsuits when it breaks the internet.
In a letter (pdf) sent Friday, Verisign asks ICANN to justify the existence of this war chest in light of the fact that it has managed to secure legal indemnities from pretty much everyone involved in the program.
It attempts to link the risk fund to the possible security risks of introducing new gTLDs to the internet, which Verisign has been haranguing ICANN about for the last few months.
“We believe ICANN should be forthcoming about the risks it is shifting and the need for the substantial risk reserve fund, in particular,” the letter, signed by general counsel Richard Goshorn, says.
It’s been well known for a few years that $60,000 of each $185,000 new gTLD application fee was to be allocated to a risk fund created to cover unexpected extra program costs.
The reserve was designed to cover things like underestimating the costs or time needed to evaluate applications, but also, crucially, the lawsuits that ICANN expected but has not yet received.
The cash pile is often to referred to, usually with black humor, as the “legal defense fund”.
Now Verisign seems to be saying that the legal risks are not limited to trademark disputes or the usual antitrust nonsense, but to the security risks ICANN is “transferring” to others.
As we’ve been reporting for the last few months, Verisign has suddenly decided that new gTLDs pose a risk to the internet, largely due to the potential for clashes between newly delegated strings and the unnofficial domains that many organizations already use on their intranets.
For a great discussion on the merits of this argument check out this DI article and comment thread.
With the latest letter, Verisign suggests that ICANN knows it might be sued for messing up corporate intranets, but is keeping that fact quiet.
Referring to a report it issued in March, when its security concerns first emerged, it says:

We believe that ICANN may have established and be maintaining the Risk Reserve in such a high amount in anticipation of significant claims relating to one or more risks identified in the Verisign Report.

If ICANN does get sued on these grounds, the defense cost will effectively have been covered by new gTLD applicants (and therefore their customers, assuming the costs are passed on), Verisign says.
It’s therefore asking for ICANN to disclose the reasons why its risk fund is so big, “in particular, the details regarding what ‘possible litigation’ factored into ICANN’s decisions”.
In other words, Verisign is asking ICANN to publish a list of reasons people might sue it, something I can’t imagine its general counsel agreeing to any time soon.
Is this an effort to shame ICANN into taking its security concerns more seriously, or just more FUD designed to disrupt the new gTLD program and protect its .com dominance?
Opinions, no doubt, will be split.