idnits 2.17.1 draft-ietf-dnsext-zone-status-04.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 8 longer pages, the longest (page 1) being 59 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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (January 3, 2001) is 8511 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) == Missing Reference: 'RFC 2119' is mentioned on line 231, but not defined == Unused Reference: 'RFC1034' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC3007' is defined on line 447, 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) ** Obsolete normative reference: RFC 3008 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 5 errors (**), 0 flaws (~~), 11 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 January 3, 2001 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 DNSEXT WG mailing list 29 namedroppers@ops.ietf.org. 31 This draft expires on July 3, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (1999-2001). All rights reserved. 37 Abstract 39 The definition of a secured zone is presented, clarifying and updating 40 sections of RFC 2535. RFC 2535 defines a zone to be secured based on a 41 per algorithm basis, e.g., a zone can be secured with RSA keys, and 42 not secured with DSA keys. This document changes this to define a 43 zone to be secured or not secured regardless of the key algorithm used 44 (or not used). To further simplify the determination of a zone's 45 status, "experimentally secure" status is deprecated. 47 1 Introduction 49 Whether a DNS zone is "secured" or not is a question asked in at least 50 four contexts. A zone administrator asks the question when 51 configuring a zone to use DNSSEC. A dynamic update server asks the 52 question when an update request arrives, which may require DNSSEC 53 processing. A delegating zone asks the question of a child zone when 54 the parent enters data indicating the status the child. A resolver 55 asks the question upon receipt of data belonging to the zone. 57 Expires July 3, 2001 [Page 1] 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. 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. Under what 79 circumstances does a parent consider a child zone to be secure, and 80 how does a parent know if the child 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 colloquial phrase describing the collection of contiguous secured 108 zones at or below subarea1.region1.test. is an "island of security." 109 The only way in which a DNSSEC resolver will come to trust any data 110 from this island is if the resolver is pre-configured with the zone 111 key(s) for subarea1.region1.test., i.e., the root of the island of 113 Expires July 3, 2001 [Page 2] 114 security. Other resolvers (not so configured) will recognize this 115 island as unsecured. 117 An island of security begins with one zone whose public key is 118 pre-configured in resolvers. Within this island are subzones which 119 are also secured. The "bottom" of the island is defined by 120 delegations to unsecured zones. One island may also be on top of 121 another - meaning that there is at least one unsecured zone between 122 the bottom of the upper island and the root of the lower secured 123 island. 125 Although both subarea1.region1.test. and region2.test. have both been 126 properly brought to a secured state by the administering staff, only 127 the latter of the two is actually "globally" secured - in the sense 128 that all DNSSEC resolvers can and will verify its data. The former, 129 subarea1, will be seen as secured by a subset of those resolvers, just 130 those appropriately configured. This document refers to such zones as 131 being "locally" secured. 133 In RFC 2535, there is a provision for "certification authorities," 134 entities that will sign public keys for zones such as subarea1. There 135 is another draft, [RFC3008], that restricts this activity. Regardless 136 of the other draft, resolvers would still need proper configuration to 137 be able to use the certification authority to verify the data for the 138 subarea1 island. 140 1.2.1 Determing the closest security root 142 Given a domain, in order to determine whether it is secure or not, the 143 first step is to determine the closest security root. The closest 144 security root is the top of an island of security whose name has the 145 most matching (in order from the root) right-most labels to the given 146 domain. 148 For example, given a name "sub.domain.testing.signed.exp.test.", and 149 given the secure roots "exp.test.", "testing.signed.exp.test." and 150 "not-the-same.xy.", the middle one is the closest. The first secure 151 root shares 2 labels, the middle 4, and the last 0. 153 The reason why the closest is desired is to eliminate false senses of 154 insecurity becuase of a NULL key. Continuing with the example, the 155 reason both "testing..." and "exp.test." are listed as secure root is 156 presumably because "signed.exp.test." is unsecured (has a NULL key). 157 If we started to descend from "exp.test." to our given domain 158 (sub...), we would encounter a NULL key and conclude that sub... was 159 unsigned. However, if we descend from "testing..." and find keys 160 "domain...." then we can conclude that "sub..." is secured. 162 Note that this example assumes one-label deep zones, and assumes that 163 we do not configure overlapping islands of security. To be clear, the 164 definition given should exclude "short.xy.test." from being a closest 165 security root for "short.xy." even though 2 labels match. 167 Overlapping islands of security introduce no conceptually interesting 169 Expires July 3, 2001 [Page 3] 170 ideas and do not impact the protocol in anyway. However, protocol 171 implementers are advised to make sure their code is not thrown for a 172 loop by overlaps. Overlaps are sure to be configuration problems as 173 islands of security grow to encompass larger regions of the name 174 space. 176 1.3 Parent Statement of Child Security 178 In 1.1 of this document, there is the comment "the parent states that 179 the child is secured." This has caused quite a bit of confusion. 181 The need to have the parent "state" the status of a child is derived 182 from the following observation. If you are looking to see if an 183 answer is secured, that it comes from an "island of security" and is 184 properly signed, you must begin at the (appropriate) root of the 185 island of security. 187 To find the answer you are inspecting, you may have to descend through 188 zones within the island of security. Beginning with the trusted root 189 of the island, you descend into the next zone down. As you trust the 190 upper zone, you need to get data from it about the next zone down, 191 otherwise there is a vulnerable point in which a zone can be hijacked. 192 When or if you reach a point of traversing from a secured zone to an 193 unsecured zone, you have left the island of security and should 194 conclude that the answer is unsecured. 196 However, in RFC 2535, section 2.3.4, these words seem to conflict with 197 the need to have the parent "state" something about a child: 199 There MUST be a zone KEY RR, signed by its superzone, for every 200 subzone if the superzone is secure. This will normally appear in 201 the subzone and may also be included in the superzone. But, in 202 the case of an unsecured subzone which can not or will not be 203 modified to add any security RRs, a KEY declaring the subzone 204 to be unsecured MUST appear with the superzone signature in the 205 superzone, if the superzone is secure. 207 The confusion here is that in RFC 2535, a secured parent states that a 208 child is secured by SAYING NOTHING ("may also be" as opposed to "MUST 209 also be"). This is counter intuitive, the fact that an absence of 210 data means something is "secured." This notion, while acceptable in a 211 theoretic setting has met with some discomfort in an operation 212 setting. However, the use of "silence" to state something does indeed 213 work in this case, so there hasn't been sufficient need demonstrated 214 to change the definition. 216 1.4 Impact on RFC 2535 218 This document updates sections of RFC 2535. The definition of a 219 secured zone is an update to section 3.4 of the RFC. Section 3.4 is 220 updated to eliminate the definition of experimental keys and 221 illustrate a way to still achieve the functionality they were designed 222 to provide. Section 3.1.3 is updated by the specifying the value of 223 the protocol octet in a zone key. 225 Expires July 3, 2001 [Page 4] 226 1.5 "MUST" and other key words 228 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 229 in this document are to be interpreted as described in [RFC 2119]. 230 Currently, only "MUST" is used in this document. 232 2 Status of a Zone 234 In this section, rules governing a zone's DNSSEC status are presented. 235 There are three levels of security defined: global, local, and 236 unsecured. A zone is globally secure when it complies with the 237 strictest set of DNSSEC processing rules. A zone is locally secured 238 when it is configured in such a way that only resolvers that are 239 appropriately configured see the zone as secured. All other zones are 240 unsecured. 242 Note: there currently is no document completely defining DNSSEC 243 verification rules. For the purposes of this document, the strictest 244 rules are assumed to state that the verification chain of zone keys 245 parallels the delegation tree up to the root zone. (See 2.b below.) 246 This is not intended to disallow alternate verification paths, just to 247 establish a baseline definition. 249 To avoid repetition in the rules below, the following terms are 250 defined. 252 2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 253 for name type (indicating a zone key) and either value 00 or value 01 254 for key type (indicating a key permitted to authenticate data). (See 255 RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value 256 of DNSSEC (3) or ALL (255). 258 The definition updates RFC 2535's definition of a zone key. The 259 requirement that the protocol field be either DNSSEC or ALL is a new 260 requirement, a change to section 3.1.3.) 262 2.b On-tree Validation - The authorization model in which only the 263 parent zone is recognized to supply a DNSSEC-meaningful signature that 264 is used by a resolver to build a chain of trust from the child's keys 265 to a recognized root of security. The term "on-tree" refers to 266 following the DNS domain hierarchy (upwards) to reach a trusted key, 267 presumably the root key if no other key is available. The term 268 "validation" refers to the digital signature by the parent to prove 269 the integrity, authentication and authorization of the child' key to 270 sign the child's zone data. 272 2.c Off-tree Validation - Any authorization model that permits domain 273 names other than the parent's to provide a signature over a child's 274 zone keys that will enable a resolver to trust the keys. 276 2.1 Globally Secured 278 A globally secured zone, in a nutshell, is a zone that uses only 279 mandatory to implement algorithms (RFC 2535, section 3.2) and relies 281 Expires July 3, 2001 [Page 5] 282 on a key certification chain that parallels the delegation tree 283 (on-tree validation). Globally secured zones are defined by the 284 following rules. 286 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least 287 one zone signing KEY RR (2.a) of a mandatory to implement algorithm in 288 the set. 290 2.1.b. The zone's apex KEY RR set MUST be signed by a private key 291 belonging to the parent zone. The private key's public companion MUST 292 be a zone signing KEY RR (2.a) of a mandatory to implement algorithm 293 and owned by the parent's apex. 295 If a zone cannot get a conforming signature from the parent zone, the 296 child zone cannot be considered globally secured. The only exception 297 to this is the root zone, for which there is no parent zone. 299 2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies 300 RFC 2535, section 2.3.2.) Note: there is some operational discomfort 301 with the current NXT record. This requirement is open to modification 302 when two things happen. First, an alternate mechanism to the NXT is 303 defined and second, a means by which a zone can indicate that it is 304 using an alternate method. 306 2.1.d. Each RR set that qualifies for zone membership MUST be signed 307 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 308 (2.a) of a mandatory to implement algorithm. (Updates 2535, section 309 2.3.1.) 311 Mentioned earlier, the root zone is a special case. The root zone 312 will be considered to be globally secured provided that if conforms to 313 the rules for locally secured, with the exception that rule 2.1.a. be 314 also met (mandatory to implement requirement). 316 2.2 Locally Secured 318 The term "locally" stems from the likely hood that the only resolvers 319 to be configured for a particular zone will be resolvers "local" to an 320 organization. 322 A locally secured zone is a zone that complies with rules like those 323 for a globally secured zone with the following exceptions. The 324 signing keys may be of an algorithm that is not mandatory to implement 325 and/or the verification of the zone keys in use may rely on a 326 verification chain that is not parallel to the delegation tree 327 (off-tree validation). 329 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least 330 one zone signing KEY RR (2.a) in the set. 332 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and 333 one of the following two subclauses MUST hold true. 335 Expires July 3, 2001 [Page 6] 336 2.2.b.1 The private key's public companion MUST be pre-configured in 337 all the resolvers of interest. 339 2.2.b.2 The private key's public component MUST be a zone signing KEY 340 RR (2.a) authorized to provide validation of the zone's apex KEY RR 341 set, as recognized by resolvers of interest. 343 The previous sentence is trying to convey the notion of using a 344 trusted third party to provide validation of keys. If the domain name 345 owning the validating key is not the parent zone, the domain name must 346 represent someone the resolver trusts to provide validation. 348 2.2.c. NXT records MUST be deployed throughout the zone. Note: see 349 the discussion following 2.1.c. 351 2.2.d. Each RR set that qualifies for zone membership MUST be signed 352 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 353 (2.a). (Updates 2535, section 2.3.1.) 355 2.3 Unsecured 357 All other zones qualify as unsecured. This includes zones that are 358 designed to be experimentally secure, as defined in a later section on 359 that topic. 361 2.4 Wrap up 363 The designation of globally secured, locally secured, and unsecured 364 are merely labels to apply to zones, based on their contents. 365 Resolvers, when determining whether a signature is expected or not, 366 will only see a zone as secured or unsecured. 368 Resolvers that follow the most restrictive DNSSEC verification rules 369 will only see globally secured zones as secured, and all others as 370 unsecured, including zones which are locally secured. Resolvers that 371 are not as restrictive, such as those that implement algorithms in 372 addition to the mandatory to implement algorithms, will see some 373 locally secured zones as secured. 375 The intent of the labels "global" and "local" is to identify the 376 specific attributes of a zone. The words are chosen to assist in the 377 writing of a document recommending the actions a zone administrator 378 take in making use of the DNS security extensions. The words are 379 explicitly not intended to convey a state of compliance with DNS 380 security standards. 382 3 Experimental Status 384 The purpose of an experimentally secured zone is to facilitate the 385 migration from an unsecured zone to a secured zone. This distinction 386 is dropped. 388 The objective of facilitating the migration can be achieved without a 389 special designation of an experimentally secure status. Experimentally 391 Expires July 3, 2001 [Page 7] 392 secured is a special case of globally secured. A zone administrator 393 can achieve this by publishing a zone with signatures and configuring 394 a set of test resolvers with the corresponding public keys. Even if 395 the public key is published in a KEY RR, as long as there is no parent 396 signature, the resolvers will need some pre-configuration to know to 397 process the signatures. This allows a zone to be secured with in the 398 sphere of the experiment, yet still be registered as unsecured in the 399 general Internet. 401 4 IANA/ICANN Considerations 403 This document does not request any action from an assigned number 404 authority nor recommends any actions. 406 5 Security Considerations 408 Without a means to enforce compliance with specified protocols or 409 recommended actions, declaring a DNS zone to be "completely" secured 410 is impossible. Even if, assuming an omnipotent view of DNS, one can 411 declare a zone to be properly configured for security, and all of the 412 zones up to the root too, a misbehaving resolver could be duped into 413 believing bad data. If a zone and resolver comply, a non-compliant or 414 subverted parent could interrupt operations. The best that can be 415 hoped for is that all parties are prepared to be judged secure and 416 that security incidents can be traced to the cause in short order. 418 6 Acknowledgements 420 The need to refine the definition of a secured zone has become 421 apparent through the efforts of the participants at two DNSSEC 422 workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a 423 DARPA-funded research network), and other workshops. Further 424 discussions leading to the document include Olafur Gudmundsson, Russ 425 Mundy, Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen 426 and others have contributed significant input via the namedroppers 427 mailing list. 429 7 References 431 [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," 432 RFC 1034, November 1987. 434 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 435 Specification," RFC 1034, November 1987. 437 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 438 Requirement Levels," RFC 2119, March 1997 440 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic 441 Updates in the Domain Name System," RFC 2136, April 1997. 443 [RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC 444 2535, March 1999. 446 Expires July 3, 2001 [Page 8] 447 [RFC3007] B. Wellington, "Simple Secure Domain Name System (DNS) 448 Dynamic Update," November, 2000. 450 [RFC3008] B. Wellington, "Domain Name System Security (DNSSEC) 451 Signing Authority", November, 2000. 453 10 Author Information 455 Edward Lewis 456 NAI Labs 457 3060 Washington Road Glenwood 458 MD 21738 459 +1 443 259 2352 460 462 11 Full Copyright Statement 464 Copyright (C) The Internet Society (1999-2001). All Rights Reserved. 466 This document and translations of it may be copied and furnished to 467 others, and derivative works that comment on or otherwise explain it 468 or assist in its implementation may be prepared, copied, published and 469 distributed, in whole or in part, without restriction of any kind, 470 provided that the above copyright notice and this paragraph are 471 included on all such copies and derivative works. However, this 472 document itself may not be modified in any way, such as by removing 473 the copyright notice or references to the Internet Society or other 474 Internet organizations, except as needed for the purpose of developing 475 Internet standards in which case the procedures for copyrights defined 476 in the Internet Standards process must be followed, or as required to 477 translate it into languages other than English. 479 The limited permissions granted above are perpetual and will not be 480 revoked by the Internet Society or its successors or assigns. 482 This document and the information contained herein is provided on an 483 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 484 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 485 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 486 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 487 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 489 Expires July 3, 2001 [Page 9]