Federal Register: October 9, 2008 (Volume 73, Number 197)
DOCID: fr09oc08-61 FR Doc E8-23974
DEPARTMENT OF COMMERCE
National Telecommunications and Information Administration
DOCUMENT ACTION: Notice of Inquiry
Docket Number: 0810021307-81308-01
DATES: Comments are due on November 24, 2008.
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.
Enhancing the Security and Stability of the Internet's Domain Name and Addressing System,
DOCUMENT BODY 2:
Enhancing the Security and Stability of the Internet's Domain Name and Addressing System
Background. The Domain Name and Addressing System (DNS) is a critical component of the Internet infrastructure and is used by almost every Internet protocolbased 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), http://books.nap.edu/
vulnerabilities including DNS spoofing, cache poisoning, etc., and includes links to tools and solutions).
Development of the DNSSEC Protocol. To mitigate the longrecognized
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), http://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), http://www.ietf.org/rfc/ rfc4033.txt (last checked September 24, 2008).
The DNSSEC protocol is designed to allow for deployment in discrete
zones within the DNS infrastructure without requiring deployment
elsewhere, as DNSSEC is an optin technology. Signing of any individual zone or domain within the hierarchy does not
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 subdomains 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 8687. The Department recognizes that the ultimate success of DNSSEC would also require a widespread education campaign among endusers 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 secondlevel 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), http:// 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), http://www.networkworld .com/news/2008/092208government 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), http://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), www.whitehouse.gov/omb/ memoranda/fy2008/ m0823.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), http://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 securityaware 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 8586.
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), http://www.dnssecdeployment.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), http://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, subdomains) and the
trust anchor framework required for securityaware 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), http://www.watson.org/~weiler/INI 199919.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 testbed 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), www.ripe.net/ripe/wg/dns/icannrootsigning.pdf (last checked September 24, 2008); Nominet (the .uk registry), see Nominet, ``Signing the Root'' (October 2007), http:// 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 (http://www.rs.net/)
These testbeds were established to demonstrate the technical feasibility for signing the root zone on a daytoday routine basis. However, as they have largely been developed to evaluate technical aspects of signing the root, these testbed 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, www.ntia.doc.gov/ntiahome/domainname/ usdnsprinciples06302005.htm (last checked September 24, 2008). \20\ National Institute of Standards and Technology (NIST), U.S. Department of Commerce, DNSSEC Project, http://wwwx.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), http://www.whitehouse.gov/ omb/memoranda/fy2008/m0823.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 subdomains 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 http://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 keybased system, DNSSEC employs two types of
publicprivate 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 80081, at 93 95 (May 2006), http://csrc.nist.gov/publications/ nistpubs/800 81/SP80081.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 http:// 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.
FOR FURTHER INFORMATION CONTACT
For further information about this Notice, please contact Ashley Heineman at (202) 4820298 or email@example.com.