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.
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.
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.
Google’s Kenyan web site was reportedly inaccessible yesterday due to a hijacking of the company’s local domain name.
Google.co.ke briefly redirected users to a site bearing the slogan “hacked” on a black background, according to the Daily Nation. A change of DNS was blamed.
Google Kenya reportedly said:
Google services in Kenya were not hacked. For a short period, some users visiting www.google.co.ke and a few other website were re-directed to a different website. We are in contact with the organisation responsible for managing domain names in Kenya.
Google is of course a high-profile target; hackers often exploit weaknesses at third-party providers such as domain name registries in order to take down its satellite sites.
Its Irish site was taken down in October last year, after attackers broke in through a vulnerability in IEDR’s Joomla content management system.
Potential security vulnerabilities recently disclosed by Verisign and PayPal are well in hand and not a reason to delay the launch of new gTLDs, according to the chair of ICANN’s security committee.
Patrick Falstrom, chair of the Security and Stability Advisory Committee, said today that the risk of disastrous clashes between new gTLDs and corporate security certificates has been taken care of.
Talking to the GNSO Council at the ICANN public meeting in Beijing, he gave a definitive “no” when asked directly if the SSAC would advise ICANN to delay the delegation of new gTLDs for security reasons.
Falstrom had given a presentation on “internal name certificates”, one of the security risks raised by Verisign in a paper last week.
These are the same kinds of digital certificates given out by Certificate Authorities for use in SSL transactions on the web, but to companies for their own internal network use instead.
The SSAC, judging by Falstrom’s presentation, had a bit of an ‘oh-shit’ moment late last year when a member raised the possibility of new gTLDs clashing with the domain names on these certificates.
Consider the scenario:
A company has a private namespace on its LAN called .corp, for example, where it stores all of its sensitive corporate data. It uses a digital certificate, issued by a reputable CA, to encrypt this data in transit.
But today we have more than a few applicants for .corp that would use it as a gTLD accessible to the whole internet.
Should .corp get delegated by ICANN — which of course is by no means assured — then there could be the risk of CAs issuing certificates for public domains that clash with private domains.
That might enable, for example, a hacker on a Starbucks wifi network to present his evil laptop as a secured, green-padlocked, corporate server to an unlucky road warrior sitting in the same cafe.
According to Falstrom, at least 157 CAs have issued certificates that clash with applied-for new gTLDs. The actual number is probably much higher.
This risk was outlined in Verisign’s controversial security report to ICANN, which recommended delay to the new gTLD program until security problems were resolved, two weeks ago.
But Falstrom told the GNSO Council today that recent secretive work by the SSAC, along with ICANN security staff and the CA/Browser Forum, a certificate industry authority, has mitigated this risk to the point that delay is not needed.
Falstrom said that after the SSAC realized that there was a potential vulnerability, it got it touch with the CA/Browser Forum to share its concerns. But as it turned out, the Forum was already on the case.
The Forum decided in February, a couple of weeks after an SSAC briefing, that member CAs should stop issuing internal name certificates that clash with new gTLDs within 30 days of ICANN signing a registry contract for that gTLD.
It has also decided to revoke any already-issued internal domain certificate that clashes with a new gTLD within 120 days of contract signing.
This means that the vulnerability window will be much shorter, should the vulnerability start getting exploited in wild.
But only if all CAs conform to the CA/Browser Forum’s guidelines.
ICANN’s announcement of a big media bash in New York on April 23, to announce the launch of new gTLDs, has gotten many people thinking the first launches are imminent.
We’re not going to see any new gTLD domains on sale until the third quarter at the earliest, in my view, and here are a few good reasons why.
April 23 is just a PR thing
ICANN has said that April 23 is primarily about awareness-raising.
Not only does it hope to garner plenty of column inches talking about new gTLDs — helping the marketing efforts of their registries — it also hopes to ceremonially sign the first Registry Agreements.
But there’s never been any suggestion that any strings will be delegated at that time, much less go live.
The contracts are still hugely controversial
If ICANN wants to sign a Registry Agreement on April 23, it’s going to need a Registry Agreement to sign.
Right now, applicants are up in arms about ICANN’s demand for greater powers to amend the contract in future.
While ICANN has toned down its proposals, they may still be unacceptable to many registries and gTLD applicants.
Applicants have some impetus to reach agreement quickly — because they want to launch and start making money as soon as possible.
But ICANN wants the same powers added to the 2013 Registrar Accreditation Agreement, and registrars are generally less worried about the speedy approval of new gTLDs.
ICANN has tied the approval of the RA and the RAA together — only registrars on the new RAA will be able to sell domains in new gTLDs.
Chehade has also made it clear that agreement on the new RAA is a gating issue for new gTLD launches.
If registries, registrars and ICANN can’t settle these issues in Beijing, it’s hard to see how any contracts could be signed April 23. The first launch would be delayed accordingly.
GAC Advice might not be what we’re expecting
GAC Advice on New gTLDs is, in my view, the biggest gating issue applicants are facing right now.
GAC Advice is an integral part of the approval process outlined in the Applicant Guidebook and ICANN has said many times that it cannot and will not sign any contracts until the GAC has spoken.
But what does that mean from a process and timing point of view?
According to the Applicant Guidebook, if an application receives GAC Advice, it gets shunted from the main evaluation track to the ICANN board of directors for consideration.
It’s the only time the ICANN board has to get directly involved with the approval process, according to the Guidebook’s rather complex flow-charts.
GAC Advice is not an automatic death sentence, but any application the GAC is unanimously opposed to stands a very slim chance of getting approved by the board.
Given that ICANN is has said it will not sign contracts until it has received GAC Advice, and given that it has said it wants to sign the first contract April 23, it’s clearly expecting to know which applications are problematic and which are not during the next three weeks.
But I don’t think that’s necessarily going to happen. The GAC moves slowly and it has a track record of missing ICANN-imposed deadlines, which it often seems to regard as irksome.
Neither ICANN nor the GAC have ever said GAC Advice on New gTLDs will be issued during next week’s public meeting in Beijing. If a time is given it’s usually “after” or “following” Beijing.
And I don’t think the GAC, which decided against holding an inter-sessional meeting between Toronto and Beijing, is remotely close to providing a full list of specific applications of concern.
I do think a small number of slam-dunk bad applications – such as DotConnectAfrica’s .africa bid – will get Advised against during or after the Beijing meeting.
But I also think the GAC is likely to issue Advice that is much broader, and which may not provide the detail ICANN needs to carry the process forward for many applicants.
The GAC, in its most recent (delayed) update, is still talking about “categories” of concern – such as “consumer protection” and “geographical names” – some of which are very broad indeed.
Given the limited amount of time available to it in Beijing, I think it’s quite likely that the GAC is going to produce advice about categories as well as about individual applications.
And, crucially, I don’t think it’s necessarily going to give ICANN a comprehensive list of which specific applications fall into which categories.
If the GAC decides to issue Advice under the banner of “consumer protection”, for example, somebody is going to have to decide which applications are captured by that advice.
Is that just strings that relate to regulated industries such as pharmaceuticals or banking? Or is it any string that relates to selling stuff? What about .shop and .car? Shops and cars are “regulated” by consumer protection and safety laws in most countries.
Deciding which Advice covered which applications would not be an easy task, nor would it be a quick one. I don’t think the GAC has done this work yet, nor do I think it will in Beijing.
For the GAC to reach consensus advice against specific applications will in some cases require GAC representatives to return to their capitals for guidance, which would add delay.
There is, in my view, a very real possibility of more discussions being needed following Beijing, just in order to make sense of what the GAC comes up with.
The new gTLD approval process needs the GAC to provide a list of specific applications or strings with which it has concerns, and we may not see that before April 23.
ICANN may get a short list of applications that definitely do have Advice by then, but it won’t necessarily know which applications do not, which may complicate the contract-signing process.
The Trademark Clearinghouse still needs testing
The Trademark Clearinghouse is already, in one sense, open for business. Trademark owners have been able to submit their marks for validation for a couple of weeks now.
But the hard integration work has not been done yet, because the technical specifications the registries and registrars need to interface with IBM’s TMCH database have not all been finalized.
When the specs are done (it seems likely this will happen in the next few weeks), registries and registrars will need to finish writing their software and start production testing.
ICANN’s working timetable has the TMCH going live July 1, but companies that know much more than me about the technical issues at play here say it’s unlikely that they’ll be ready to go live with Sunrise and Trademark Claims services before August.
It’s in everyone’s interests to get all the bugs ironed out before launch.
For new gTLD registries, a failure of the centralized TMCH database could mean embarrassing bugs and downtime during their critical launch periods.
Trademark owners and domain registrants may also be concerned about the potential for loopholes.
For example, it’s still not clear to some how Trademark Claims – which notifies registrants when there’s a clash between a trademark and a domain they want – will interact with landrush periods.
Does the registrant only get a warning when they apply for the domain, which could be some weeks before a landrush auction? If so, what happens if a mark is submitted to the TMCH between the application and the auction and ultimate registration?
Is that a loophole to bypass Trademark Claims? Could a registrant get hit by a Claim after they’ve just spent thousands to register a domain?
These are the kinds of things that will need to be ironed out before the TMCH goes fully live.
There’s a sunrise notice period
The sunrise period is the first stage of launch in which customers get to register domain names.
Lest we forget, ICANN recently decided to implement a mandatory 30-day notice period for every new gTLD sunrise period. This adds a month to every registry’s go-live runway.
Because gTLD sunrise periods from now on all have to use the TMCH, registries may have to wait until the Clearinghouse is operational before announcing their sunrise dates.
If the TMCH goes live in July, this would push the first launch dates out until August.
Super-eager registries may of course announce their sunrise period as soon as they are able, and then delay it as necessary to accommodate the TMCH, but this might carry public relations risks.
Verisign’s security scare
It’s still not clear how Verisign’s warning about the security risks of launching new gTLDs on the current timetable will be received in Beijing.
If the GAC reckons Verisign’s “concerns” are valid, particularly on the issue of root zone stability, ICANN will have to do a lot of reassuring to avoid being advised to delay its schedule.
Could ICANN offer to finish off its work of root zone automation, for example, before delegating new gTLDs? To do so would add months to the roll-out timetable.