idnits 2.17.1 draft-ietf-dnsext-parent-stores-zone-keys-01.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 document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) 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 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 13 instances of lines with control characters in the document. == 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: To make sure, that the local zone is authoritative for its own local KEY RRs, and that they get not exported and signed externally, these local KEY records SHOULD not be part of the zone KEY RRset. Therefore, they could be placed under a label in the zonefile, f.i. keys.child.parent, or for these kind of keys a new RR type could be defined (e.g. PUBKEY). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC 2119' is defined on line 420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3090 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Gieben 2 DNSEXT Working Group NLnet Labs 3 Expires September 2001 T. Lindgreen 4 NLnet Labs 6 Parent stores the child's zone KEYs 8 draft-ietf-dnsext-parent-stores-zone-keys-01.txt 10 Status of This Document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference 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. The list of 24 Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Comments should be sent to the authors or the DNSEXT WG mailing 28 list namedroppers@ops.ietf.org. 30 This document updates RFC 2535. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All rights reserved. 36 Abstract 38 When dealing with large amounts of keys the procedures to update a 39 zone and to sign a zone need to be clearly defined and practically 40 possible. The current idea is to have the zone KEY RR and the 41 parent's SIG to reside in the child's zone and perhaps also in the 42 parent's zone. Operational experiences have prompted us to develop an 43 alternative scheme in which the parent zone stores the parent's 44 signature over the child's key and also the child's key itself. 46 The advantage of this scheme is that all signatures signed by a key 47 are in the same zone file as the producing key. This allows for a 48 simple key rollover and resigning mechanism. For large TLDs this is 49 extremely important. 51 Besides the operational advantages, this also obsoletes the NULL key, 52 as the absence of child's zone KEY, which is securely verified by the 53 absence of the KEY-bit in the corresponding NXT RR, now unambiguously 54 indicates that the child is not secured by this parent. 56 We further discuss the impact on a secure aware resolver/forwarder 57 and the impact on the authority of KEYs and the NXT record. 59 Table of Contents 61 Status of This Document.................................... 62 Abstract................................................... 64 Table of Contents.......................................... 65 1 Introduction............................................. 66 2 Proposal................................................. 67 2.1. TTL of the KEY and SIG at the parent.................. 68 2.2. No NULL KEY........................................... 69 3 Impact on a secure aware resolver/forwarder.............. 70 3.1 Impact of key rollovers on resolver/forwarder.......... 71 4 Scheduled key rollover................................... 72 5 Unscheduled key rollover................................. 73 6 Zone resigning........................................... 74 7. Consequences for KEY and NXT records.................... 75 7.1. KEY bit in NXT records................................ 76 7.2. Authority of KEY records.............................. 77 7.3. Selecting KEY sets.................................... 78 8. The zone-KEY and local KEY records...................... 79 9. Security Considerations................................. 81 Authors' Addresses......................................... 82 References................................................. 83 Full Copyright Statement................................... 85 1. Introduction 86 Within a CENTR working group NLnet Labs is researching the impact of 87 DNSSEC on the ccTLDs and gTLDs. 89 In this document we are considering a secure zone, somewhere under a 90 secure entry point and on-tree [RFC 3090] validation between the 91 secure entry point and the zone in question. The resolver we are 92 considering is security aware and is preconfigured with the KEY of 93 the secure entry point. We also make a distinction between a 94 scheduled and a unscheduled key rollover. A scheduled rollover is 95 announced before hand. An unscheduled key rollover is needed when a 96 private key is compromised. 98 RFC 2535 states that a zone KEY must be present in the apex of a 99 zone. This can be in the at the delegation point in the parent's 100 zonefile, or in the child's zonefile, or in both. This key is only 101 valid if it is signed by the parent, so there is also the question 102 where this signature and this zone KEY are located. 104 The original idea was to have the zone KEY RR and the parent's SIG to 105 reside in the child's zone and perhaps also in the parent's zone. 106 There is a draft proposal [RFC 2535], that describes how a 107 keyrollover can be handled. 109 At NLnet Labs we found that storing the parent's signature over the 110 child's zone KEY in the child's zone: 111 - makes resigning a KEY by the parent difficult 112 - makes a scheduled keyrollover very complicated 113 - makes an unscheduled keyrollover virtually impossible 115 We propose an alternative scheme in which the parent's signature over 116 the child's zone KEY and the child's zone KEY itself are only stored 117 in the parent's zone, i.e. where the signing key resides. This would 118 solve the above problems and also obsoletes the NULL KEY. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119. 124 2. Proposal 125 The core of the new proposal is that the parent zone stores the 126 parent's signature over the child's zone KEY and also the child's 127 zone KEY itself, and is authoritative for both KEY and SIG. The 128 child zone may also contain its zone KEY, in which case is must be 129 selfsigned. The child zone must not hold the parent's SIG, and must 130 also not set the AA-bit on requests for its zone KEY. 132 The main advantage of this proposal is that all signatures signed by 133 a key are in the same zone file as the producing key. This allows for 134 a simple key rollover and resigning mechanism. For large TLDs this is 135 extremely important. A disadvantage would be that not all the 136 information concerning one zone is stored at that zone, this is 137 covered in section 7.2. 139 A parent running DNSSEC SHOULD NOT refuse a request from a child to 140 include and sign its key, but can ask for certain conditions to be 141 met. These condition could include a fee, sufficient authentication, 142 signing a non liability clause, the conditions specified in section 8 143 of this document, etc. 145 2.1. TTL of the KEY and SIG at the parent 146 Each zone in DNS expresses in its SOA record the maximum and minimum 147 TTL values that they allow in the zone. Thus it is possible that the 148 parent will sign with a value that is unacceptable to the child. The 149 parent MUST follow the TTL request of the child as long as that is 150 within the allowed range for the parent. 152 2.2. No NULL KEY 153 This proposal obsoletes the NULL KEY. If there is no child KEY at the 154 parent, which can be securely verified by inspecting the the unset 155 KEY-bit in the corresponding NXT RR, the child is not secured by this 156 parent (of course, the child can then still be secured off-tree). 157 This updates section 3.1.2 "The zone KEY RR Flag Field" of RFC 2535, 158 it says: 160 " 11: If both bits are one, the "no key" value, there is no key 161 information and the RR stops after the algorithm octet. 162 By the use of this "no key" value, a signed zone KEY RR can 163 authenticatably assert that, for example, a zone is not 164 secured. See section 3.4 below. " 166 As we don't have a NULL KEY anymore this is obsoleted. 167 Section 3.4 "Determination of Zone Secure/Unsecured Status": 169 " A zone KEY RR with the "no-key" type field value (both key type 170 flag bits 0 and 1 on) indicates that the zone named is unsecured 171 while a zone KEY RR with a key present indicates that the zone named 172 is secure. The secured versus unsecured status of a zone may vary 173 with different cryptographic algorithms. Even for the same 174 algorithm, conflicting zone KEY RRs may be present. " 176 This is rewritten as: 178 " A zone is considered secured by on-tree validation [RFC 3090] when 179 the there is a zone KEY from that zone present at its parent. If 180 there is no zone KEY present, and the resolver is also unaware of 181 alternative algorithms used and/or possible off-tree validation, the 182 zone is considered unsecured. " 184 To further clarify this. A zone is secure, when the resolver expects 185 it to be, there are two possibilities: 186 1. When its parent is secure and holds a signed KEY for this child. 187 2. When zone is a secure entry point, i.e. the resolver is 188 preconfigured with the KEY of this zone. 190 RFC 3090 calls this globally secured. 192 When a zone contains SIGs and a selfsigned KEY and this KEY is 193 preconfigured in the resolvers of interest, the a zone can be 194 considered locally secured (the RFC 3090 defintion). hijacked. 196 If a zone is not globally or locally it must be considered unsecure. 198 3. Impact on a secure aware resolver/forwarder 199 The resolver must be aware of the fact that the parent is more 200 authoritative than a child when it comes to deciding whether a zone 201 is secured or not. 203 Without caching and with on-tree validation, a resolver will always 204 start its search at a secure entry point. In this way it can 205 determine whether it must expect SIG records or not. 207 Considering caching in a secure aware resolver or forwarder. If 208 information of a secure zone is cached, its validated KEY should also 209 be cached. 211 3.1. Impact of key rollovers on resolver/forwarder 212 When a zone is in the process of a key rollover, there could be a 213 discrepancy between the KEY and the SIG in the apex of the zone and 214 the KEY and SIG that are stored in the cache of a resolver. 216 Suppose a resolver has cached the NS, KEY and SIG records of a zone. 217 Next a request comes for an A record in that zone. Also the zone is 218 in the process of a key rollover and already has new keys in its 219 zone. The resolver receives an answer consisting of the A record and 220 a SIG over the A record. It uses the tag field in the SIG to 221 determine if it has a KEY which is suitable to validate the SIG. If 222 it does not has such a KEY the resolver must ask the parent of the 223 zone for a new KEY and then try it again. Now the resolver has 2 224 keys for the zone, according to the tag field in the SIG it can use 225 either one. 227 If the new key also does not validate the SIG the zone is marked bad. 228 If the parent indicates by having a not set KEY-bit in the NXT RR 229 that there is no KEY for this zone, the child must be considered 230 unsecured by this parent, despite the appearance of an (old) KEY in 231 the cache. This could for instance happen after an emergency request 232 from the child, who has suffered a key compromise, and has decided to 233 prefer being unsecured over either dropping of the Internet or being 234 exposed to have verifiable secure info added by the key-compromiser 235 to their zone information. 237 4. Scheduled key rollover 238 When the signatures, produced by the key to be rolled over, are all 239 in one zone file, there are two parties involved. Let us look at an 240 possible example where a TLD rolls over its zone KEY. The new key 241 needs to be signed with the root's key before it can be used to sign 242 the TLD zone and the zone KEYs of the TLD's children. The steps that 243 need to be taken by TLD and root are: 244 - the TLD adds the new key to its KEY set in its zonefile. This 245 zone and KEY set are signed with the old zone KEY 246 - then the TLD signals the parent 247 - the root copies the new KEY set, consisting of the both new and 248 the old key, in its zonefile, resigns it and signals the TLD 249 - the TLD removes the old key from its KEY set, resigns its zone 250 with the new KEY, and signals the the root 251 - the root copies the new KEY set, now consisting of the new key 252 only, and resigns it 254 Note that this procedure is immune to fake signals and spoofing 255 attacks (as long as there is no key compromise): 256 - on a fake signal either way the action becomes a null-action as 257 the new KEY set is identical to the existing one. 258 - a spoofed new KEY set will not validate with the existing KEY 259 that the parent holds. 261 5. Unscheduled key rollover 262 Although nobody hopes that this will ever happen, we must be able to 263 cope with possible key compromises. When such an event occurs, an 264 immediate keyrollover is needed and must be completed in the shortest 265 possible time. With two parties involved, it will still be awkward, 266 but not impossible to update two zonefiles overnight. "Out-of-band" 267 communication between the two parties will be necessary, since the 268 compromised old key can not be trusted. We think that between two 269 parties this is doable, but this complicated procedure is beyond the 270 scope of this document. 272 An alternative to an emergency key-rollover is becoming unsecured as 273 an emergency measure. This has already been mentioned above in 274 section 3.1. This only involves an emergency change in the parents 275 zonefile (deleting the child's zone KEY), and allows the child and 276 its underlying zones time to clean up before becoming secured again, 277 without dropping from the Internet or being exposed to having secured 278 but false zone information. 280 6. Zone resigning 281 Resigning a TLD is necessary before the current signatures expire. 282 When all SIGs (produced by the TLD's zone KEY) and the child KEY 283 records, are kept in the TLD's zonefile, such a resign session is 284 trivial, as only one party (the TLD) and one zonefile are involved. 286 7. Consequences for KEY and NXT records 287 There are two reasons to have of the child's zone KEY not only at the 288 parent but also in the child's own zonefile: 289 1. to facilitate a key-rollover 290 2. to prevent local lookups for local information to suffer 291 from possible loss of access to its outside parent 293 To cope with 1, secure aware resolvers MUST be aware that during a 294 key-rollover there may be a conflict, and that in that case the 295 parent always holds the active KEY set. To cope with 2, the local 296 resolver/caching forwarder should be preconfigured with the zone-KEY 297 and thus looks at its own zone as were it a secure entry-point. For 298 both things to work, the zone-KEY set must be selfsigned in the child 299 zonefile. 301 7.1. KEY bit in NXT records 302 RFC 2535, section 5.2 states: 304 " The NXT RR type bit map format currently defined is one bit per RR 305 type present for the owner name. A one bit indicates that at least 306 one RR of that type is present for the owner name. A zero indicates 307 that no such RR is present. [....] " 309 As the zone KEY is present in a child zone, and signed by the zone 310 KEY (thus selfsigned), the definition of NXT RR type bit states in 311 RFC 2535, section 5.2 that the KEY bit must be set. We do not see a 312 compelling reason to change this default behavior. 314 7.2. Authority of KEY records 315 The parent of a zone generates the signature for the key belonging to 316 that zone. By making that signature available the parent publicly 317 states that the child zone is trustworthy: when it comes to security 318 in DNSSEC the parent is more authoritative than the child. 320 From this we conclude that a parent zone MUST set the authority bit 321 to 1 and child zones MUST set this bit to 0 when dealing with KEYs 322 from that child zone.This also causes resolvers to pick up and cache 323 the right KEY set, in case it finds conflicting KEY sets during a 324 key-rollover. 326 Some zones have no parent to make it authoritatively secure, for 327 instance, the root. To be secure anyway it must be defined a secure 328 entry point. If a resolver knows that a secure entry point is a 329 secure entry point it must have its key preconfigured. There is no 330 need for a parent in this scenario, because the resolver itself can 331 check the security of that zone. A interesting consequence of this is 332 that nobody is authoritative for a key belonging to a secure entry 333 point. This authority must established via some out of band 334 mechanism, like publishing it in a newspaper. 336 7.3. Selecting KEY sets 337 As the zone KEY set is present in two places, there is a possibility 338 of two conflicting KEY sets, this will happen during a key-rollover 339 and may happen at other times. 341 With one exception, a resolver MUST always select the KEY set from 342 the parent in case of a conflict, as this is the active KEY set. For 343 this reason, the parent sets the AA-bit on requests, while the child 344 does not. 346 The one exception is when a resolver regards the child's zone as a 347 secure-entry point, in which case it has the zone KEY preconfigured. 348 In other words: a preconfigured KEY has even more authority then what 349 a parent says. Specifying a zone as a secure entry-point makes sense 350 for a local resolver in its own local zone. 352 8. The zone KEY and local KEY records. 353 It must be recognized that the zone KEY RR, which is signed by a 354 non-local organization, is something special. The external signature 355 over the public part of the key provides the local zone-administrator 356 with the authority to use the corresponding private part to sign 357 everything local, and thus to make his/her own zone secure. Please 358 also note that the external signer, and NOT the local zone is 359 authoritative for the zone KEY RRset. 361 Part of the RRs that the zone-administrator may wish to sign are KEY 362 RRs for local use, for instance for IPSEC. 364 To make sure, that the local zone is authoritative for its own local 365 KEY RRs, and that they get not exported and signed externally, these 366 local KEY records SHOULD not be part of the zone KEY RRset. 367 Therefore, they could be placed under a label in the zonefile, f.i. 368 keys.child.parent, or for these kind of keys a new RR type could be 369 defined (e.g. PUBKEY). 371 Besides being kept clear of local KEY records, the zone KEY RRset 372 SHOULD also be kept clear of any other obsolete or otherwise not 373 strictly needed KEY records, because this increases the number of 374 possible key compromise attacks and also increases the size of the 375 parents zone file unnecessarily. 377 In other words: the KEY RRset with the toplevel label of a zone 378 SHOULD only contain its active zone KEY, unless a key-rollover is in 379 progress. During a keyrollover a new KEY RR must be added to this 380 RRset. Once the new KEY becomes the active zone KEY, the old KEY 381 becomes obsolete and SHOULD be removed as soon as practically 382 possible. Information stored in caches SHOULD NOT be an issue on when 383 to remove the old zone KEY. 385 9. Security Considerations 386 This document addresses the operational difficulties that arise when 387 DNSSEC is deployed. By putting the child's zone KEY at the parent we 388 solve at lot of problems by minimizing the amount of communication 389 between the two. There is one security issue: the parent must not 390 ever create a valid parental SIG over a KEY RR, from which the 391 private part is (also) known to someone else than the legitimate 392 administrator of the child zone. This can happen in two ways: 393 1. The private KEY at the child has been compromised. 394 2. The parent has been fooled and thus insufficiently checked 395 whether the KEY RR is really from the child. 397 For the security it doesn't matter if the SIG and the KEY are located 398 at the child or at the parent, but if they are located at the parent 399 it is much easier to replace the SIG. And by keeping the parental SIG 400 lifetime short, the parent helps to protect the child against 401 possible key compromises. The selfsigned zone KEY stored in the 402 child's zone can have a long SIG expiration lifetime, this has no 403 impact on the child's security. 405 All security considerations from RFC 2535 apply. 407 Authors' Addresses 409 R. Gieben T. Lindgreen 410 Stichting NLnet Labs Stichting NLnet Labs 411 Kruislaan 419 Kruislaan 419 412 1098 VA Amsterdam 1098 VA Amsterdam 413 miek@nlnetlabs.nl ted@nlnetlabs.nl 415 References 417 [RFC 3090] Lewis, E. "DNS Security Extension Clarification on Zone 418 Status", RFC 3090 419 www.ietf.org/rfc/rfc3090.txt 420 [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement 421 Levels", RFC 2119 422 www.ietf.org/rfc/rfc2119.txt 423 [RFC 2535] Eastlake, D. "DNS Security Extensions", RFC 2535 424 www.ietf.org/rfc/rfc2535.txt 426 Full Copyright Statement 428 Copyright (C) The Internet Society (2001). All Rights Reserved. 430 This document and translations of it may be copied and furnished 431 to others, and derivative works that comment on or otherwise explain 432 it or assist in its implementation may be prepared, copied, published 433 and distributed, in whole or in part, without restriction of any 434 kind, provided that the above copyright notice and this paragraph are 435 included on all such copies and derivative works. However, this 436 document itself may not be modified in any way, such as by removing 437 the copyright notice or references to the Internet Society or other 438 Internet organizations, except as needed for the purpose of 439 developing Internet standards in which case the procedures for 440 copyrights defined in the Internet Standards process must be 441 followed, or as required to translate it into languages other than 442 English. 444 The limited permissions granted above are perpetual and will not 445 be revoked by the Internet Society or its successors or assigns. 447 This document and the information contained herein is provided on 448 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 449 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 450 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 451 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 452 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.