idnits 2.17.1 draft-ietf-dnsind-zone-status-00.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. 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 (December 25, 1999) is 8887 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 437, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 447, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 450, 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: 4 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND WG Edward Lewis 2 INTERNET DRAFT NAI Labs 3 Category: I-D 4 December 25, 1999 6 DNS Security Extension Clarification on Zone Status 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Comments should be sent to the authors or the DNSIND WG mailing list 30 namedroppers@internic.net. 32 This draft expires on June 25, 1999. 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All rights reserved. 38 Abstract 40 The definition of a secured zone is presented, updating RFC 2535. The 41 new definition has consequences which alter the interpretation of the 42 NXT record, obsolete NULL keys, and the designation of "experimentally 43 secure." 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 A zone administrator needs to be able to determine what steps are 56 needed to make the zone as secure as it can be. Realizing that due to 58 Expires June 25, 2000 [Page 1] 59 the distributed nature of DNS and its administration, any single zone 60 is at the mercy of other zones when it comes to the appearance of 61 security. This document will define what makes a zone qualify as 62 secure (absent interaction with other zones). 64 A name server performing dynamic updates needs to know whether a zone 65 being updated is to have signatures added to the updated data, NXT 66 records applied, and other required processing. In this case, it is 67 conceivable that the name server is configured with the knowledge, but 68 being able to determine the status of a zone by examining the data is 69 a desirable alternative to configuration parameters. 71 A delegating zone is required to indicate whether a child zone is 72 secured. The reason for this requirement lies in the way in which a 73 resolver makes its own determination about a zone (next paragraph). 74 To shorten a long story, a parent needs to know whether a child should 75 be considered secured. This is a two part question, what does a 76 parent consider a secure child to be, and how does a parent know if 77 the child conforms? 79 A resolver needs to know if a zone is secured when the resolver is 80 processing data from the zone. Ultimately, a resolver needs to know 81 whether or not to expect a usable signature covering the data. How 82 this determination is done is out of the scope of this document, 83 except that, in some cases, the resolver will need to contact the 84 parent of the zone to see if the parent states that the child is 85 secured. 87 This document updates several sections of RFC 2535. The definition of 88 a secured zone is an update to section 3.4 of the RFC. The document 89 updates section 2.3.4, by specifying a replacement for the NULL zone 90 keys. The document also updates section 3.4 to eliminate the 91 definition of experimental keys and illustrate a way to still achieve 92 the functionality they were designed to provide. 94 2 Status of a Zone 96 In this section, rules governing a zone's DNSSEC status are presented. 97 There are three levels of security defined; full, private, and 98 unsecured. A zone is fully secure when it complies with the strictest 99 set of DNSSEC processing rules. A zone is privately secured when it 100 is configured in such a way that only resolvers that are appropriately 101 configured see the zone as secured. All other zones are unsecured. 103 Note: there currently is no other document completely defining DNSSEC 104 processing rules. For the purposes of this document, the strictest 105 rules are assumed to state that the verification chain of zone keys 106 parallels the delegation tree up to the root zone. This is not 107 intended to disallow alternate verification paths, just to establish a 108 baseline definition. 110 To avoid repetition in the rules below, the following term is defined. 112 2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 114 Expires June 25, 2000 [Page 2] 115 for name type (indicating a zone key) and either value 00 or value 01 116 for key type (indicating a key permitted to authenticate data). (See 117 RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value 118 of DNSSEC (3) or All (255). 120 2.1 Fully Secured 122 A fully secured zone, in a nutshell, is a zone that uses only 123 mandatory to implement algorithms (RFC 2535, section 3.2) and relies 124 on a key certification chain that parallels the delegation tree. 125 Fully secured zones are defined by the following rules. 127 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least 128 one zone signing KEY RR (2.a) of a mandatory to implement algorithm in 129 the set. 131 2.1.b. The zone's apex KEY RR set MUST be signed by a private key 132 belonging to the parent zone. The private key's public companion MUST 133 be a zone signing KEY RR (2.a) of a mandatory to implement algorithm 134 and owned by the parent's apex. 136 If a zone cannot get a conforming signature from the parent zone, the 137 child zone cannot be considered fully secured. 139 2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC 140 2535, section 2.3.2.) Note: there is some operational discomfort with 141 the current NXT record. This requirement is open to modification when 142 two things happen. First, an alternate mechanism to the NXT is 143 defined and second, a means by which a zone can indicate that it is 144 using an alternate method. 146 2.1.d. Each RR set that qualifies for zone membership MUST be signed 147 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 148 (2.a) of a mandatory to implement algorithm. (Updates 2535, section 149 2.3.1.) 151 2.2 Privately Secured 153 A privately secured zone is a zone that complies with rules like those 154 for fully secured, with the following exceptions. The signing keys 155 may be of an algorithm that is not mandatory to implement and/or the 156 verification of the zone keys in use may rely on a verification chain 157 that is not parallel to the delegation tree. 159 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least 160 one zone signing KEY RR (2.a) in the set. 162 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and 163 one of the following two sentences MUST hold true. The private key's 164 public companion MUST be preconfigured in all the resolvers of 165 interest. The private key's public component MUST be a zone signing 166 KEY RR (2.a) authorized to provide validation of the zone's apex KEY 167 RR set, as recognized by resolvers of interest. 169 Expires June 25, 2000 [Page 3] 170 The previous sentence is trying to convey the notion of using a 171 trusted third party to provide validation of keys. If the domain name 172 owning the validating key is not the parent zone, the domain name must 173 represent someone the resolver trusts to provide validation. 175 2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC 176 2535, section 2.3.2.) Note: see the discussion following 2.1.c. 178 2.2.d. Each RR set that qualifies for zone membership MUST be signed 179 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 180 (2.a). (Updates 2535, section 2.3.1.) 182 2.3 Unsecured 184 All other zones qualify as unsecured. This includes zones that are 185 designed to be experimentally secure, as defined in a later section on 186 that topic. 188 2.4 Wrap up 190 The designation of fully secured, privately secured, and unsecured are 191 merely labels to apply to zones, based on their contents. Resolvers, 192 when determining whether a signature is expected or not, will only see 193 a zone as secured or unsecured. 195 Resolvers that follow the most restrictive DNSSEC verification rules 196 will only see fully secured zones as secured, and all others as 197 unsecured, including zones which are privately secured. Resolvers 198 which are not as restrictive, such as those that implement algorithms 199 in addition to the mandatory to implement algorithms, will see some 200 privately secured zones as secured. 202 The intent of the labels "fully" and "privately" is to identify the 203 specific attributes of a zone. The words are chosen to assist in the 204 writing of a document recommending the actions a zone administrator 205 take in making use of the DNS security extensions. The words are 206 explicitly not intended to convey a state of compliance with DNS 207 security standards. 209 3 Parental Notification 211 For a resolver to come to a definitive answer concerning a zone's 212 security status, there is a requirement that the parent of a zone 213 signify whether the child zone is signed or not. The justification of 214 this requirement requires a discussion of the resolver's activity, 215 which is described in RFC 2535. 217 In RFC 2535, a parent is required to hold a NULL key for an unsigned 218 child (a bone of contention here is how this works in light of 219 multiple algorithms). The parent has the option to hold the keys of 220 the child if the child is signed. The parent may also hold nothing 221 cryptographic if the child is signed. This, of course, assumes the 222 parent is a signed zone. 224 Expires June 25, 2000 [Page 4] 225 There is a strong case for discouraging a parent from holding keys of 226 a signed child. These include concrete concerns about performance and 227 more abstract concerns about the liability of the parent. 229 DNS [RFC 1034 and 1035] requires a parent to hold NS records for a 230 child zone, this signifies the delegation. RFC 2535 requires a 231 secured parent to also have signed NXT records for the child, and 232 possibly a signed KEY RR set (required for NULL key situations). 234 By redefining the security status of a zone to be per zone and not per 235 algorithm, there is an opportunity to completely remove the need for a 236 KEY RR set in the parent. Because the question of whether the zone is 237 secure or not is a yes-or-no question, the notification needs just one 238 bit to be expressed. 240 Keep in mind that the following sections speak to the contents of a 241 zone, not a name server. In the case of a name server speaking 242 authoritatively for both the parent and child, or if a server caches 243 the information for the other half of the delegation, then a server 244 will have more types of data at a delegation point than a parent is 245 supposed to hold. (E.g., if a parent zone's name server caches the 246 SOA for the child, the SOA is not in the parent zone, but is in the 247 server's cache.) 249 3.1 Child Is Secured Bit 251 This section is written assuming the current definition of NXT 252 holds. There is some controversy surrounding the NXT record 253 which may result in a complete replacement of it for proof of 254 non-existence. The current NXT definition provides an extension 255 bit in the types present bit map, whose use is remains 256 incompletely defined. The following text largely ignores these 257 uncertainties, and should be rewritten to accommodate these 258 uncertainties in revisions. 260 In the parent's half of the delegation point, there will be an NXT 261 record. According to the rules for a delegation point, only the NS, 262 NXT, and SIG bits will be turned on in the types present field, 263 assuming we drop the KEY set altogether. 265 The KEY bit in the parent's NXT types present bit map is hereby 266 redefined to have the following meaning. 268 If the bit corresponding to the KEY RR set in a parent NXT is set, the 269 parent has signed a KEY RR set for the child that includes a zone 270 signing KEY RR (2.a). Furthermore, the validity period on the SIG 271 (KEY) RR covers the current time and the public component of the key 272 used to generate the SIG (KEY) RR is validly available from the 273 parent. 275 E.g., Assume the zone "test." signs a key for "zone1.test.," with the 276 signature valid from May 1st to June 1st and a public key from "test." 277 available from April 1st until July 1st. The NXT record for 278 "zone1.test." will have the KEY RR bit set from May 1st to June 1st. 280 Expires June 25, 2000 [Page 5] 281 This constraint may be enforced in the SIG (NXT) RR validity period, 282 timely editing of the master file, or whatever other mechanism "test." 283 chooses to implement. 285 Conversely, if the bit is 0, then the child is not secured. Note that 286 for a fully secured zone (section 2.1), the bit is on (1). For all 287 unsecured zones (section 2.3) the bit is off (0). For privately 288 secured zones (section 2.2), the setting of the bit is determined by 289 whether the parent signs the child's keys or not. Hence, for 290 privately secured zones, the parent may have no responsibility. A 291 child wishing to have the parent set the bit must contact the parent. 293 3.2 Rules Governing the Bit 295 In this section, the words of the previous are turned into definitive 296 MUST and SHOULDs. Note that this section does not refer to the bit in 297 the NXT. This is in anticipation of a change in the way NXT indicates 298 types present (e.g., if bit 0 of the field is defined) or a successor 299 to the NXT is defined. 301 3.2.a. At a delegation point, a parent zone MUST have a mechanism in 302 place to indicate which RR sets are present. The mechanism MUST 303 indicate that the NS, SIG, and the type(s) corresponding to the 304 mechanism itself are present (of course, with these types actually 305 being present). With the exception of the KEY RR type, all other 306 types MUST be indicated as not present, and, in accordance with 307 delegation rules, actually be absent from the zone. If, in the 308 future, other data is permitted to be present at a delegation point, 309 this requirement MUST be amended. 311 Assuming the NXT record, the above requirement reads as follows. At a 312 delegation point, a parent zone must have a secured NXT record. This 313 NXT record must indicate that the NS, SIG, and NXT types are present. 314 With the exception of KEY, all other types must be indicated as not 315 present. The lower casing of the word "must" is intentional, 316 conveying that this is an explanation of the rule above. 318 3.2.b. The KEY set MUST be indicated as present during the time when 319 the parent has issued a signature for the child's KEY set. 320 Conversely, during periods of time in which the parent knows it has 321 not generated a signature for the KEY RR set, the KEY set MUST be 322 indicated to be absent. 324 If the parent has issued signatures with discontinuous validity spans, 325 then the presence of the KEY set will flip from present to not present 326 and back as time progresses. 328 If the parent is aware that the child's keys are becoming valid or 329 will be becoming invalid at a certain point in time, it is recommended 330 that this be reflected in the NXT's signature validity period. 332 3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully 333 consider the algorithm of the key used to generate the signature. The 334 parent SHOULD make clear to child zones what steps are to be taken to 336 Expires June 25, 2000 [Page 6] 337 get the parent to indicate that the child is signed. This document 338 will go no further in specifying operational considerations. 340 (Let's say the parent signs the child's key set with an algorithm the 341 child can't process. The child could elect not to advertise this 342 signature as it cannot verify that the signature covers the real key 343 set. If this happens, is the parent justified in claiming that the 344 child is secured?) 346 3.2.d. The parent MUST allow the child, through some trusted, probably 347 non-DNS mechanism, to request that the indication of the KEY set in 348 the NXT be turned off. This allows a child to revert to an unsigned 349 state. 351 3.2.e. The parent SHOULD NOT allow the child to request that the KEY 352 set be indicated in the absence of a key signing request. 354 3.3 Operational Considerations 356 Retrieving the NXT for a delegated name from the parent zone (the 357 upper NXT) is not a trivial operation. The complication arises due to 358 having an NXT in the delegatee (the lower NXT) that matches the owner 359 name of the upper NXT. (The case in which both the parent and child 360 zones are secured is the only case mentioned here. If both are not 361 secured, then there will be at most one NXT, which is easily 362 retrieved.) 364 There are two complications to describe. One involves the multiple 365 NXT sets matching the same owner. The other is the pragmatic issue of 366 knowing where to get the answer. 368 With multiple NXT sets at the same owner, caches may become a problem. 369 If a (for example) recursive server has cached the lower NXT, any 370 query for the upper NXT may be confused for a lower NXT query. This 371 is akin to the issue of the ANY query, where a server with some cached 372 data will answer with just that and not seek the rest of the data. 374 A resolver may know the child's server's addresses and the parent zone 375 may not be sharing servers with the child. In this case the resolver 376 will need to be able to locate the parent zones (possibly having to go 377 to the root servers and descend) in order to obtain the upper NXT 378 record. 380 A potential solution to this is to define an NXT meta-query which will 381 force a recursive server to find all available NXT RR sets for a given 382 name. Details of this have not been examined. 384 4 NULL keys 386 Through the use of the types present to indicate the existence of a 387 signature validating the KEY set of a child, the need for NULL keys 388 effectively disappears. NULL keys are left as a defined entity, but 389 are rendered meaningless in DNSSEC. 391 Expires June 25, 2000 [Page 7] 392 5 Experimental Status 394 Without NULL keys, an experimentally secured zone cannot be defined as 395 it is in RFC 2535. The purpose of an experimentally secured zone was 396 to facilitate the migration from an unsecured zone to a secured zone. 398 The objective of facilitating the migration can be achieved without a 399 special designation of an experimentally secure status. 400 Experimentally secured is a special case of privately secured. A zone 401 administrator can achieve this by publishing a zone with signatures 402 and configuring a set of test resolvers with the corresponding public 403 keys. Even if the public key is published in a KEY RR, as long as 404 there is no parent signature, the resolvers will need some 405 preconfiguration to know to process the signatures. This allows a 406 zone to be secured with in the sphere of the experiment, yet still be 407 registered as unsecured in the general Internet. 409 6 IANA/ICANN Considerations 411 This document does not request any action from an assigned number 412 authority nor recommends any actions. 414 7 Security Considerations 416 Without a means to enforce compliance with specified protocols or 417 recommended actions, declaring a DNS zone to be "completely" secured 418 is impossible. Even if, assuming an omnipotent view of DNS, one can 419 declare a zone to be properly configured for security, and all of the 420 zones up to the root too, a misbehaving resolver could be duped into 421 believing bad data. If a zone and resolver comply, a non-compliant or 422 subverted parent could interrupt operations. The best that can be 423 hoped for is that all parties are prepared to be judged secure and 424 that security incidents can be traced to the cause in short order. 426 8 Acknowledgements 428 The need to refine the definition of a secured zone has become 429 apparent through the efforts of the participants at two DNSSEC 430 workshops, sponsored by the NIC-SE (.se registrar) and CAIRN (a 431 DARPA-funded research network). Further discussions leading to the 432 document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and 433 Brian Wellington. 435 9 References 437 [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," 438 RFC 1034, November 1987. 440 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 441 Specification," RFC 1034, November 1987. 443 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 444 Requirement Levels," RFC 2119, March 1997 446 Expires June 25, 2000 [Page 8] 447 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic 448 Updates in the Domain Name System," RFC 2136, April 1997. 450 [RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC 451 2535, March 1999. 453 10 Author Information 455 Edward Lewis 456 NAI Labs 457 3060 Washington Road 458 Glenwood, MD 21738 459 +1 443 259 2352 460 462 11 Full Copyright Statement 464 Copyright (C) The Internet Society (1999). 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 475 developing Internet standards in which case the procedures for 476 copyrights defined in the Internet Standards process must be 477 followed, or as required to translate it into languages other than 478 English. 480 The limited permissions granted above are perpetual and will not be 481 revoked by the Internet Society or its successors or assigns. 483 This document and the information contained herein is provided on an 484 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 485 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 486 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 487 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 488 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 490 Expires June 25, 2000 [Page 9]