ICANN's technical competence queried by Verisign report
Upcoming dossier highlights dozens of problems with domain name overseer
The report then spends some time focusing on issues surrounding the key root servers. These servers act as the internet's top-level address book; when you need to, say, visit theregister.com, your web browser can ask the root servers for the address of the systems handling .com. These will then resolve theregister.com to our load balancers' IP addresses. It's a hierarchical design, with the root servers controlling the very top level of the internet.
Verisign runs two of the 13 root servers, ICANN runs one. The root servers have been dealing with an unprecedented level of change thanks to the introduction of hundreds of new extensions and, perhaps for the first time, have come under broader scrutiny.
In response, ICANN has nudged the notoriously independent root server operators into writing documentation for the first time through its Root Server System Advisory Committee (RSSAC). Two draft documents on service levels and data have been produced.
Verisign is unhappy about the degree of progress however, sub-titling an entire section on the issue "Flying Blind". There is "little or no accountability associated with the operation of these critical infrastructure elements" the report complains, before highlighting the metrics its makes available for its 'A' and 'J' root servers.
It then lists a series of concerns that have long been raised over how the root servers operate, most of which are addressed within the draft RSSAC documents.
On this topic, Conrad as ICANN CTO notes that he agrees with many of the points raised by Verisign over needed improvements in communications, metrics and general accountability. But, he points out, ICANN has limited ability to make changes beyond the root server that it operates since it has no authority over the other operators (something that the internet community agrees is a good thing). ICANN is doing what it can by supporting the RSSAC.
What Conrad is too polite to point out in this case is that it is a little rich for Verisign to complain about root server operators when it has been running two of them, and in particular what used to be the central root server ('A'), for over 20 years. The company has only recently begun producing metrics and is all too aware that ICANN is not responsible for corralling the other operators to improve.
That said, with ICANN and Verisign in agreement that the root server operators need to up their game, the report can serve as a useful guide for how and where to improve.
Where the report raises some significant concerns over ICANN and potentially over its running of the IANA functions is when it addresses the topic of DNSSEC.
DNSSEC is the security protocol that makes it extremely difficult for so-called "man in the middle" attacks on the internet's basic infrastructure. At the highest level, ICANN, through its position as the IANA functions operator, coordinates a complicated and lengthy "key signing ceremony" every three months.
That ceremony creates an electronic key that is used to sign three months of Zone Signing Keys (ZSK), used by Verisign to sign the root zone. Taken together, it ensures the internet's core infrastructure can be sure it is talking only with authorized servers.
Verisign raises concerns over several aspects of this critical process. For one, it says the ZSKs are only 1024-bit (the Key Signing Key used to create the ZSKs is 2048-bit), which could leave them open to being compromised.
It is also unhappy that the dedicated hardware used to generate the KSK has not been replaced yet. Although it is designed to last ten years, the warranty on the hardware ends after five years and the vendor (Ultra Electronics) recommends changing them after five years. ICANN has had the hardware for six years and has been using it for five so is on the edge of the warranty.
Verisign references a report [PDF] from ICANN's own Security and Stability Advisory Committee (SSAC) from November 2013 and notes that its recommendations, on which it argues that immediate action needs to be taken, have not been implemented by ICANN.
And it highlights some technical failings that have required modification after the fact, including the wrong KSK information attached to new gTLDs, technical conditions that should have seen registries moved into an emergency failover system but were not, and several "general operational hygiene" issues. It also points out that there were a number of problems with the most recent key signing ceremony that it says "could threaten to undermine trust in the entire process".
"Such occurrences continue to plague root zone operations. It seems clear that expediency tends to trump technical rigor and advisability," the report argues.
From the company that arguably has the most important role in the internet's entire infrastructure, the section is a damning indictment of ICANN's technical ability.
ICANN CTO Conrad addresses the issues by first noting that while the DNSSEC hardware does indeed come with a five-year replacement recommendation it is guaranteed for 10 years, and the organization is also preparing to replace it in the first quarter of 2015 (he notes that Verisign is aware of this fact).
"Yes, we should have replaced them before five years and so by changing them in year six, there is a slight risk, but that is also why we have multiple key signing facilities," he noted. "We are still well within the specifications." As to the ZSK key length, that is largely under Verisign's control.
He notes that the report is actually very useful in highlighting security, stability and resiliency issues and says the organization is studying it to determine which of the concerns raised ICANN can deal with, particularly any that may be new.
Taken overall, the report from Verisign does raise serious questions over how ICANN prioritizes its core technical functions.
This is an issue that has been gathering pace in recent years with the organization focused more on the business side of new gTLDs than its technical responsibilities and with its executives and Board members spending far more time (and money) on broader internet governance issues.
ICANN spent $1.4m on expenses [PDF] for its 23 Board members alone on top of their $500,000 compensation between June 2013 and July 2014. And CEO Fadi Chehade spent $360,000 solely on flights in the same time period as he flew around the world talking about ICANN and its role in internet governance.
Although ICANN's revenues have exploded in the past year thanks to the millions of dollars that the new gTLD program has brought in, the job that the entire organization was created to carry out - the technical underpinnings of the internet - accounts for just five per cent of its budget.
Verisign does have an ulterior motive in highlighting how ICANN is falling down on its technical responsibilities - it causes Verisign as the root zone maintainer, dot-com registry operator and operator of two root servers to look more competent and may strengthen its position as the root zone maintainer.
While it has not yet released the report, Verisign has highlighted much of its content in a submission [PDF] to the IANA transition proposal. In that submission, it repeatedly highlights its role as a stable entity within the internet's root zone while questioning ICANN's "uneven performance record". The message is clear: keep us in place for a stable internet.
However the fact that Verisign is able to put together a 33-page report full of dozens of examples of where ICANN is found wanting should serve as a warning sign both to ICANN and the broader technical community of likely underfunding and under-resourcing of vital internet functions.
"Many of the problems discussed in this report serve as fair warning," the report notes. "Specifically, they constitute early indicators of larger operational problems ahead. As in the title of this report, one could view these as foreshocks, both to ongoing operations, and to the confidence that stakeholders have in the DNS in general." ®
- Black Hat
- Common Vulnerability Scoring System
- Cybersecurity and Infrastructure Security Agency
- Cybersecurity Information Sharing Act
- Data Breach
- Data Protection
- Data Theft
- Digital certificate
- Identity Theft
- Kenna Security
- Palo Alto Networks
- Trusted Platform Module
- Zero trust