[Editors Note: Apologies for the belated writeup of an informative panel discussion on the implications of DNSSEC deployment and signing the root.]
“If you hold the [DNSSEC] keys you can decide who is the root zone file editor and who are the root servers. You hold the keys to the Internet kingdom.” – Paul Vixie
On May 17, 2007, IGP, George Mason University Law School's Critical Infrastructure Protection Program and the EPFL eGov program hosted a panel on DNS Security Extensions (DNSSEC) at the Swiss Embassy in Washington DC. Several recognized technical experts from the private sector, ICANN and the US government discussed the deployment of DNSSEC, and in particular the policy dimensions of digitally signing the Internet’s root zone file. The audience of nearly 80 people included Department of Commerce officials, US government contractors, policy-makers, public-interest advocates and graduate students. Moderated by Brenden Kuerbis of the Internet Governance Project, the panel included Paul Vixie (ISC), David Conrad (IANA), Scott Rose (US Department of Commerce-NIST), Matt Larson (VeriSign), and Thierry Moreau (Connotech). The discussion highlighted major technical challenges facing DNSSEC deployment, and the effects of root signing on tld zone operators and the Internet’s Domain Name System (DNS).
(Dis)incentives to deploy
The panel agreed that while the DNSSEC standard is mostly complete, the protocol is difficult to implement operationally. As a security retrofit, there are some conflicts with already deployed DNS update protocols. The complexity of DNSSEC implementation can increase the need for technical skill in IT staff, and can produce unexpected failure modes. For instance, Conrad noted how simple time synchronization issues had resulted in a zone “disappearing” from the Internet. Larson noted how these kinds of complications are magnified in large zones, e.g., .com, which processes 25 billion queries per day on average.
Even if all the technological issues are resolved, DNSSEC faces a classic “chicken and egg” adoption problem: DNSSEC is most valuable for secure applications, but who will deploy and buy secure applications until DNSSEC is installed? As the prices of gtld zone operators are regulated by ICANN, VeriSign and other registries currently have no pricing model (and therefore little incentive) for providing DNSSEC services. Rose claimed that NIST was trying to lay an egg or hatch a chicken. Larson noted that registrars will demand DNSSEC when their customers do, creating the potential for additional registrar revenue. Early indications from the Swedish registry are that it has been able to charge twice as much for a secure domain name, providing some indication of a market for DNSSEC services. The financial services sector seems a likely candidate for DNSSEC services.
A major concern voiced by Conrad, and acknowledged by others, is the associated liability that any root signing authority would assume. The historical assumption was that IANA would sign the root but this was based on a “different world” in the early 1990s. While the 2006 ICANN-VeriSign settlement agreement included language that some infrastructure services would migrate to ICANN, Conrad maintained signing the root is not clearly in the scope of the IANA contract. However, IANA is now signing .arpa and its children zones at the request of the IETF’s Internet Architecture Board. And if requested by the USG, IANA would sign any zone for which it is authoritative (this includes 5 zones).
Why is signing the root important, who should do it?
Signing the root is important to tld zone operators because it is an irreversible operation. A root trust anchor would get configured into millions of resolvers. Conrad noted the risks associated with signing any zone and key rollover. If a key of a zone high up in the DNS hierarchy is compromised you have to go out to every caching server on the planet to notify them to change their trust anchor. However, there is no protocol for doing that, so it has to be manual. In the meantime, the resolvers won’t work. According to Larson, VeriSign is reluctant to sign the .com and .net zones without having the root signed. Any signing of the .com zone by VeriSign without a single root zone trust anchor would be a “point of no return” because of the costs associated with trust anchor distribution.
The panelists were asked about IGP’s proposal to sign the root using multiple root key operators (RKOs). While Conrad was open to more than one party being involved in root signing operations, Larson said that VeriSign, as the current root zone maintainer (RZM), would prefer to work with a single party. He said that publishing the root zone file twice a day, every day, is a significant operational burden. Additional root key operators add lots of moving parts and may affect the reliability of the system. Rose agreed, saying the more moving parts the more likely they are to break. However, there could be a separation of the key signing key (KSK) and zone signing key (ZSK). A KSK keyset could be shipped around “a bit more” between root key operators (RKOs), but the root zone file changes many times and should be signed with the ZSK by the RZM.
Vixie mentioned a 2002 IETF Internet-draft by Johan Ihren of Autonomica that outlined a procedure for having multiple root signers. It was dropped from the DNSEXT Working Group not for any technical reason, but rather it was seen as unnecessary complexity at the time. The panelists agreed that any RKO has to be trusted for people to use their key, and that a RKO could not charge for zone signing unless that key is trusted. Vixie also noted that DLV (DNS Look-aside Validation), originally proposed as a bootstrapping method while the root was unsigned, was another option to consider. However, the IGP paper noted that a risk in DLV is the proliferation of trust anchors and trust models, which may not be scalable across the Internet.
The keys to the Internet kingdom
The panelists agreed that an important but little talked about side effect of signing the root is how DNSSEC makes implementing competing or alternate roots much more difficult. This can be viewed positively or negatively. The complexity of the protocol requires clarifying and possibly reinforcing the operational relations between the root key and root zone operator(s), registries and registrars, which could improve DNS stability. But it would also increase the infrastructure burden on any alternate root, and globally lock users into the current structure. Moreau said a competing root would have to strip all the signatures from the ICANN root and then add their own. It would have to publish alternative keys, which would then have to be installed as a trust anchor in the resolvers using it.
Vixie said DNSSEC could prevent cache pollution from alternative roots and also stop uncoordinated initiatives, e.g., Sitefinder-like services, which can affect the DNS. But he also said that the organization which controls the root key signing key (KSK) is in a “kingmaking” position, as they can decide who is the editor of the root zone file and who are the root servers. He concluded that anybody who wants the “keys to the Internet kingdom” wants the DNSSEC keys.
Vixie also claimed that Internet community trust in IANA was harmed by the US government’s unilateral oversight authority, and suggested that the US “take its hand off the tiller.”