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