As ICANN opened its 30th meeting in Los Angeles on Monday, the .uk registry Nominet released a short position paper on DNSSEC — and focused on the issue of signing the root zone. Intentionally or not, Nominet's paper validates IGP's long-held contention that there are major public policy issues around DNSSEC. In it they highlight the need for a single trust anchor and warn against alternative solutions. They emphasize the need for the keys to be managed by ICANN/IANA and used by the root zone maintainer to sign the root, and, most importantly, the necessity of opening up root management through “enhanced cooperation.”
Like many other organizations (e.g., RIPE), Nominet wants a single trust anchor. Furthermore, they believe it should reside in the same point of the DNS hierarchy as the single authoritative list of TLDs (i.e., the root zone file under DOC/ICANN control). In their words, “anything else would be splitting the root” and would hinder DNSSEC adoption. Their request appears to be a response to two risks: one is that alternative trust anchor schemes might be adopted first, especially DNS Lookaside Validation (DLV) which ISC has currently implemented and is pushing. The other is the threat that the self signing of zones by early adopter registries like .se and .br will become widespread.
Nominet suggests that creating and maintaining of root zone KSKs and ZSKs reside with the IANA function of ICANN. IANA would then distribute the public portions of the KSKs and the public and private portions of the ZSKs to an unspecified root zone maintainer (RZM) for use in signing the root zone file. The paper stipulates that the RZM would actually sign the root zone file, “following agreed algorithms,” and publish the public portions of the KSK and ZSK. Nominet does “not believe there is any role for a third party in this process.” But strangely, Nominet continues on to say that their “proposal would not alter (or strengthen) the role currently undertaken by the US Government” who is clearly a third party in the process and makes the final call on what resource records go in the root zone file.
In granting the actual signing function to an unspecified RZM, Nominet recognizes the power of that role. The caveat about “agreed algorithms” is something that has had little attention paid to it but is incredibly important. Without means for agreement, only the RZM would have its hand on the knob that determines the difficulty of breaking digital signatures associated with root zone file data. One can easily see how TLD operators might be concerned about a US-based private sector communications company fulfilling this role, especially given the recent history between US national security interests and telecom companies and VeriSign's well-known close ties to the USG. If the RZM continues to be VeriSign, inquiring minds would certainly want to know, what/who would guide VeriSign's decision in algorithm selection, and how could this impact the security of DNSSEC-enabled TLD zones? To whom would VeriSign be accountable?
Most importantly though, Nominet argues that “mechanisms incorporated into the Tunis Agenda, such as the process towards enhanced cooperation, together with ongoing discussions within the Internet Governance Forum, should incorporate the expanded root management function, including DNSSEC signing.” Essentially, Nominet seems to be arguing unsurprisingly that decisions about implementing technologies at the root of the global Internet require broad discussion among those affected and expanded oversight. No single government or organization should be in charge of critical global infrastructure.
So, how exactly is “enhanced cooperation” occurring now? Unfortunately, there was a not so positive sign at this week's ICANN meeting. Tuesday there was a closed session on DNSSEC for members of the Governmental Advisory Group (GAC). Some ccTLD operators were invited as well, but apparently no civil society actors. According to the chair of ICANN's Security and Stability Committee and a DNSSEC Deployment Initiative group member, the GAC has asked for a briefing on DNSSEC “starting with what it is and why it's important.” The agenda is supposed to be an overview of DNSSEC, the IANA implementation, and a discussion of signing the root. The individual was hoping to “focus [the discussion] on the technical role signing the root plays” while trying “to finesse the political aspects.”
That's not a fair representation of our view on root politics in this position paper.
First, the RZM is not unspecified, it is a contracted function operated by Verisign with defined processes. The paper uses RZM to make it clear that it is the function that is important, not the company fulfilling it.
Second, what the paper clearly says is that DNSSEC is a technical issue not a political issue as IGP are mistakenly claiming. There are already concerns about root politics and DNSSEC does not change those concerns, for better or worse.
Jay:
Is “enhanced cooperation” — your paper's choice of words — a technical process? Is the Tunis Agenda, the document from which those words are taken, an RFC?
Oh, and I forgot: you note correctly that the RZM is a “contracted function.” Is that contracting with VeriSign conducted bilaterally with the USG, or are other stakeholders involved? Is that a “technical” issue?
“Enhanced co-operation” already exists, the RZM already exists. Without DNSSEC they would still exist.
There is still no case to say the technical function of DNSSEC changes anything.
DNSSEC just makes things more visible. Once deployed, every nameserver system administrator will encounter a configuration element, i.e. root trust anchor, which is cryptographically bound to some “entity.” No worry for the overwhelming wast majority of cases.
But in the very few cases where the “entity” qualification matters, it triggers an escalation of political concerns.
The political concerns are already influencing the way the USG is handling its unique oversight position over ICANN. DNSSEC does not change this, it just makes it more acute.
I would like to see the view that DNSSEC changes nothing supported by a better document. The current one assumes the RZM function to be separate from IANA, while in fact it is being “transitioned” to ICANN, by the will of the USG and the efforts of IANA (and Verisign?). Turning to DNSSEC technicalities, does it matter that root KSKs and ZSKs are generated and used by a single entity?
– Thierry Moreau
Thierry:
In your first five sentences I believe you got it exactly right. But if those statements are true, then the view that “DNSSEC changes nothing” is clearly not true. If the choice of a contracting party matters and is political, if the procedures adopted affect a large number of people and affects the distribution of power, then there are political issues. IGP is not making an argument exclusively about DNSSEC. We are making an argument about how the political governance structures handle DNSSEC. This means one must understand both the technology and the organizational and political implications of how regimes adapt to the technology. Technologists can contribute to this debate best, not by denying that there is any political dimension, but by keeping everyone honest about how the organizational and governance processes interface with the technology.
Sorry Thierry but that again is making too much of this If there is a problem over who the TLD is then that already affects changing nameservers in the root zone. DNSSEC just means one more bit of data, but does not change the dependencies and so does not change the politics.
If IANA does incorporate the RZM function (and you appear to know something there that nobody else does) then sure the mechanism we suggest should change. But the mechanism should fit the root management arrangements, not dictate them.
Since you ask, here are sonme references, all public information.
The “root transition agreement” is a contractual provision between ICANN and Verisign, which was also subject to NTIA approval, for “completion of the transition to ICANN of those technical coordination and management functions currently undertaken by VeriSign with respect to the ARPA TLD and the root zone system, in particular to enable ICANN to edit, sign and publish the root zone and ARPA zones” (http://www.icann.org/topics/vrsn-settlement/revised-root-transition-agreement-clean-29jan06.pdf and http://www.icann.org/topics/verisign-settlement.htm).
The ICANN 2007/2008 Operating Plan describes the IANA root zone management project as “complete the implementation of automated root zone management tools begun through relationship with NASK and use of mutually developed code and procedures” (http://www.icann.org/planning/ops-plan-strategic-view-fy07-08_rev1_14may07.pdf and http://www.icann.org/planning/).
See also a related ICANN announcement at http://www.icann.org/announcements/announcement-05jul06.htm.
Hey, if that's not ICANN transparency, I'm lost!
– Thierry Moreau