Securing the Root: A proposal for distributing signing authority

[Editor's note: To clearly understand how securing the DNS will impact modifying and publishing the Root Zone File (RZF) it is best to briefly outline the current process and actors involved. Currently, change requests from TLD Operators are sent to ICANN (specifically IANA) for processing. Once meeting IANA’s narrow technical requirements and approval by the ICANN Board, the request is forwarded to the U.S. Department of Commerce for authorization to be input into the RZF. Upon approval, the Root Zone Maintainer (RZM), currently VeriSign, edits the master database and generates the revised RZF. The RZF is then loaded by the Root Zone Distributor (RZD) (also VeriSign at this time) to the Distribution Master Name Server, from which the other root server operators (RSO) located around the world retrieve it. Implementing DNSSEC will require modifications of hardware, software and operational procedures within most of the aforementioned organizations. The notable exception to these change requirements is the authorization role played by the U.S. Department of Commerce, which has no impact on the technical operation of the DNS or the deployment of DNSSEC.]

A proposal for signing the root

The implementation of DNSSEC and required development of a procedure to sign the DNS root zone file provides an opportunity to restructure the current political oversight exerted by the United States and achieve shared responsibility for the secure and stable operation of the Internet’s root zone. Specifically, multiple, but limited number of, non-governmental Root Key Operators (RKOs) should be responsible for generating, use and distribution of root zone key-signing keys (KSKs) and zone signing keys (ZSKs). In practice, this will require close coordination between RKO and RZM organizations in executing contractually agreed upon roles.

As shown below, the RKOs would be responsible for generating KSKs and ZSKs and transmitting the public portions of these keys to the RZM for construction of a Root Keyset. RKOs would be also responsible for distribution of the public portion of their KSK (i.e., the “trust anchor”) globally. Once constructed, the Root Keyset would be distributed to the RKOs for signature over the complete set of keys. The signed Root Keyset is then returned to the RZM for inclusion in the RZF. Each RKO will then sign a copy of the root zone file using the private portion of their respective ZSKs and transmit it to the RZM who will merge the files. All of the exchange of data between RKOs and the RZM would occur on secure out-of-band channels. The merged RZF would then be distributed according to existing procedures. A resolver could utilize any one of the available KSK to authenticate the RZF contents.

RZF_Signing_Process

Like any technical or procedural recommendation, there are benefits, risks and unknowns. Below, I identify some of them:

Eliminate threats of political interference

A prominent aspect of this proposal is the elimination of governmental organizations from the root zone management process. While the majority of domain names are currently registered in gTLD namespaces, the majority of TLDs in the root are ccTLDs and it is these namespaces which are experiencing strong growth. The issue of who controls delegation and redelegation of ccTLDs has always been sensitive, and the addition of Delegation Signer records to the root will only serve to amplify these concerns. Because of this, the direct involvement in root signing, or additional oversight of data flows between RKOs and the RZM, by any government is ill advised. It only serves to introduce risk, raise uncertainty among contracted parties, and undermine the credibility of the system. Moreover, it is unnecessary from an operations perspective. Cases of incorrect data being sent to another party can be remedied using operational quality control techniques like standards certification. Furthermore, given the openness of the DNS, any verification that an outside party would perform can be done by anyone if the process is done with minimum standards of transparency. The deployment of DNSSEC at the root is best left to the organizations that are contractually obligated for maintaining the RZF contents and should be let alone from potentially destabilizing interference created by government oversight.

Mitigate threats of rogue actors

The obvious risk of the process outlined above is that an RKO could alter the contents of the root zone file it signs and return it to the RZM for inclusion in the merged RZF. If this was the case, and the RZF were published, any resolver using the trust anchor from that “rogue” RKO could be directed unknowingly into an “alternative root.” However, this risk is mitigated simply by incorporating audits at certain points in the process. E.g., prior to publication of the merged file, any inconsistencies could be identified by the RZM, thereby identifying the RKO which “went rogue.” Similarly, any uncoordinated change introduced by the RZM could also identified by the RKOs auditing the merged zone contents prior to its distribution. Processing audits will add additional steps, however, is likely not to pose a significant operational hurdle. Even with the addition of DNSSEC RRs, the RZF will not be not a large data file. The current management of the RZF already incorporates digital signatures, error checking, and correction processes, so the existing parties are familiar with the techniques. And while auditing potentially slows down the root signing process, it should be recognized that rolling over the root's trust anchors is anticipated to be a fairly infrequent event. E.g., ISC outlines a security policy which rolls over the KSK for their DLV implementation one time per year. Nonetheless, any process that involves coordinating multiple parties and which may need to occur on an unscheduled basis will need to be well documented, tested, and transparent.

Distributing authority increases resilience, diffuses liability

A key feature of the Internet's architecture and the DNS is decentralization. For instance, the DNS is distributed among many nameservers, another example is the anycasting of root servers. Decentralization of critical Internet resources increases robustness of the entire system, protecting it from intentional and unintentional attacks. Having multiple, coequal RKOs makes the DNSSEC architecture more resilient against temporary outages that might be suffered by a single RKO. Resolver operators could use any number of available RKO trust anchors to validate RZF contents depending on their desired level of assurance. Distribution of control over the RZF KSK among multiple entities is desirable from the viewpoint of a decentralized Internet.

Liability is a powerful negative incentive which could easily prevent organizations from signing the root. By involving multiple RKOs in the root signing process, potential liability associated with providing a signed RZF could be diffused. It could increase the variety of contracting arrangements between RKOs, the RZM and those relying on stable operation of a secure root. It is unknown in the proposed system what legal relationships may develop between RKOs, nameserver and resolver operators and under what jurisdiction these relationship may fall. Given the unique position held by RKOs as “root authorities,” it may be necessary for them to gain international status to limit their liability. For example, just as common carriers in the US have limited liability, other governments and transnational organizations (e.g., the ITU) have also placed limitations of liability on specific telecommunications services. Another approach to consider may be the development of a safe harbor for RKOs. Safe harbors have been used in other Internet governance issues (e.g., EU-US data protection and the Communications Decency Act), where an actors liability is made conditional only upon the non-compliance with some private rule regime.

Determining Root Key Operators

A central question is determining how many and what organizations could be a RKO. This is an answer partially determined by any technical constraints, prior experience with other root authorities, and in all likelihood, market mechanisms. Technical constraints may include the number of keys in the Root Keyset, the number of keys used to generate signatures for the root zone data, properties of the keys such as size and algorithm used, response message size constraints, and the need to rollover keys periodically. Some of these constraints have policy dimensions as well, for instance, the choice of key size and algorithm used.

A secured DNS is not unlike a public PKI (Public Key Infrastructure). It is a combination of products, limited digital signature services, facilities, policies, procedures, agreements, organizations and people that provide for and sustain secure DNS queries and resolutions. Documentation concerning root authorities in other large-scale authentication chains (e.g., certificate authorities (CAs) in PKIs) could help identify what kind of organizations would be suitable to be a RKO. For example, the US General Accounting Office has provided examples of the risks facing and the internal control objectives associated with root certification authorities. Similarly, NIST has documented best practices for key management organizations which could serve as guidelines. Guidelines from other countries should be examined as well. At a global level UNCITRAL offers general remarks for characteristics that organizations within a PKI, including root authorities, should posses.

To date the development of broadly available public PKIs has been slow, with a mix of widely available CAs offering minimal liability protection, while more purpose-specific “private” CAs (i.e., it also includes substantial government efforts) have emerged for higher-risk scenarios. The levels of assurance provide by the digital signatures in each case varies accordingly. It is unclear at this time what level of assurance RKOs and other organizations involved in providing secure DNS information would be willing to provide.

4 comments

  1. Anonymous

    Great proposal!
    I would suggest to make the RZM role as policy-deprived as possible: it mechanically behaves if at least so many RKOs maintain their cooperation agreement; turns off DNSSEC otherwise. No attempt to reconcile discrepancies among RKOs. For the bulk of Internet usage, discrepancies about a given ccTLD are totally irrelevant. For the few paranoids, discrepancies are reflected in ZSK RRSIGs, plus an out-of-band knowledge of which RKO has which ZSK.
    If an RKO exists, it can not be “rogue”. This side of the border, “The king can do no wrong” and the same applies to NTIA overseeing the ICANN-Verisign deal. I suspect that any situation where the RZM must make a decision would put it “above” the RKO jurisdiction/authority, then you fall in a circular argument.
    Here is a mechanical bandwidth optimization that the RZM can put in place: when merging the signed RZFs from the various RKOs, if the sets of ZSK RRSIGs from RKO A and B cover the exact same RRsets, and if the ZSKs from A and B use the same algorithm, drop every RRSIGs from either A or B (the dropped A or B should alternate from one RZF revision to the other).
    The rationale is that the only case where ZSK RRSIGs from A and B may matter is if one of them denied a DS to a TLD while the other one endorsed it with an RRSIG.
    Although the RZF is small, the DNSSEC has a significant bandwidth impact on root queries for non-existent TLDs,as in example.cvom (sic).
    Regards,
    – Therry Moreau

  2. Anonymous

    Politically, the gain of this proposal is not obvious. It seems that the RKO has little choice but to blindly sign what the RZM gives it.
    DLV seems much more open: a DLV root can sign only the part it konws, several DLV roots can coexist, etc.

  3. Anonymous

    About a given RKO margin of action: it may agree with other RKO for instructions to the RZM; it may agree to disagree with other RKOs and sign only an edited root zone file. Think of a corporation board of directors with its CEO. The latter works for the board. Likewise, the RZM works for RKOs.
    But the intriguing part of your post is about “DLV root”. A DLV registry contains trust anchors for DNSSEC islands of security; if it contains an entry for the DNS root, then the root is signed, great!
    I am quite certain that the DLV scheme was never envisioned as a means of coexistence for multiple roots, even less for independent DNSSEC secure delegation policies.
    Regards,
    – Thierry Moreau

  4. Anonymous

    Thanks for the comments. Well, the proposal is in development, so often it's not even obvious to us!
    That said, a feature of the proposal is that the relationships between all the involved parties be contractually based in some body of law. I'm sure legal experts could envision a lot of scenarios, but one simplification(!) of the relationships could be:
    RKOs
    – contract with TLDs and ICANN to provide root signing services
    TLDs
    – contract with ICANN/IANA for additions to the RZF. These contracts could vary given the wide organizational array of TLD registries.
    ICANN/IANA
    – contracts with RZM for editing and distribution of RZF. Or ICANN/IANA could assume this role.
    ISPs
    – contract with Nameserver Operators (including RSOs) for secure DNS services
    So in your scenario, I'm assuming some change is made to the RZF which a RKO disagrees with because they would be unable to perform the root signing services which they're obligated to provide. Their recourse would be the contract provisions they have with ICANN/IANA (or possibly the RZM if it was a technical snafu). The TLD would also have recourse.
    Which brings us rather quickly to the problem of deciding what are the contents of the RZF. In our proposal, eliminating the opportunity for outside political influence of those contents is the big gain. I.e., the removal of DoC oversight, and the simplification of the RZM's role to strictly make the requested changes, audit for RKO files consistency, and publish the RZF reliably. Of course this doesn't mean that ICANN/IANA would be without internal political influence, but it is an institution which could be limited to simply verifying technical requirements are met for any requested change, and whose processes for additions to the RZF could be transparent and not subject to oversight by any govt.
    RE: DLV. I think the fear with DLV (and a single RKO, particularly a USG agency or contractor) is potential for multiple DNSSEC roots, right? In that scenario, wouldn't widespread deployment be hampered because of numerous trust anchors which resolver operators would have to manage? But if the root remained unsigned, maybe you'd end up with a more manageable number?