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