idnits 2.17.1 draft-ietf-dnsext-parent-stores-zone-keys-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 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 7 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 2 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 SHOULD be placed under a label in the zonefile, f.i. keys.child.parent. -- 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: '4' is defined on line 392, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3090 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2535 (ref. '3') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 4 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-00.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 [2]. 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....................................2 62 Abstract...................................................2 64 Table of Contents..........................................3 65 1 Introduction.............................................3 66 2 Proposal.................................................4 67 2.1. TTL of the KEY and SIG at the parent..................4 68 2.2. No NULL KEY...........................................5 69 3 Impact on a secure aware resolver/forwarder..............5 70 3.1 Impact of key rollovers on resolver/forwarder..........5 71 4 Scheduled key rollover...................................6 72 5 Unscheduled key rollover.................................6 73 6 Zone resigning...........................................7 74 7. Consequences for KEY and NXT records....................7 75 7.1. KEY bit in NXT records................................7 76 7.2. Authority of KEY records..............................8 77 7.3. Selecting KEY sets....................................8 78 8. The zone-KEY and local KEY records......................8 79 9. Security Considerations.................................8 81 Authors' Addresses.........................................9 82 References.................................................9 83 Full Copyright Statement...................................9 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 [1] validation between the secure 91 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 [2] 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 [3], that describes how a keyrollover can 107 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 [2]. 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. The child zone may also contain its zone KEY, in 128 which case is must be selfsigned. 130 The main advantage of this proposal is that all signatures signed by 131 a key are in the same zone file as the producing key. This allows for 132 a simple key rollover and resigning mechanism. For large TLDs this is 133 extremely important. A disadvantage would be that not all the 134 information concerning one zone is stored at that zone, this is 135 covered in section 7.2. 137 A parent running DNSSEC SHOULD NOT refuse a request from a child to 138 include and sign its key, but can ask for certain conditions to be 139 met. These condition could include a fee, sufficient authentication, 140 signing a non liability clause, the conditions specified in section 8 141 of this document, etc. 143 2.1. TTL of the KEY and SIG at the parent 144 Each zone in DNS expresses in its SOA record the maximum and minimum 145 TTL values that they allow in the zone. Thus it is possible that the 146 parent will sign with a value that is unacceptable to the child. The 147 parent MUST follow the TTL request of the child as long as that is 148 within the allowed range for the parent. 150 2.2. No NULL KEY 151 This proposal obsoletes the NULL KEY. If there is no child KEY at the 152 parent, which can be securely verified by inspecting the the unset 153 KEY-bit in the corresponding NXT RR, the child is not secured by this 154 parent (of course, the child can then still be secured off-tree). 155 This updates section 3.1.2 "The zone KEY RR Flag Field" of RFC 2535, 156 it says: 158 " 11: If both bits are one, the "no key" value, there is no key 159 information and the RR stops after the algorithm octet. 160 By the use of this "no key" value, a signed zone KEY RR can 161 authenticatably assert that, for example, a zone is not 162 secured. See section 3.4 below. " 164 As we don't have a NULL KEY anymore this is obsoleted. 165 Section 3.4 "Determination of Zone Secure/Unsecured Status": 167 " A zone KEY RR with the "no-key" type field value (both key type 168 flag bits 0 and 1 on) indicates that the zone named is unsecured 169 while a zone KEY RR with a key present indicates that the zone named 170 is secure. The secured versus unsecured status of a zone may vary 171 with different cryptographic algorithms. Even for the same 172 algorithm, conflicting zone KEY RRs may be present. " 174 This is rewritten as: 176 " A zone is considered secured by on-tree validation [1] when the 177 there is a zone KEY from that zone present at its parent. If there 178 is no zone KEY present, and the resolver is also unaware of 179 alternative algorithms used and/or possible off-tree validation, the 180 zone is considered unsecured. " 182 3. Impact on a secure aware resolver/forwarder 183 The resolver must be aware of the fact that the parent is more 184 authoritative than a child when it comes to deciding whether a zone 185 is secured or not. 187 Without caching and with on-tree validation, a resolver will always 188 start its search at a secure entry point. In this way it can 189 determine whether it must expect SIG records or not. 191 Considering caching in a secure aware resolver or forwarder. If 192 information of a secure zone is cached, its validated KEY should also 193 be cached. 195 3.1. Impact of key rollovers on resolver/forwarder 196 When a zone is in the process of a key rollover, there could be a 197 discrepancy between the KEY and the SIG in the apex of the zone and 198 the KEY and SIG that are stored in the cache of a resolver. 200 Suppose a resolver has cached the NS, KEY and SIG records of a zone. 201 Next a request comes for an A record in that zone. Also the zone is 202 in the process of a key rollover and already has new keys in its 203 zone. The resolver receives an answer consisting of the A record and 204 a SIG over the A record. It uses the tag field in the SIG to 205 determine if it has a KEY which is suitable to validate the SIG. If 206 it does not has such a KEY the resolver must ask the parent of the 207 zone for a new KEY and then try it again. Now the resolver has 2 208 keys for the zone, according to the tag field in the SIG it can use 209 either one. 211 If the new key also does not validate the SIG the zone is marked bad. 212 If the parent indicates by having a not set KEY-bit in the NXT RR 213 that there is no KEY for this zone, the child must be considered 214 unsecured by this parent, despite the appearance of an (old) KEY in 215 the cache. This could for instance happen after an emergency request 216 from the child, who has suffered a key compromise, and has decided to 217 prefer being unsecured over either dropping of the Internet or being 218 exposed to have verifiable secure info added by the key-compromiser 219 to their zone information. 221 4. Scheduled key rollover 222 When the signatures, produced by the key to be rolled over, are all 223 in one zone file, there are two parties involved. Let us look at an 224 example where a TLD rolls over its zone KEY. The new key needs to be 225 signed with the root's key before it can be used to sign the TLD zone 226 and the zone KEYs of the TLD's children. The steps that need to be 227 taken by TLD and root are: 228 - the TLD adds the new key to its KEY set in its zonefile. This 229 zone and KEY set are signed with the old zone KEY 230 - then the TLD signals the parent 231 - the root copies the new KEY set, consisting of the both new and 232 the old key, in its zonefile, resigns it and signals the TLD 233 - the TLD removes the old key from its KEY set, resigns its zone 234 with the new KEY, and signals the the root 235 - the root copies the new KEY set, now consisting of the new key 236 only, and resigns it 238 Note that this procedure is immune to fake signals and spoofing 239 attacks (as long as there is no key compromise): 240 - on a fake signal either way the action becomes a null-action as 241 the new KEY set is identical to the existing one. 242 - a spoofed new KEY set will not validate with the existing KEY 243 that the parent holds. 245 5. Unscheduled key rollover 246 Although nobody hopes that this will ever happen, we must be able to 247 cope with possible key compromises. When such an event occurs, an 248 immediate keyrollover is needed and must be completed in the shortest 249 possible time. With two parties involved, it will still be awkward, 250 but not impossible to update two zonefiles overnight. "Out-of-band" 251 communication between the two parties will be necessary, since the 252 compromised old key can not be trusted. We think that between two 253 parties this is doable, but this complicated procedure [5] is beyond 254 the scope of this document. 256 An alternative to an emergency key-rollover is becoming unsecured as 257 an emercengy measure. This has already been mentioned above in 258 section 3.1. This only involves an emergency change in the parents 259 zonefile (deleting the child's zone KEY), and allows the child and 260 its underlying zones time to clean up before becoming secured again, 261 without dropping from the Internet or being exposed to having secured 262 but false zone information. 264 6. Zone resigning 265 Resigning a TLD is necessary before the current signatures expire. 266 When all SIGs (produced by the TLD's zone KEY) and the child KEY 267 records, are kept in the TLD's zonefile, such a resign session is 268 trivial, as only one party (the TLD) and one zonefile are involved. 270 7. Consequences for KEY and NXT records 271 There are two reasons to have of the child's zone KEY not only at the 272 parent but also in the child's own zonefile: 273 1. to facilitate a key-rollover 274 2. to prevent local lookups for local information to suffer 275 from possible loss of access to its outside parent 277 To cope with 1, secure aware resolvers MUST be aware that during a 278 key-rollover there may be a conflict, and that in that case the 279 parent always holds the active KEY set. To cope with 2, the local 280 resolver/caching forwarder should be preconfigured with the zone-KEY 281 and thus looks at its own zone as were it a secure entry-point. For 282 both things to work, the zone-KEY set must be selfsigned in the child 283 zonefile. 285 7.1. KEY bit in NXT records 286 RFC 2535 [3], section 5.2 states: 288 " The NXT RR type bit map format currently defined is one bit per 289 RR type present for the owner name. A one bit indicates that at 290 least one RR of that type is present for the owner name. A zero 291 indicates that no such RR is present. [....] " 293 As the zone KEY is present in a child zone, and signed by the 294 zone KEY (thus selfsigned), the definition of NXT RR type bit states 295 in RFC 2535 [3], section 5.2 that the KEY bit must be set. We do not 296 see a compelling reason to change this default behavior. 298 7.2. Authority of KEY records 299 The parent of a zone generates the signature for the key belonging to 300 that zone. By making that signature available the parent publicly 301 states that the child zone is trustworthy: when it comes to security 302 in DNSSEC the parent is more authoritative than the child. 304 From this we conclude that a parent zone MUST set the authority bit 305 to 1 and child zones MUST set this bit to 0 when dealing with KEYs 306 from that child zone.This also causes resolvers to pick up and cache 307 the right KEY set, in case it finds conflicting KEY sets during a 308 key-rollover. 310 Some zones have no parent to make it authoritatively secure, for 311 instance, the root. To be secure anyway it must be defined a secure 312 entry point. If a resolver knows that a secure entry point is a 313 secure entry point it must have its key preconfigured. There is no 314 need for a parent in this scenario, because the resolver itself can 315 check the security of that zone. A interesting consequence of this is 316 that nobody is authoritative for a key belonging to a secure entry 317 point. This authority must established via some out of band 318 mechanism, like publishing it in a newspaper. 320 7.3. Selecting KEY sets 321 As the zone KEY set is present in two places, there may be a 322 possibility to find conflicting KEY sets, and this will at least 323 really happen during a key-rollover. 325 With one exception, a resolver MUST always select the KEY set from 326 the parent in case of a conflict, as this is the active KEY set. For 327 this reason, the parent sets the AA-bit on requests, while the child 328 does not. 330 The one exception is when a resolver regards the child's zone as a 331 secure-entry point, in which case it has the zone KEY preconfigured. 332 In other words: a preconfigured KEY has even more authority then what 333 a parent says. Specifying a zone as a secure entry-point makes sense 334 for a local resolver in its own local zone. 336 8. The zone KEY and local KEY records. 337 It must be recognized that the zone KEY RR, which is signed by a 338 non-local organisation, is something special. The external signature 339 over the public part of the key provides the local zone-administrator 340 with the authority to use the corresponding private part to sign 341 everything local, and thus to make his/her own zone secure. Please 342 also note that the external signer, and NOT the local zone is 343 authoritative for the zone KEY RRset. 345 Part of the RRs that the zone-administrator may wish to sign are KEY 346 RRs for local use, for instance for IPSEC. 348 To make sure, that the local zone is authoritative for its own local 349 KEY RRs, and that they get not exported and signed externally, these 350 local KEY records SHOULD not be part of the zone KEY RRset. 351 Therefore, they SHOULD be placed under a label in the zonefile, f.i. 352 keys.child.parent. 354 Besides being kept clear of local KEY records, the zone KEY RRset 355 SHOULD also be kept clear of any other obsolete or otherwise not 356 strictly needed KEY records, because this increases the number of 357 possible key compromise attacks and also increases the size of the 358 parents zone file unnecessarily. 360 In other words: the KEY RRset with the toplevel label of a zone 361 SHOULD only contain its active zone KEY, unless a key-rollover is in 362 progress. During a keyrollover a new KEY RR must be added to this 363 RRset. Once the new KEY becomes the active zone KEY, the old KEY 364 becomes obsolete and SHOULD be removed as soon as practically 365 possible. 367 9. Security Considerations 368 This document addresses the operational difficulties that arise if 369 DNSSEC is deployed as it stands now, with the child's zone KEY not 370 stored at the parent. By putting that key in the parent's zone the 371 communication between the two is kept to a minimum thus reducing the 372 risk of errors. All security considerations from RFC 2535 apply. 374 Authors' Addresses 376 R. Gieben T. Lindgreen 377 Stichting NLnet Labs Stichting NLnet Labs 378 Kruislaan 419 Kruislaan 419 379 1098 VA Amsterdam 1098 VA Amsterdam 380 miek@nlnetlabs.nl ted@nlnetlabs.nl 382 References 384 [1] Lewis, E. "DNS Security Extension Clarification on Zone 385 Status", RFC 3090 386 www.ietf.org/rfc/rfc3090.txt 387 [2] Bradner, S. "Key words for use in RFCs to Indicate Requirement 388 Levels", RFC 2119 389 www.ietf.org/rfc/rfc2119.txt 390 [3] Eastlake, D. "DNS Security Extensions", RFC 2535 391 www.ietf.org/rfc/rfc2535.txt 392 [4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security 393 Key Rollover" 394 www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt 395 [5] Gieben, R. "Chain of trust" 396 secnl.nlnetlabs.nl/thesis/thesis.html 398 Full Copyright Statement 400 Copyright (C) The Internet Society (2001). All Rights Reserved. 402 This document and translations of it may be copied and furnished 403 to others, and derivative works that comment on or otherwise explain 404 it or assist in its implementation may be prepared, copied, published 405 and distributed, in whole or in part, without restriction of any 406 kind, provided that the above copyright notice and this paragraph are 407 included on all such copies and derivative works. However, this 408 document itself may not be modified in any way, such as by removing 409 the copyright notice or references to the Internet Society or other 410 Internet organizations, except as needed for the purpose of 411 developing Internet standards in which case the procedures for 412 copyrights defined in the Internet Standards process must be 413 followed, or as required to translate it into languages other than 414 English. 416 The limited permissions granted above are perpetual and will not 417 be revoked by the Internet Society or its successors or assigns. 419 This document and the information contained herein is provided on 420 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 421 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 422 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 423 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.