VeriSign's plan to sign the root

UPDATED 10/3 VeriSign has publicly released its proposal to sign the root. It comes on the heels of ICANN submitting their own (yet to be publicly released) proposal to the NTIA on September 2. In brief, VeriSign's proposal to deploy DNSSEC at the root:

1. Retains the existing root zone editing, authorizing, and publishing roles held by IANA, DoC, and VeriSign, respectively.

2. Integrates the use of an IANA-run TAR to provide registry key material (i.e., DS records) for inclusion in the root zone.

3. Advocates that VeriSign generate the Zone Signing Key (ZSK), sign and publish the root zone.

4. Proposes that the generation of the Key Signing Key (KSK) be distributed among organizations, using a “M of N” key technique, where N is the number of entities that share control of the key, and M is the minimum number of those entities that must agree to any use of the key, (e.g., using it for signing).

5. Proposes, in an attempt to address the political sensitivities surrounding root signing, distributing KSK activity to the root server operators (RSOs).

6. Suggests that RSOs authorize VeriSign's use of that KSK to sign the next year’s entire set of key sets (twelve in all) in advance. The root zone maintainer and signer (currently VeriSign) would store these key sets and use them throughout the year as required.

VeriSign adds a much needed dimension to the root signing debate, introducing a well known threshold cryptographic technique. But the reliance on root server operators needs to be considered carefully. It's true that most of them are a fairly non-controversial, tightly knit group of actors that has the interest of serving up a consistent root globally. But this view of RSOs is partially due to the low profile that root server operators maintain. A more nuanced analysis, which recognizes the political and economic importance of the root zone, could see this as an effort to convince the RSOs to lock in to the institutions and policy making processes which control the content of the DNS root.

It's pretty clear that, in terms of representing the various political and economic interests concerned, the diversity of root server organizations is inadequate. They are geographically concentrated in the United States, with ten of the 13 RSOs being legally located in the United States and subject to its laws and government. Root server operations are also concentrated among limited set of interests. While classifying organizations according to the “multistakeholder” categories being used widely in Internet governance institutions is difficult, it's clear that 10 are private sector non-governmental organizations, 3 are US government agencies, and that there are no CS or intergovernmental organizations involved. Furthermore, the USG has substantial influence and oversight over 6 of the 13 root server operators, either through the fact that they are government agencies, or that the USG maintains a contractual relationship that can impact the organization's behavior (and that isn't counting the RSOs that have research funding from the USG).

Because of these issues, the VeriSign proposed number of RSOs needed to successfully use the root KSK, i.e. 5 root server organizations, is simply too low. The number (M) needs to at least exceed 6, and preferably it needs to exceed the number of organizations legally based in the US (i.e., 10). If there is a desire to keep the number smaller, an alternative would be to increase the geographic and interest diversity of root server organizations. This could be achieved by shifting the legal location of some of the RSOs, or perhaps increasing multi-stakeholder involvement in the activities of root server organizations. A third option could be to use the same “M of N” technique, but to simply tap a different group of organizations entirely.

UPDATE: McTim raises the point of “why is 6 the magic number?” One argument could be that 6 exceeded by 1 the number of RSOs that are very close to the USG and probably most subject to its influence. But I'll agree determining an appropriate threshold needs far more analysis. The numbers chosen in a threshold arrangement (i.e., “M of N”) impact and involve tradeoffs in the integrity, confidentiality, and availability of a protocol. For instance, the higher “M” is the more difficult it is to inadvertently or maliciously reveal information outside of the protocol. However, achieving higher confidentiality decreases the availability of the protocol, i.e., getting all the necessary number of orgs together to complete the protocol. But I’m not so sure we should be focused on the threshold value per se.

McTim also took issue with my quick classification. My main point (poorly conveyed) is while we can quibble all day about classifying RSOs into various multistakeholder buckets, it's really not too helpful. What matters is the independence of the orgs participating. As I said, there is no question that most of the RSOs are legally based in the US, subject to its laws and government. If we believe the DNS is a global infrastructure, and acknowledge that a government might use their ability to influence a communications network to accomplish other policy objectives (and historically they do), then any threshold arrangement should be designed to limit (dare I say, neutralize) this influence. This could be possible if the “N” orgs are based (note I didn’t say they should be governmental) in various countries that represent political-economic power on the Internet, or maybe including an intergovernmental org. I'm not sure solely tapping the RSOs for this role is appropriate.

Finally, McTim asks if “the folk you have in mind would want to foot the bill? Do they have the capacity to be rootops?” First, I don't have anyone specific in mind, I just said using the RSOs needs to be carefully considered. Second, the “Internet community” (including CS, Govts, PS, Tech) should probably be consulted (maybe an ICANN public consultation?) to determine and ask these orgs if they're interested and capable. BTW – I don't think the VeriSign proposal suggests that the KSK “holders” need to be able to run a root. They just participate and provide oversight of key generation. Again, more analysis is needed.