IGP submitted comments yesterday to the Department of Commerce regarding the deployment of DNSSEC at the root zone. The Notice of Inquiry raised numerous questions, and put forth six proposed process flows, including ones submitted by ICANN and VeriSign. Just over 35 comments had been submitted by last night, with comments filed by organizations and individuals from the technical community, registries, government contractors involved with DNSSEC deployment, and others. We'll have more analysis on the comments filed later, but my first impression after quickly scanning them is that while there is general agreement that signing the root would obviously be helpful for DNSSEC deployment, it should not be done in haste for a variety of reasons. And numerous parties raised the point that it is critical that any process flow implemented serve the global Internet community, otherwise the presumed benefits of signing will be for naught.
Our comments argued that the act of signing the DNS root raises political and economic issues as well as technical ones. While the DNSSEC protocol has been refined technically over more than a decade within the IETF and elsewhere, discussion and analysis of the political and economic dimensions of DNSSEC deployment have just begun. Our analysis flowed from the basic fact that,
1. Deployment of DNSSEC at the root zone, if it led to widespread reliance on a single trust anchor, would dramatically increase the switching costs associated with any attempt to defect from, or provide an alternative to, the existing DNS root. In effect, DNSSEC root signing presents a risk of locking in existing DNS root zone management arrangements.
This raises both political concerns and competition policy concerns, and suggests an interim step as these issues are worked out. With respect to the first concern, we made the point that the Department should,
2. Support a process flow that recognizes diverse national interests in a secure DNS root
More than 200 TLD operators rely on the root zone, including rapidly-growing ccTLD namespaces. Internet-supported economies and governments are developing around the world. Thus, if it wants DNSSEC to succeed, the U.S. Department of Commerce must ensure that any process flow for deploying DNSSEC at the root zone considers and serves not only the interests of the United States government, but also the interests of the global Internet community. We noted that the VeriSign proposal is flawed in that it does not require sufficient regional or political diversity. By suggesting only 5 root server operators to constitute “M”, it would allow U.S. based root server operators to sign the root zone without any support from other regions. And that while this NOI does not specifically consider the issue of oversight, it is the opinion of the IGP that the Department’s authorization role in the deployment of DNSSEC at the root zone unnecessarily politicizes what should be a technical coordination activity.
With respect to the second concern, we suggest DoC
3. Do not institute a process flow that creates competition policy problems
From an economic perspective, deployment of DNSSEC at the root zone raises competition policy concerns with respect to possible vertical integration of root zone management functions with either root zone Key Signing Key (KSK) activities or Zone Signing Key (ZSK) activities. Depending on if and how these functions are integrated, there is the potential for them to be controlled to gain an advantage over competitors in an adjacent or downstream market. Discriminatory behavior could include tampering with or refusing to sign a TLD operator’s resource records, effectively excluding the TLD zone and its users from benefits provided by a secured authoritative root. Unfortunately, this risk is reflected in the current proposals put forth by ICANN and VeriSign. We found ICANN's proposal to be insufficiently developed in that it offers no specifics regarding to whom KSK operations would be distributed or how they would be conducted. And consistent with concerns expressed by other registries, we noted that the VeriSign proposal is flawed in that it potentially allows the operator of the world’s largest TLD zone to adversely affect competing TLD operations.
The typical remedy for vertical integration problems is structural separation. With respect to KSK activities, this would entail selecting a process flow that clearly establishes independent, globally representative Root Key Operators that are jointly responsible for KSK operations. With respect to ZSK activities, we acknowledged that root zone edits, generation and ZSK activities should remain within a single organization. However, ZSK operations should not reside with an organization that competes directly with other TLD operators.
Finally, we suggested that the Department,
4. Support the deployment of a Trust Anchor Repository as an interim step in securing the DNS root
Given the important and irreversible changes that would be affected by signing the root zone, and the obvious flaws in the two major proposals (ICANN and VeriSign) before the Department, there is no need to rush the choice of an optimal method. Fortunately, a viable interim solution exists: an IANA run Trust Anchor Repository (TAR).
A TAR is an adequate interim solution, given the relatively small number of TLD operators currently signing or expressing interest in deploying DNSSEC. It will enable registries and resolver operators to experiment with DNSSEC and deploy the technology if they choose. It is recognized that a TAR might not provide a long-term solution because of scalability concerns expressed by resolver operators. However, a TAR does not prevent or conflict with the pursuit of DNSSEC deployment at the root zone. In fact, it is viewed as a possible component of one proposed process flow. Perhaps most importantly, an interim TAR would avoid the current political and economic issues of deployment of DNSSEC at the root, since IANA could 1) develop the procedures for its operation (e.g., authentication of TAR data) with the global Internet community within the ICANN process and, 2) deploy it without the oversight of a U.S. government agency or operational involvement of VeriSign. Deploying a TAR would allow time for development and implementation of a process flow that encourages convergence by the global Internet community on a single DNS root trust anchor.
