Report names and shames most-abused TLDs

Newish gTLDs .tel and .xxx are among the most secure top-level domains, while .cn and .pw are the most risky.
That’s according to new gTLD services provider Architelos, which today published a report analyzing the prevalence of abuse in each TLD.
Assigning an “abuse per million domains” score to each TLD, the company found .tel the safest with 0 and .cn the riskiest, with a score of 30,406.
Recently relaunched .pw, which has had serious problems with spammers, came in just behind .cn, with a score of 30,151.
Generally, the results seem to confirm that the more tightly controlled the registration process and the more expensive the domain, the less likely it is to see abuse.
Norway’s .no and ICM Registry’s .xxx scored 17 and 27, for example.
Surprisingly, the free ccTLD for Tokelau, .tk, which is now the second-largest TLD in the world, had only 224 abusive domains per million under management, according to the report..
Today’s report ranked TLDs with over 100,000 names under management. Over 90% of the abusive domains used to calculate the scores were related to spam, rather than anything more nefarious.
The data was compiled from Architelos’ NameSentry service, which aggregates abusive URLs from numerous third-party sources and tallies up the number of times each TLD appears.
The methodology is very similar to the one DI PRO uses in TLD Health Check, but Architelos uses more data sources. NameSentry is also designed to automate the remediation workflow for registries.

Artemis signs 30 anchor tenants for .secure gTLD

Artemis, the NCC Group subsidiary applying for .secure, says it has signed up 30 big-name customers for its expensive, high-security new gTLD offering.
CTO Alex Stamos said that the list includes three “too big to fail” banks and three of the four largest social networking companies. They’ve all signed letters of intent to use .secure domains, he said.
He was speaking at a small gathering of customers and potential customers in London yesterday, to which DI was invited on the condition that we not report the name of anyone else in attendance.
Artemis is doing this outreach despite the facts that a) .secure is still in a two-way contention set and b) deep-pocketed online retailer Amazon is the other applicant.
Stamos told DI he’s confident that Artemis will win .secure one way or the other — hopefully Amazon’s single-registrant bid will run afoul of ICANN’s current rethink of “closed generics”.
He expects to launch .secure in the second or third quarter of next year with a few dozen registrants live from pretty much the start.
The London event yesterday, which was also attended by executives from a few household names, was the second of three the company has planned. New York was the first and there’ll soon be one in California.
I’m hearing so many stories about new gTLD applicants that still haven’t figured out their go-to-market strategies recently that it was refreshing to see one that seems to be on the ball.
Artemis’ vision for .secure is also probably the most technologically innovative proposed gTLD that I’m currently aware of.
As the name suggests, security is the order of the day. Registrants would be vetted during the lengthy registration process and the domain names themselves would be manually approved.
Not only will there not be any typosquatting, but there’s even talk of registering common typos on behalf of registrants.
Registrants would also be expected to adhere to levels of security on their web sites (mandatory HTTPS, for example) and email systems (mandatory TLS). Domains would be scanned daily for malware and would have manual penetration testing at least annually.
Emerging security standards would be deployed make sure that browsers would only trust SSL certificates provided by Artemis (or, more likely, its CA partner) when handling connections to .secure sites.
Many of the policies are still being worked out, sometimes in conversation with an emerging “community” of the aforementioned anchor tenants, but there’s one thing that’s pretty clear:
This is not a domain name play.
If you buy a .secure domain name, you’re really buying an NCC managed security service that allows you to use a domain name, as opposed to an easily-copied image, as your “trust mark”.
Success for .secure, if it goes live as planned, won’t be measured in registration volume. I wouldn’t expect it to be much bigger than .museum, the tiniest TLD today, within its first few years.
Prices for .secure have not yet been disclosed, but I’m expecting them to be measured in the tens of thousands of dollars. If “a domain” costs $50,000 a year, don’t be surprised.
Artemis’ .secure would however be available to any enterprise that can afford it and can pass its stringent security tests, which makes it more “open” than Amazon’s vaguely worded closed generic bid.
Other ICANN accredited registrars will technically be allowed to sell .secure domains, but the Registry-Registrar Agreement will be written in such a way as to make it economically non-viable for them to do so.
Overall, the company has a bold strategy with some significant challenges.
I wonder how enthusiastic enterprises will be about using .secure if their customers start to assume that their regular domain name (which may even be a dot-brand) is implicitly insecure.
Artemis is also planning to expose some information about how well its registrants are complying with their security obligations to end users, which may make some potential registrants nervous.
Even without this exposure, simply complying appears to be quite a resource-intensive ongoing process and not for the faint-hearted.
However, that’s in keeping with the fact that it’s a managed security service — companies buy these things in order to help secure their systems, not cover up problems.
Stamos also said that its eligibility guidelines are being crafted with its customers in such a way that registrants will only ever be kicked out of .secure if they’re genuinely bad actors.
Artemis’ .secure is a completely new concept for the gTLD industry, and I wouldn’t like to predict whether it will work or not, but the company seems to be going about its pre-sales marketing and outreach in entirely the correct way.

ICANN offers to split the cost of GAC “safeguards” with new gTLD registries

All new gTLD applicants will have to abide by stricter rules on security and Whois accuracy under government-mandated changes to their contracts approved by the ICANN board.
At least one of the new obligations is likely to laden new gTLDs registries with additional ongoing costs. In another case, ICANN appears ready to shoulder the financial burden instead.
The changes are coming as a result of ICANN’s New gTLD Program Committee, which on on Tuesday voted to adopt six more pieces of the Governmental Advisory Committee’s advice from March.
This chunk of advice, which deals exclusively with security-related issues, was found in the GAC’s Beijing communique (pdf) under the heading “Safeguards Applicable to all New gTLDs”.
Here’s what ICANN has decided to do about it.
Mandatory Whois checks
The GAC wanted all registries to conduct mandatory checks of Whois data at least twice a year, notifying registrars about any “inaccurate or incomplete records” found.
Many new gTLD applicants already offered to do something similar in their applications.
But ICANN, in response to the GAC advice, has volunteered to do these checks itself. The NGPC said:

ICANN is concluding its development of a WHOIS tool that gives it the ability to check false, incomplete or inaccurate WHOIS data
…
Given these ongoing activities, ICANN (instead of Registry Operators) is well positioned to implement the GAC’s advice that checks identifying registrations in a gTLD with deliberately false, inaccurate or incomplete WHOIS data be conducted at least twice a year. To achieve this, ICANN will perform a periodic sampling of WHOIS data across registries in an effort to identify potentially inaccurate records.

While the resolution is light on detail, it appears that new gTLD registries may well be taken out of the loop completely, with ICANN notifying their registrars instead about inaccurate Whois records.
It’s not the first time ICANN has offered to shoulder potentially costly burdens that would otherwise encumber registry operators. It doesn’t get nearly enough credit from new gTLD applicants for this.
Contractually banning abuse
The GAC wanted new gTLD registrants contractually forbidden from doing bad stuff like phishing, pharming, operating botnets, distributing malware and from infringing intellectual property rights.
These obligations should be passed to the registrants by the registries via their contracts with registrars, the GAC said.
ICANN’s NGPC has agreed with this bit of advice entirely. The base new gTLD Registry Agreement is therefore going to be amended to include a new mandatory Public Interest Commitment reading:

Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.

The decision to include it as a Public Interest Commitment, rather than building it into the contract proper, is noteworthy.
PICs will be subject to a Public Interest Commitment Dispute Resolution Process (PICDRP) which allows basically anyone to file a complaint about a registry suspected of breaking its commitments.
ICANN would act as the enforcer of the ruling, rather than the complainant. Registries that lose PICDRP cases face consequences up to an including the termination of their contracts.
In theory, by including the GAC’s advice as a PIC, ICANN is handing a loaded gun to anyone who might want to shoot down a new gTLD registry in future.
However, the proposed PIC language seems to be worded in such a way that the registry would only have to include the anti-abuse provisions in its contract in order to be in compliance.
Right now, the way the PIC is worded, I can’t see a registry getting terminated or otherwise sanctioned due to a dispute about an instance of copyright infringement by a registrant, for example.
I don’t think there’s much else to get excited about here. Every registry or registrar worth a damn already prohibits its customers from doing bad stuff, if only to cover their own asses legally and keep their networks clean; ICANN merely wants to formalize these provisions in its chain of contracts.
Actually fighting abuse
The third through sixth pieces of GAC advice approved by ICANN this week are the ones that will almost certainly add to the cost of running a new gTLD registry.
The GAC wants registries to “periodically conduct a technical analysis to assess whether domains in its gTLD are being used to perpetrate security threats such as pharming, phishing, malware, and botnets.”
It also wants registries to keep records of what they find in these analyses, to maintain a complaints mechanism, and to shut down any domains found to be perpetrating abusive behavior.
ICANN has again gone the route of adding a new mandatory PIC to the base Registry Agreement. It reads:

Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

You’ll notice that the language is purposefully vague on how registries should carry out these checks.
ICANN said it will convene a task force or GNSO policy development process to figure out the precise details, enabling new gTLD applicants to enter into contracts as soon as possible.
It means, of course, that applicants could wind up signing contracts without being fully apprised of the cost implications. Fighting abuse costs money.
There are dozens of ways to scan TLDs for abusive behavior, but the most comprehensive ones are commercial services.
ICM Registry, for example, decided to pay Intel/McAfee millions of dollars — a dollar or two per domain, I believe — for it to run daily malware scans of the entire .xxx zone.
More recently, Directi’s .PW Registry chose to sign up to Architelos’ NameSentry service to monitor abuse in its newly relaunched ccTLD.
There’s going to be a fight about the implementation details, but one way or the other the PIC would make registries scan their zones for abuse.
What the PIC does not state, and where it may face queries from the GAC as a result, is what registries must do when they find abusive behavior in their gTLDs. There’s no mention of mandatory domain name suspension, for example.
But in an annex to Tuesday’s resolution, ICANN’s NGPC said the “consequences” part of the GAC advice would be addressed as part of the same future technical implementation discussions.
In summary, the NGPC wants registries to be contractually obliged to contractually oblige their registrars to contractually oblige their registrants to not do bad stuff, but there are not yet any obligations relating to the consequences, to registrants, of ignoring these rules.
This week’s resolutions are the second big batch of decisions ICANN has taken regarding the GAC’s Beijing communique.
Earlier this month, it accepted some of the GAC’s direct advice related to certain specific gTLDs it has a problem with, the RAA and intergovernmental organizations and pretended to accept other advice related to community objections.
The NGPC has yet to address the egregiously incompetent “Category 1” GAC advice, which was the subject of a public comment period.

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.

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.

Google domain hijacked in Kenya

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.

Verisign’s security angst no reason to delay new gTLDs, says expert

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.
Much of this is detailed in a report issued by SSAC last month (pdf). The CA/Browser Forum’s guidance is here (pdf). Falstrom’s PowerPoint is available here (pdf)

Six big reasons we won’t see any new gTLD launches until Q3

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.
Wrong.
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.
I think CEO Fadi Chehade’s push to make the industry look more respectable will also play a part, with the promotion of the Registrant Rights and Responsibilities document.
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.

ANA calls for new gTLDs delay, again

The Association of National Advertisers has seized upon Verisign’s recent report into the security risks of ICANN’s new gTLD timetable to call for delays to the program.
In a blog post yesterday, ANA vice president Dan Jaffe said ICANN’s dismissal of the surprising Verisign letter is “like the Captain of the Titanic before the crash saying that the dangers of icebergs had been discussed for years.”
The post highlights the lack of finalized Trademark Clearinghouse specs as “one of the greatest concerns”, saying “millions of customers are the ones who will face harm”.
That’s not strictly true, of course. New gTLD registries are contractually unable to launch until the TMCH is ready, so the risk of registrants being harmed by the lack of specs today is a non-starter.
The ANA also points to ongoing concerns about proposed TLDs such as .corp and .home, which run the risk of clashing with existing private TLDs used on internal corporate and ISP networks.
It’s on much firmer ground here. If a user tries to access a LAN resource on a .corp domain while roaming, what’s to stop them sending sensitive data to a third-party web site instead?
I’ve yet to see a compelling reason why this is not a problem, but it’s not yet known whether the many applications for .corp, .home and similar strings have passed their ICANN technical evaluations.
The ICANN application form asked applicants to disclose potential operational problems such as these, but some applicants that were very familiar with the problem decided not to do so.
But the ANA’s main concern is its belief that new gTLDs will increase cybersquatting and increase the cost of defensive registrations, of course.
“Adequate steps have not been taken to protect Internet users, and we are headed toward uncharted waters with major danger to consumers, brandholders, and the Internet itself,” Jaffe wrote.
“The only prudent action for ICANN now is to delay this arbitrary domain name roll-out until it has fixed these very serious problems.”