Enhancing the Security and Stability of the Internet's Domain Name and Addressing System, 59608-59612 [E8-23974]

Agencies

• DEPARTMENT OF COMMERCE
• National Telecommunications and Information Administration

[Federal Register Volume 73, Number 197 (Thursday, October 9, 2008)]
[Notices]
[Pages 59608-59612]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: E8-23974]


-----------------------------------------------------------------------

DEPARTMENT OF COMMERCE

National Telecommunications and Information Administration

Docket Number: 0810021307-81308-01


Enhancing the Security and Stability of the Internet's Domain 
Name and Addressing System

AGENCY: National Telecommunications and Information Administration, 
U.S. Department of Commerce

ACTION: Notice of Inquiry

-----------------------------------------------------------------------

SUMMARY: The Department of Commerce (Department) notes the increase in 
interest among government, technology experts and industry 
representatives regarding the deployment of Domain Name and Addressing 
System Security Extensions (DNSSEC) at the root zone level. The 
Department remains committed to preserving the security and stability 
of the DNS and is exploring the implementation of DNSSEC in the DNS 
hierarchy, including at the authoritative root zone level. Accordingly, 
the Department is issuing this notice to invite comments regarding 
DNSSEC implementation at the root zone.

DATES: Comments are due on November 24, 2008.

ADDRESSES: Written comments may be submitted by mail to Fiona 
Alexander, Associate Administrator, Office of International Affairs, 
National Telecommunications and Information Administration, U.S. 
Department of Commerce, 1401 Constitution Avenue, N.W., Room 4701, 
Washington, DC 20230. Written comments may also be sent by facsimile to 
(202) 482-1865 or electronically via electronic mail to 
DNSSEC@ntia.doc.gov. Comments will be posted on NTIA's website at 
https://www.ntia.doc.gov/DNS/DNSSEC.html.

FOR FURTHER INFORMATION CONTACT: For further information about this 
Notice, please contact Ashley Heineman at (202) 482-0298 or 
aheineman@ntia.doc.gov.

SUPPLEMENTARY INFORMATION: Background. The Domain Name and Addressing 
System (DNS) is a critical component of the Internet infrastructure and 
is used by almost every Internet protocol-based application to 
associate human readable computer hostnames with the numerical 
addresses required to deliver information on the Internet. It is a 
hierarchical and globally distributed system in which distinct servers 
maintain the detailed information for their local domains and pointers 
for how to navigate the hierarchy to retrieve information from other 
domains. The accuracy, integrity, and availability of the information 
supplied by the DNS are essential to the operation of any system, 
service or application that uses the Internet.
    The DNS was not originally designed with strong security mechanisms 
to ensure the integrity and authenticity of the DNS data. Over the 
years, a number of vulnerabilities have been identified in the DNS 
protocol that threaten the accuracy and integrity of the DNS data and 
undermine the trustworthiness of the system. Technological advances in 
computing power and network transmission speeds have made it possible 
to exploit these vulnerabilities more rapidly and effectively.\1\
---------------------------------------------------------------------------

    \1\ See, National Research Council, The National Academies, 
Signposts in Cyberspace: The Domain Name System and Internet 
Navigation 154 (2005)(Signposts), https://books.nap.edu/
catalog.php?record_id=11258toc (last checked September 29, 
2008); Department of Homeland Security, National Security Division, 
and National Institute of Standards and Technology, National 
Vulnerability Database, Vulnerability Summary for CVE-2008-1447 
(Original release date July 08, 2008; last revised September 17, 
2008) available at http:/ /web.nvd.nist.gov/view/vuln/detail?vuln 
Id=CVE-2008-1447 (last checked September 23, 2008) (This site 
provides a list of most recent advisories regarding DNS 
vulnerabilities including DNS spoofing, cache poisoning, etc., and 
includes links to tools and solutions).
---------------------------------------------------------------------------

    Development of the DNSSEC Protocol. To mitigate the long-recognized 
vulnerabilities in the DNS, the Internet Engineering Task Force (IETF), 
using the same open standards process employed to develop the core DNS 
protocols, has developed a set of protocol extensions to protect the 
Internet from certain DNS related attacks: DNSSEC.\2\ DNSSEC is 
designed to support authentication of the source and integrity of 
information stored in the DNS using public key cryptography and a 
hierarchy of digital signatures. It is designed to offer protection 
against forged (``spoofed'') DNS data, such as that created by DNS 
cache poisoning, by providing: (1) validation that DNS data is 
authentic; (2) assurance of data integrity; and (3) authenticated 
denial of existence.\3\ DNSSEC does not provide any confidentiality 
for, or encryption of, the DNS data itself. The DNSSEC protocol also 
does not protect against denial of service (DoS) attacks or other 
attacks against the name server itself.\4\
---------------------------------------------------------------------------

    \2\ The DNSSEC protocol has been under development since the 
1990s with the latest revision approved by the IETF in 2005. RFC 
4033 and its companion documents RFCs 4034 and 4035 update, clarify 
and refine the security extensions previously defined orginally in 
RFC 2535 and its predecessors. Id., Signposts, at 154; see also, S. 
Rose and R. Chandramouli, ``Challenges in Securing the Domain Name 
System,'' Institute of Electrical and Electronics Engineers (IEEE) 
Security and Privacy Journal, Vol. 4, No. 1, 84 (Tom Karygiannis, 
Rick Kuhn, and Susan Landau eds., Jan./Feb. 2006)(Challenges), 
https://www.antd.nist.gov/pubs/Rose-
Challenges%20in%20Securing%20DNS.pdf.
    \3\ R. Arends et al., DNS Security Introduction and 
Requirements, Internet Engineering Task Force (IETF) Request for 
Comment (RFC) 4033 (March 2005)(RFC 4033), https://www.ietf.org/rfc/
rfc4033.txt (last checked September 24, 2008).
    \4\ Id.
---------------------------------------------------------------------------

    The DNSSEC protocol is designed to allow for deployment in discrete 
zones within the DNS infrastructure without requiring deployment 
elsewhere, as DNSSEC is an opt-in technology. Signing of any individual 
zone or domain within the hierarchy does not

[[Page 59609]]

obligate or force any entity operating a zone elsewhere in the DNS 
hierarchy to deploy. In addition, end users systems only receive DNSSEC 
signed information if they request it.
    Proponents of DNSSEC assert that widespread deployment of the 
protocol would mitigate many of the vulnerabilities currently 
associated with the DNS, increasing the security and integrity of the 
Internet DNS in a scalable fashion.\5\ Ubiquitous deployment of DNSSEC 
would also enable authentication of the hierarchical relationship 
between domains to provide the highest levels of assurance. Thus, to 
realize the greatest benefits from DNSSEC, there needs to be an 
uninterrupted chain of trust from the zones that choose to deploy 
DNSSEC back to the root zone.\6\
---------------------------------------------------------------------------

    \5\ Id., at 6.
    \6\ See Signposts, supra note 1 at 158.
---------------------------------------------------------------------------

    Ubiquitous deployment of DNSSEC throughout the Internet landscape 
would require action by a broad range of entities supporting the 
operation of the DNS infrastructure including, for example, domain name 
registrars, top level domain (TLD) registry operators and the operators 
or managers for sub-domains or enterprise networks, Internet service 
providers (ISPs), software vendors, and others.\7\ Additionally, 
software will need to be developed, servers will need to be configured 
to support DNSSEC, and users' systems will need to be configured to 
look for the authenticating signatures.
---------------------------------------------------------------------------

    \7\ See e.g., Challenges, supra note 2, at 86-87. The Department 
recognizes that the ultimate success of DNSSEC would also require a 
widespread education campaign among end-users and DNSSEC awareness 
would have to be integrated into application and operating system 
software and development.
---------------------------------------------------------------------------

    Current DNSSEC Deployment Status. To date, deployment of DNSSEC has 
been somewhat piecemeal. At present, only a small number of country 
code top level domain (ccTLD) operators (e.g., .se [Sweden], .pr 
[Puerto Rico], .bg [Bulgaria], and .br [Brazil]) have deployed 
DNSSEC.\8\ In addition, the operators of several generic TLDs 
(including .org and .gov) have publicly announced their intention to do 
so.\9\ A number of second-level domain operators have also signed their 
zones, such as nist.gov.\10\
---------------------------------------------------------------------------

    \8\ To check which TLDs that have deployed DNSSEC, see 
University of Southern California Los Angeles, ``SecSpider: the 
DNSSEC Monitoring Project'' (UCLA SecSpider), https://
secspider.cs.ucla.edu (last checked September 19, 2008) (each TLD 
zone can be looked up separately using this tool); Carolyn Duffy 
Marsan, Network World, ``Feds Tighten Security on .GOV'' (September 
22, 2008), https://www.networkworld.com/news/2008/092208-government-
web-security.html?page=1 (last checked September 25, 2008).
    \9\ Public Interest Registry, `` .ORG Becomes First Generic Top 
Level Domain to Start DNSSEC Implementation'' (July 21, 2008), 
https://pir.org/index.php?db=content/News&tbl=Press&id=9 (last 
checked September 24, 2008); Executive Office of the President, 
Office of Management and Budget, Memorandum for Chief Information 
Officers, Securing the Federal Government's Domain Name System 
Infrastructure (August 22, 2008), https://www.whitehouse.gov/omb/
memoranda/fy2008/m08-23.pdf (last checked September 24, 2008).
    \10\ See UCLA SecSpider, supra note 8, (second level zones may 
also be looked up using this tool).
---------------------------------------------------------------------------

    Some argue that DNSSEC deployment has been delayed because without 
a signed root, early deployments operate as ``islands of trust'' with 
no established chain of trust above them in the DNS hierarchy 
connecting them to other signed zones.\11\ Without a common, shared 
``trust anchor,''\12\ these early deployers and others that wish to 
deploy DNSSEC must be able to manage not only their own trust anchors 
or ``keys,'' but also the trust anchors for other signed domains within 
the DNS hierarchy.\13\ The technical and procedural challenges 
presented by this ``key management'' dilemma need to be overcome to 
facilitate DNSSEC deployment.\14\
---------------------------------------------------------------------------

    \11\ R. Arends, et al., Protocol Modifications for the DNS 
Security Extensions, Internet Engineering Task Force (IETF) Request 
for Comment (RFC) 4035 (March 2005)(RFC 4035), https://www.ietf.org/
rfc/rfc4035.txt (last checked September 25, 2008) (This document 
defines the concept of a signed zone and lists requirements for a 
zone signature).
    \12\ As defined in RFC 4033, a ``Trust Anchor'' is ``a 
configured DNSKEY RR or RR hash of a DNSKEY RR. A validating 
security-aware resolver uses this public key or hash as a starting 
point for building the authentication chain to a signed DNS 
response.'' Further, ``presence of a trust anchor also implies that 
the resolver should expect the zone to which the trust anchor points 
to be signed.'' See RFC 4033, supra note 3.
    \13\ See RFC 4035, supra note 11.
    \14\ See Challenges, supra note 2 at 85-86.
---------------------------------------------------------------------------

    Due to the complexities involved in managing trust anchors in the 
absence of a signed root, alternative mechanisms such as ``trust anchor 
repositories'' (TARs) are also being developed.\15\ TARs are just one 
type of alternative available today. It is not clear what other 
alternatives for key management may be currently under development or 
could be developed in the future.\16\
---------------------------------------------------------------------------

    \15\ TARs allow a trusted third party to collect, authenticate, 
and manage the required keys on behalf of a group of DNSSEC users. 
For additional information on TARs, see, Sparta Inc., Shinkuro Inc., 
and National Institute of Science and Technology, ``Statement of 
Needed Internet Capability: Trust Anchor Repositories'' (June 9, 
2008), https://www.dnssec-deployment.org/tar/tarpaper.pdf (last 
checked September 24, 2008). In April 2008, the Board of Directors 
of the Internet Corporation for Assigned Names and Numbers (ICANN) 
authorized the creation and maintenance of an Interim TAR to act as 
a registry of DNSSEC trust anchors for top level domains. See, 
Minutes of the Special Meeting of the ICANN Board of Directors 
(April 30, 2008), https://www.icann.org/en/minutes/minutes-
30apr08.htm (last checked September 24, 2008).
    \16\ The potential risks and benefits associated with TARs and 
other alternatives to signing of the root are not the primary focus 
of this NOI and, accordingly, are addressed only briefly here. 
However, depending on the comments received in response to this NOI, 
the Department may consider these issues more fully at a later date.
---------------------------------------------------------------------------

    Implementing DNSSEC at the Root. The hierarchical nature of the DNS 
structure (e.g., root zone, top level domains, sub-domains) and the 
trust anchor framework required for security-aware resolvers to 
validate a signed response arguably make DNSSEC deployment at the root 
level (i.e., ``signing'' of the root) an important step to achieve 
optimal benefits from the protocol. Signing the root would provide a 
single trust anchor at the top of the hierarchy upon which the DNS 
infrastructure could depend. Proponents contend this would simplify the 
validation process for those who have already deployed DNSSEC, while 
providing an incentive for possible broader deployment by others across 
the DNS domain space by removing one of the primary deterrents (the 
lack of a single trust anchor) to adoption.\17\
---------------------------------------------------------------------------

    \17\ See, Samuel Weiler, Carnegie Mellon University, Information 
Networking Institute, ``Deploying DNSSEC Without a Signed Root'' 
(April 2004), https://www.watson.org/~weiler/INI 1999-19.pdf (last 
checked September 25, 2008) (This document discusses the importance 
of a signed root from a technical perspective and discusses 
alternatives if the root is not signed).
---------------------------------------------------------------------------

    Support among the DNS community for implementation of DNSSEC at the 
root level has progressively grown over the years, as threats to the 
DNS have emerged. Several organizations have publicly indicated their 
support for signing the root zone.\18\ Various Internet entities have 
undertaken a number of test-bed and pilot project initiatives to assess 
the technical feasibility and issues associated with signing of the 
root zone. Some notable examples include:
---------------------------------------------------------------------------

    \18\ The National Academies, see Signposts, supra note 1, at 
158; The European Internet Regional Internet Registry (RIPE), see 
Letter from Axel Pawlik, Managing Director, RIPE Network 
Coordination Centre to Dr. Vinton Cerf and Paul Twomey, ICANN (June 
12, 2007), https://www.ripe.net/ripe/wg/dns/icann-root-signing.pdf 
(last checked September 24, 2008); Nominet (the .uk registry), see 
Nominet, ``Signing the Root'' (October 2007), https://
www.nominet.org.uk/digitalAssets/27762_Signing_the_Root.pdf 
(last checked September 24, 2008); Public Interest Registry (PIR), 
see Letter from Alexa A.S. Raad, President and CEO, Public Internet 
Registry to the Honorable Carlos M. Gutierrez, Secretary of 
Commerce, U.S. Department of Commerce (September 5, 2008).
---------------------------------------------------------------------------

    Internet Corporation for Assigned Names and Numbers (ICANN) DNSSEC 
testing demo (https://ns.iana.org/dnssec/status.html)
    VeriSign DNSSEC Root testbed (https://webroot.verisignlabs.com/)

[[Page 59610]]

    EP.NET, LLC Root Server Testbed Network (https://www.rs.net/)
    These test-beds were established to demonstrate the technical 
feasibility for signing the root zone on a day-to-day routine basis. 
However, as they have largely been developed to evaluate technical 
aspects of signing the root, these test-bed efforts have not addressed 
or considered certain policy and procedural issues regarding the 
management of a signed root zone. These policy and procedural issues, 
especially regarding key management for the root zone, must be resolved 
before deployment in the root zone to ensure transparency and 
trustworthiness to the Internet community.
    While deployment of DNSSEC at the root has many benefits, it 
introduces new security requirements. In particular, the cryptographic 
keys used to protect the root zone must be protected from disclosure. 
If an unauthorized entity gains access to the keys, it could publish 
incorrect information in the DNS with DNSSEC extensions falsely 
indicating the DNS data's integrity and authenticity. This risk can be 
mitigated through a variety of procedural and technical mechanisms, 
many of which can be applied in concert. The Department welcomes 
comments regarding procedural and technical mechanisms available to 
address such security requirements.
    DNSSEC Implementation Models. A DNSSEC signed root zone would 
represent one of most significant changes to the DNS infrastructure 
since it was created. Consistent with the U.S. Principles on the 
Internet's Domain Name and Addressing System, the Department is now 
undertaking a review of the various implementation models to enhance 
the security and stability of the Internet DNS.\19\ The Department 
recognizes the potential benefits of a DNSSEC signed root and is 
actively examining various implementation models in coordination with 
the National Institute of Standards and Technology (NIST) as well as 
other U.S. Government stakeholders and experts. NIST has been at the 
forefront of DNSSEC research and deployment domestically.\20\ The U.S. 
Government also recently announced the deployment of DNSSEC throughout 
the .gov domain.\21\ The Department has also been consulting with other 
relevant stakeholders, including ICANN and VeriSign, Inc., with respect 
to DNSSEC deployment.\22\
---------------------------------------------------------------------------

    \19\ See U.S. Principles on the Internet's Domain Name and 
Addressing System, https://www.ntia.doc.gov/ntiahome/domainname/
usdnsprinciples_06302005.htm (last checked September 24, 2008).
    \20\ National Institute of Standards and Technology (NIST), U.S. 
Department of Commerce, DNSSEC Project, https://www-x.antd.nist.gov/
dnssec/ (last checked September 24, 2008).
    \21\ Executive Office of the President, Office of Management and 
Budget, Memorandum for Chief Information Officers, Securing the 
Federal Government's Domain Name System Infrastructure (August 22, 
2008), https://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf 
(last checked September 24, 2008)(The U.S. Government is requiring 
deployment of DNSSEC at the TLD level in .gov by January 2009 and in 
all .gov sub-domains used by Federal agencies by December 2009).
    \22\ The Department's agreements with ICANN and VeriSign, Inc. 
provide the process through which changes are currently made to the 
authoritative root zone file.
---------------------------------------------------------------------------

    As a fundamental consideration, it is essential that implementation 
of DNSSEC at the root further ensures the stability and reliability of 
the root zone management system. All of the DNSSEC root zone deployment 
models of which the Department is aware would incorporate the elements 
required for ``signing'' the root into the process flow for management 
of the authoritative root zone file. At present, the process flow (see 
diagram at https://www.ntia.doc.gov/DNS/CurrentProcessFlow.pdf) 
includes the following steps: (1) TLD operator submits change request 
to the Internet Assigned Numbers Authority (IANA) Functions Operator; 
(2) the IANA Functions Operator processes the request; (3) the IANA 
Functions Operator sends a request to the Administrator for 
verification/authorization; (4) the Administrator sends verification/
authorization to the Root Zone Maintainer to make the change; (5) the 
Root Zone Maintainer edits and generates the new root zone file; and 
(6) the Root Zone Maintainer distributes the new root zone file to the 
13 root server operators. Deployment of DNSSEC in the root zone would 
introduce new steps into this process flow, but would not necessarily 
require a change in the existing roles of the various participants in 
the process.
    As a cryptographic key-based system, DNSSEC employs two types of 
public-private key pairs created for the zone; one is referred to as 
the Zone Signing Key (ZSK) and the other is referred to as the Key 
Signing Key (KSK).\23\ The private components of these keys are kept 
secret and are used for signing purposes. The collection of KSK and ZSK 
public keys published for the root zone is referred to as the root 
keyset.
---------------------------------------------------------------------------

    \23\ See, Ramaswamy Chandramouli and Scott Rose, NIST, ``Secure 
Domain Name System (DNS) Deployment Guide,'' NIST SP 800-81, at 9-3 
- 9-5 (May 2006), https://csrc.nist.gov/publications/nistpubs/800-
81/SP800-81.pdf (last checked September 24, 2008) (This document 
provides deployment guidelines for securing DNS at the enterprise 
level including use of keys and provides a general discussion of the 
structure of the DNS).
---------------------------------------------------------------------------

    Specifically, signing of the root zone would involve three steps:
    (1) The signing of the root zone file itself and the creation of 
the Zone Signing Key (ZSK), which would be performed by the Root Zone 
Signer (RZS);
    (2) The signing of the zone signing keyset and the creation of the 
Key Signing Key (KSK), which would be performed by the Root Key 
Operator (RKO); and
    (3) Publication of the public key information for propagation 
throughout the rest of the Internet.\24\
---------------------------------------------------------------------------

    \24\ See generally, id., at Sections 8 and 9 (These document 
sections provide a general discussion of zone signing guidelines).
---------------------------------------------------------------------------

    As with other changes to the root zone, the Administrator would be 
responsible for verifying/authorizing updates to the root keyset.
    A number of possible models exist to implement these steps into the 
existing root zone file management system. Six possible process flow 
models are presented in Appendix A for consideration and comment; 
commenters are encouraged to also review the graphic representations of 
these process flows posted on NTIA's website at https://
www.ntia.doc.gov/DNS/DNSSEC.html. The Department recognizes that the 
six process flow models discussed in the appendix may not represent all 
of the possibilities available and invites comments below on alternate 
models, as appropriate.

REQUEST FOR COMMENT:

    The Department seeks comments on DNSSEC deployment and a signed 
root generally, as well as specific details, comments, and evaluations 
of the various process flow models proposed or other process flow 
models that may otherwise be technically feasible to implement DNSSEC 
at the root zone level. Please include an analysis of the risks, 
benefits, and impacts of each process flow on the DNS security and 
stability generally. This analysis should include whether there are 
security weaknesses or strengths with each process flow model, whether 
there are methods or suggestions that will increase security and 
efficiency, and/or whether any alternative process flow models exist 
that may be preferable to those described in the appendix.

Questions on DNSSEC Deployment Generally

    [bul] In terms of addressing cache poisoning and similar attacks on 
the DNS, are there alternatives to DNSSEC

[[Page 59611]]

that should be considered prior to or in conjunction with consideration 
of signing the root?
    [bul] What are the advantages and/or disadvantages of DNSSEC 
relative to other possible security measures that may be available?
    [bul] What factors impede widespread deployment of DNSSEC?
    [bul] What additional steps are required to facilitate broader 
DNSSEC deployment and use? What end user education may be required to 
ensure that end users possess the ability to utilize and benefit from 
DNSSEC?

General Questions Concerning Signing of the Root Zone

    [bul] Should DNSSEC be implemented at the root zone level? Why or 
why not? What is a viable time frame for implementation at the root 
zone level?
    [bul] What are the risks and/or benefits of implementing DNSSEC at 
the root zone level?
    [bul] Is additional testing necessary to assure that deployment of 
DNSSEC at the root will not adversely impact the security and stability 
of the DNS? If so, what type of operational testing should be required, 
and under what conditions and parameters should such testing occur? 
What entities (e.g., root server operators, registrars, registries, TLD 
operators, ISPs, end users) should be involved in such testing?
    [bul] How would implementation of DNSSEC at the root zone impact 
DNSSEC deployment throughout the DNS hierarchy?
    [bul] How would the different entities (e.g., root operators, 
registrars, registries, registrants, ISPs, software vendors, end users) 
be affected by deployment of DNSSEC at the root level? Are these 
different entities prepared for DNSSEC at the root zone level and /or 
are each considering deployment in their respective zones?
    [bul] What are the estimated costs that various entities may incur 
to implement DNSSEC? In particular, what are the estimated costs for 
those entities that would be involved in deployment of DNSSEC at the 
root zone level?

Operational Questions Concerning Signing of the Root Zone

    [bul] The Department recognizes that the six process flow models 
discussed in the appendix may not represent all of the possibilities 
available. The Department invites comment on these process flow models 
as well as whether other process flow model(s) may exist that would 
implement deployment of DNSSEC at the root zone more efficiently or 
effectively.
    [bul] Of the six process flow models or others not presented, which 
provides the greatest benefits with the fewest risks for signing the 
root and why? Specifically, how should key management (public and 
private key sets) be distributed and why? What other factors related to 
key management (e.g., key roll over, security, key signing) need to be 
considered and how best should they be approached?
    [bul] We invite comment with respect to what technical capabilities 
and facilities or other attributes are necessary to be a Root Key 
Operator.
    [bul] What specific security considerations for key handling need 
to be taken into account? What are the best practices, if any, for 
secure key handling?
    [bul] Should a multi-signature technique, as represented in the M 
of N approach discussed in the appendix, be utilized in implementation 
of DNSSEC at the root zone level? Why or why not? If so, would 
additional testing of the technique be required in advance of 
implementation?

    Dated: October 3, 2008.
Meredith Attwell Baker,
Acting Assistant Secretary for Communications and Information 
Administration.

Appendix A: Six Possible Process Flow Models

    The first three of the process flows described below assign the 
responsibilities of Root Zone Signer, Root Key Operator, and key 
publishing among the existing parties to the root zone file 
management process or to a new, as yet unspecified, third party 
without materially changing the other pre- existing roles and 
responsibilities. The fourth model represents a variation of 
previous models, while changing the current root zone management 
process flow. The fifth model is also a variation of previous 
models, while maintaining the current root zone management process 
flow. The sixth model describes a process flow in which more than 
one third party, as yet unspecified, are introduced as Root Key 
Operators, which can be applied to all the previous process flows.
    Proposed Process Flow 1 (see diagram at https://www.ntia.doc.gov/
DNS/DNSSECproposal1.pdf). In Proposed Process Flow 1, the current 
root zone file management process outlined previously would remain 
unchanged except that after the Root Zone Maintainer edits and 
generates the new root zone file, it would then generate the ZSK and 
send it to the Root Key Operator. The Root Key Operator would then 
generate the KSK, sign the root keyset, and transmit the keyset 
update request to the Administrator. After the Administrator 
verifies/authorizes the key update request, it would notify the Root 
Zone Maintainer (in this model serving as the Root Zone Signer), 
which would sign the root zone file and publish it to the root 
server operators. Concurrently, the Administrator would also notify 
the Root Key Operator that the key update request has been verified/
authorized and the RKO would then publish the public key 
information.
    In this process flow, the role of Root Zone Signer is assigned 
to the Root Zone Maintainer. The Root Key Operator responsibilities 
are assigned to none of the current participants in the root zone 
file management process. Rather, these duties are assigned to an 
unspecified third party. This approach involves little change to the 
current root zone file management process and its existing 
assignments of roles and responsibilities.
    Proposed Process Flow 2 (see diagram at https://www.ntia.doc.gov/
DNS/DNSSECproposal2.pdf). Proposed Process Flow 2 is similar to 
Proposed Process Flow 1 except that in this model, the Root Key 
Operator is responsible for generating both the Zone Signing Key as 
well as the Key Signing Key. After creating the ZSK, the Root Key 
Operator transmits it to the Root Zone Maintainer/Signer, which 
maintains the ZSK.
    Proposed Process Flow 3 (see diagram at https://www.ntia.doc.gov/
DNS/DNSSECproposal3.pdf). This model also corresponds closely to 
Proposed Process Flow 1. However, in this model, the Root Key 
Operator, both generates the ZSK and signs the root zone file. Thus, 
after the Root Zone Maintainer generates the root zone file, it 
would then transmit the file to the Root Key Operator. In turn, the 
Root Key Operator, after generating the ZSK and the KSK, signing the 
root keyset, and obtaining verification/authorization from the 
Administrator, would sign the root zone file and return it to the 
Root Zone Maintainer for delivery. In this scenario, the 
Administrator would communicate only with the Root Key Operator with 
respect to the verification/authorization of the key update request.
    Proposed Process Flow 4 (see diagram at https://www.ntia.doc.gov/
DNS/DNSSECproposal4.pdf). This model describes a process flow in 
which the existing roles and responsibilities with respect to the 
management of the authoritative root zone file are significantly 
altered.\25\ Specifically, under this proposed process flow, 
existing responsibilities for editing and generating the root zone 
file that now reside with the Root Zone Maintainer would be 
transferred to the IANA Functions Operator. In addition, the IANA 
Functions Operator would also be assigned the responsibilities of 
Root Zone Signer. The Root Zone Maintainer would continue to be 
responsible for distributing the now-signed root zone file to the 13 
root server operators.
---------------------------------------------------------------------------

    \25\ Under the IANA functions contract with the Department, 
ICANN submitted a proposal substantially similar to Process Flow 4 
for the Department of Commerce's consideration on September 2, 2008. 
That proposal is pending before the Department. This proposal is 
available at http:/ /www.ntia.doc.gov/DNS/ICANNDNSSEC Proposal.pdf.
---------------------------------------------------------------------------

    Thus, under this model the process would operate as follows: 
After receiving a change request from a TLD operator, the IANA 
Functions Operator would process the request and send a request to 
the

[[Page 59612]]

Administrator for verification/authorization to make the change. 
Upon receiving verification/authorization, the IANA Functions 
Operator would then edit and generate a new root zone file. The Root 
Key Operator function would be physically collocated with the IANA 
Functions Operator, responsible for generation of the KSK, signing 
the root keyset, and publishing the public key information. The IANA 
Functions Operator would also generate the ZSK and sign the root 
zone file. After signing the root zone file, the IANA Functions 
Operator would send the signed root zone file to the Root Zone 
Distributor (formally Root Zone Maintainer), which, in turn, would 
distribute it to the 13 root server operators. Under this process 
flow, the Administrator would perform the verification/authorization 
functions as in the other models.
    Proposed Process Flow 5 (see diagram at https://www.ntia.doc.gov/
DNS/DNSSECproposal5.pdf). This model maintains the existing roles 
and responsibilities with respect to the management of the 
authoritative root zone file.\26\ That is, the existing 
responsibilities for editing and generating the root zone file that 
now reside with the Root Zone Maintainer would remain the same with 
the additional/new responsibility of Root Zone Signer and 
collocating the Root Key Operator function. The Root Zone Maintainer 
would continue to be responsible for distributing the now-signed 
root zone file to the 13 root server operators.
---------------------------------------------------------------------------

    \26\ Under the Cooperative Agreement with the Department, 
VeriSign submitted a proposal substantially similar to Process Flow 
5 for the Department of Commerce's consideration on September 23, 
2008. That proposal is pending before the Department. This proposal 
is available at https://www.ntia.doc.gov/DNS/VeriSignDNSSEC 
Proposal.pdf.
---------------------------------------------------------------------------

    Thus, under this model the process would operate as follows: 
After receiving a change request from a TLD operator, the IANA 
Functions Operator would process and send a request to the 
Administrator for verification/authorization to make the change. 
Upon receiving verification/authorization, the Root Zone Maintainer 
would then edit and generate a new root zone file. The Root Key 
Operator responsibility would be physically collocated with the Root 
Zone Maintainer, responsible for generation of the KSK, signing the 
root keyset, and publishing the public key information. The Root 
Zone Maintainer would also generate the ZSK and sign the root zone 
file. After signing the root zone file, the Root Zone Maintainer 
would distribute it to the 13 root server operators. Under this 
process flow, the Administrator would perform the verification/
authorization functions as in the other models.
    Proposed Process Flow 6 (see diagram at https://www.ntia.doc.gov/
DNS/DNSSECproposal6.pdf). The proposed process flow models one 
through three illustrate the important role played by the Root Key 
Operator. As presented, they depict the RKO responsibilities as 
being discharged by a single entity. In process flows four and five, 
the RKO responsibilities are collocated with either the IANA 
Functions Operator or the Root Zone Maintainer. However, 
cryptographic mechanisms exist that theoretically would permit two 
or more entities to participate in the RKO procedures, known as 
multi-signature technique, no matter where the RKO responsibilities 
are located.\27\ Such a shared key framework is commonly referred to 
as an ``M of N'' approach, in which ``M'' is the minimum number of 
those entities that must participate in order to generate and use 
the key in question, and ``N'' represents the number of entities 
that share control of the key. In an M of N approach, only a 
predetermined subset of the key shares is required to generate a 
signature. For example, a three (3) of five (5) scheme would include 
five parties (N) with distinct key shares, but any three (M) of the 
five parties are required to generate a valid signature.\28\
---------------------------------------------------------------------------

    \27\ See Tal Rabin, IBM T. J. Watson Research Center, ``A 
Simplified Approach to Threshold and Proactive RSA'' (1998)(Rabin), 
https://www.research.ibm.com/security/prsa.ps (last checked 
September 24, 2008); Adi Shamir, ``How to Share a Secret,'' 
Communications of the ACM, Volume 22, Issue 11, 612-13 (R. Rivest, 
eds., Nov. 1979)(discussion of a mathematical model that facilitates 
dividing a set of data in a certain number pieces that allows the 
data set to be easily reconstructed); T. Keisler and L. Harn, ``RSA 
Blocking and Multisignature Schemes with No Bit Expansion,'' 
Electronic Letters, Volume 26, Issue 18, 1490-91 (Aug. 
1990)(describes one example of a multi-signature technique).
    \28\ See Rabin, supra note 27; for further information on this 
technique see generally, Elaine Barker, William Barker, William 
Burr, William Polk, and Miles Smid, NIST, ``Recommendation for Key 
Management - Part 1: General (revised)'' NIST Special Publication 
800-57 Part 1 (May 2006), http:/ /csrc.nist.gov/publications/
nistpubs/ 800-57/SP800-57-Part1.pdf (last checked September 24, 
2008) (this refers to this class of techniques as ``split knowledge 
procedures'').
---------------------------------------------------------------------------

    The M of N approach could theoretically be applied to the KSK, 
the ZSK, or both. However, increasing the number of participants 
under this approach increases the complexities of the key management 
process. Because the ZSK would be used much more frequently than the 
KSK, Process Flow 6 applies the M of N approach only to management 
of the KSK. It should be noted that this cryptographic approach 
could be applied to any of the previous process flow models.
    Process Flow 6 depicts the multi-signature technique as applied 
to Process Flow 1. The N entities would participate in the 
generation of the KSK key pair, and each would retain a share of the 
private key. Generating a signature with the KSK, such as signing a 
new ZSK, would require participation of M key shares.
    Process Flow 6 does not propose specific values for either M or 
N; however, these parameters would need to be resolved prior to 
implementation of such a framework. This would entail deciding, 
among other things, (a) how many total RKOs (N) would be technically 
feasible; (b) what subset of these (M) would be reasonable or 
appropriate to enable reconstitution of the key; and (c) what other 
attributes would be necessary from a technical and policy standpoint 
to carry out this responsibility. The Department invites comments 
regarding this technique and its application at the root zone level.
[FR Doc. E8-23974 Filed 10-8-08; 8:45 am]
BILLING CODE 3510-60-S