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.”
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.