Date: June 28, 2006
Office of International Affairs
National Telecommunications and Information Administration
1401 Constitution Avenue, NW., Room 4701,
Washington, DC 20230
Subject: DNS Transition Notice of Inquiry Contribution -- re DNSSEC Deployment at the DNS Root
From: Thierry Moreau
CONNOTECH Experts-conseils, inc.
9130 Place de Montgolfier
Canada H2M 2A1
Dear Ms Alexander:
In response to the NTIA Notice of Inquiry on the Internet Technical Coordination Transition, I submit the following contribution, not addressing a specific question. I notice the strong commitment of the US Government to its role in the ICANN institutional framework, which the following contribution abstain from questioning directly. Instead, I present an analysis of a specific aspect of Internet evolution, with the humble hope to assist policy development and governance in an environment of increased reliance on the DNS data for ever more critical applications.
The DNS governance NoI (Notice of Inquiry) from NTIA is a welcome initiative. I use this opportunity to discuss the DNS integrity vulnerability that was not a significant concern in 1998, and the DNSSEC protocol development project which addresses this integrity vulnerability. The DNSSEC emerging technology deserves explanations, hence the extensiveness of the present NoI contribution. In these explanations, I attempt to reflect views prevailing in specialized circles, but I also present personal opinions generally based on forward looking analysis of DNS governance issues created by the attempt to fix the DNS integrity vulnerability. However, the present NoI contribution is not written as a tutorial: a text portion may be based on notions discussed in greater details later in the document.
2. The DNS Integrity Vulnerability
It is well known that data retrieved from the DNS is not protected by any integrity mechanism that would prevent data tampering between zone data publication by the DNS zone administrator and Internet user reliance on this data. I refer to this as the DNS integrity vulnerability. DNS cache poisoning is a type of IT security attack that exploits the DNS integrity vulnerability.
Does the DNS integrity vulnerability really matter? In discussing this question, we get a sense of the demand for IT security technology, i.e. an intriguing paradox between the ever increasing set of attacks on e-commerce operators (including e-government and online banking) and the limited effectiveness of any workable IT security mechanism. A magic fix of the DNS integrity vulnerability would directly solve a limited set of attacks (reference ), but it is doubtful that any encompassing approach to e-commerce security can be drafted without addressing the DNS integrity vulnerability. While the DNS integrity vulnerability definitely needs to be addressed from the perspective of an educated observer of Internet security, the application use of any DNS integrity mechanism is currently absent, and the impact on human factors still needs attention. In summary, some latent demand exists for improving DNS integrity as an e-commerce strengthening measure; the timing is as soon as possible; but the measurable benefits are indirect and contingent on application support of DNS services not currently available.
Some niche applications would benefit from a fix for the DNS integrity vulnerability. Here is some explanation on their generic relationship to the DNS vulnerability. The primary use of the global DNS database is the translation of domain names to host addresses. But the DNS has other uses, based on its distributed database arrangement, providing on-line access to “resource records” indexed by domain names. Some of these DNS alternate uses may benefit from a solution to the DNS integrity vulnerability, notably the distribution of cryptographic keys associated with domain names. There are current developments for two applications which would rely on DNS distributed cryptographic keys: unsolicited bulk e-mail prevention or filtering, and message encryption. These two emerging Internet security schemes would clearly benefit from a solution to the DNS integrity vulnerability, but would still provide security with the current DNS, at a reduced level.
It is not a purpose of the present NoI contribution to comprehensively review the security schemes which depend of a solution to the DNS integrity vulnerability, but a list of references certainly supports the emergence of a recurring pattern. In the case of unsolicited bulk e-mail filtering, two protocol development initiatives can be cited:
In the case of message encryption supported by DNS distribution of cryptographic keys, some of the current protocol developments can be cited:
It remains to be seen whether any subset of these initiatives will drive sufficient demand for fixing the DNS integrity vulnerability in the scope of the global DNS.
3. Impact of DNS Support for IT Security Schemes
There are possible policy implications in the distribution of trusted public encryption keys in the global DNS in which the integrity vulnerability would have been addressed. These policy implications are linked to government imposed controls on encryption technologies. Network traffic encryption technologies are readily available nowadays; however, one can argue that ubiquitous trusted encryption key distribution does not exist yet, based on the ease with which end-users can be deceived by browser X.509 certificate spoofing, including tampering with self-signed certificate configuration. The emergence of a different strategy for large-scale distribution of encryption public keys is likely to trigger questioning in some of the government offices having a “national security” mandate. In this regard, the relaxation of export controls on encryption items by the United States (back in year 2000) should not be mistaken as a global elimination of government imposed controls on encryption technologies.
It is obvious that if the above suspected encryption controls concerns are real, they would inextricably relate to the international nature of the global DNS. This is compounded by fact that the application uses of the DNS would be targeted by the government control scrutiny, while DNS technical coordination and policy development has historically focused on the name registration aspect of the DNS.
4. The DNSSEC Protocol Extension
Up to now, I didn't mention DNSSEC a solution to the DNS integrity vulnerability. Indeed, DNSSEC is the only proposal that addresses this vulnerability, originated from a decade-long protocol development effort in the IETF (references , , and ), notably with the bind software supplier as a flagship open source implementation (reference ). It is not a purpose of the present NoI contribution to explain the DNSSEC security technology besides what is relevant to identify current and potential stakeholders and policy implications of the technology.
The DNSSEC security architecture is both conceptually simple and intricate at the implementation level. In a nutshell, the DNS security services are provided with the public key digital signature technology applied in batch mode, i.e. the DNS data is digitally signed when it is changed in the distributed database, and not when it is requested in a DNS query. Moreover, the DNSSEC chains of digital signatures are structured along the DNS tree structured name space: this superimposes a trust model over a delegation scheme that was originally intended for database maintenance operational duties. The DNS technical coordination burden associated with DNSSEC deployment is thus closely linked to the DNS root zone administration, and the term “DNS root zone singing” is understood among specialized forums as referring to the necessary procedures and operations for DNSSEC support at the DNS root, within the institutional framework subject to the NTIA NoI.
Currently, DNSSEC is deployed operationally in at least one TLD, namely the Swedish .se TLD (reference ). Another noteworthy deployment effort occurs at RIPE NCC (Reséaux IP Européens Network Coordination Center) (reference ), with a coverage limited to portions of the DNS hierarchy but with a rich set of support documentation and software utilities. There are other limited-scope experiments, and a few TLD administrations are planning DNSSEC deployment. DNSSEC adoption signals from US government comes through a few NIST publications, including a detailed guidelines document (reference ), and a formal designation as a recommended security control in an IT security standard applicable to the US government (reference ), where secure name lookup service is referred under acronyms SC-20 and SC-21, respectively for DNS authoritative source and DNS resolution. None of these DNSSEC deployment initiatives cover the trust anchor key management issues to be explained shortly.
There is still on-going work on DNSSEC protocols. Progress is being made on the NSEC3 work item, a privacy enhancement mechanism, more specifically a countermeasure against unauthorized collection of every domain name in a given DNS zone, a possibility inadvertently introduced in the DNSSEC protocol (“privacy” is not to be confused with “confidentiality” in the context of NSEC3). Progress is less clear for the issue called “trust anchor key management,” (an alternate term is “automated trust anchor key rollover,” focusing on the required technical functionality). Trust anchor key management refers to the security procedures surrounding the DNS root signature key (the trust “anchor” is tied to the “end of the chain” of digital signatures along the DNS name hierarchy). It is thus an IETF work item related to the institutional framework subject to the NTIA NoI. As the promoter of a patent-pending solution for automated trust anchor key rollover, I am an interested observer of any initiative which might ease the DNSSEC deployment at the DNS root and TLDs, including sensible trust anchor key management procedures.
There are also important issues for deployment. The DNSSEC operational burden on registries and registrars can hardly be ignored, and a DNSSEC business model for the highly price competitive registrar market is yet to emerge. Moreover, DNSSEC, as a global service upgrade in the Internet, faces the chicken-and-egg acceptance paradox, where the end-user benefits seems to materialize only when some critical mass of DNS nameserver support is reached. Other important issues for effectiveness in providing DNS data assurance include application software support, and an unbounded security awareness campaign: after all, it is the end-user who makes the ultimate decision to rely on computer results based on DNS provided data. Some of these issues are relevant to the institutional framework subject to the NTIA NoI.
5. The Policy Implications of DNSSEC
The DNSSEC security technology is “almost ready for field deployment,” but this assessment has been made for years, with repeated postponements. As the list of outstanding issues slowly shortens, the toughest issues remain, including the policy implications at the DNS root and TLD levels. The intricacies of “DNS root signing politics” are often mentioned, but seldom described. In the present contribution to the NoI, I attempt to describe these DNSSEC policy implications at a greater level of details than in other public accounts (in this regard, reference  is a presentation which I find the most comprehensive).
The DNSSEC deployment has implications at the DNS root level, including:
These are new operational requirements tainted by the incremental security provided by the DNSSEC technology architecture. Some observers expressed the desire to see these operational requirements to be fulfilled without any impact on DNS root administration policy debates. Indeed, such a course of events would allow smooth introduction of DNSSEC, in a timely manner at the DNS root and, in the global Internet, at the pace of the emerging demand for fixing the DNS integrity vulnerability.
However, my understanding of the DNSSEC deployment within the institutional framework subject to the NTIA NoI let me identify some governance issues:
6.DNSSEC Deployment Efforts in Current Institutional Framework
We can make an historical review of ICANN reaction to the DNSSEC development activities. The first mention of DNSSEC in the ICANN activity reports to the US DoC are in March 2003 (reference ), as an area of attention for the SSAC (Security and Stability Advisory Committee). In October 2005, the ICANN actual involvement with DNSSEC amounted to little more than taking note of progress made in other Internet organizations: “ICANN has provided opportunities to promote DNSSEC to its constituents [...]. Many of the developers of DNSSEC are directly involved in the ICANN process[...]” (references  and ). I see no sign of any work actually done within ICANN, or under the auspices of ICANN.
However, there is now consideration of a DNSSEC deployment at the management level at ICANN. A foremost sign is the root transition agreement (reference ) which is part of the ICANN-Verisign lawsuit settlement agreement currently pending DoC approval. The root transition agreement appears as a contractual arrangement for DNSSEC deployment at the DNS root by ICANN, Verisign, and the US DoC, with input from the IAB. But the vagueness of this document wording let me qualify it as an “agreement to agree,” which I believe is dubious practice in contract negotiations, even more so when the negotiations are in the context of a pending dispute resolution. In any event, the root transition agreement seemed to be echoed in the latest ICANN operational plan (reference ) where the DNSSEC deployment activity is described as “Determine timetable, coordination requirements and costs for full deployment.”
In summary, there has been little actual ICANN involvement in the DNSSEC deployment initiative, and certainly no leadership in either policy development, or assertion that DNSSEC deployment is devoid of policy implications.
The other institutional angle to DNSSEC is focused on the protocol development, mainly with the IETF, as a consensus-based engineering organization, and the IAB, as a liaison between IETF/IESG protocol development and the operational perspective of ICANN. There is a cultural gap between the voluntary-participation-based IETF working groups, including the DNSEXT working group mandated for DNSSEC protocol development, and the operational accountability demands on the more formal ICANN processes. I personally see this cultural gap impeding progress towards adoption of a good automated trust anchor key rollover solution for the DNS root signature key.
7.Summary Observation and Recommendations
My foremost summary observation is that DNSSEC deployment adds specific technical coordination issues to the list of ICANN coordination functions, and to the extent that the prior functions were not performed as originally intended and/or to the expectations of Internet community participants, there is little chance for the current institutional framework to be effective in providing DNSSEC support at the root.
According to the DoC statement of June 2005, DoC maintains its “historic role in authorizing changes or modifications to the authoritative root zone file.” (reference ) Irrespective of which organization has formal authority over ICANN, I may state recommendations for guidance from such an organization to ICANN (or successor) about DNSSEC deployment.
7.1 Don't Use DNSSEC Support at Root Level for to Control Encryption Key Distribution
The recommendation reads as follows:
7.2 Help the Emergence of a “DNSSEC Business Model”
The recommendation reads as follows:
7.3 Avoid Contractual Restrictions on DNSSEC Secure Delegations from the Root
The recommendation reads as follows:
E.g. the precondition might be limited to a provision where the TLD administrator acknowledges that DNSSEC private signature keys deserve protection by commercially acceptable security procedures. Another way to see this recommendation is that the DNSSEC secure delegation option from the root should be provided almost automatically, and not contingent upon a formal contractual relationship where one does not exist prior to DNSSEC support by the TLD.
Note that the above three recommendations focus on DNS governance, while ICANN is expected to develop the required operational procedures (e.g. for implementation characteristics of the digital signature technology -- who controls the root signature key) as part of its technical coordination functions.
In the absence of such guidance from whichever organization has formal authority over ICANN, uncertainty will remain in these three aspects of DNSSEC deployment at the root, and a realistic deployment timetable is unlikely to emerge. For Internet participants wishing to see an end to the DNS integrity vulnerability, lack of progress at DNSSEC deployment at the root due to ICANN inefficiency in policy development is perhaps an hopeless circumstance. Conversely, the stakeholders questioning the current ICANN institutional framework for limited actual support of Internet evolution would see the DNSSEC deployment delays as yet another argument for radical change.
The above is my attempt to make a structured analysis of DNSSEC for policy development and governance purposes, with focus at the DNS root. At the TLD administration level, there appears diverse environments which might shape diverse approaches to DNSSEC deployment. If the DNS root administration is seen as a service to a federation of TLD administrations, attention should be paid to a TLD administration perspective, which I did not address. Moreover, it should be noted that ICANN inaction is used as a justification for at least one initiative that circumvent the lack of DNSSEC support at the root.
In summary, DNSSEC deployment somehow rests on whichever organization has formal authority over ICANN, e.g. with respect to the three above recommendations. Otherwise, many of the above issues deserve to be addressed in forums organized by ICANN for to achieve meaningful participation and representation of key stakeholders through this significant Internet evolution. This is obviously not occurring as it should.
 Aaron Emigh, "Online Identity Theft: Phishing Technology, Chokepoints and Countermeasures", Radix Labs, October 3, 2005, available at http://www.antiphishing.org/Phishing-dhs-report.pdf -- note that some experts involved in the preparation of this report acknowledged the editorial oversight of omitting DNSSEC as a countermeasure for the DNS integrity vulnerability.
 E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas, "DomainKeys Identified Mail Signatures (DKIM)", May 22, 2006, draft-ietf-dkim-base-02, http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-02.txt, see also http://www.ietf.org/html.charters/dkim-charter.html
 Mark Delany, "Domain-based Email Authentication Using Public-Keys Advertised in the DNS (DomainKeys)", 27 March 2006, http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-04.txt
 E. Allman, H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC4405, April 2006.
 J. Lyon, M. Wong, "Sender ID: Authenticating E-Mail", RFC4406, April 2006.
 J. Lyon, "Purported Responsible Address in E-Mail Messages", RFC4407, April 2006.
 M. Wong, W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC4408, April 2006.
 S. Josefsson, "Storing Certificates in the Domain Name System (DNS)", RFC4398, March 2006
 M. Richardson, "A Method for Storing IPsec Keying Material in DNS", RFC4025, March 2005
 M. Richardson, D.H. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC4322, December 2005
 J. Schlyter, W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", RFC4255, January 2006
 P. Nikander, J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", February 24, 2006, http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-06.txt
 R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005
 R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005
 R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005
 Internet Systems Consortium, ISC BIND, http://www.isc.org/index.pl
 DNSSEC(.se) -- signed since 13th September 2005, http://dnssec.nic.se/
 DNSSEC Deployment at the RIPE NCC, https://www.ripe.net/rs/reverse/dnssec/index.html
 NIST Special Publication 800-81, Secure Domain Name System (DNS) Deployment Guide, http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf
 NIST Special Publication 800-53, Revision 1, Recommended Security Controls for Federal Information Systems, public draft, March 2006, http://csrc.nist.gov/publications/drafts/800-53-rev1-ipd-clean.pdf
 Jim Reid, DNS-MODA, TLD Registry Considerations for Secure DNS (DNSSEC), presentation to APTLD (Asia Pacific Top Level Domain Association) meeting in Aman, Jordan, October 2005, http://www.aptld.org/meeting/2005/10_Amman/file/Jim-Reid-Secure-DNS.pdf
 Sixth Status Report Under ICANN/US Government Memorandum of Understanding, 31 March 2003, http://www.icann.org/general/status-report-31mar03.htm
 Twelfth Status Report under ICANN/US Government Memorandum of Understanding Quarter ending 30 September 2005, http://www.icann.org/general/mou-status-report-07oct05.pdf
 Thirteenth Status Report under ICANN/US Government Memorandum of Understanding Quarter ending 30 March 2006, http://www.icann.org/general/mou-status-report-07apr06.pdf
 Root Server Management Transition Completion Agreement, http://www.icann.org/topics/vrsn-settlement/revised-root-transition-agreement-clean-29jan06.pdf
 ICANN Annual Operating Objectives for Fiscal Year 2006-07, Draft dated 22 Jun 2006 http://www.icann.org/announcements/operating-plan-22jun06.htm
 U.S. Principles on the Internet’s Domain Name and Addressing System, http://www.ntia.doc.gov/ntiahome/domainname/USDNSprinciples_06302005.pdf