It is helpful when reading this proposal to understand the goals for a signed root zone that VeriSign followed in its preparation.
- Preserve existing roles and responsibilities. In accordance with DoC NTIA’s previously stated public position, this proposal does not change any of the roles and responsibilities of the three parties that currently cooperate to perform the root zone change process:
- ICANN, under the IANA functions contract, continues to accept and validate requests from TLD managers and submit the requests to NTIA for authorization and VeriSign for implementation.
- VeriSign continues to implement these changes to produce the authoritative root zone file and publish these changes to the root operators.
- NTIA continues its role in authorizing changes to the root zone.
- Sign the root expeditiously but cautiously. The root should be signed without undue delay, but we recognize that this operation is a significant undertaking, requiring the coordination of several parties, and will therefore take time. Further, the root zone is the most important zone in DNS and also one of the most queried zones. Its stability is vital, as is the stability and proper operation of clients that query the root zone. Signing the root cannot disrupt root operations (producing, publishing and serving the root zone), nor especially can signing the root disrupt DNS resolution throughout the Internet. The root zone is queried by literally millions of DNS clients and signing the root cannot be allowed to break resolution of even a small percentage. Proper testing in advance of signing the production root is therefore important to gauge the impact. Any decision to sign must include a review of the testing results to determine what actions, if any, may be needed to ease any harmful effects of signing the root before proceeding.
- Shared control of the root zone key-signing key. When discussion of root signing occurs, the question of what organization will control the root zone KSK inevitably emerges as a complicated and contested issue, with different parties expressing different positions, sometimes in complete opposition. Determining control of the KSK is a significant issue because of the importance of this key: from a technical perspective, whoever controls it is the final authority over what information is published in the root zone.
A well-established technique used in the public key infrastructure industry offers another option to simplify this control issue: rather than being controlled by a single organization, control of the KSK can be shared among multiple organizations. In this model, multiple organizations must cooperate to create and use the key. For such an important function as the root zone KSK, requiring multiple parties is a better alternative than vesting control in a single organization, which is subject to failure or capture by other parties desiring control of the root zone.
- Allow appropriate parties to control the root zone KSK. Shared control of the KSK allows multiple parties to authorize its use, but these parties must be chosen with care. The parties must be:
- Neutral, without a stake in the contents of the root zone;
- Trustworthy, with an established and public record;
- Non-controversial, likely to be accepted by a large portion of the Internet community, including the international community; and
- Competent, with an understanding of DNSSEC, an appreciation of operational matters, and the capabilities to perform this role in a secure manner (potentially subcontracting certain responsibilities, such as physical key storage, as necessary).
- Store and use all root zone keys securely. The root zone keys (both KSK and ZSK) will be extremely sensitive and need extraordinary protection. A compromised ZSK would allow forged signatures of root zone data, and the KSK will be configured as a “trust anchor” in millions of DNSSEC validators; its loss would require an unprecedented amount of reconfiguration across the entire Internet to update trust anchors and the potential exposure resulting from its loss is significant.