Verisign says people might die if new gTLDs are delegated

If there was any doubt in your mind that Verisign is trying to delay the launch of new gTLDs, its latest letter to ICANN and the Governmental Advisory Committee advice should settle it.
The company has ramped up its anti-expansion rhetoric, calling on the GAC to support its view that launching new gTLDs now will put the security and stability of the internet at risk.
People might die if some strings are delegated, Verisign says.
Among other things, Verisign is now asking for:

• Each new gTLD to be individually vetted for its possible security impact, with particular reference to TLDs that clash with widely-used internal network domains (eg, .corp).
• A procedure put in place to throttle the addition of new gTLDs, should a security problem arise.
• A trial period for each string ICANN adds to the root, so that new gTLDs can be tested for security impact before launching properly.
• A new process for removing delegated gTLDs from the root if they cause problems.

In short, the company is asking for much more than it has to date — and much more that is likely to frenzy its rivals — in its ongoing security-based campaign against new gTLDs.
The demands came in Verisign’s response to the GAC’s Beijing communique, which detailed government concerns about hundreds of applied-for gTLDs and provided frustratingly vague remediation advice.
Verisign has provided one of the most detailed responses to the GAC advice of any ICANN has received to date, discussing how each item could be resolved and/or clarified.
In general, it seems to support the view that the advice should be implemented, but that work is needed to figure out the details.
In many cases, it’s proposing ICANN community working groups. In others, it says each affected registry should negotiate individual contract terms with ICANN.
But much of the 12-page letter talks about the security problems that Verisign suddenly found itself massively concerned about in March, a week after ICANN started publishing Initial Evaluation results.
The letter reiterates the potential problem that when a gTLD is delegated that is already widely used on internal networks, security problems such as spoofing could arise.
Verisign says there needs to be an “in-depth study” at the DNS root to figure out which strings are risky, even if the volume of traffic they receive today is quite low.
It also says each string should be phased in with an “ephemeral root delegation” — basically a test-bed period for each new gTLD — and that already-delegated strings should be removed if they cause problems:

A policy framework is needed in order to codify a method for braking or throttling new delegations (if and when these issues occur) either in the DNS or in dependent systems that provides some considerations as to when removing an impacting string from the root will occur.

While it’s well-known that strings such as .home and .corp may cause issues due to internal name clashes and their already high volume of root traffic, Verisign seems to want every string to be treated with the same degree of caution.
Lives may be on the line, Verisign said:

The problem is not just with obvious strings like .corp, but strings that have even small query volumes at the root may be problematic, such as those discussed in SAC045. These “outlier” strings with very low query rates may actually pose the most risks because they could support critical devices including emergency communication systems or other such life-supporting networked devices.
…
We believe the GAC, and its member governments, would undoubtedly share our fundamental concern.

The impact of pretty much every recommendation made in the letter would be to delay or prevent the delegation of new gTLDs.
A not unreasonable interpretation of this is that Verisign is merely trying to protect its $800 million .com business by keeping competitors out of the market for as long as possible.
Remember, Verisign adds roughly 2.5 million new .com domains every month, at $7.85 a pop.
New gTLDs may well put a big dent in that growth, and Verisign doesn’t have anything to replace it yet. It can’t raise prices any more, and the patent licensing program it has discussed has yet to bear fruit.
But because the company also operates the primary DNS root server, it has a plausible smokescreen for shutting down competition under the guise of security and stability.
If that is what is happening, one could easily make the argument that it is abusing its position.
If, on the other hand, Verisign’s concerns are legitimate, ICANN would be foolhardy to ignore its advice.
ICANN CEO Fadi Chehade has made it clear publicly, several times, that new gTLDs will not be delegated if there’s a good reason to believe they will destabilize the internet.
The chair of the SSAC has stated that the internal name problem is largely dealt with, at least as far as SSL certificates go.
The question now for ICANN — the organization and the community — is whether Verisign is talking nonsense or not.

Is the .home new gTLD doomed? ICANN poses study of security risks

ICANN has set up a study into whether certain applied-for new gTLD strings pose a security risk to the internet, admitting that some gTLDs may be rejected as a result.
Its board of directors on Saturday approved new research into the risk of new gTLD clashes with “internal name certificates”, saying that the results could kill off some gTLD applications.
In its rationale, the board stated:

it is possible that study might uncover risks that result in the requirement to place special safeguards for gTLDs that have conflicts. It is also possible that some new gTLDs may not be eligible for delegation.

Internal name certificates are the same digital certificates used in secure, web-based SSL transactions, but assigned to domain names in private, non-standard namespaces.
Many companies have long used non-existent TLDs such as .corp, .mail and .home on their private networks and quite often they obtain SSL certs from the usual certificate authorities in order to enable encryption between corporate resources and their internal users.
The problem is that browsers and other applications on laptops and other mobile devices can attempt to access these private namespaces from anywhere, not only from the local network.
If ICANN should set these TLD strings live in the authoritative DNS root, registrants of clashing domain names might be able to hijack traffic intended for secure resources and, for example, steal passwords.
That’s obviously a worry, but it’s one that did not occur to ICANN’s Security and Stability Advisory Committee until late last year, when it immediately sought out the help of the CA/Browser Forum.
It turned out the the CA/Browser forum, an alliance of certificate authorities and browser makers, was already on the case. It has put in new rules that state certificates issued to private TLDs that match new gTLDs will be revoked 120 days after ICANN signs a contract with the new gTLD registry.
But it’s still not entirely clear whether this will sufficiently mitigate risk. Not every CA is a member of the Forum, and some enterprises might find 120 day revocation windows challenging to work with.
Verisign recently highlight the internal certificate problem, along with many other potential risks, in an open letter to ICANN.
But both ICANN CEO Fadi Chehade and the chair of SSAC, Patrick Falstrom, have said that the potential security problems are already being addressed and not a reason to delay new gTLDs.
The latest board resolution appears to modify that position.
The board has now asked CEO Fadi Chehade and SSAC to “consider the potential security impacts of applied-for new-gTLD strings in relation to this usage.”
The Root Server Stability Advisory Committee and the CA/Browser Forum will also be tapped for data.
While the study will, one assumes, not be limited to any specific applied-for gTLD strings, it’s well known that some strings are more risky than others.
The root server operators already receive vast amounts of erroneous DNS traffic looking for .home and .corp, for example. If any gTLD applications are at risk, it’s those.
There are 10 remaining applications for .home and five for .corp.