Network Working Group G. Guette Internet-Draft IRISA / INRIA Expires: February 15, 2005 D. Fort B. Cousin IRISA / University of Rennes I August 17, 2004 Generalization of Delegation Signer Resource Record (DS RR) use draft-guette-ds-generalization-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document generalise the DS RR use in order to reduce the number of secure entry points in a resolver and in order to create a secure link between islands of security. This allows to simulate a secure spanning tree among all secure zones and reduces the number of non secure name resolutions. Guette, et al. Expires February 15, 2005 [Page 1] Internet-Draft DS Generalization August 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The three ways to add a secure zone in the DNS tree . . . . . 3 2.1 The new secure zone is a leaf of an island of security . . 3 2.2 The new secure zone is the new apex of an island of security . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 The new secure zone is a new island of security . . . . . 4 3. Influence of the three previous topologies on the name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 The new secure zone is a leaf of an island of security . . 4 3.2 The new secure zone is the new apex of an island of security . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3 The new secure zone is a new island of security . . . . . 4 4. The DS resource record . . . . . . . . . . . . . . . . . . . . 4 4.1 DS RR wire format and its new use . . . . . . . . . . . . 4 5. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Authentication of a new secure zone and key rollover problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1 The key rollover problem . . . . . . . . . . . . . . . . . 9 7. Changes on the resolver's resolution algorithm . . . . . . . . 10 8. Pros and cons . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security considerations . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 13 Guette, et al. Expires February 15, 2005 [Page 2] Internet-Draft DS Generalization August 2004 1. Introduction The DNS security extensions (DNSSEC) [5][2][1][3] uses public-key cryptography and digital signatures. It stores the public part of keys in DNSKEY Resource Records (RRs) and signatures in RRSIG RRs. In order to validate a resource record, a chain of trust is built from a secure entry point [4] to the RR queried. To allows the build of a chain of trust, a delegation signer (DS) RR [6] is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. Nevertheless, some delegation may remain unsecure and then no DS RR is stored in the parent zone for this delegation. This implies islands of security in the DNS tree. From the point of view of resolvers, secure name resolutions can be performed if and only if the resolver has a secure entry point and a secure path exists between this secure entry point and the resource queried (i.e., there is no unsecure delegation on the path). In consequence, as a resolver may query any DNS name, a resolver must have statically configured at least one secure entry point for the apex of all existing islands of security. This is totally impossible to manage due to the number of keys needed. In this document we describe a generalization of DS RR use that allows to reduce the number of secure entry point configured in the resolver at the minimum. Section 2 and 3 describe the different topologies induce by adding a new secure zone and their consequences. Section 4, 5 and 6 describe the new use of DS RRs and the algorithm to update/create these DS RRs. Section 7 proposes changes on the resolver's resolution algorithm and section 8 discusses the pros and cons of the new use of DS RR. 2. The three ways to add a secure zone in the DNS tree When a DNS zone deploys DNSSEC, three cases can arise: o This zone becomes a new leaf of an existing island of security. o This zone becomes a new apex of at least one existing island of security. o This zone becomes a new island of security. 2.1 The new secure zone is a leaf of an island of security When a DNS zone deploys DNSSEC and becomes a leaf of an existing island of security, its parent zone must create and deploy the DS RR for this new secure delegation. Guette, et al. Expires February 15, 2005 [Page 3] Internet-Draft DS Generalization August 2004 2.2 The new secure zone is the new apex of an island of security When a DNS zone deploys DNSSEC and becomes the new apex of an island of security (i.e., the new zone owns any delegation for an existing apex of an island of security), the new secure zone must create and store DS RR for all its secure delegated zones. 2.3 The new secure zone is a new island of security This topology appears when the new secure zone has no secure parent and no secure child zone. DS RR for this zone can not be created because the parent zone is not secure and the new secure zone does not create DS RR because it does not own any secure delegation. 3. Influence of the three previous topologies on the name resolution 3.1 The new secure zone is a leaf of an island of security In this case, the new secure zone does not impact on the name resolution. Either resolvers have already a trust anchor for the apex of the island of security and the resolver can perform secure name resolution, or resolvers do not have a trust anchor for the apex of the island of security and they can not perform a secure name resolution. 3.2 The new secure zone is the new apex of an island of security In this case, the apex of the island of security changes and a resolver that wants to perform secure name resolution about the new secure zone must have a trust anchor for this new secure zone. Thus, the new secure zone should publish its public key on various media in order to notify administrators of resolvers that a new secure zone exists. A diffusion is needed. 3.3 The new secure zone is a new island of security The new secure zone is nor a leaf neither an apex of an island of security, this case is the creation of a new island of security. The new secure zone has no secure parent and no secure child. This zone becomes a new apex of an island of security and the diffusion of its public key is needed. 4. The DS resource record 4.1 DS RR wire format and its new use All information about the DS wire format can be found in the RFC 3658 [6], the DS RR stores, in the parent zone, some information allowing Guette, et al. Expires February 15, 2005 [Page 4] Internet-Draft DS Generalization August 2004 to identify a key of its secure child zone. For example, the zone "example." has two child zones: "secure.example." which is secure and "unsecure.example." which is unsecure. Assuming that the zone "apex.unsecure.example." exists and is secure, the zone "example." contains at least the following records: example. SOA example. NS ns1.example. example. DNSKEY example. NSEC secure.example. NS SOA DNSKEY RRSIG NSEC example. RRSIG(SOA) example. RRSIG(NS) example. RRSIG(NSEC) example. RRSIG(DNSKEY) secure.example. NS ns1.secure.example. secure.example. DS tag=12345 alg=3 digest_type=1 secure.example. NSEC unsecure.example. NS RRSIG NSEC DS secure.example. RRSIG(NSEC) secure.example. RRSIG(DS) unsecure.example. NS ns1.unsecure.example. unsecure.example. NSEC example. NS RRSIG NSEC unsecure.example. RRSIG(NSEC) There is nothing in the "example." zone file about the secure zone "apex.unsecure.example.". In this document, we generalized the use of the DS RR, allowing a zone that has unsecure delegation(s) to store a DS RR that identifies a key of the apex of the next island of security in the subdomain of the unsecure delegation. On the previous example this is: Guette, et al. Expires February 15, 2005 [Page 5] Internet-Draft DS Generalization August 2004 example. SOA example. NS ns1.example. example. DNSKEY example. NSEC secure.example. NS SOA DNSKEY RRSIG NSEC example. RRSIG(SOA) example. RRSIG(NS) example. RRSIG(NSEC) example. RRSIG(DNSKEY) secure.example. NS ns1.secure.example. secure.example. DS tag=12345 alg=3 digest_type=1 secure.example. NSEC unsecure.example. NS RRSIG NSEC DS secure.example. RRSIG(NSEC) secure.example. RRSIG(DS) unsecure.example. NS ns1.unsecure.example. unsecure.example. NSEC apex.unsecure.example. NS RRSIG NSEC unsecure.example. RRSIG(NSEC) apex.unsecure.example. DS tag=12345 alg=3 digest_type=1 apex.unsecure.example. NSEC example. RRSIG NSEC DS apex.unsecure.example. RRSIG(NSEC) apex.unsecure.example. RRSIG(DS) As the zone "unsecure.example." is unsecure, a DS RR identifying the apex of the next island of security is stored in the "example." zone file. Storing DS RR that identifies the apex of the next island of security, allows to simulate a complete DNSSEC tree containing all the existing secure DNSSEC zone. As a consequence, the number of trusted anchors in a resolver is reduced to the upper island(s) of security keys. 5. Algorithm In this section, we assume that the generalization of DS RR use is effective on all islands of security. The problem of authentication of the new secure zone is discussed in the next section. When a zone deploys DNSSEC, it firstly creates keys and signs its zone file and must contact its closest secure ancestor (CSA) in order to create DS RRs. Then, the CSA creates DS RR for this new secure zone and must transmit to the new secure zone all the DS RRs identifying keys of zones contained in the subdomain of the new secure zone, it owns. The new secure zone takes the transmitted DS RR and signs them to create secure delegations. If some of these delegations are already present in the new secure zone, this means that the new secure zone has become an apex of another island of security. Guette, et al. Expires February 15, 2005 [Page 6] Internet-Draft DS Generalization August 2004 Assuming the following tree with the secure zones "a", "b.a", "f.e.c.a", "g.e.c.a": +--------a--------+ | | | | b.a +----c.a----+ | | | | d.c.a +----e.c.a----+ | | | | f.e.c.a g.e.c.a Zone "a." contains at least the following records: a. SOA a. NS ns1.a. a. DNSKEY a. NSEC b.a. NS SOA DNSKEY RRSIG NSEC a. RRSIG(SOA) a. RRSIG(NS) a. RRSIG(NSEC) a. RRSIG(DNSKEY) b.a. NS ns1.b.a. b.a. DS tag=12345 alg=3 digest_type=1 b.a. NSEC c.a. NS RRSIG NSEC DS b.a. RRSIG(NSEC) b.a. RRSIG(DS) c.a. NS ns1.c.a. c.a. NSEC f.e.c.a. NS RRSIG NSEC c.a. RRSIG(NSEC) f.e.c.a. DS tag=12345 alg=3 digest_type=1 f.e.c.a. NSEC g.e.c.a. RRSIG NSEC DS f.e.c.a. RRSIG(NSEC) f.e.c.a. RRSIG(DS) g.e.c.a. DS tag=12345 alg=3 digest_type=1 g.e.c.a. NSEC a. RRSIG NSEC DS g.e.c.a. RRSIG(NSEC) g.e.c.a. RRSIG(DS) Zone "e.c.a." contains at least the following records: Guette, et al. Expires February 15, 2005 [Page 7] Internet-Draft DS Generalization August 2004 e.c.a. SOA e.c.a. NS ns1.e.c.a. f.e.c.a. NS ns1.f.e.c.a. g.e.c.a. NS ns1.g.e.c.a. When the zone "e.c.a." becomes secure, the previous zone file becomes: a. SOA a. NS ns.a. a. DNSKEY a. NSEC b.a. NS SOA DNSKEY RRSIG NSEC a. RRSIG(SOA) a. RRSIG(NS) a. RRSIG(NSEC) a. RRSIG(DNSKEY) b.a. NS ns1.b.a. b.a. DS tag=12345 alg=3 digest_type=1 b.a. NSEC c.a. NS RRSIG NSEC DS b.a. RRSIG(NSEC) b.a. RRSIG(DS) c.a. NS ns1.c.a. c.a. NSEC e.c.a. NS RRSIG NSEC c.a. RRSIG(NSEC) e.c.a. DS tag=12345 alg=3 digest_type=1 e.c.a. NSEC a. NS RRSIG NSEC DS e.c.a. RRSIG(NSEC) e.c.a. RRSIG(DS) and: Guette, et al. Expires February 15, 2005 [Page 8] Internet-Draft DS Generalization August 2004 e.c.a. SOA e.c.a. NS ns1.e.c.a. e.c.a. DNSKEY e.c.a. NSEC f.e.c.a. NS SOA DNSKEY RRSIG NSEC e.c.a. RRSIG(SOA) e.c.a. RRSIG(NS) e.c.a. RRSIG(NSEC) e.c.a. RRSIG(DNSKEY) f.e.c.a. NS ns1.f.e.c.a. f.e.c.a. DS tag=12345 alg=3 digest_type=1 f.e.c.a. NSEC g.e.c.a. NS RRSIG NSEC DS f.e.c.a. RRSIG(NSEC) f.e.c.a. RRSIG(DS) g.e.c.a. NS ns1.g.e.c.a. g.e.c.a. DS tag=12345 alg=3 digest_type=1 g.e.c.a. NSEC e.c.a. NS RRSIG NSEC DS g.e.c.a. RRSIG(NSEC) g.e.c.a. RRSIG(DS) A secure zone 'X' can store DS RR identifying a key of a non directly delegated zone 'Y' only if it does not exist a secure zone on the path between 'X' and 'Y'. 6. Authentication of a new secure zone and key rollover problem Authentication of a new secure zone is reduced to a DNSSEC bootstrap problem. When a zone becomes secure with DNSSEC there is no in-band way to authentify the key of this new zone. Authentication of the new secure zone, keys of the new secure zone and owner of the new secure zone must be done by the parent zone administrator with another method (X.509 certificates, phone call, meeting, etc.). The generalization of DS RR use implies the generalization of this authentication. In all cases, the new secure zone must contact its CSA and the authentication of the new secure zone must be done by the CSA. Once the authentication is complete, the CSA can create DS RR(s) for the new secure zone. 6.1 The key rollover problem At the present time, when a zone creates a new KSK and has a secure parent zone, the parent zone must create appropriated DS RR(s). If its parent zone is not secured, no DS is needed. The generalization of DS RR use implies that a secure link exists Guette, et al. Expires February 15, 2005 [Page 9] Internet-Draft DS Generalization August 2004 between islands of security and their closest secure ancestor. Thus, when a zone creates a new KSK, this zone must notify its closest secure ancestor. If the zone is inside an island of security (not the apex), the CSA is its parent zone. If a secure zone has no CSA, no DS can be created for this secure zone and no action is needed. This is the case for the root zone. 7. Changes on the resolver's resolution algorithm Currently, a resolver begins a name resolution from a secure entry point and follows the delegations to the resource queried. If there is an unsecured delegation on the path the name resolution is unsecured. With the generalization of DS RR use, this case does not exit anymore. A resolver follows the delegations, if a delegation is unsecure the resolver continues until the next secure zone is found. Then, the resolver asks for a DS RR for this zone, the DS RR is stored in the CSA, the resolver validates the key with this DS and continues the name resolution until to find the RR queried. 8. Pros and cons With the generalization of DS RR use, the number of trusted anchors needed in a single resolver to perform secure name resolution on the whole DNS tree are largely reduced. Only a secure entry point for the apex of the highest islands of security for each branch of the DNS tree are needed. In the best case, if the root zone is secured, only the root zone key is needed. Moreover, the generalization of DS RR use ensures that if a resource record is in a secure zone in a given island of security, all resolvers can verify the signature of this record. The generalization of DS RR use implies that zones that have unsecured delegation stores additional DS resource records for the apex of the next island of security in the subdomain. In the worst case, the number of additionnal records for a zone 'A' is equal to the number of leaves in the domain 'A'. 9. Security considerations This document describes a generalization of DS RR use. This generalization ensures that all signatures of resource records contained in a secure zone can be verified if the resolver trusts only the apex of the highest island of security. If the root zone is secured, only the root zone key is needed. Guette, et al. Expires February 15, 2005 [Page 10] Internet-Draft DS Generalization August 2004 10 Normative References [1] Arends, R., "Resource Records for the DNS Security Extensions", July 2004. [2] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, "DNS Security Introduction and Requirements", July 2004. [3] Arends, R., "Protocol Modifications for the DNS Security Extensions", July 2004. [4] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", RFC 3757, May 2004. [5] Eastlake, D., "Domain Name System Security Extensions", March 1999. [6] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", December 2003. Authors' Addresses Gilles Guette IRISA / INRIA Campus de Beaulieu 35042 Rennes CEDEX FR EMail: gilles.guette@irisa.fr URI: http://www.irisa.fr David Fort IRISA / University of Rennes I Campus de Beaulieu 35042 Rennes CEDEX FR EMail: david.fort@irisa.fr URI: http://www.irisa.fr Guette, et al. Expires February 15, 2005 [Page 11] Internet-Draft DS Generalization August 2004 Bernard Cousin IRISA / University of Rennes I Campus de Beaulieu 35042 RENNES CEDEX FR EMail: bernard.cousin@irisa.fr URI: http://www.irisa.fr Guette, et al. Expires February 15, 2005 [Page 12] Internet-Draft DS Generalization August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Guette, et al. Expires February 15, 2005 [Page 13] Internet-Draft DS Generalization August 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Guette, et al. Expires February 15, 2005 [Page 14]