From 7a1786bec0d213f8d39e38fce2d137b4dec04c15 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 3 Jul 2002 03:28:10 +0000 Subject: [PATCH] new rev --- .../draft-ietf-dnsext-dnssec-opt-in-01.txt | 895 -------------- .../draft-ietf-dnsext-dnssec-opt-in-02.txt | 1061 +++++++++++++++++ 2 files changed, 1061 insertions(+), 895 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-opt-in-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-01.txt deleted file mode 100644 index ecdf693516..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-01.txt +++ /dev/null @@ -1,895 +0,0 @@ - - -Network Working Group R. Arends -Internet-Draft Nominum, Inc. -Expires: May 2, 2002 M. Kosters - D. Blacka - Verisign, Inc. - November 1, 2001 - - - DNSSEC Opt-In - draft-ietf-dnsext-dnssec-opt-in-01 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 May 2, 2002. - -Copyright Notice - - Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - - RFC 2535 defines a secure zone as completely signed. There are cases - where there is no need, it is not practical, or simply not possible - to maintain a completely signed zone. To allow administrators to - gradually adopt DNSSEC, a model, "Opt-In", is proposed that - generalizes the inclusion of unsigned records within a secure zone. - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 1] - -Internet-Draft DNSSEC Opt-In November 2001 - - -Table of Contents - - 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 - References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 - A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 2] - -Internet-Draft DNSSEC Opt-In November 2001 - - -1. Definitions and Terminology - - Throughout this document, familiarity with the DNS system, RFC 1035 - [1], DNS security extensions, RFC 2535 [4], and DNSSEC terminology - RFC 3090 [5] is assumed. - - The following abbreviations and terms are used in this document: - - RR: is used to refer to a DNS resource record. - - RRset: refers to a Resource Record Set, as defined by [3]. - - Delegation RRset: refers to a RRset of type NS that forms a zone cut. - That is, any NS RRsets except those residing at the zone apex. - - node: describes the set all RRsets for a single owner name. In other - words, all records in the zone with the same name (but possibly - differing types). - - secure node: refers to a node where all RRsets within the node are - signed, minus delegation RRsets. All signed nodes contain a - single NXT record. - - insecure node: refers to a node where none of the RRsets within the - node are signed. - - name: refers to the owner name of a node. - - The key words "MUST, "MUST NO", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [2]. - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 3] - -Internet-Draft DNSSEC Opt-In November 2001 - - -2. Overview - - In order to ease deployment of DNSSEC, it is desirable to have a - mechanism that generally allows for unsigned records to exist within - an otherwise secure zone. - - In the current definition of DNSSEC, RFC 2535 [4], there are already - two types of unsigned RRsets: delegation point NS RRsets and glue - RRsets. This document proposes a model, Opt-In, that generalizes the - capability to have unsigned records within a secure zone. This is - accomplished by extending the semantics of the NXT record using a - redundant bit in the type bit map. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 4] - -Internet-Draft DNSSEC Opt-In November 2001 - - -3. Protocol Additions - - In RFC 2535, a secured zone consists of a series of secured nodes, - where each node contains a signed NXT RR. The (non)existence of a - node is proven using the intervals defined by the NXT RR's owner - names and next values. The (non)existence of a RRset within a node - is proven using the type bit map in the NXT RR. - - Opt-In expands this definition by allowing insecure nodes to be - interleaved between secure nodes. Since this represents a change of - the interpretation of NXT records, resolvers must be able to - distinguish between RFC 2535 NXT records and Opt-In NXT records. - This is accomplished by tagging the NXT records that span (or - potentially span) insecure nodes. This tag is indicated by the - absence of the NXT bit in the type bit map. Since the NXT bit in the - type map merely indicates the existence of the record itself, this - bit is redundant and open for use as a tag. - - Using Opt-In, the existence or non-existence of insecure nodes is not - asserted by the tagged NXT records. This allows for the addition or - removal of insecure RRsets without recalculating and resigning the - NXT chain. However, Opt-In NXT records still assert the - (non)existence of secure nodes, and the existence of individual - RRsets within the secure nodes. - - Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records - and RFC 2535 NXT records. At each secure node, the NXT record within - that node MUST either be RFC 2535 or Opt-In compliant. If it is not - Opt-In, there MUST NOT be any insecure nodes between it and the next - node. - - In summary, - - o An Opt-In NXT type is identified by a zero-valued (or not- - specified) NXT bit in the type bit map of the NXT record. - - o A RFC2535 NXT type is identified by a one-valued NXT bit in the - type bit map of the NXT record. - - and - - o In RFC 2535, NXT records indicate the existence or non-existence - of all nodes in the zone. - - o In Opt-In, tagged NXT records indicate the existence or non- - existence of all SECURE nodes in the zone. - - - - - -Arends, et al. Expires May 2, 2002 [Page 5] - -Internet-Draft DNSSEC Opt-In November 2001 - - -4. Benefits - - Using Opt-In allows administrators of large or rapidly changing zones - to minimize the overhead involved in maintaining the security of the - zone. One particular way that Opt-In accomplishes this is by - eliminating the need for "no-key" KEY records for insecure subzone - delegations. In RFC 2535, insecure delegations are required to have - an associated signed "no-key" KEY RR. Instead, under Opt-In, - insecure subzone delegation records are stored in insecure nodes. - For large, delegation-centric zones (like TLDs) this can lead to - substantial reductions in overhead. - - In addition, because the NXT chain for the zone does not have to be - changed when adding or removing insecure RRs, zones that may be - constantly adding and/or removing RRs can do so without incurring the - overhead associated with modifying and resigning the NXT chain. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 6] - -Internet-Draft DNSSEC Opt-In November 2001 - - -5. Examples - - Consider the zone EXAMPLE, shown below. This is a zone where all of - the NXT records are tagged as Opt-In. It consists of 5 nodes: 3 - secure nodes (EXAMPLE., FIRST-SECURE.EXAMPLE., and SECOND- - SECURE.EXAMPLE.) and 2 insecure nodes (NOT-SECURE.EXAMPLE., and - UNSIGNED.EXAMPLE.). - - Example A: Fully Opt-In Zone. - - EXAMPLE. SOA ... - EXAMPLE. SIG SOA ... - EXAMPLE. NS FIRST-SECURE.EXAMPLE. - EXAMPLE. SIG NS ... - EXAMPLE. KEY ... - EXAMPLE. SIG KEY ... - EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY - EXAMPLE. SIG NXT ... - - FIRST-SECURE.EXAMPLE. A ... - FIRST-SECURE.EXAMPLE. SIG A ... - FIRST-SECURE.EXAMPLE. NXT SECOND-SECURE.EXAMPLE. A SIG - FIRST-SECURE.EXAMPLE. SIG NXT ... - - NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. - NS.NOT-SECURE.EXAMPLE. A ... - - SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. - SECOND-SECURE.EXAMPLE. KEY ... - SECOND-SECURE.EXAMPLE. SIG KEY ... - SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY - SECOND-SECURE.EXAMPLE. SIG NXT ... - - UNSIGNED.EXAMPLE. MX ... - - - In this example, a query for a signed RRset (e.g., "FIRST- - SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- - SECURE.EXAMPLE A") will result in a standard RFC 2535 response. A - query for a nonexistent RRset will result in a response that differs - from RFC 2535 only in the fact that the NXT record will be tagged as - Opt-In. - - A query for an insecure RR will return both the answer (in the Answer - or Authority section, as appropriate) and the corresponding Opt-In - NXT record to prove that it is not secure. - - - - - -Arends, et al. Expires May 2, 2002 [Page 7] - -Internet-Draft DNSSEC Opt-In November 2001 - - - Example A.1: Response to query for UNSECURE.EXAMPLE. MX - - - RCODE=NOERROR - - Answer Section: - UNSECURE.EXAMPLE. MX ... - - Authority Section: - SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY - SECOND-SECURE.EXAMPLE. SIG NXT ... - - Additional Section: - EXAMPLE. KEY ... - EXAMPLE. SIG KEY ... - - Similarly, a query for an RR that is delegated to an insecure subzone - will return both the referral and the corresponding Opt-In NXT record - to prove that it is not secure. - - Example A.2: Response to query for WWW.NOT-SECURE.EXAMPLE. A - - RCODE=NOERROR - - Authority Section: - NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. - FIRST-SECURE.EXAMPLE. NXT SECOND-SECURE.EXAMPLE. A SIG - FIRST-SECURE.EXAMPLE. SIG NXT ... - - Additional Section: - NS.NOT-SECURE.EXAMPLE. A ... - EXAMPLE. KEY ... - EXAMPLE. SIG KEY ... - - In Example A, the EXAMPLE. node MAY use either style of NXT record, - because there are no insecure nodes that occur between it and the - next node, FIRST-SECURE.EXAMPLE. In other words, Example A would - still be a valid zone if the NXT record for EXAMPLE. was changed to - the following RR: - - EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT - - However, the other secure nodes (FIRST-SECURE.EXAMPLE. and SECOND- - SECURE.EXAMPLE.) MUST use Opt-In NXT records, because there are - insecure nodes in the range they define. (NOT-SECURE.EXAMPLE and - UNSECURE.EXAMPLE, respectively). - - - - - -Arends, et al. Expires May 2, 2002 [Page 8] - -Internet-Draft DNSSEC Opt-In November 2001 - - -6. Security Considerations - - Opt-In allows for unsigned names. All unsigned names are insecure, - and their validity can not be cryptographically proven. With Opt-In, - a malicious entity is able to insert, modify or delete unsigned names - in a secured zone. Thus, it is recommended to use RFC 2535 [4] where - possible and to use Opt-In where necessary. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 9] - -Internet-Draft DNSSEC Opt-In November 2001 - - -7. IANA Considerations - - None. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 10] - -Internet-Draft DNSSEC Opt-In November 2001 - - -8. Acknowledgments - - The contributions, suggestions and remarks of the following persons - (in alphabetic order) to this draft are acknowledged: - - Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf - Kolkman, Ted Lindgreen, Bill Manning, Dan Massey, Scott Rose, Mike - Schiraldi, Jakob Schlyter, Brian Wellington. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 11] - -Internet-Draft DNSSEC Opt-In November 2001 - - -References - - [1] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [6] R. Conrad, D., "Indicating Resolver Support of DNSSEC", draft- - ietf-dnsext-dnssec-okbit-03 (work in progress), October 2001. - - -Authors' Addresses - - Roy Arends - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94063 - US - - Phone: +1 650 381 6000 - EMail: Roy.Arends@nominum.com - URI: http://www.nominum.com - - - Mark Kosters - Verisign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - EMail: markk@verisign.com - URI: http://www.verisignlabs.com - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 12] - -Internet-Draft DNSSEC Opt-In November 2001 - - - David Blacka - Verisign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - EMail: davidb@verisign.com - URI: http://www.verisignlabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 13] - -Internet-Draft DNSSEC Opt-In November 2001 - - -Appendix A. Implementing Opt-In using "Views" - - In many cases, it may be convenient to implement an opt-in zone by - combining two separately maintained "views" of a zone at request - time. In this context, "view" refers to a particular version of a - zone, not to any specific DNS implementation feature. - - In this scenario, one view is the secure view, the other is the - insecure (or legacy) view. The secure view consists of an entirely - signed zone using opt-in tagged NXT records. The insecure view - contains no DNSSEC information. It is helpful, although not - necessary, for the secure view to be a subset (minus DNSSEC records) - of the insecure view. - - In addition, the secure view must contain entire nodes. That is, if - any of the RRsets with a given name are signed in the combined opt-in - zone, all RRsets must be signed (and thus in the secure view). - - These two views may be combined at request time to provide a virtual, - single opt-in zone. The following algorithm is used when responding - to each query: - - V_A is the secure view as described above. - - V_B is the insecure view as described above. - - R_A is a response generated from V_A, following RFC 2535 [4]. - - R_B is a response generated from V_B, following DNS resolution as - per RFC 1035 [1]. - - R_C is the response generated by combining R_A with R_B, as - described below. - - A query is DNSSEC-aware if it either has the DO bit [6] turned on, - or is for a DNSSEC-specific record type. - - - - - 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, - generate and return R_B, otherwise - - 2. Generate R_A. - - 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise - - 4. Generate R_B and combine it with R_A to form R_C: - - - -Arends, et al. Expires May 2, 2002 [Page 14] - -Internet-Draft DNSSEC Opt-In November 2001 - - - For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the - records from R_A into R_B, EXCEPT the AUTHORITY section SOA - record, if R_B's RCODE = NOERROR. - - 5. Return R_C. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 15] - -Internet-Draft DNSSEC Opt-In November 2001 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2001). 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 assigns. - - 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 - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires May 2, 2002 [Page 16] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt new file mode 100644 index 0000000000..8f716aecfb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-02.txt @@ -0,0 +1,1061 @@ +Network Working Group R. Arends +Internet-Draft Nominum, Inc. +Expires: December 26, 2002 M. Kosters + D. Blacka + Verisign, Inc. + June 27, 2002 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-02 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + 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 December 26, 2002. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + In RFC 2535, delegations to unsigned subzones are cryptographically + secured. Maintaining this cryptography is not practical or + necessary. This document describes an "Opt-In" model that allows + administrators to omit this cryptography and manage the cost of + adopting DNSSEC. + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 1] + +Internet-Draft DNSSEC Opt-In June 2002 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . . 5 + 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . . 6 + 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 16 + B. Changes from Prior Versions . . . . . . . . . . . . . . . . . 18 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 2] + +Internet-Draft DNSSEC Opt-In June 2002 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system, RFC 1035 + [1], DNS security extensions, RFC 2535 [4], and DNSSEC terminology + RFC 3090 [5] is assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + + RRset: refers to a Resource Record Set, as defined by [3]. + + covering NXT record/RRset: is the NXT record used to prove + (non)existance of a particular name or RRset. This means that for + a RRset or name 'N', the covering NXT record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + + delegation: refers to a NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + + secure delegation: refers to the NS, DS, NXT and SIG RRsets for a + non-zone-apex owner name, signifying a delegation to a DNSSEC + signed subzone. + + 2535/DS insecure delegation: refers to the NS, NXT, and SIG RRsets + for a non-zone-apex owner name, signifying a delegation to an + unsigned subzone. This differs from the secured delegation by the + absence of a DS RRset, marked by the zero value for the DS type + code in the NXT type map. + + Opt-In insecure delegation: refers to the NS RRset for a non-zone- + apex owner name where the covering NXT record uses the Opt-In + methodology described in this document. + + The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 3] + +Internet-Draft DNSSEC Opt-In June 2002 + + +2. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NXT record chain may not be relative to the gain of + cryptographically securing delegations to unsigned zones. + + This document describes a method of eliminating the superfluous + cryptography present in secure delegations to insecure zones. Using + "Opt-In", a zone administrator can choose to remove insecure + delegations from the NXT chain. This is accomplished by extending + the semantics of the NXT record by using a redundant bit in the type + map. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 4] + +Internet-Draft DNSSEC Opt-In June 2002 + + +3. Protocol Additions + + In RFC 2535, delegation NS RRsets are not signed, but instead are + accompanied by a NXT RRset of the same name, and possibly a ("no- + key") KEY RR [4] or DS record [7]. The security status of the + subzone is determined by the presence or absence of the KEY or DS + records, cryptographically proven by the NXT record. Opt-In expands + this definition by allowing insecure delegations to exist within an + otherwise signed zone without the corresponding NXT record at the + delegation's owner name. These insecure delegations are proven + insecure by using the covering NXT record. + + Since this represents a change of the interpretation of NXT records, + resolvers must be able to distinguish between RFC 2535 NXT records + and Opt-In NXT records. This is accomplished by "tagging" the NXT + records that cover (or potentially cover) insecure delegation nodes. + This tag is indicated by the absence of the NXT bit in the type map. + Since the NXT bit in the type map merely indicates the existence of + the record itself, this bit is redundant and safe for use as a tag. + + Using Opt-In, the existence or non-existence of insecure delegations + is not asserted by the tagged NXT records. This allows for the + addition or removal of delegations to unsigned zones without + recalculating and resigning the NXT chain. However, Opt-In NXT + records still assert the (non)existence of signed RRsets. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records + and RFC 2535 NXT records. If a NXT record is not Opt-In, there MUST + NOT be any insecure delegations between it and the RRsets indicated + by the 'next domain name' in the NXT RDATA. If it is Opt-In, there + MUST only be insecure delegations between it and the next node + indicated by the 'next domain name' in the NXT RDATA. + + In summary, + + o An Opt-In NXT type is identified by a zero-valued (or not- + specified) NXT bit in the type bit map of the NXT record. + + o A RFC2535 NXT type is identified by a one-valued NXT bit in the + type bit map of the NXT record. + + +3.1 Server Considerations + + This protocol change dictates a number of changes to the operation of + an authoritative server: + + o The server MUST enforce the protocol requirement that ONLY + + + +Arends, et al. Expires December 26, 2002 [Page 5] + +Internet-Draft DNSSEC Opt-In June 2002 + + + insecure delegation nodes may exist between the secure nodes of + the zone. + + o The server must be able to retrieve the proper NXT records along + with referrals to insecure subzone. + + In the delegation signer proposal, NXT records already must be + returned along with referrals to insecure delegations. The primary + difference that this proposal introduces is that the appropriate NXT + record will have a different owner name. + +3.2 Client Considerations + + Opt-In imposes some new requirements on the DNS resolver (caching or + otherwise): + + o Resolvers MUST be able to use Opt-In style NXT records to + cryptographically prove the validity and security status (as + insecure) of a referral: + + * In RFC 2535, this is proven by existence of a verified "no-key" + KEY RRset. + + * Using Delegation Signer, this is proven by the existence of a + verified NXT record. This NXT record has same name as the + delegation RRset and does not have the DS bit set in the type + map. + + * Using Opt-In, this is proven by the existence of a verified + Opt-In NXT record. This NXT record does not have the NXT bit + set in the type map (that is, it is an Opt-In style NXT record) + and the name of the delegation RRset is lexicographically + between the owner and next names of the NXT record. + + Note that using Opt-In does not substantially change the nature of + following referrals within DNSSEC. At every delegation point, the + resolver will have cryptographic proof that the subzone is secure + or insecure. + + o Resolvers MUST reject as invalid non-NS RRsets that fall within an + Opt-In tagged NXT record's span. + + o Caching resolvers must be able to retrieve the appropriate + covering Opt-In NXT record when returning referrals that need + them. This is only a difference when you consider that the + covering NXT record will not have the same name as the delegation + RRset itself. + + + + +Arends, et al. Expires December 26, 2002 [Page 6] + +Internet-Draft DNSSEC Opt-In June 2002 + + + o The AD bit (as defined by [8]) MUST NOT be set in a response + containing an Opt-In tagged NXT record in the authority section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 7] + +Internet-Draft DNSSEC Opt-In June 2002 + + +4. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for both "no-key" + KEY (in [4]) and NXT records for insecure delegations. This, in a + zone with a large number of delegations to unsigned subzones, can + lead to substantial space savings (both in memory and on disk). + Additionally, Opt-In allows for the addition or removal of insecure + delegations without modifying the NXT record chain. Zones that are + frequently updating insecure delegations (e.g., TLDs) can avoid the + substantial overhead of modifying and resigning the affected NXT + records. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 8] + +Internet-Draft DNSSEC Opt-In June 2002 + + +5. Example + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NXT records are tagged as Opt-In. + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. SIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. SIG NS ... + EXAMPLE. KEY ... + EXAMPLE. SIG KEY ... + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY + EXAMPLE. SIG NXT ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. SIG A ... + FIRST-SECURE.EXAMPLE. NXT SECOND-SECURE.EXAMPLE. A SIG + FIRST-SECURE.EXAMPLE. SIG NXT ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. KEY ... + SECOND-SECURE.EXAMPLE. SIG KEY ... + SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY + SECOND-SECURE.EXAMPLE. SIG NXT ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + In this example, a query for a signed RRset (e.g., "FIRST- + SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- + SECURE.EXAMPLE A") will result in a standard RFC 2535 response. A + query for a nonexistent RRset will result in a response that differs + from RFC 2535 only in the fact that the NXT record will be tagged as + Opt-In. + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding Opt- + In NXT record to prove that it is not secure. + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 9] + +Internet-Draft DNSSEC Opt-In June 2002 + + + Example A.1: Response to query for WWW.UNSECURE.EXAMPLE. A + + + RCODE=NOERROR + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY + SECOND-SECURE.EXAMPLE. SIG NXT ... + + Additional Section: + NS.UNSIGNED.EXAMPLE A ... + EXAMPLE. KEY ... + EXAMPLE. SIG KEY ... + + In the Example A zone, the EXAMPLE. node MAY use either style of NXT + record, because there are no insecure delegations that occur between + it and the next node, FIRST-SECURE.EXAMPLE. In other words, Example + A would still be a valid zone if the NXT record for EXAMPLE. was + changed to the following RR: + + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT + + However, the other NXT records (FIRST-SECURE.EXAMPLE. and SECOND- + SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure + delegations in the range they define. (NOT-SECURE.EXAMPLE. and + UNSIGNED.EXAMPLE., respectively). + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 10] + +Internet-Draft DNSSEC Opt-In June 2002 + + +6. Security Considerations + + Opt-In allows for unsigned delegations. All unsigned names are + insecure, and their validity (or existence) can not be + cryptographically proven. With Opt-In, a malicious entity is able + to: insert, modify, or delete insecure delegation RRsets within a + secured zone. For example, if a resolver received the following + response from the example zone above: + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY + EXAMPLE. SIG NXT ... + + Additional Section: + EXAMPLE. KEY ... + EXAMPLE. SIG KEY ... + + The resolver would have no choice but to believe that the referral to + NS.FORGED. is valid. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. It + is strongly RECOMMENDED that Opt-In be used sparingly. In + particular, zone signing tools SHOULD NOT default to Opt-In, and MAY + choose to not support Opt-In at all. + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 11] + +Internet-Draft DNSSEC Opt-In June 2002 + + +7. IANA Considerations + + None. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 12] + +Internet-Draft DNSSEC Opt-In June 2002 + + +8. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Ted Lindgreen, Bill Manning, Dan Massey, Scott Rose, Mike + Schiraldi, Jakob Schlyter, Brian Wellington. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 13] + +Internet-Draft DNSSEC Opt-In June 2002 + + +References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [6] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [7] Gudmundsson, O., "Delegation Signer Resource Record", draft- + ietf-dnsext-delegation-signer-07 (work in progress), March 2002. + + [8] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit", + draft-ietf-dnsext-ad-is-secure-05 (work in progress), March + 2002. + + +Authors' Addresses + + Roy Arends + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94063 + US + + Phone: +1 650 381 6000 + EMail: Roy.Arends@nominum.com + URI: http://www.nominum.com + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 14] + +Internet-Draft DNSSEC Opt-In June 2002 + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: markk@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 15] + +Internet-Draft DNSSEC Opt-In June 2002 + + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NXT records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and + the zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single opt-in zone. The following algorithm is used when responding + to each query: + + V_A is the secure view as described above. + + V_B is the insecure view as described above. + + R_A is a response generated from V_A, following RFC 2535 [4]. + + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + + R_C is the response generated by combining R_A with R_B, as + described below. + + A query is DNSSEC-aware if it either has the DO bit [6] turned on, + or is for a DNSSEC-specific record type. + + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + + 2. Generate R_A. + + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + + 4. Generate R_B and combine it with R_A to form R_C: + + + +Arends, et al. Expires December 26, 2002 [Page 16] + +Internet-Draft DNSSEC Opt-In June 2002 + + + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + + 5. Return R_C. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 17] + +Internet-Draft DNSSEC Opt-In June 2002 + + +Appendix B. Changes from Prior Versions + + Changes from version 01: + + Changed to "delegation only". Strengthened "Security + Considerations" section. Added "Server Considerations" and + "Client Considerations" sections. Added AD bit requirement. + + Changes from version 00: + + Complete rewrite, altering approach from "views" to tagged NXT + records + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 18] + +Internet-Draft DNSSEC Opt-In June 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 assigns. + + 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 + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires December 26, 2002 [Page 19]