idnits 2.17.1 draft-ietf-dnsop-dnssec-operational-practices-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1477. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document updates RFC2541, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2541, updated by this document, for RFC5378 checks: 1998-02-26) -- 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 (October 24, 2005) is 6759 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: '7' is defined on line 1191, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3757 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2137 (ref. '4') (Obsoleted by RFC 3007) -- Obsolete informational reference (is this intentional?): RFC 2541 (ref. '6') (Obsoleted by RFC 4641) -- Obsolete informational reference (is this intentional?): RFC 3658 (ref. '7') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-08) exists of draft-hollenbeck-epp-secdns-07 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP O. Kolkman 3 Internet-Draft R. Gieben 4 Updates: 2541 (if approved) NLnet Labs 5 Expires: April 27, 2006 October 24, 2005 7 DNSSEC Operational Practices 8 draft-ietf-dnsop-dnssec-operational-practices-06.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes a set of practices for operating the DNS with 42 security extensions (DNSSEC). The target audience is zone 43 administrators deploying DNSSEC. 45 The document discusses operational aspects of using keys and 46 signatures in the DNS. It discusses issues as key generation, key 47 storage, signature generation, key rollover and related policies. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 4 53 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 54 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 55 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 56 3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 57 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7 58 3.1.2. KSKs for High Level Zones . . . . . . . . . . . . . . 7 59 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8 60 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 8 61 3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9 62 3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 11 64 4. Signature generation, Key Rollover and Related Policies . . . 12 65 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12 66 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 12 67 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 14 68 4.2.1. Zone signing Key Rollovers . . . . . . . . . . . . . . 14 69 4.2.2. Key signing Key Rollovers . . . . . . . . . . . . . . 18 70 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 19 71 4.2.4. Automated Key Rollovers . . . . . . . . . . . . . . . 20 72 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 21 73 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 21 74 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 23 75 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 23 76 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 23 77 4.4.1. Initial Key Exchanges and Parental Policies 78 Considerations . . . . . . . . . . . . . . . . . . . . 23 79 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 24 80 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 24 81 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 25 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 84 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 88 Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 27 89 Appendix B. Zone signing Key Rollover Howto . . . . . . . . . . . 28 90 Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 29 91 Appendix D. Document Details and Changes . . . . . . . . . . . . 31 92 D.1. draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 31 93 D.2. draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 31 94 D.3. draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 31 95 D.4. draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 32 96 D.5. draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 32 97 D.6. draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 32 98 D.7. draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 32 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 100 Intellectual Property and Copyright Statements . . . . . . . . . . 34 102 1. Introduction 104 During workshops and early operational deployment tests, operators 105 and system administrators have gained experience about operating the 106 DNS with security extensions (DNSSEC). This document translates 107 these experiences into a set of practices for zone administrators. 108 At the time of writing, there exists very little experience with 109 DNSSEC in production environments; this document should therefore 110 explicitly not be seen as representing 'Best Current Practices'. 112 The procedures herein are focused on the maintenance of signed zones 113 (i.e. signing and publishing zones on authoritative servers). It is 114 intended that maintenance of zones such as re-signing or key 115 rollovers be transparent to any verifying clients on the Internet. 117 The structure of this document is as follows. In Section 2 we 118 discuss the importance of keeping the "chain of trust" intact. 119 Aspects of key generation and storage of private keys are discussed 120 in Section 3; the focus in this section is mainly on the private part 121 of the key(s). Section 4 describes considerations concerning the 122 public part of the keys. Since these public keys appear in the DNS 123 one has to take into account all kinds of timing issues, which are 124 discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the 125 rollover, or supercession, of keys. Finally Section 4.4 discusses 126 considerations on how parents deal with their children's public keys 127 in order to maintain chains of trust. 129 The typographic conventions used in this document are explained in 130 Appendix C. 132 Since this is a document with operational suggestions and there are 133 no protocol specifications, the RFC2119 [3] language does not apply. 135 This document obsoletes RFC2541 [6]. 137 1.1. The Use of the Term 'key' 139 It is assumed that the reader is familiar with the concept of 140 asymmetric keys on which DNSSEC is based (Public Key Cryptography 141 [12]). Therefore, this document will use the term 'key' rather 142 loosely. Where it is written that 'a key is used to sign data' it is 143 assumed that the reader understands that it is the private part of 144 the key pair that is used for signing. It is also assumed that the 145 reader understands that the public part of the key pair is published 146 in the DNSKEY resource record and that it is the public part that is 147 used in key exchanges. 149 1.2. Time Definitions 151 In this document we will be using a number of time related terms. 152 The following definitions apply: 153 o "Signature validity period" 154 The period that a signature is valid. It starts at the time 155 specified in the signature inception field of the RRSIG RR and 156 ends at the time specified in the expiration field of the RRSIG 157 RR. 158 o "Signature publication period" 159 Time after which a signature (made with a specific key) is 160 replaced with a new signature (made with the same key). This 161 replacement takes place by publishing the relevant RRSIG in the 162 master zone file. 163 After one stopped publishing an RRSIG in a zone it may take a 164 while before the RRSIG has expired from caches and has actually 165 been removed from the DNS. 166 o "Key effectivity period" 167 The period during which a key pair is expected to be effective. 168 This period is defined as the time between the first inception 169 time stamp and the last expiration date of any signature made 170 with this key, regardless of any discontinuity in the use of 171 the key. 172 The key effectivity period can span multiple signature validity 173 periods. 174 o "Maximum/Minimum Zone TTL" 175 The maximum or minimum value of the TTLs from the complete set 176 of RRs in a zone. Note that the minimum TTL is not the same as 177 the MINIMUM field in the SOA RR. 179 2. Keeping the Chain of Trust Intact 181 Maintaining a valid chain of trust is important because broken chains 182 of trust will result in data being marked as Bogus (as defined in [2] 183 section 5), which may cause entire (sub)domains to become invisible 184 to verifying clients. The administrators of secured zones have to 185 realize that their zone is, to verifying clients, part of a chain of 186 trust. 188 As mentioned in the introduction, the procedures herein are intended 189 to ensure that maintenance of zones, such as re-signing or key 190 rollovers, will be transparent to the verifying clients on the 191 Internet. 193 Administrators of secured zones will have to keep in mind that data 194 published on an authoritative primary server will not be immediately 195 seen by verifying clients; it may take some time for the data to be 196 transferred to other secondary authoritative nameservers and clients 197 may be fetching data from caching non-authoritative servers. In this 198 light it is good to note that the time for a zone transfer from 199 master to slave is negligible when using NOTIFY and IXFR, increasing 200 by reliance on AXFR, and more if you rely on the SOA timing 201 parameters for zone refresh. 203 For the verifying clients it is important that data from secured 204 zones can be used to build chains of trust regardless of whether the 205 data came directly from an authoritative server, a caching nameserver 206 or some middle box. Only by carefully using the available timing 207 parameters can a zone administrator assure that the data necessary 208 for verification can be obtained. 210 The responsibility for maintaining the chain of trust is shared by 211 administrators of secured zones in the chain of trust. This is most 212 obvious in the case of a 'key compromise' when a trade off between 213 maintaining a valid chain of trust and replacing the compromised keys 214 as soon as possible must be made. Then zone administrators will have 215 to make a trade off, between keeping the chain of trust intact - 216 thereby allowing for attacks with the compromised key - or to 217 deliberately break the chain of trust and making secured sub domains 218 invisible to security aware resolvers. Also see Section 4.3. 220 3. Keys Generation and Storage 222 This section describes a number of considerations with respect to the 223 security of keys. It deals with the generation, effectivity period, 224 size and storage of private keys. 226 3.1. Zone and Key Signing Keys 228 The DNSSEC validation protocol does not distinguish between different 229 types of DNSKEYs. All DNSKEYs can be used during the validation. In 230 practice operators use Key Signing and Zone Signing Keys and use the 231 so-called (Secure Entry Point) SEP [1] flag to distinguish between 232 them during operations. The dynamics and considerations are 233 discussed below. 235 To make zone re-signing and key rollover procedures easier to 236 implement, it is possible to use one or more keys as Key Signing Keys 237 (KSK). These keys will only sign the apex DNSKEY RRset in a zone. 238 Other keys can be used to sign all the RRsets in a zone and are 239 referred to as Zone Signing Keys (ZSK). In this document we assume 240 that KSKs are the subset of keys that are used for key exchanges with 241 the parent and potentially for configuration as trusted anchors - the 242 SEP keys. In this document we assume a one-to-one mapping between 243 KSK and SEP keys and we assume the SEP flag to be set on all KSKs. 245 3.1.1. Motivations for the KSK and ZSK Separation 247 Differentiating between the KSK and ZSK functions has several 248 advantages: 250 o No parent/child interaction is required when ZSKs are updated. 251 o The KSK can be made stronger (i.e. using more bits in the key 252 material). This has little operational impact since it is only 253 used to sign a small fraction of the zone data. Also the KSK is 254 only used to verify the zone's key set, not for other RRsets in 255 the zone. 256 o As the KSK is only used to sign a key set, which is most probably 257 updated less frequently than other data in the zone, it can be 258 stored separately from and in a safer location than the ZSK. 259 o A KSK can have a longer key effectivity period. 261 For almost any method of key management and zone signing the KSK is 262 used less frequently than the ZSK. Once a key set is signed with the 263 KSK all the keys in the key set can be used as ZSK. If a ZSK is 264 compromised, it can be simply dropped from the key set. The new key 265 set is then re-signed with the KSK. 267 Given the assumption that for KSKs the SEP flag is set, the KSK can 268 be distinguished from a ZSK by examining the flag field in the DNSKEY 269 RR. If the flag field is an odd number it is a KSK. If it is an 270 even number it is a ZSK. 272 The zone signing key can be used to sign all the data in a zone on a 273 regular basis. When a zone signing key is to be rolled, no 274 interaction with the parent is needed. This allows for "Signature 275 Validity Periods" on the order of days. 277 The key signing key is only to be used to sign the DNSKEY RRs in a 278 zone. If a key signing key is to be rolled over, there will be 279 interactions with parties other than the zone administrator. These 280 can include the registry of the parent zone or administrators of 281 verifying resolvers that have the particular key configured as secure 282 entry points. Hence, the key effectivity period of these keys can 283 and should be made much longer. Although, given a long enough key, 284 the Key Effectivity Period can be on the order of years we suggest 285 planning for a key effectivity of the order of a few months so that a 286 key rollover remains an operational routine. 288 3.1.2. KSKs for High Level Zones 290 Higher level zones are generally more sensitive than lower level 291 zones. Anyone controlling or breaking the security of a zone thereby 292 obtains authority over all of its sub domains (except in the case of 293 resolvers that have locally configured the public key of a sub 294 domain, in which case this, and only this, sub domain wouldn't be 295 affected by the compromise of the parent zone). Therefore, extra 296 care should be taken with high level zones and strong keys should 297 used. 299 The root zone is the most critical of all zones. Someone controlling 300 or compromising the security of the root zone would control the 301 entire DNS name space of all resolvers using that root zone (except 302 in the case of resolvers that have locally configured the public key 303 of a sub domain). Therefore, the utmost care must be taken in the 304 securing of the root zone. The strongest and most carefully handled 305 keys should be used. The root zone private key should always be kept 306 off line. 308 Many resolvers will start at a root server for their access to and 309 authentication of DNS data. Securely updating the trust anchors in 310 an enormous population of resolvers around the world will be 311 extremely difficult. 313 3.2. Key Generation 315 Careful generation of all keys is a sometimes overlooked but 316 absolutely essential element in any cryptographically secure system. 317 The strongest algorithms used with the longest keys are still of no 318 use if an adversary can guess enough to lower the size of the likely 319 key space so that it can be exhaustively searched. Technical 320 suggestions for the generation of random keys will be found in 321 RFC4086 [9]. One should carefully assess if the random number 322 generator used during key generation adheres to these suggestions. 324 Keys with a long effectivity period are particularly sensitive as 325 they will represent a more valuable target and be subject to attack 326 for a longer time than short period keys. It is strongly recommended 327 that long term key generation occur off-line in a manner isolated 328 from the network via an air gap or, at a minimum, high level secure 329 hardware. 331 3.3. Key Effectivity Period 333 For various reasons keys in DNSSEC need to be changed once in a 334 while. The longer a key is in use, the greater the probability that 335 it will have been compromised through carelessness, accident, 336 espionage, or cryptanalysis. Furthermore when key rollovers are too 337 rare an event, they will not become part of the operational habit and 338 there is risk that nobody on-site will remember the procedure for 339 rollover when the need is there. 341 From a purely operational perspective a reasonable key effectivity 342 period for Key Signing Keys is 13 months, with the intent to replace 343 them after 12 months. An intended key effectivity period of a month 344 is reasonable for Zone Signing Keys. 346 For a key sizes that matches these effectivity periods see 347 Section 3.5. 349 As argued in Section 3.1.2 securely updating trust anchors will be 350 extremely difficult. On the other hand the "operational habit" 351 argument does also apply to trust anchor reconfiguration. If a short 352 key-effectivity period is used and the trust anchor configuration has 353 to be revisited on a regular basis the odds that the configuration 354 tends to be forgotten is smaller. The trade-off is against a system 355 that is so dynamic that administrators of the validating clients will 356 not be able to follow the modifications. 358 Key effectivity periods can be made very short, as in the order of a 359 few minutes. But when replacing keys one has to take the 360 considerations from Section 4.1 and Section 4.2 into account. 362 3.4. Key Algorithm 364 There are currently three different types of algorithms that can be 365 used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter 366 is fairly new and has yet to be standardized for usage in DNSSEC. 368 RSA has been developed in an open and transparent manner. As the 369 patent on RSA expired in 2000, its use is now also free. 371 DSA has been developed by NIST. The creation of signatures is 372 roughly done at the same speed as with RSA, but is 10 to 40 times as 373 slow for verification [12]. 375 We suggest the use of RSA/SHA-1 as the preferred algorithm for the 376 key. The current known attacks on RSA can be defeated by making your 377 key longer. As the MD5 hashing algorithm is showing (theoretical) 378 cracks, we recommend the usage of SHA-1. 380 In 2005 some discoveries were made that SHA-1 also has some 381 weaknesses. Currently SHA-1 is strong enough for DNSSEC. It is 382 expected that a new hashing algorithm is rolled out, before any 383 attack becomes practical. 385 3.5. Key Sizes 387 When choosing key sizes, zone administrators will need to take into 388 account how long a key will be used, how much data will be signed 389 during the key publication period (See Section 8.10 of [12]) and, 390 optionally, how large the key size of the parent is. As the chain of 391 trust really is "a chain", it does not make much sense in making one 392 of the keys in the chain several times larger then the others. As 393 always, it's the weakest link that defines the strength of the entire 394 chain. Also see Section 3.1.1 for a discussion of how keys serving 395 different roles (ZSK v. KSK) may need different key sizes. 397 Generating a key of the correct size is a difficult problem, RFC3766 398 [8] tries to deal with that problem. Paragraph 1 of that RFC states: 400 1. Determine the attack resistance necessary to satisfy the 401 security requirements of the application. Do this by 402 estimating the minimum number of computer operations that 403 the attacker will be forced to do in order to compromise 404 the security of the system and then take the logarithm base 405 two of that number. Call that logarithm value "n". 407 A 1996 report recommended 90 bits as a good all-around choice 408 for system security. The 90 bit number should be increased 409 by about 2/3 bit/year, or about 96 bits in 2005. 411 [8] goes on to explain how this number "n" can be used to calculate 412 the key sizes in public key cryptography. This culminated in the 413 table given below (slightly modified for our purpose): 415 +-------------+-----------+--------------+ 416 | System | | | 417 | requirement | Symmetric | RSA or DSA | 418 | for attack | key size | modulus size | 419 | resistance | (bits) | (bits) | 420 | (bits) | | | 421 +-------------+-----------+--------------+ 422 | 70 | 70 | 947 | 423 | 80 | 80 | 1228 | 424 | 90 | 90 | 1553 | 425 | 100 | 100 | 1926 | 426 | 150 | 150 | 4575 | 427 | 200 | 200 | 8719 | 428 | 250 | 250 | 14596 | 429 +-------------+-----------+--------------+ 431 The key sizes given are rather large. This is because these keys are 432 resilient against a trillionaire attacker. Assuming this rich 433 attacker will not attack your key and that the key is rolled over 434 once a year, we come to the following recommendations about KSK 435 sizes; 1024 bits low value domains, 1300 for medium value and 2048 436 for the high value domains. 438 Whether a domain is of low, medium, high value depends solely on the 439 views of the zone owner. One could for instance view leaf nodes in 440 the DNS as of low value and TLDs or the root zone of high value. The 441 suggested key sizes should be safe for the next 5 years. 443 As ZSKs can be rolled over more easily (and thus more often) the key 444 sizes can be made smaller. But as said in the introduction of this 445 paragraph, making the ZSKs' key sizes too small (in relation to the 446 KSKs' sizes) doesn't make much sense. Try to limit the difference in 447 size to about 100 bits. 449 Note that nobody can see into the future, and that these key sizes 450 are only provided here as a guide. Further information can be found 451 in [11] and Section 7.5 of [12]. It should be noted thought that 452 [11] is already considered overly optimistic about what key sizes are 453 considered safe. 455 One final note concerning key sizes. Larger keys will increase the 456 sizes of the RRSIG and DNSKEY records and will therefore increase the 457 chance of DNS UDP packet overflow. Also the time it takes to 458 validate and create RRSIGs increases with larger keys, so don't 459 needlessly double your key sizes. 461 3.6. Private Key Storage 463 It is recommended that, where possible, zone private keys and the 464 zone file master copy that is to be signed, be kept and used in off- 465 line, non-network connected, physically secure machines only. 466 Periodically an application can be run to add authentication to a 467 zone by adding RRSIG and NSEC RRs. Then the augmented file can be 468 transferred. 470 When relying on dynamic update to manage a signed zone [4], be aware 471 that at least one private key of the zone will have to reside on the 472 master server. This key is only as secure as the amount of exposure 473 the server receives to unknown clients and the security of the host. 474 Although not mandatory one could administer the DNS in the following 475 way. The master that processes the dynamic updates is unavailable 476 from generic hosts on the Internet, it is not listed in the NS RR 477 set, although its name appears in the SOA RRs MNAME field. The 478 nameservers in the NS RR set are able to receive zone updates through 479 NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism. This 480 approach is known as the "hidden master" setup. 482 The ideal situation is to have a one way information flow to the 483 network to avoid the possibility of tampering from the network. 484 Keeping the zone master file on-line on the network and simply 485 cycling it through an off-line signer does not do this. The on-line 486 version could still be tampered with if the host it resides on is 487 compromised. For maximum security, the master copy of the zone file 488 should be off net and should not be updated based on an unsecured 489 network mediated communication. 491 In general keeping a zone-file off-line will not be practical and the 492 machines on which zone files are maintained will be connected to a 493 network. Operators are advised to take security measures to shield 494 unauthorized access to the master copy. 496 For dynamically updated secured zones [4] both the master copy and 497 the private key that is used to update signatures on updated RRs will 498 need to be on-line. 500 4. Signature generation, Key Rollover and Related Policies 502 4.1. Time in DNSSEC 504 Without DNSSEC all times in DNS are relative. The SOA fields 505 REFRESH, RETRY and EXPIRATION are timers used to determine the time 506 elapsed after a slave server synchronized with a master server. The 507 Time to Live (TTL) value and the SOA RR minimum TTL parameter [5] are 508 used to determine how long a forwarder should cache data after it has 509 been fetched from an authoritative server. By using a signature 510 validity period, DNSSEC introduces the notion of an absolute time in 511 the DNS. Signatures in DNSSEC have an expiration date after which 512 the signature is marked as invalid and the signed data is to be 513 considered Bogus. 515 4.1.1. Time Considerations 517 Because of the expiration of signatures, one should consider the 518 following: 519 o We suggest the Maximum Zone TTL of your zone data to be a fraction 520 of your signature validity period. 521 If the TTL would be of similar order as the signature validity 522 period, then all RRsets fetched during the validity period 523 would be cached until the signature expiration time. Section 524 7.1 of [2] suggests that "the resolver may use the time 525 remaining before expiration of the signature validity period of 526 a signed RRset as an upper bound for the TTL". As a result 527 query load on authoritative servers would peak at signature 528 expiration time, as this is also the time at which records 529 simultaneously expire from caches. 530 To avoid query load peaks we suggest the TTL on all the RRs in 531 your zone to be at least a few times smaller than your 532 signature validity period. 533 o We suggest the Signature Publication Period to end at least one 534 Maximum Zone TTL duration before the end of the Signature Validity 535 Period. 536 Re-signing a zone shortly before the end of the signature 537 validity period may cause simultaneous expiration of data from 538 caches. This in turn may lead to peaks in the load on 539 authoritative servers. 540 o We suggest the minimum zone TTL to be long enough to both fetch 541 and verifying all the RRs in the trust chain. In workshop 542 environments it has been demonstrated [13] that a low TTL (under 5 543 to 10 minutes) caused disruptions because of the following two 544 problems: 545 1. During validation, some data may expire before the 546 validation is complete. The validator should be able to keep 547 all data, until is completed. This applies to all RRs needed 548 to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the 549 final answers i.e. the RRset that is returned for the initial 550 query. 551 2. Frequent verification causes load on recursive nameservers. 552 Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from 553 caching. The TTL on those should be relatively long. 554 o Slave servers will need to be able to fetch newly signed zones 555 well before the RRSIGs in the zone served by the slave server pass 556 their signature expiration time. 557 When a slave server is out of sync with its master and data in 558 a zone is signed by expired signatures it may be better for the 559 slave server not to give out any answer. 560 Normally a slave server that is not able to contact a master 561 server for an extended period will expire a zone. When that 562 happens the server will respond differently to queries for that 563 zone. Some servers issues SERVFAIL while others turn off the 564 'AA' bit in the answers. The time of expiration is set in the 565 SOA record and is relative to the last successful refresh 566 between the master and the slave server. There exists no 567 coupling between the signature expiration of RRSIGs in the zone 568 and the expire parameter in the SOA. 569 If the server serves a DNSSEC zone then it may well happen that 570 the signatures expire well before the SOA expiration timer 571 counts down to zero. It is not possible to completely prevent 572 this from happening by tweaking the SOA parameters. 574 However, the effects can be minimized where the SOA expiration 575 time is equal or shorter than the signature validity period. 576 The consequence of an authoritative server not being able to 577 update a zone, whilst that zone includes expired signatures, is 578 that non-secure resolvers will continue to be able to resolve 579 data served by the particular slave servers while security 580 aware resolvers will experience problems because of answers 581 being marked as Bogus. 582 We suggest the SOA expiration timer being approximately one 583 third or one fourth of the signature validity period. It will 584 allow problems with transfers from the master server to be 585 noticed before the actual signature times out. 586 We also suggest that operators of nameservers that supply 587 secondary services develop 'watch dogs' to spot upcoming 588 signature expirations in zones they slave, and take appropriate 589 action. 590 When determining the value for the expiration parameter one has 591 to take the following into account: What are the chances that 592 all my secondary zones expire; How quickly can I reach an 593 administrator of secondary servers to load a valid zone? All 594 these arguments are not DNSSEC specific but may influence the 595 choice of your signature validity intervals. 597 4.2. Key Rollovers 599 A DNSSEC key cannot be used forever (see Section 3.3). So key 600 rollovers -- or supercessions, as they are sometimes called -- are a 601 fact of life when using DNSSEC. Zone administrators who are in the 602 process of rolling their keys have to take into account that data 603 published in previous versions of their zone still lives in caches. 604 When deploying DNSSEC, this becomes an important consideration; 605 ignoring data that may be in caches may lead to loss of service for 606 clients. 608 The most pressing example of this occurs when zone material signed 609 with an old key is being validated by a resolver which does not have 610 the old zone key cached. If the old key is no longer present in the 611 current zone, this validation fails, marking the data Bogus. 612 Alternatively, an attempt could be made to validate data which is 613 signed with a new key against an old key that lives in a local cache, 614 also resulting in data being marked Bogus. 616 4.2.1. Zone signing Key Rollovers 618 For zone signing key rollovers there are two ways to make sure that 619 during the rollover data still cached can be verified with the new 620 key sets or newly generated signatures can be verified with the keys 621 still in caches. One schema, described in Section 4.2.1.2, uses 622 double signatures; the other uses key pre-publication 623 (Section 4.2.1.1). The pros, cons and recommendations are described 624 in Section 4.2.1.3. 626 4.2.1.1. Pre-publish Key Rollover 628 This section shows how to perform a ZSK rollover without the need to 629 sign all the data in a zone twice - the so-called "pre-publish 630 rollover".This method has advantages in the case of a key compromise. 631 If the old key is compromised, the new key has already been 632 distributed in the DNS. The zone administrator is then able to 633 quickly switch to the new key and remove the compromised key from the 634 zone. Another major advantage is that the zone size does not double, 635 as is the case with the double signature ZSK rollover. A small 636 "HOWTO" for this kind of rollover can be found in Appendix B. 638 initial new DNSKEY new RRSIGs DNSKEY removal 640 SOA0 SOA1 SOA2 SOA3 641 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 643 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 644 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 645 DNSKEY11 DNSKEY11 646 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 647 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 649 initial: Initial version of the zone: DNSKEY 1 is the key signing 650 key. DNSKEY 10 is used to sign all the data of the zone, the zone 651 signing key. 652 new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no 653 signatures are generated with this key yet, but this does not 654 secure against brute force attacks on the public key. The minimum 655 duration of this pre-roll phase is the time it takes for the data 656 to propagate to the authoritative servers plus TTL value of the 657 key set. 658 new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is 659 used to sign the data in the zone exclusively (i.e. all the 660 signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 661 remains published in the key set. This way data that was loaded 662 into caches from version 1 of the zone can still be verified with 663 key sets fetched from version 2 of the zone. 664 The minimum time that the key set including DNSKEY 10 is to be 665 published is the time that it takes for zone data from the 666 previous version of the zone to expire from old caches i.e. the 667 time it takes for this zone to propagate to all authoritative 668 servers plus the Maximum Zone TTL value of any of the data in the 669 previous version of the zone. 670 DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now 671 only containing DNSKEY 1 and DNSKEY 11 is re-signed with the 672 DNSKEY 1. 674 The above scheme can be simplified by always publishing the "future" 675 key immediately after the rollover. The scheme would look as follows 676 (we show two rollovers); the future key is introduced in "new DNSKEY" 677 as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY 678 (II)": 680 initial new RRSIGs new DNSKEY 682 SOA0 SOA1 SOA2 683 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) 685 DNSKEY1 DNSKEY1 DNSKEY1 686 DNSKEY10 DNSKEY10 DNSKEY11 687 DNSKEY11 DNSKEY11 DNSKEY12 688 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 689 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 691 new RRSIGs (II) new DNSKEY (II) 693 SOA3 SOA4 694 RRSIG12(SOA3) RRSIG12(SOA4) 696 DNSKEY1 DNSKEY1 697 DNSKEY11 DNSKEY12 698 DNSKEY12 DNSKEY13 699 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 700 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 702 Note that the key introduced in the "new DNSKEY" phase is not used 703 for production yet; the private key can thus be stored in a 704 physically secure manner and does not need to be 'fetched' every time 705 a zone needs to be signed. 707 4.2.1.2. Double Signature Zone signing Key Rollover 709 This section shows how to perform a ZSK key rollover using the double 710 zone data signature scheme, aptly named "double sig rollover". 712 During the "new DNSKEY" stage the new version of the zone file will 713 need to propagate to all authoritative servers and the data that 714 exists in (distant) caches will need to expire, requiring at least 715 the maximum Zone TTL. 717 initial new DNSKEY DNSKEY removal 719 SOA0 SOA1 SOA2 720 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 721 RRSIG11(SOA1) 723 DNSKEY1 DNSKEY1 DNSKEY1 724 DNSKEY10 DNSKEY10 DNSKEY11 725 DNSKEY11 726 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 727 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 728 RRSIG11(DNSKEY) 730 initial: Initial Version of the zone: DNSKEY 1 is the key signing 731 key. DNSKEY 10 is used to sign all the data of the zone, the zone 732 signing key. 733 new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is 734 introduced into the key set and all the data in the zone is signed 735 with DNSKEY 10 and DNSKEY 11. The rollover period will need to 736 exist until all data from version 0 of the zone has expired from 737 remote caches. This will take at least the maximum Zone TTL of 738 version 0 of the zone. 739 DNSKEY removal: DNSKEY 10 is removed from the zone. All the 740 signatures from DNSKEY 10 are removed from the zone. The key set, 741 now only containing DNSKEY 11, is re-signed with DNSKEY 1. 743 At every instance, RRSIGs from the previous version of the zone can 744 be verified with the DNSKEY RRset from the current version and the 745 other way around. The data from the current version can be verified 746 with the data from the previous version of the zone. The duration of 747 the "new DNSKEY" phase and the period between rollovers should be at 748 least the Maximum Zone TTL. 750 Making sure that the "new DNSKEY" phase lasts until the signature 751 expiration time of the data in initial version of the zone is 752 recommended. This way all caches are cleared of the old signatures. 753 However, this duration could be considerably longer than the Maximum 754 Zone TTL, making the rollover a lengthy procedure. 756 Note that in this example we assumed that the zone was not modified 757 during the rollover. New data can be introduced in the zone as long 758 as it is signed with both keys. 760 4.2.1.3. Pros and Cons of the Schemes 762 Pre-publish Key Rollover: This rollover does not involve signing the 763 zone data twice. Instead, before the actual rollover, the new key 764 is published in the key set and thus available for cryptanalysis 765 attacks. A small disadvantage is that this process requires four 766 steps. Also the pre-publish scheme involves more parental work 767 when used for KSK rollovers as explained in Section 4.2.3. 768 Double Signature Zone-signing Key Rollover: The drawback of this 769 signing scheme is that during the rollover the number of 770 signatures in your zone doubles, this may be prohibitive if you 771 have very big zones. An advantage is that it only requires three 772 steps. 774 4.2.2. Key signing Key Rollovers 776 For the rollover of a key signing key the same considerations as for 777 the rollover of a zone signing key apply. However we can use a 778 double signature scheme to guarantee that old data (only the apex key 779 set) in caches can be verified with a new key set and vice versa. 780 Since only the key set is signed with a KSK, zone size considerations 781 do not apply. 783 initial new DNSKEY DS change DNSKEY removal 784 Parent: 785 SOA0 --------> SOA1 --------> 786 RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> 787 DS1 --------> DS2 --------> 788 RRSIGpar(DS) --------> RRSIGpar(DS) --------> 790 Child: 791 SOA0 SOA1 --------> SOA2 792 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) 793 --------> 794 DNSKEY1 DNSKEY1 --------> DNSKEY2 795 DNSKEY2 --------> 796 DNSKEY10 DNSKEY10 --------> DNSKEY10 797 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) 798 RRSIG2 (DNSKEY) --------> 799 RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) 801 initial: Initial version of the zone. The parental DS points to 802 DNSKEY1. Before the rollover starts the child will have to verify 803 what the TTL is of the DS RR that points to DNSKEY1 - it is needed 804 during the rollover and we refer to the value as TTL_DS. 806 new DNSKEY: During the "new DNSKEY" phase the zone administrator 807 generates a second KSK, DNSKEY2. The key is provided to the 808 parent and the child will have to wait until a new DS RR has been 809 generated that points to DNSKEY2. After that DS RR has been 810 published on all servers authoritative for the parent's zone, the 811 zone administrator has to wait at least TTL_DS to make sure that 812 the old DS RR has expired from caches. 813 DS change: The parent replaces DS1 with DS2. 814 DNSKEY removal: DNSKEY1 has been removed. 816 The scenario above puts the responsibility for maintaining a valid 817 chain of trust with the child. It also is based on the premises that 818 the parent only has one DS RR (per algorithm) per zone. An 819 alternative mechanism has been considered. Using an established 820 trust relation, the interaction can be performed in-band, and the 821 removal of the keys by the child can possibly be signaled by the 822 parent. In this mechanism there are periods where there are two DS 823 RRs at the parent. Since at the moment of writing the protocol for 824 this interaction has not been developed, further discussion is out of 825 scope for this document. 827 4.2.3. Difference Between ZSK and KSK Rollovers 829 Note that KSK rollovers and ZSK rollovers are different in the sense 830 that a KSK rollover requires interaction with the parent (and 831 possibly replacing of trust anchors) and the ensuing delay while 832 waiting for it. 834 A zone key rollover can be handled in two different ways: pre-publish 835 (Section Section 4.2.1.1) and double signature (Section 836 Section 4.2.1.2). 838 As the KSK is used to validate the key set and because the KSK is not 839 changed during a ZSK rollover, a cache is able to validate the new 840 key set of the zone. The pre-publish method would work for a KSK 841 rollover. The records that are to be pre-published are the parental 842 DS RRs. The pre-publish method has some drawbacks for KSKs. We 843 first describe the rollover scheme and then indicate these drawbacks. 845 initial new DS new DNSKEY DS/DNSKEY removal 846 Parent: 847 SOA0 SOA1 --------> SOA2 848 RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) 849 DS1 DS1 --------> DS2 850 DS2 --------> 851 RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) 853 Child: 854 SOA0 --------> SOA1 SOA1 855 RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) 856 --------> 857 DNSKEY1 --------> DNSKEY2 DNSKEY2 858 --------> 859 DNSKEY10 --------> DNSKEY10 DNSKEY10 860 RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 861 RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) 863 When the child zone wants to roll it notifies the parent during the 864 "new DS" phase and submits the new key (or the corresponding DS) to 865 the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 866 and DNSKEY2 respectively. During the rollover ("new DNSKEY" phase), 867 which can take place as soon as the new DS set propagated through the 868 DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that 869 ("DS/DNSKEY removal" phase) it can notify the parent that the old DS 870 record can be deleted. 872 The drawbacks of this scheme are that during the "new DS" phase the 873 parent cannot verify the match between the DS2 RR and DNSKEY2 using 874 the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a 875 "security lame" key (See Section 4.4.3). Finally the child-parent 876 interaction consists of two steps. The "double signature" method 877 only needs one interaction. 879 4.2.4. Automated Key Rollovers 881 As keys must be renewed periodically, there is some motivation to 882 automate the rollover process. Consider that: 884 o ZSK rollovers are easy to automate as only the child zone is 885 involved. 886 o A KSK rollover needs interaction between parent and child. Data 887 exchange is needed to provide the new keys to the parent, 888 consequently, this data must be authenticated and integrity must 889 be guaranteed in order to avoid attacks on the rollover. 891 4.3. Planning for Emergency Key Rollover 893 This section deals with preparation for a possible key compromise. 894 Our advice is to have a documented procedure ready for when a key 895 compromise is suspected or confirmed. 897 When the private material of one of your keys is compromised it can 898 be used for as long as a valid trust chain exists. A trust chain 899 remains intact for: 900 o as long as a signature over the compromised key in the trust chain 901 is valid, 902 o as long as a parental DS RR (and signature) points to the 903 compromised key, 904 o as long as the key is anchored in a resolver and is used as a 905 starting point for validation (this is generally the hardest to 906 update). 908 While a trust chain to your compromised key exists, your name-space 909 is vulnerable to abuse by anyone who has obtained illegitimate 910 possession of the key. Zone operators have to make a trade off if 911 the abuse of the compromised key is worse than having data in caches 912 that cannot be validated. If the zone operator chooses to break the 913 trust chain to the compromised key, data in caches signed with this 914 key cannot be validated. However, if the zone administrator chooses 915 to take the path of a regular roll-over, the malicious key holder can 916 spoof data so that it appears to be valid. 918 4.3.1. KSK Compromise 920 A zone containing a DNSKEY RRset with a compromised KSK is vulnerable 921 as long as the compromised KSK is configured as trust anchor or a 922 parental DS points to it. 924 A compromised KSK can be used to sign the key set of an attackers 925 zone. That zone could be used to poison the DNS. 927 Therefore when the KSK has been compromised, the trust anchor or the 928 parental DS, should be replaced as soon as possible. It is local 929 policy whether to break the trust chain during the emergency 930 rollover. The trust chain would be broken when the compromised KSK 931 is removed from the child's zone while the parent still has a DS 932 pointing to the compromised KSK (the assumption is that there is only 933 one DS at the parent. If there are multiple DSs this does not apply 934 -- however the chain of trust of this particular key is broken). 936 Note that an attacker's zone still uses the compromised KSK and the 937 presence of a parental DS would cause the data in this zone to appear 938 as valid. Removing the compromised key would cause the attacker's 939 zone to appear as valid and the child's zone as bogus. Therefore we 940 advise not to remove the KSK before the parent has a DS to a new KSK 941 in place. 943 4.3.1.1. Keeping the Chain of Trust Intact 945 If we follow this advice the timing of the replacement of the KSK is 946 somewhat critical. The goal is to remove the compromised KSK as soon 947 as the new DS RR is available at the parent. And also make sure that 948 the signature made with a new KSK over the key set with the 949 compromised KSK in it expires just after the new DS appears at the 950 parent. Thus removing the old cruft in one swoop. 952 The procedure is as follows: 953 1. Introduce a new KSK into the key set, keep the compromised KSK in 954 the key set. 955 2. Sign the key set, with a short validity period. The validity 956 period should expire shortly after the DS is expected to appear 957 in the parent and the old DSs have expired from caches. 958 3. Upload the DS for this new key to the parent. 959 4. Follow the procedure of the regular KSK rollover: Wait for the DS 960 to appear in the authoritative servers and then wait as long as 961 the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRset 962 and modify/extend the expiration time. 963 5. Remove the compromised DNSKEY RR from the zone and re-sign the 964 key set using your "normal" validity interval. 966 An additional danger of a key compromise is that the compromised key 967 could be used to facilitate a legitimate DNSKEY/DS rollover and/or 968 nameserver changes at the parent. When that happens the domain may 969 be in dispute. An authenticated out of band and secure notify 970 mechanism to contact a parent is needed in this case. 972 Note that this is only a problem when the DNSKEY and or DS records 973 are used for authentication at the parent. 975 4.3.1.2. Breaking the Chain of Trust 977 There are two methods to break the chain of trust. The first method 978 causes the child zone to appear as 'bogus' to validating resolvers. 979 The other causes the the child zone to appear as 'insecure'. These 980 are described below. 982 In the method that causes the child zone to appear as 'bogus' to 983 validating resolvers, the child zone replaces the current KSK with a 984 new one and resigns the key set. Next it sends the DS of the new key 985 to the parent. Only after the parent has placed the new DS in the 986 zone, the child's chain of trust is repaired. 988 An alternative method of breaking the chain of trust is by removing 989 the DS RRs from the parent zone altogether. As a result the child 990 zone would become insecure. 992 4.3.2. ZSK Compromise 994 Primarily because there is no parental interaction required when a 995 ZSK is compromised, the situation is less severe than with a KSK 996 compromise. The zone must still be re-signed with a new ZSK as soon 997 as possible. As this is a local operation and requires no 998 communication between the parent and child this can be achieved 999 fairly quickly. However, one has to take into account that just as 1000 with a normal rollover the immediate disappearance of the old 1001 compromised key may lead to verification problems. Also note that as 1002 long as the RRSIG over the compromised ZSK is not expired the zone 1003 may be still at risk. 1005 4.3.3. Compromises of Keys Anchored in Resolvers 1007 A key can also be pre-configured in resolvers. For instance, if 1008 DNSSEC is successfully deployed the root key may be pre-configured in 1009 most security aware resolvers. 1011 If trust-anchor keys are compromised, the resolvers using these keys 1012 should be notified of this fact. Zone administrators may consider 1013 setting up a mailing list to communicate the fact that a SEP key is 1014 about to be rolled over. This communication will of course need to 1015 be authenticated e.g. by using digital signatures. 1017 End-users faced with the task of updating an anchored key should 1018 always validate the new key. New keys should be authenticated out of 1019 the DNS, for example, looking them up on an SSL secured announcement 1020 website. 1022 4.4. Parental Policies 1024 4.4.1. Initial Key Exchanges and Parental Policies Considerations 1026 The initial key exchange is always subject to the policies set by the 1027 parent. When designing a key exchange policy one should take into 1028 account that the authentication and authorization mechanisms used 1029 during a key exchange should be as strong as the authentication and 1030 authorization mechanisms used for the exchange of delegation 1031 information between parent and child. I.e. there is no implicit need 1032 in DNSSEC to make the authentication process stronger than it was in 1033 DNS. 1035 Using the DNS itself as the source for the actual DNSKEY material, 1036 with an off-band check on the validity of the DNSKEY, has the benefit 1037 that it reduces the chances of user error. A DNSKEY query tool can 1038 make use of the SEP bit [1] to select the proper key from a DNSSEC 1039 key set; thereby reducing the chance that the wrong DNSKEY is sent. 1040 It can validate the self-signature over a key; thereby verifying the 1041 ownership of the private key material. Fetching the DNSKEY from the 1042 DNS ensures that the chain of trust remains intact once the parent 1043 publishes the DS RR indicating the child is secure. 1045 Note: the off-band verification is still needed when the key-material 1046 is fetched via the DNS. The parent can never be sure whether the 1047 DNSKEY RRs have been spoofed or not. 1049 4.4.2. Storing Keys or Hashes? 1051 When designing a registry system one should consider which of the 1052 DNSKEYs and/or the corresponding DSs to store. Since a child zone 1053 might wish to have a DS published using a message digest algorithm 1054 not yet understood by the registry, the registry can't count on being 1055 able to generate the DS record from a raw DNSKEY. Thus, we recommend 1056 that registry systems at least support storing DS records. 1058 It may also be useful to store DNSKEYs, since having them may help 1059 during troubleshooting and, as long as the child's chosen message 1060 digest is supported, the overhead of generating DS records from them 1061 is minimal. Having an out-of-band mechanism, such as a registry 1062 directory (e.g. Whois), to find out which keys are used to generate 1063 DS Resource Records for specific owners and/or zones may also help 1064 with troubleshooting. 1066 The storage considerations also relate to the design of the customer 1067 interface and the method by which data is transferred between 1068 registrant and registry; Will the child zone administrator be able to 1069 upload DS RRs with unknown hash algorithms or does the interface only 1070 allow DNSKEYs? In the registry-registrar model one can use the 1071 DNSSEC EPP protocol extensions [10] which allows transfer of DS RRs 1072 and optionally DNSKEY RRs. 1074 4.4.3. Security Lameness 1076 Security Lameness is defined as what happens when a parent has a DS 1077 RR pointing to a non-existing DNSKEY RR. When this happens the 1078 child's zone may be marked as "Bogus" by verifying DNS clients. 1080 As part of a comprehensive delegation check the parent could, at key 1081 exchange time, verify that the child's key is actually configured in 1082 the DNS. However if a parent does not understand the hashing 1083 algorithm used by child the parental checks are limited to only 1084 comparing the key id. 1086 Child zones should be very careful removing DNSKEY material, 1087 specifically SEP keys, for which a DS RR exists. 1089 Once a zone is "security lame", a fix (e.g. removing a DS RR) will 1090 take time to propagate through the DNS. 1092 4.4.4. DS Signature Validity Period 1094 Since the DS can be replayed as long as it has a valid signature, a 1095 short signature validity period over the DS minimizes the time a 1096 child is vulnerable in the case of a compromise of the child's 1097 KSK(s). A signature validity period that is too short introduces the 1098 possibility that a zone is marked Bogus in case of a configuration 1099 error in the signer. There may not be enough time to fix the 1100 problems before signatures expire. Something as mundane as operator 1101 unavailability during weekends shows the need for DS signature 1102 validity periods longer than 2 days. We recommend an absolute 1103 minimum for a DS signature validity period of a few days. 1105 The maximum signature validity period of the DS record depends on how 1106 long child zones are willing to be vulnerable after a key compromise. 1107 On the other hand shortening the DS signature validity interval 1108 increases the operational risk for the parent. Therefore the parent 1109 may have policy to use a signature validity interval that is 1110 considerably longer than the child would hope for. 1112 A compromise between the operational constraints of the parent and 1113 minimizing damage for the child may result in a DS signature validity 1114 period somewhere between the order of a week to order of months. 1116 In addition to the signature validity period, which sets a lower 1117 bound on the number of times the zone owner will need to sign the 1118 zone data and which sets an upper bound to the time a child is 1119 vulnerable after key compromise, there is the TTL value on the DS 1120 RRs. Shortening the TTL means that the authoritative servers will 1121 see more queries. But on the other hand, a short TTL lowers the 1122 persistence of DS RRSets in caches thereby increases the speed with 1123 which updated DS RRSets propagate through the DNS. 1125 5. IANA Considerations 1127 This overview document introduces no new IANA considerations. 1129 6. Security Considerations 1131 DNSSEC adds data integrity to the DNS. This document tries to assess 1132 the operational considerations to maintain a stable and secure DNSSEC 1133 service. Not taking into account the 'data propagation' properties 1134 in the DNS will cause validation failures and may make secured zones 1135 unavailable to security aware resolvers. 1137 7. Acknowledgments 1139 Most of the ideas in this draft were the result of collective efforts 1140 during workshops, discussions and try outs. 1142 At the risk of forgetting individuals who were the original 1143 contributors of the ideas we would like to acknowledge people who 1144 were actively involved in the compilation of this document. In 1145 random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael 1146 Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette 1147 Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger 1148 Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch. 1150 Some material in this document has been shamelessly copied from 1151 RFC2541 [6] by Donald Eastlake. 1153 Mike StJohns designed the key exchange between parent and child 1154 mentioned in the last paragraph of Section 4.2.2 1156 Section 4.2.4 was supplied by G. Guette and O. Courtay. 1158 Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of 1159 the spelling and style issues. 1161 Kolkman and Gieben take the blame for introducing all miscakes(SIC). 1163 Kolkman was employed by the RIPE NCC while working on this document. 1165 8. References 1167 8.1. Normative References 1169 [1] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY 1170 (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", 1171 RFC 3757, May 2004. 1173 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1174 "DNS Security Introduction and Requirements", RFC 4033, 1175 March 2005. 1177 8.2. Informative References 1179 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1180 Levels", BCP 14, RFC 2119, March 1997. 1182 [4] Eastlake, D., "Secure Domain Name System Dynamic Update", 1183 RFC 2137, April 1997. 1185 [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1186 RFC 2308, March 1998. 1188 [6] Eastlake, D., "DNS Security Operational Considerations", 1189 RFC 2541, March 1999. 1191 [7] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", 1192 RFC 3658, December 2003. 1194 [8] Orman, H. and P. Hoffman, "Determining Strengths For Public 1195 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 1196 April 2004. 1198 [9] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1199 Requirements for Security", BCP 106, RFC 4086, June 2005. 1201 [10] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 1202 Mapping for the Extensible Provisioning Protocol (EPP)", 1203 draft-hollenbeck-epp-secdns-07 (work in progress), March 2005. 1205 [11] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1206 Sizes", The Journal of Cryptology 14 (255-293), 2001. 1208 [12] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and 1209 Source Code in C", 1996. 1211 [13] Rose, S., "NIST DNSSEC workshop notes", June 2001. 1213 Appendix A. Terminology 1215 In this document there is some jargon used that is defined in other 1216 documents. In most cases we have not copied the text from the 1217 documents defining the terms but given a more elaborate explanation 1218 of the meaning. Note that these explanations should not be seen as 1219 authoritative. 1221 Anchored Key: A DNSKEY configured in resolvers around the globe. 1222 This key is hard to update, hence the term anchored. 1223 Bogus: Also see Section 5 of [2]. An RRset in DNSSEC is marked 1224 "Bogus" when a signature of a RRset does not validate against a 1225 DNSKEY. 1226 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used 1227 exclusively for signing the apex key set. The fact that a key is 1228 a KSK is only relevant to the signing tool. 1229 Key size: The term 'key size' can be substituted by 'modulus size' 1230 throughout the document. It is mathematical more correct to use 1231 modulus size, but as this is a document directed at operators we 1232 feel more at ease with the term key size. 1233 Private and Public Keys: DNSSEC secures the DNS through the use of 1234 public key cryptography. Public key cryptography is based on the 1235 existence of two (mathematical related) keys, a public key and a 1236 private key. The public keys are published in the DNS by use of 1237 the DNSKEY Resource Record (DNSKEY RR). Private keys should 1238 remain private. 1239 Key Rollover: A key rollover (also called key supercession in some 1240 environments) is the act of replacing one key pair by another at 1241 the end of a key effectivity period. 1242 Secure Entry Point key or SEP Key: A KSK that has a parental DS 1243 record pointing to it or is configured as a trust anchor. 1244 Although not required by the protocol we recommend that the SEP 1245 flag [1] is set on these keys. 1246 Self-signature: This is only applies to signatures over DNSKEYs; a 1247 signature made with DNSKEY x, over DNSKEY x is called a self- 1248 signature. Note: without further information self-signatures 1249 convey no trust, they are usefull to check the authenticity of the 1250 DNSKEY, i.e. they can be used as a hash. 1251 Singing the Zone File: The term used for the event where an 1252 administrator joyfully signs its zone file while producing melodic 1253 sound patterns. 1254 Signer: The system that has access to the private key material and 1255 signs the Resource Record sets in a zone. A signer may be 1256 configured to sign only parts of the zone e.g. only those RRsets 1257 for which existing signatures are about to expire. 1258 Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is 1259 used for signing all data in a zone. The fact that a key is a ZSK 1260 is only relevant to the signing tool. 1261 Zone Administrator: The 'role' that is responsible for signing a zone 1262 and publishing it on the primary authoritative server. 1264 Appendix B. Zone signing Key Rollover Howto 1266 Using the pre-published signature scheme and the most conservative 1267 method to assure oneself that data does not live in caches, here 1268 follows the "HOWTO". 1269 Step 0: The preparation: Create two keys and publish both in your key 1270 set. Mark one of the keys as "active" and the other as 1271 "published". Use the "active" key for signing your zone data. 1272 Store the private part of the "published" key, preferably off- 1273 line. 1274 The protocol does not provide for attributes to mark a key as 1275 active or published. This is something you have to do on your 1276 own, through the use of a notebook or key management tool. 1277 Step 1: Determine expiration: At the beginning of the rollover make a 1278 note of the highest expiration time of signatures in your zone 1279 file created with the current key marked as "active". 1280 Wait until the expiration time marked in Step 1 has passed 1281 Step 2: Then start using the key that was marked as "published" to 1282 sign your data i.e. mark it as "active". Stop using the key that 1283 was marked as "active", mark it as "rolled". 1284 Step 3: It is safe to engage in a new rollover (Step 1) after at 1285 least one "signature validity period". 1287 Appendix C. Typographic Conventions 1289 The following typographic conventions are used in this document: 1290 Key notation: A key is denoted by DNSKEYx, where x is a number or an 1291 identifier, x could be thought of as the key id. 1292 RRset notations: RRs are only denoted by the type. All other 1293 information - owner, class, rdata and TTL - is left out. Thus: 1294 "example.com 3600 IN A 192.168.1.1" is reduced to "A". RRsets are 1295 a list of RRs. A example of this would be: "A1, A2", specifying 1296 the RRset containing two "A" records. This could again be 1297 abbreviated to just "A". 1298 Signature notation: Signatures are denoted as RRSIGx(RRset), which 1299 means that RRset is signed with DNSKEYx. 1300 Zone representation: Using the above notation we have simplified the 1301 representation of a signed zone by leaving out all unnecessary 1302 details such as the names and by representing all data by "SOAx" 1303 SOA representation: SOAs are represented as SOAx, where x is the 1304 serial number. 1305 Using this notation the following signed zone: 1307 example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 1308 10 ; serial 1309 86400 ; refresh (1 day) 1310 7200 ; retry (2 hours) 1311 3600000 ; expire (1000 hours) 1312 172800 ) ; minimum (2 days) 1314 86400 RRSIG SOA 5 2 86400 20130522213204 ( 1315 20130422213204 14 example.net. 1316 cmL62SI6iAX46xGNQAdQ... ) 1317 86400 NS a.iana-servers.net. 1318 86400 NS b.iana-servers.net. 1319 86400 RRSIG NS 5 2 86400 20130507213204 ( 1320 20130407213204 14 example.net. 1321 SO5epiJei19AjXoUpFnQ ... ) 1322 86400 DNSKEY 256 3 5 ( 1323 EtRB9MP5/AvOuVO0I8XDxy0... ) 1324 ; key id = 14 1325 86400 DNSKEY 257 3 5 ( 1326 gsPW/Yy19GzYIY+Gnr8HABU... ) 1327 ; key id = 15 1328 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1329 20130422213204 14 example.net. 1330 J4zCe8QX4tXVGjV4e1r9... ) 1331 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1332 20130422213204 15 example.net. 1333 keVDCOpsSeDReyV6O... ) 1334 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 1335 20130407213204 14 example.net. 1336 obj3HEp1GjnmhRjX... ) 1337 a.example.net. 86400 IN TXT "A label" 1338 86400 RRSIG TXT 5 3 86400 20130507213204 ( 1339 20130407213204 14 example.net. 1340 IkDMlRdYLmXH7QJnuF3v... ) 1341 86400 NSEC b.example.com. TXT RRSIG NSEC 1342 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 1343 20130407213204 14 example.net. 1344 bZMjoZ3bHjnEz0nIsPMM... ) 1345 ... 1347 is reduced to the following representation: 1349 SOA10 1350 RRSIG14(SOA10) 1352 DNSKEY14 1353 DNSKEY15 1355 RRSIG14(KEY) 1356 RRSIG15(KEY) 1358 The rest of the zone data has the same signature as the SOA record, 1359 i.e a RRSIG created with DNSKEY 14. 1361 Appendix D. Document Details and Changes 1363 This section is to be removed by the RFC editor if and when the 1364 document is published. 1366 $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14 1367 2005/03/21 15:51:41 dnssec Exp $ 1369 D.1. draft-ietf-dnsop-dnssec-operational-practices-00 1371 Submission as working group document. This document is a modified 1372 and updated version of draft-kolkman-dnssec-operational-practices-00. 1374 D.2. draft-ietf-dnsop-dnssec-operational-practices-01 1376 changed the definition of "Bogus" to reflect the one in the protocol 1377 draft. 1379 Bad to Bogus 1381 Style and spelling corrections 1383 KSK - SEP mapping made explicit. 1385 Updates from Sam Weiler added 1387 D.3. draft-ietf-dnsop-dnssec-operational-practices-02 1389 Style and errors corrected. 1391 Added Automatic rollover requirements from I-D.ietf-dnsop-key- 1392 rollover-requirements. 1394 D.4. draft-ietf-dnsop-dnssec-operational-practices-03 1396 Added the definition of Key effectivity period and used that term 1397 instead of Key validity period. 1399 Modified the order of the sections, based on a suggestion by Rip 1400 Loomis. 1402 Included parts from RFC2541 [6]. Most of its ground was already 1403 covered. This document obsoletes RFC2541 [6]. Section 3.1.2 1404 deserves some review as it in contrast to RFC2541 does _not_ give 1405 recomendations about root-zone keys. 1407 added a paragraph to Section 4.4.4 1409 D.5. draft-ietf-dnsop-dnssec-operational-practices-04 1411 Somewhat more details added about the pre-publish KSK rollover. Also 1412 moved that subsection down a bit. 1414 Editorial and content nits that came in during wg last call were 1415 fixed. 1417 D.6. draft-ietf-dnsop-dnssec-operational-practices-05 1419 Applied some another set of comments that came in _after_ the the 1420 WGLC. 1422 Applied comments from Hilarie Orman and made a referece to RFC 3766. 1423 Deleted of a lot of key length discussion and took over the 1424 recommendations from RFC 3766. 1426 Reworked all the heading of the rollover figures 1428 D.7. draft-ietf-dnsop-dnssec-operational-practices-06 1430 One comment from Scott Rose applied. 1432 Marcos Sanz gave a lots of editorial nits. Almost all are 1433 incorporated. 1435 Authors' Addresses 1437 Olaf M. Kolkman 1438 NLnet Labs 1439 Kruislaan 419 1440 Amsterdam 1098 VA 1441 The Netherlands 1443 Email: olaf@nlnetlabs.nl 1444 URI: http://www.nlnetlabs.nl 1446 Miek Gieben 1447 NLnet Labs 1448 Kruislaan 419 1449 Amsterdam 1098 VA 1450 The Netherlands 1452 Email: miek@nlnetlabs.nl 1453 URI: http://www.nlnetlabs.nl 1455 Intellectual Property Statement 1457 The IETF takes no position regarding the validity or scope of any 1458 Intellectual Property Rights or other rights that might be claimed to 1459 pertain to the implementation or use of the technology described in 1460 this document or the extent to which any license under such rights 1461 might or might not be available; nor does it represent that it has 1462 made any independent effort to identify any such rights. Information 1463 on the procedures with respect to rights in RFC documents can be 1464 found in BCP 78 and BCP 79. 1466 Copies of IPR disclosures made to the IETF Secretariat and any 1467 assurances of licenses to be made available, or the result of an 1468 attempt made to obtain a general license or permission for the use of 1469 such proprietary rights by implementers or users of this 1470 specification can be obtained from the IETF on-line IPR repository at 1471 http://www.ietf.org/ipr. 1473 The IETF invites any interested party to bring to its attention any 1474 copyrights, patents or patent applications, or other proprietary 1475 rights that may cover technology that may be required to implement 1476 this standard. Please address the information to the IETF at 1477 ietf-ipr@ietf.org. 1479 Disclaimer of Validity 1481 This document and the information contained herein are provided on an 1482 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1483 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1484 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1485 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1486 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1487 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1489 Copyright Statement 1491 Copyright (C) The Internet Society (2005). This document is subject 1492 to the rights, licenses and restrictions contained in BCP 78, and 1493 except as set forth therein, the authors retain all their rights. 1495 Acknowledgment 1497 Funding for the RFC Editor function is currently provided by the 1498 Internet Society.