idnits 2.17.1 draft-ietf-dnsext-zone-status-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 465 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Category:I-D', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2000) is 8682 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1034' is defined on line 354, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 366, but no explicit reference was found in the text -- Duplicate reference: RFC1034, mentioned in 'RFC1035', was also mentioned in 'RFC1034'. ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSEXT WG Edward Lewis 2 INTERNET DRAFT NAI Labs 3 Category:I-D July 12, 2000 5 DNS Security Extension Clarification on Zone Status 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Comments should be sent to the authors or the DNSIND WG mailing list 29 namedroppers@internic.net. 31 This draft expires on January 12, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (1999, 2000). All rights reserved. 37 Abstract 39 The definition of a secured zone is presented, updating RFC 2535. 40 After discussion on the mailing list and other working group 41 consideration, removed from earlier editions of this draft are a new 42 interpretation of the NXT record and a proposal to obsolete NULL 43 keys. Deprecation of "experimentally secure" remains. 45 1 Introduction 47 Whether a DNS zone is "secured" or not is a question asked in at least 48 four contexts. A zone administrator asks the question when 49 configuring a zone to use DNSSEC. A dynamic update server asks the 50 question when an update request arrives, which may require DNSSEC 51 processing. A delegating zone asks the question of a child zone when 52 the parent enters data indicating the status the child. A resolver 53 asks the question upon receipt of data belonging to the zone. 55 Expires July 12, 2000 [Page 1] 56 ^LDNS Security Extension Clarification on Zone Status January 12, 2001 58 1.1 When a Zone's Status is Important 60 A zone administrator needs to be able to determine what steps are 61 needed to make the zone as secure as it can be. Realizing that due to 62 the distributed nature of DNS and its administration, any single zone 63 is at the mercy of other zones when it comes to the appearance of 64 security. This document will define what makes a zone qualify as 65 secure (absent interaction with other zones). 67 A name server performing dynamic updates needs to know whether a zone 68 being updated is to have signatures added to the updated data, NXT 69 records applied, and other required processing. In this case, it is 70 conceivable that the name server is configured with the knowledge, but 71 being able to determine the status of a zone by examining the data is 72 a desirable alternative to configuration parameters. 74 A delegating zone is required to indicate whether a child zone is 75 secured. The reason for this requirement lies in the way in which a 76 resolver makes its own determination about a zone (next paragraph). To 77 shorten a long story, a parent needs to know whether a child should be 78 considered secured. This is a two part question, what does a parent 79 consider a secure child to be, and how does a parent know if the child 80 conforms? 82 A resolver needs to know if a zone is secured when the resolver is 83 processing data from the zone. Ultimately, a resolver needs to know 84 whether or not to expect a usable signature covering the data. How 85 this determination is done is out of the scope of this document, 86 except that, in some cases, the resolver will need to contact the 87 parent of the zone to see if the parent states that the child is 88 secured. 90 1.2 Islands of Security 92 The goal of DNSSEC is to have each zone secured, from the root zone 93 and the top-level domains down the hierarchy to the leaf zones. 94 Transitioning from an unsecured DNS, as we have now, to a fully 95 secured - or "as much as will be secured" - tree will take some time. 96 During this time, DNSSEC will be applied in various locations in the 97 tree, not necessarily "top down." 99 For example, at a particular instant, the root zone and the "test." 100 TLD might be secured, but region1.test. might not be. (For reference, 101 let's assume that region2.test. is secured.) However, 102 subarea1.region1.test. may have gone through the process of becoming 103 secured, along with its delegations. The dilemma here is that 104 subarea1 cannot get its zone keys properly signed as its parent zone, 105 region1, is not secured. 107 The popular term for the secured zones at or below subarea1 is an 108 "island of security." The only way in which a DNSSEC resolver will 109 come to trust any data from this island is if the resolver is 110 pre-configured with the zone key(s) for subarea1. All other resolvers 111 will not recognize this island as secured. 113 Expires July 12, 2000 [Page 2] 114 ^LDNS Security Extension Clarification on Zone Status January 12, 2001 116 Although both subarea1.region1.test. and region2.test. have both been 117 properly brought to a secure state by the administering staff, only 118 the latter of the two is actually fully secured - in the sense that 119 all DNSSEC resolvers can and will verify its data. The former, 120 subarea1, will be seen as secured by a subset of those resolvers, just 121 those appropriately configured. 123 In RFC 2535, there is a provision for "certification authorities," 124 entities that will sign public keys for zones such as subarea1. There 125 is another draft (currently in last call) that restricts this 126 activity. Regardless of the other draft, resolvers would still need 127 proper configuration to be able to use the certification authority to 128 verify the data for the subarea1 island. 130 1.3 Impact on RFC 2535 132 This document updates several sections of RFC 2535. The definition of 133 a secured zone is an update to section 3.4 of the RFC. Section 3.4 is 134 updated to eliminate the definition of experimental keys and 135 illustrate a way to still achieve the functionality they were designed 136 to provide. Section 3.1.3 is updated by the specifying the value of 137 the protocol octet in a zone key. 139 2 Status of a Zone 141 In this section, rules governing a zone's DNSSEC status are presented. 142 There are three levels of security defined: full, private, and 143 unsecured. A zone is fully secure when it complies with the strictest 144 set of DNSSEC processing rules. A zone is privately secured when it 145 is configured in such a way that only resolvers that are appropriately 146 configured see the zone as secured. All other zones are unsecured. 148 Note: there currently is no document completely defining DNSSEC 149 verification rules. For the purposes of this document, the strictest 150 rules are assumed to state that the verification chain of zone keys 151 parallels the delegation tree up to the root zone. This is not 152 intended to disallow alternate verification paths, just to establish a 153 baseline definition. 155 To avoid repetition in the rules below, the following terms are 156 defined. 158 2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 159 for name type (indicating a zone key) and either value 00 or value 01 160 for key type (indicating a key permitted to authenticate data). (See 161 RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value 162 of DNSSEC (3) or ALL (255). 164 The definition updates RFC 2535's definition of a zone key. The 165 requirement that the protocol field be either DNSSEC or ALL is a new 166 requirement. 168 2.b On-tree Validation - The authorization model in which only the 169 parent zone can is recognized to supply a DNSSEC-meaningful signature 171 Expires July 12, 2000 [Page 3] 172 ^LDNS Security Extension Clarification on Zone Status January 12, 2001 174 that is used by a resolver to build a chain of trust from the child's 175 keys to a recognized root of security. The term "on-tree" refers to 176 following up the DNS domain hierarchy to reach a trusted key, 177 presumably the root key if no other key is available. The term 178 "validation" refers to the digital signature by the parent to prove 179 the integrity, authentication and authorization of the child' key to 180 sign the child's zone data. 182 2.c Off-tree Validation - Any authorization model that permits domain 183 names other than the parent's to provide a signature over a child's 184 zone keys that will enable a resolver to trust the keys. 186 2.1 Fully Secured 188 A fully secured zone, in a nutshell, is a zone that uses only 189 mandatory to implement algorithms (RFC 2535, section 3.2) and relies 190 on a key certification chain that parallels the delegation tree 191 (on-tree validation). Fully secured zones are defined by the 192 following rules. 194 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least 195 one zone signing KEY RR (2.a) of a mandatory to implement algorithm in 196 the set. 198 2.1.b. The zone's apex KEY RR set MUST be signed by a private key 199 belonging to the parent zone. The private key's public companion MUST 200 be a zone signing KEY RR (2.a) of a mandatory to implement algorithm 201 and owned by the parent's apex. 203 If a zone cannot get a conforming signature from the parent zone, the 204 child zone cannot be considered fully secured. The only exception to 205 this is the root zone, for which there is no parent zone. 207 2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC 208 2535, section 2.3.2.) Note: there is some operational discomfort with 209 the current NXT record. This requirement is open to modification when 210 two things happen. First, an alternate mechanism to the NXT is 211 defined and second, a means by which a zone can indicate that it is 212 using an alternate method. 214 2.1.d. Each RR set that qualifies for zone membership MUST be signed 215 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 216 (2.a) of a mandatory to implement algorithm. (Updates 2535, section 217 2.3.1.) 219 Mentioned earlier, the root zone is a special case. Defining what 220 constitutes a secure root zone is difficult, as the discussion on 221 securing the root zone has not come to a consensus in an open forum. 222 However, the security of the root zone will be determined by the 223 pre-configuration of a trusted key in resolvers. Who generates and 224 distributes the trusted key is an open issue. 226 Expires July 12, 2000 [Page 4] 227 ^LDNS Security Extension Clarification on Zone Status January 12, 2001 229 2.2 Privately Secured 231 Note that the term "privately" is open to debate. The term stems from 232 the likely hood that the only resolvers to be configured for a 233 particular zone will be resolvers "private" to an organization. 234 Perhaps the more clumsy "colloquially secure" is more accurate. 236 A privately secured zone is a zone that complies with rules like those 237 for a fully secured zone with the following exceptions. The signing 238 keys may be of an algorithm that is not mandatory to implement and/or 239 the verification of the zone keys in use may rely on a verification 240 chain that is not parallel to the delegation tree (off-tree 241 validation). 243 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least 244 one zone signing KEY RR (2.a) in the set. 246 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and 247 one of the following two subclauses MUST hold true. 249 2.2.b.1 The private key's public companion MUST be pre-configured in 250 all the resolvers of interest. 252 2.2.b.2 The private key's public component MUST be a zone signing KEY 253 RR (2.a) authorized to provide validation of the zone's apex KEY RR 254 set, as recognized by resolvers of interest. 256 The previous sentence is trying to convey the notion of using a 257 trusted third party to provide validation of keys. If the domain name 258 owning the validating key is not the parent zone, the domain name must 259 represent someone the resolver trusts to provide validation. 261 2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC 262 2535, section 2.3.2.) Note: see the discussion following 2.1.c. 264 2.2.d. Each RR set that qualifies for zone membership MUST be signed 265 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 266 (2.a). (Updates 2535, section 2.3.1.) 268 2.3 Unsecured 270 All other zones qualify as unsecured. This includes zones that are 271 designed to be experimentally secure, as defined in a later section on 272 that topic. 274 2.4 Wrap up 276 The designation of fully secured, privately secured, and unsecured are 277 merely labels to apply to zones, based on their contents. Resolvers, 278 when determining whether a signature is expected or not, will only see 279 a zone as secured or unsecured. 281 Resolvers that follow the most restrictive DNSSEC verification rules 282 will only see fully secured zones as secured, and all others as 284 Expires July 12, 2000 [Page 5] 285 ^LDNS Security Extension Clarification on Zone Status January 12, 2001 287 unsecured, including zones which are privately secured. Resolvers 288 that are not as restrictive, such as those that implement algorithms 289 in addition to the mandatory to implement algorithms, will see some 290 privately secured zones as secured. 292 The intent of the labels "fully" and "privately" is to identify the 293 specific attributes of a zone. The words are chosen to assist in the 294 writing of a document recommending the actions a zone administrator 295 take in making use of the DNS security extensions. The words are 296 explicitly not intended to convey a state of compliance with DNS 297 security standards. 299 3 Deleted 301 4 Deleted 303 5 Experimental Status 305 The purpose of an experimentally secured zone is to facilitate the 306 migration from an unsecured zone to a secured zone. This distinction 307 is dropped. 309 The objective of facilitating the migration can be achieved without a 310 special designation of an experimentally secure status. 311 Experimentally secured is a special case of privately secured. A zone 312 administrator can achieve this by publishing a zone with signatures 313 and configuring a set of test resolvers with the corresponding public 314 keys. Even if the public key is published in a KEY RR, as long as 315 there is no parent signature, the resolvers will need some 316 pre-configuration to know to process the signatures. This allows a 317 zone to be secured with in the sphere of the experiment, yet still be 318 registered as unsecured in the general Internet. 320 6 IANA/ICANN Considerations 322 This document does not request any action from an assigned number 323 authority nor recommends any actions. 325 7 Security Considerations 327 Without a means to enforce compliance with specified protocols or 328 recommended actions, declaring a DNS zone to be "completely" secured 329 is impossible. Even if, assuming an omnipotent view of DNS, one can 330 declare a zone to be properly configured for security, and all of the 331 zones up to the root too, a misbehaving resolver could be duped into 332 believing bad data. If a zone and resolver comply, a non-compliant or 333 subverted parent could interrupt operations. The best that can be 334 hoped for is that all parties are prepared to be judged secure and 335 that security incidents can be traced to the cause in short order. 337 8 Acknowledgements 339 The need to refine the definition of a secured zone has become 340 apparent through the efforts of the participants at two DNSSEC 342 Expires July 12, 2000 [Page 6] 343 ^LDNS Security Extension Clarification on Zone Status January 12, 2001 345 workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a 346 DARPA-funded research network), and other workshops. Further 347 discussions leading to the document include Olafur Gudmundsson, Russ 348 Mundy, Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen 349 and others have contributed significant input via the namedroppers 350 mailing list. 352 9 References 354 [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," 355 RFC 1034, November 1987. 357 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 358 Specification," RFC 1034, November 1987. 360 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 361 Requirement Levels," RFC 2119, March 1997 363 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic 364 Updates in the Domain Name System," RFC 2136, April 1997. 366 [RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC 367 2535, March 1999. 369 [draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple 370 Secure Domain Name System (DNS) Dynamic Update," version 00, February 371 2000. 373 10 Author Information 375 Edward Lewis 376 NAI Labs 377 3060 Washington Road 378 Glenwood, MD 21738 379 +1 443 259 2352 380 382 11 Full Copyright Statement 384 Copyright (C) The Internet Society (1999, 2000). All Rights Reserved. 386 This document and translations of it may be copied and furnished to 387 others, and derivative works that comment on or otherwise explain it 388 or assist in its implementation may be prepared, copied, published and 389 distributed, in whole or in part, without restriction of any kind, 390 provided that the above copyright notice and this paragraph are 391 included on all such copies and derivative works. However, this 392 document itself may not be modified in any way, such as by removing 393 the copyright notice or references to the Internet Society or other 394 Internet organizations, except as needed for the purpose of developing 395 Internet standards in which case the procedures for copyrights defined 396 in the Internet Standards process must be followed, or as required to 397 translate it into languages other than English. 399 Expires July 12, 2000 [Page 7] 400 ^LDNS Security Extension Clarification on Zone Status January 12, 2001 402 The limited permissions granted above are perpetual and will not be 403 revoked by the Internet Society or its successors or assigns. 405 This document and the information contained herein is provided on an 406 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 407 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 408 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 409 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 410 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 412 Expires July 12, 2000 [Page 8]