Verisign today said that the new gTLD program presents risks to the security of the internet, but ICANN CEO Fadi Chehade told DI that he’s not expecting any new delays.
The .com behemoth tonight delivered a scathing review of the security and stability risks of launching new gTLDs on ICANN’s current timetable.
The new Verisign report catalogs the myriad ways in which ICANN is not ready to start approving new gTLDs, and the various security problems they could cause if launched without due care.
It strongly suggests that ICANN should delay the program until its concerns are addressed.
But Chehade, in an exclusive interview with DI tonight, rebutted the already-emerging conspiracy theories and said: “There’s nothing new here that would cause me to predict a new delay.”
What does the Verisign report say?
It’s a 21-page document, and it covers a lot of ground.
The gist of it is that ICANN is rushing to launch new gTLDs without paying enough attention to the potential security and stability risks that a vast influx of new gTLDs could cause.
It covers about a dozen main points, but here are the highlights:
- Certificate authorities and browser makers are not ready. CAs have long issued certificates for use on organizations’ internal networks. In many cases, these certs will use TLDs that only exist on that internal network. A company might have a private .mail TLD, for example, and use certs to secure those domains for its users. The CA/Browser Forum, which coordinates CAs and browser makers, has decided (pdf) to deprecate these certs, but not until October 2016. This, Verisign says, creates a “vulnerability window” of three years during which attackers could exploit clashes between certs on internal TLDs and new gTLDs.
- Root server operators are not ready. The organizations that run the 13 DNS root servers do not currently coordinate their performance metrics, Verisign said. This makes it difficult to see what impact new gTLDs will have on root server stability. “The current inability to view the root server system’s performance as a whole presents a risk when combined with the impending delegation of the multitude of new gTLDs,” Verisign said.
- Root zone automation isn’t done yet. ICANN, Verisign and the US Department of Commerce are responsible for adding new gTLDs to the root zone, and work on automating the “TLD add” process is not yet complete. Verisign reckons this could cause “data integrity” problems at the root.
- The Trademark Clearinghouse is not ready. Delays in finalizing the TMCH technical specs mean registries haven’t had sufficient time to build their interfaces and test them, and the TMCH itself is a potential single point of failure with an unknown attack profile.
- Universal acceptance of new TLDs. Verisign points out that new gTLDs won’t be immediately available to users when they go live due to lack of software support. It points specifically to the ill-maintained Public Suffix List, used by browsers to set cookie boundaries, as a potential risk factor.
- A bunch of other stuff. The report highlights issues such as zone file access, data escrow, Whois and pre-delegation testing where Verisign reckons ICANN has not given registries enough time to prepare.
Basically, Verisign has thrown pretty much every risk factor it can think of into the document.
Some of the issues of concern have been well-discussed in the ICANN community at large, others not so much.
Yeah, yeah, but what did Fadi say?
Chehade told DI this evening that he was surprised by the report. He said he’s been briefed on its contents today and that there’s “nothing new” in it. The program is “on track”, he said.
“What is most surprising here is that there is nothing new,” he said. “I’m trying to get my finger on what is new here and I can’t find it.”
“It was very surprising to see this cornucopia of things put together,” he said. “I’m struggling to see how the Trademark Clearinghouse has a security impact, for example.”
He added that some of Verisign’s other concerns, such as the fact that the Emergency Back-End Registry Operator is not yet up and running, are confusing given that existing TLDs don’t have EBEROs.
The report could be divided into two buckets, he said: those things related to ICANN’s operational readiness and those things related to the DNS root.
“Are these operational issues really security and stability risks, and given that we can only launch TLDs when these things are done… what’s the issue there?” he said.
On the DNS root issues, he pointed to a November 2012 report, signed by Verisign, that said the root is ready to take 1,000 new gTLDs a year or 100 a week.
So the Conspiracy Theory is wrong?
When ICANN held a webinar for new gTLD applicants earlier this week, Chehade spent an inordinate amount of time banging home the point that security and stability concerns underpin every stage of the new gTLD program’s timetable.
As this slide from his presentation (click to enlarge) illustrates, security, stability and resiliency or “SSR” is the foundation of every timing assumption.
He said during the webinar:
Nothing will trump the gTLD process, nothing, but the SSR layer. The SSR layer is paramount. It is our number one responsibility to the internet community. Nothing will be done that jeopardizes the security and stability of the internet, period.
At any time if we as a community do not believe that all relevant security and stability matters have been addressed, if we do not believe that’s the case, the program freezes, period.
There is too much riding on the DNS. Hundreds of billions of dollars of commerce. Some may say livelihoods. We will not jeopardize it, not on my watch, not during my administration.
During the webinar, I was lurking on an unofficial chat room of registries, registrars and others, where the mood at that point could be encapsulated by: “Shit, what does Chehade know that he’s not telling us?”
Most people listening to the webinar were immediately suspicious that Chehade was expecting to receive some last-minute security and stability advice and that he was preparing the ground for delay.
The Verisign report was immediately taken as confirmation that their suspicions were correct.
It seemed quite likely that ICANN knew in advance that the report was coming down the pike and was not-so-subtly readying applicants for a serious SSR discussion in Beijing a little over a week from now.
When I asked Chehade a few times whether he knew the Verisign report was coming in advance, he declined to give a straight answer.
My feeling is he probably did, though he may not have known precisely what it was going to say. The question is perhaps less relevant given what he said about its contents.
But what Chehade thinks right now is probably not the biggest concern for new gTLD applicants.
The GAC’s reaction is now critical
The Verisign document could be seen as pure GAC fodder. How the Governmental Advisory Committee reacts to the report, which was CC’d to the US Department of Commerce, is now key.
The GAC has been banging on about root system stability for years and will, in my view, lap up anything that seems to prove that it was right all along.
The GAC will raise the Verisign report with ICANN in Beijing and, if it doesn’t like what it hears, it might advise delay. GAC advice is a lot harder for ICANN’s board to ignore than a self-serving Verisign report.
What’s Verisign playing at?
So why did Verisign issue the report now? I’ve been unable to get the company on the phone at this late hour, but I’ve asked some other industry folk for their responses.
Verisign’s super-lucrative .com contract is the obvious place to start theorizing.
Even though the company has over 200 new gTLD back-end contracts — largely with dot-brand applicants — .com is its cash cow and new gTLDs are a potential threat to that business.
The company has sounded a little more aggressive — talking about enforcing its patents and refusing to comply with ICANN’s audits — since the US Department of Commerce ordered a six-year .com price freeze last November.
But Chehade would not speculate too much about Verisign’s motives.
“I can’t read why this report and why now,” Chehade said. “Especially when there’s nothing new in it. That’s not for me to figure out. It’s for me to look at this report with a critical eye and understand if there’s something we’re not addressing. If there is, and we find it, we’ll address it.”
He pointed to a flurry of phone calls and emails to his desk after the Initial Evaluation results started getting published last week for a possible reason for the report’s timing.
“I think the real change that’s happened in the last few months is that the new gTLD program is now on track and for the first time people are seeing it coming,” he said.
Competitors were more blunt.
“It’s a bloody long report,” said ARI Registry Services CEO Adrian Kinderis. “Had they put the same amount of effort into working with ICANN, we’d be a lot better off on the particular issues.”
Owners of .edu domain names have been told to change their passwords after hackers compromised a server belonging to registry manager Educause.
The registry said today that it has deactivated the admin passwords for all .edu domains after discovering a “security breach” that gave attackers access to hashed passwords for .edu registrants.
The attack also compromised passwords for users of the Educause web site, the organization said.
The .edu domain is of course reserved for US-based educational institutions, and is considered one of the most secure and prestigious TLDs available.
Educause said it “immediate steps to contain this breach and is working with Federal law enforcement, investigators, and security experts to make sure this incident is properly addressed.”
The registry did not say whether the attack is related to the attack against the Massachusetts Institute of Technology last month, which reportedly was enabled via an Educase hack.
While most new gTLD applicants were focused on delays to the program revealed during last Friday’s ICANN webinar, another bit of news may also be a cause for concern for .home applicants.
As Rubens Kuhl of Nic.br spotted, ICANN revealed that 11 applications have not yet passed their DNS Stability check.
That’s a reversal from November, when ICANN said that all new gTLD applications had passed the stability review.
As I noted at the time, that was good news for .home, which some say may cause security problems if it is delegated.
As Kuhl observed, there are exactly 11 applications for .home, the same as the number of applications that now appear to have un-passed the DNS Stability check.
So is ICANN taking a closer look at .home, or is it just a numerical coincidence?
The string is considered risky by many because .home already receives a substantial amount of DNS traffic at the root servers, which will be inherited by whichever company wins the contention set.
It’s on a list of frequently requested invalid TLDs produced by ICANN’s Security and Stability Advisory Committee which was incorporated by reference in the new gTLD Applicant Guidebook.
Some major ISPs, notably BT in the UK, use .home as a pseudo-TLD in their residential routers.
IEDR, the Irish ccTLD registry, has admitted that an attack on its own web servers was responsible for google.ie and yahoo.ie being hijacked last month.
In a detailed statement, the registry said that hackers spent 25 days probing for weaknesses in its systems, before eventually breaking in through a vulnerability in the Joomla content management software.
This enabled the attackers to upload malicious PHP scripts and access the back-end database, according to the statement. They then redirected yahoo.ie and google.ie to an Indonesian web site.
It’s a reverse of position for IEDR, which had appeared to blame one of its registrars (believed to be Mark Monitor) for the lapse in security when the hack was discovered last month.
IEDR told ZDNet October 11: “an unauthorised change was made to two .ie domains on an independent registrar’s account which resulted in a change of DNS nameservers”.
But today it said instead: “The IEDR investigation also confirmed that neither the Registrar of the affected domains nor its systems had any responsibility for this incident.”
The registry has filed a complaint with the Irish police over the incident, and apologized to its customers for the disruption.
It also said it plans to roll out a Domain Lock service to help prevent hijacking in future, though I doubt such a service would have prevented this specific incident.
The number of cybersquatted domain names being used for phishing is falling sharply and currently stands at just 2% of attacks, according to the Anti-Phishing Working Group.
The APWG’s first-half 2012 report (pdf) identified 64,204 phishing domains in total.
Of those, the group believes that only 7,712 (12%) were actually registered by the phishers themselves. The rest belonged to innocent third parties and had been compromised.
That’s a steep drop from 12,895 domains in the second half of 2011 and 14,650 in the first half of 2011.
Of the 7,712 phisher-owned domains, about 66% were being use to phish Chinese targets, according to the APWG.
The group’s research found only 1,350 that contained a brand name or a misspelling of a brand name.
That’s down from 2,232 domains in the second-half of 2011, representing just 2% of all phishing domains and 17% of phisher-owned domains.
The report states:
Most maliciously registered domain strings offered nothing to confuse a potential victim. Placing brand names or variations thereof in the domain name itself is not a favored tactic, since brand owners are proactively scanning Internet zone files for such names.
As we have observed in the past, the domain name itself usually does not matter to phishers, and a domain name of any meaning, or no meaning at all, in any TLD, will usually do.
Instead, phishers almost always place brand names in subdomains or subdirectories. This puts the misleading string somewhere in the URL, where potential victims may see it and be fooled. Internet users are rarely knowledgeable enough to be able to pick out the “base” or true domain name being used in a URL.
Taken as a percentage of attacks, brand-jacking is clearly a pretty low-occurrence offence, according to the APWG’s numbers.
In absolute numbers, it works out to about 7.5 domain names per day that are being use to phish and contain a variation of the brand name being targeted.
Unsurprisingly, the APWG found that Freedom Registry’s .tk — which offers free registration — is the TLD being abused most often to register domains for phishing attacks.
More than half of the phisher-owned domains were in .tk, according to the report.