idnits 2.17.1 draft-ietf-dnsop-dnssec-operational-practices-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1305. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 2005) is 6974 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: '8' is defined on line 1053, 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 1750 (ref. '3') (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 2137 (ref. '5') (Obsoleted by RFC 3007) -- Obsolete informational reference (is this intentional?): RFC 2541 (ref. '7') (Obsoleted by RFC 4641) -- Obsolete informational reference (is this intentional?): RFC 3658 (ref. '8') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-08) exists of draft-hollenbeck-epp-secdns-07 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP O. Kolkman 3 Internet-Draft RIPE NCC 4 Expires: September 2, 2005 R. Gieben 5 NLnet Labs 6 March 2005 8 DNSSEC Operational Practices 9 draft-ietf-dnsop-dnssec-operational-practices-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 2, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes a set of practices for operating the DNS with 43 security extensions (DNSSEC). The target audience is zone 44 administrators deploying DNSSEC. 46 The document discusses operational aspects of using keys and 47 signatures in the DNS. It discusses issues as key generation, key 48 storage, signature generation, key rollover and related policies. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 4 54 1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 55 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 56 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 57 3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 58 3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 6 59 3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 7 60 3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 8 62 3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9 63 3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 10 65 4. Signature generation, Key Rollover and Related Policies . . . 11 66 4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 11 67 4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 11 68 4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 13 69 4.2.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13 70 4.2.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 17 71 4.2.3 Difference Between ZSK and KSK Rollovers . . . . . . . 18 72 4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 19 73 4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 19 74 4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 20 75 4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 20 76 4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 20 77 4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 21 78 4.4.1 Initial Key Exchanges and Parental Policies 79 Considerations . . . . . . . . . . . . . . . . . . . . 21 80 4.4.2 Storing Keys or Hashes? . . . . . . . . . . . . . . . 21 81 4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 22 82 4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 22 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 7.1 Normative References . . . . . . . . . . . . . . . . . . . 24 87 7.2 Informative References . . . . . . . . . . . . . . . . . . 24 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 89 A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 26 91 C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 26 92 D. Document Details and Changes . . . . . . . . . . . . . . . . . 29 93 D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 29 94 D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 29 95 D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 29 96 D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 29 97 D.5 draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 30 98 Intellectual Property and Copyright Statements . . . . . . . . 31 100 1. Introduction 102 During workshops and early operational deployment tests, operators 103 and system administrators gained experience about operating the DNS 104 with security extensions (DNSSEC). This document translates these 105 experiences into a set of practices for zone administrators. At the 106 time of writing, there exists very little experience with DNSSEC in 107 production environments; this document should therefore explicitly 108 not be seen as representing 'Best Current Practices'. 110 The procedures herein are focused on the maintenance of signed zones 111 (i.e. signing and publishing zones on authoritative servers). It is 112 intended that maintenance of zones such as resigning or key rollovers 113 be transparent to any verifying clients on the Internet. 115 The structure of this document is as follows. In Section 2 we 116 discuss the importance of keeping the "chain of trust" intact. 117 Aspects of key generation and storage of private keys are discussed 118 in Section 3; the focus in this section is mainly on the private part 119 of the key(s). Section 4 describes considerations concerning the 120 public part of the keys. Since these public keys appear in the DNS 121 one has to take into account all kinds of timing issues, which are 122 discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the 123 rollover, or which, of keys. Finally Section 4.4 discusses 124 considerations on how parents deal with their children's public keys 125 in order to maintain chains of trust. 127 The typographic conventions used in this document are explained in 128 Appendix C. 130 Since this is a document with operational suggestions and there are 131 no protocol specifications, the RFC2119 [4] language does not apply. 133 This document obsoletes RFC2541 [7] 135 1.1 The Use of the Term 'key' 137 It is assumed that the reader is familiar with the concept of 138 asymmetric keys on which DNSSEC is based (Public Key Cryptography 139 [11]). Therefore, this document will use the term 'key' rather 140 loosely. Where it is written that 'a key is used to sign data' it is 141 assumed that the reader understands that it is the private part of 142 the key-pair that is used for signing. It is also assumed that the 143 reader understands that the public part of the key-pair is published 144 in the DNSKEY resource record and that it is the public part that is 145 used in key-exchanges. 147 1.2 Time Definitions 149 In this document we will be using a number of time related terms. 150 The following definitions apply: 151 o "Signature validity period" 152 The period that a signature is valid. It starts at the time 153 specified in the signature inception field of the RRSIG RR and 154 ends at the time specified in the expiration field of the RRSIG 155 RR. 156 o "Signature publication period" 157 Time after which a signature (made with a specific key) is 158 replaced with a new signature (made with the same key). This 159 replacement takes place by publishing the relevant RRSIG in the 160 master zone file. 161 After one stopped publishing an RRSIG in a zone it may take a 162 while before the RRSIG has expired from caches and has actually 163 been removed from the DNS. 164 o "Key effectivity period" 165 The period which a key pair is expected to be effective. This 166 period is defined as the time between the first inception time 167 stamp and the last expiration date of any signature made with 168 this key. 169 The key effectivity period can span multiple signature validity 170 periods. 171 o "Maximum/Minimum Zone TTL" 172 The maximum or minimum value of the TTLs from the complete set 173 of RRs in a zone. 175 2. Keeping the Chain of Trust Intact 177 Maintaining a valid chain of trust is important because broken chains 178 of trust will result in data being marked as Bogus (as defined in [2] 179 section 5), which may cause entire (sub)domains to become invisible 180 to verifying clients. The administrators of secured zones have to 181 realize that their zone is, to their clients, part of a chain of 182 trust. 184 As mentioned in the introduction, the procedures herein are intended 185 to ensure maintenance of zones, such as resigning or key rollovers, 186 will be transparent to the verifying clients on the Internet. 188 Administrators of secured zones will have to keep in mind that data 189 published on an authoritative primary server will not be immediately 190 seen by verifying clients; it may take some time for the data to be 191 transfered to other secondary authoritative nameservers and clients 192 may be fetching data from caching non-authoritative servers. 194 For the verifying clients it is important that data from secured 195 zones can be used to build chains of trust regardless of whether the 196 data came directly from an authoritative server, a caching nameserver 197 or some middle box. Only by carefully using the available timing 198 parameters can a zone administrator assure that the data necessary 199 for verification can be obtained. 201 The responsibility for maintaining the chain of trust is shared by 202 administrators of secured zones in the chain of trust. This is most 203 obvious in the case of a 'key compromise' when a trade off between 204 maintaining a valid chain of trust and replacing the compromised keys 205 as soon as possible must be made. Then zone administrators will have 206 to make a trade off, between keeping the chain of trust intact - 207 thereby allowing for attacks with the compromised key - or to 208 deliberately break the chain of trust and making secured sub domains 209 invisible to security aware resolvers. Also see Section 4.3. 211 3. Keys Generation and Storage 213 This section describes a number of considerations with respect to the 214 security of keys. It deals with the generation, effectivity period, 215 size and storage of private keys. 217 3.1 Zone and Key Signing Keys 219 The DNSSEC validation protocol does not distinguish between DNSKEYs. 220 All DNSKEYs can be used during the validation. In practice operators 221 use Key Signing and Zone Signing Keys and use the so-called (Secure 222 Entry Point) SEP flag to distinguish between them during operations. 223 The dynamics and considerations are discussed below. 225 To make zone resigning and key rollover procedures easier to 226 implement, it is possible to use one or more keys as Key Signing Keys 227 (KSK). These keys will only sign the apex DNSKEY RR set in a zone. 228 Other keys can be used to sign all the RRsets in a zone and are 229 referred to as Zone Signing Keys (ZSK). In this document we assume 230 that KSKs are the subset of keys that are used for key exchanges with 231 the parent and potentially for configuration as trusted anchors - the 232 SEP keys. In this document we assume a one-to-one mapping between 233 KSK and SEP keys and we assume the SEP flag [1] to be set on all 234 KSKs. 236 3.1.1 Motivations for the KSK and ZSK Separation 238 Differentiating between the KSK and ZSK functions has several 239 advantages: 241 o No parent/child interaction is required when ZSKs are updated. 242 o The KSK can be made stronger (i.e. using more bits in the key 243 material). This has little operational impact since it is only 244 used to sign a small fraction of the zone data. Also when 245 verifying the KSK is only used to verify the zone's keyset. 246 o As the KSK is only used to sign a key set, which is most probably 247 updated less frequently than other data in the zone, it can be 248 stored separately from and in a safer location than the ZSK. 249 o A KSK can have a longer key effectivity period. 251 For almost any method of key management and zone signing the KSK is 252 used less frequently than the ZSK. Once a key set is signed with the 253 KSK all the keys in the key set can be used as ZSK. If a ZSK is 254 compromised, it can be simply dropped from the key set. The new key 255 set is then resigned with the KSK. 257 Given the assumption that for KSKs the SEP flag is set, the KSK can 258 be distinguished from a ZSK by examining the flag field in the DNSKEY 259 RR. If the flag field is an odd number it is a KSK. If it is an 260 even number it is a ZSK. 262 The zone-signing key can be used to sign all the data in a zone on a 263 regular basis. When a zone-signing key is to be rolled, no 264 interaction with the parent is needed. This allows for "Signature 265 Validity Periods" on the order of days. 267 The key-signing key is only to be used to sign the DNSKEY RRs in a 268 zone. If a key-signing key is to be rolled over, there will be 269 interactions with parties other than the zone administrator. These 270 can include the registry of the parent zone or administrators of 271 verifying resolvers that have the particular key configured as 272 trusted entry points. Hence, the key effectivity period of these 273 keys can and should be made much longer. Although, given a long 274 enough key, the Key Usage Time can be on the order of years we 275 suggest planning for a key effectivity of the order of a few months 276 so that a key rollover remains an operational routine. 278 3.1.2 KSKs for high level zones 280 Higher level zones are generally more sensitive than lower level 281 zones. Anyone controlling or breaking the security of a zone thereby 282 obtains authority over all of its sub domains (except in the case of 283 resolvers that have locally configured the public key of a sub 284 domain). Therefore, extra care should be taken with high level zones 285 and strong keys used. 287 The root zone is the most critical of all zones. Someone controlling 288 or compromising the security of the root zone would control the 289 entire DNS name space of all resolvers using that root zone (except 290 in the case of resolvers that have locally configured the public key 291 of a sub domain). Therefore, the utmost care must be taken in the 292 securing of the root zone. The strongest and most carefully handled 293 keys should be used. The root zone private key should always be kept 294 off line. 296 Many resolvers will start at a root server for their access to and 297 authentication of DNS data. Securely updating the trust anchors in 298 an enormous population of resolvers around the world will be 299 extremely difficult. 301 3.2 Randomness 303 Careful generation of all keys is a sometimes overlooked but 304 absolutely essential element in any cryptographically secure system. 305 The strongest algorithms used with the longest keys are still of no 306 use if an adversary can guess enough to lower the size of the likely 307 key space so that it can be exhaustively searched. Technical 308 suggestions for the generation of random keys will be found in 309 RFC1750 [3]. One should carefully assess if the random number 310 generator used during key generation adheres to these suggestions. 312 Keys with a long effectivity period are particularly sensitive as 313 they will represent a more valuable target and be subject to attack 314 for a longer time than short period keys. It is strongly recommended 315 that long term key generation occur off-line in a manner isolated 316 from the network via an air gap or, at a minimum, high level secure 317 hardware. 319 3.3 Key Effectivity Period 321 For various reasons keys in DNSSEC need to be changed once in a 322 while. The longer a key is in use, the greater the probability that 323 it will have been compromised through carelessness, accident, 324 espionage, or cryptanalysis. Furthermore when key rollovers are too 325 rare an event, they will not become part of the operational habit and 326 there is risk that nobody on-site will remember the procedure for 327 rollover when the need is there. 329 For Key Signing Keys a reasonable key effectivity period is 13 330 months, with the intent to replace them after 12 months. An intended 331 key effectivity period of a month is reasonable for Zone Signing 332 Keys. 334 Using these recommendations will lead to rollovers occurring 335 frequently enough to become part of 'operational habits'; the 336 procedure does not have to be reinvented every time a key is 337 replaced. 339 Key effectivity periods can be made very short, as in the order of a 340 few minutes. But when replacing keys one has to take the 341 considerations from Section 4.1 and Section 4.2 into account. 343 3.4 Key Algorithm 345 There are currently three different types of algorithms that can be 346 used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter 347 is fairly new and still needs to be standardized for usage in DNSSEC. 349 RSA has been developed in an open and transparent manner. As the 350 patent on RSA expired in 2000, its use is now also free. 352 DSA has been developed by NIST. The creation of signatures is 353 roughly done at the same speed as with RSA, but is 10 to 40 times as 354 slow for verification [11]. 356 We suggest the use of RSA/SHA-1 as the preferred algorithm for the 357 key. The current known attacks on RSA can be defeated by making your 358 key longer. As the MD5 hashing algorithm is showing (theoretical) 359 cracks, we recommend the usage of SHA1. 361 In 2005 some discoveries were made that SHA-1 also has some 362 weaknesses. Currently SHA-1 is strong enough for DNSSEC. It is 363 expected that a new hashing algorithm is rolled out, before any 364 attack becomes practical. 366 3.5 Key Sizes 368 When choosing key sizes, zone administrators will need to take into 369 account how long a key will be used and how much data will be signed 370 during the key publication period. It is hard to give precise 371 recommendations but Lenstra and Verheul [10] supplied the following 372 table with lower bound estimates for cryptographic key sizes. Their 373 recommendations are based on a set of explicitly formulated parameter 374 settings, combined with existing data points about cryptographic 375 systems. For details we refer to the original paper. 377 Year RSA Key Sizes Year RSA Key Sizes 379 2000 952 2015 1613 380 2001 990 2016 1664 381 2002 1028 2017 1717 382 2003 1068 2018 1771 383 2004 1108 2019 1825 385 2005 1149 2020 1881 386 2006 1191 2021 1937 387 2007 1235 2022 1995 388 2008 1279 2023 2054 389 2009 1323 2024 2113 391 2026 2236 2025 2174 392 2010 1369 2027 2299 393 2011 1416 2028 2362 394 2012 1464 2029 2427 395 2013 1513 396 2014 1562 398 For example, should you wish your key to last three years from 2003, 399 check the RSA key size values for 2006 in this table. In this case 400 it should be at least 1191 bits. 402 Please keep in mind that nobody can see into the future, and that 403 these key lengths are only provided here as a guide. 405 When determining a key size one should take into account that a large 406 key will be slower during generation and verification. For RSA, 407 verification, the most common operation, will vary roughly with the 408 square of the key size; signing will vary with the cube of the key 409 size length; and key generation will vary with the fourth power of 410 the modulus length. Besides larger keys will increase the sizes of 411 the RRSIG and DNSKEY records and will therefore increase the chance 412 of DNS UDP packet overflow. Also see Section 3.1.1 for a discussion 413 of how keys serving different roles (ZSK v. KSK) may need different 414 key strengths. 416 3.6 Private Key Storage 418 It is recommended that, where possible, zone private keys and the 419 zone file master copy be kept and used in off-line, non-network 420 connected, physically secure machines only. Periodically an 421 application can be run to add authentication to a zone by adding 422 RRSIG and NSEC RRs. Then the augmented file can be transferred, 423 perhaps by sneaker-net, to the networked zone primary server machine. 425 The ideal situation is to have a one way information flow to the 426 network to avoid the possibility of tampering from the network. 427 Keeping the zone master file on-line on the network and simply 428 cycling it through an off-line signer does not do this. The on-line 429 version could still be tampered with if the host it resides on is 430 compromised. For maximum security, the master copy of the zone file 431 should be off net and should not be updated based on an unsecured 432 network mediated communication. 434 In general keeping a zone-file off-line will not be practical and the 435 machines on which zone files are maintained will be connected to a 436 network. Operators are advised to take security measures to shield 437 unauthorized access to the master copy. 439 For dynamically updated secured zones [5] both the master copy and 440 the private key that is used to update signatures on updated RRs will 441 need to be on line. 443 4. Signature generation, Key Rollover and Related Policies 445 4.1 Time in DNSSEC 447 Without DNSSEC all times in DNS are relative. The SOA RR's refresh, 448 retry and expiration timers are counters that are used to determine 449 the time elapsed after a slave server synchronized (or tried to 450 synchronize) with a master server. The Time to Live (TTL) value and 451 the SOA RR minimum TTL parameter [6] are used to determine how long a 452 forwarder should cache data after it has been fetched from an 453 authoritative server. By using a signature validity period, DNSSEC 454 introduces the notion of an absolute time in the DNS. Signatures in 455 DNSSEC have an expiration date after which the signature is marked as 456 invalid and the signed data is to be considered Bogus. 458 4.1.1 Time Considerations 460 Because of the expiration of signatures, one should consider the 461 following: 462 o We suggest the Maximum Zone TTL of your zone data to be a fraction 463 of your signature validity period. 464 If the TTL would be of similar order as the signature validity 465 period, then all RRsets fetched during the validity period 466 would be cached until the signature expiration time. Section 467 7.1 of [2] suggests that "the resolver may use the time 468 remaining before expiration of the signature validity period of 469 a signed RRset as an upper bound for the TTL". As a result 470 query load on authoritative servers would peak at signature 471 expiration time, as this is also the time at which records 472 simultaneously expire from caches. 473 To avoid query load peaks we suggest the TTL on all the RRs in 474 your zone to be at least a few times smaller than your 475 signature validity period. 476 o We suggest the signature publication period to be at least one 477 maximum TTL smaller than the signature validity period. 478 Resigning a zone shortly before the end of the signature 479 validity period may cause simultaneous expiration of data from 480 caches. This in turn may lead to peaks in the load on 481 authoritative servers. 482 o We suggest the minimum zone TTL to be long enough to both fetch 483 and verify all the RRs in the authentication chain. A low TTL 484 could cause two problems: 485 1. During validation, some data may expire before the 486 validation is complete. The validator should be able to keep 487 all data, until is completed. This applies to all RRs needed 488 to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the 489 final answers i.e. the RR set that is returned for the initial 490 query. 491 2. Frequent verification causes load on recursive nameservers. 492 Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from 493 caching. The TTL on those should be relatively long. 494 o Slave servers will need to be able to fetch newly signed zones 495 well before the RRSIGs in the zone served by the slave server pass 496 their signature expiration time. 497 When a slave server is out of sync with its master and data in 498 a zone is signed by expired signatures it may be better for the 499 slave server not to give out any answer. 500 Normally a slave server that is not able to contact a master 501 server for an extended period will expire a zone. When that 502 happens the zone will not respond on queries. The time of 503 expiration is set in the SOA record and is relative to the last 504 successful refresh between the master and the slave server. 505 There exists no coupling between the signature expiration of 506 RRSIGs in the zone and the expire parameter in the SOA. 507 If the server serves a DNSSEC zone than it may well happen that 508 the signatures expire well before the SOA expiration timer 509 counts down to zero. It is not possible to completely prevent 510 this from happening by tweaking the SOA parameters. 511 However, the effects can be minimized where the SOA expiration 512 time is equal or smaller than the signature validity period. 513 The consequence of an authoritative server not being able to 514 update a zone, whilst that zone includes expired signatures, is 515 that non-secure resolvers will continue to be able to resolve 516 data served by the particular slave servers while security 517 aware resolvers will experience problems because of answers 518 being marked as Bogus. 520 We suggest the SOA expiration timer being approximately one 521 third or one fourth of the signature validity period. It will 522 allow problems with transfers from the master server to be 523 noticed before the actual signature time out. 524 We also suggest that operators of nameservers that supply 525 secondary services develop 'watch dogs' to spot upcoming 526 signature expirations in zones they slave, and take appropriate 527 action. 528 When determining the value for the expiration parameter one has 529 to take the following into account: What are the chances that 530 all my secondary zones expire; How quickly can I reach an 531 administrator of secondary servers to load a valid zone? All 532 these arguments are not DNSSEC specific but may influence the 533 choice of your signature validity intervals. 535 4.2 Key Rollovers 537 A DNSSEC key cannot be used forever (see Section 3.3). So key 538 rollovers -- or supercessions, as they are sometimes called -- are a 539 fact of life when using DNSSEC. Zone administrators who are in the 540 process of rolling their keys have to take into account that data 541 published in previous versions of their zone still lives in caches. 542 When deploying DNSSEC, this becomes an important consideration; 543 ignoring data that may be in caches may lead to loss of service for 544 clients. 546 The most pressing example of this is when zone material signed with 547 an old key is being validated by a resolver which does not have the 548 old zone key cached. If the old key is no longer present in the 549 current zone, this validation fails, marking the data Bogus. 550 Alternatively, an attempt could be made to validate data which is 551 signed with a new key against an old key that lives in a local cache, 552 also resulting in data being marked Bogus. 554 4.2.1 Zone-signing Key Rollovers 556 For zone-signing key rollovers there are two ways to make sure that 557 during the rollover data still cached can be verified with the new 558 key sets or newly generated signatures can be verified with the keys 559 still in caches. One schema, described in Section 4.2.1.2, uses 560 double signatures; the other uses key pre-publication 561 (Section 4.2.1.1). The pros, cons and recommendations are described 562 in Section 4.2.1.3. 564 4.2.1.1 Pre-publish key set Rollover 566 This section shows how to perform a ZSK rollover without the need to 567 sign all the data in a zone twice - the so-called "pre-publish 568 rollover".This method has advantages in the case of a key compromise. 569 If the old key is compromised, the new key has already been 570 distributed in the DNS. The zone administrator is then able to 571 quickly switch to the new key and remove the compromised key from the 572 zone. Another major advantage is that the zone size does not double, 573 as is the case with the double signature ZSK rollover. A small 574 "HOWTO" for this kind of rollover can be found in Appendix B. 576 normal pre-roll roll after 578 SOA0 SOA1 SOA2 SOA3 579 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 581 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 582 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 583 DNSKEY11 DNSKEY11 584 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 585 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 587 normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. 588 DNSKEY 10 is used to sign all the data of the zone, the zone- 589 signing key. 590 pre-roll: DNSKEY 11 is introduced into the key set. Note that no 591 signatures are generated with this key yet, but this does not 592 secure against brute force attacks on the public key. The minimum 593 duration of this pre-roll phase is the time it takes for the data 594 to propagate to the authoritative servers plus TTL value of the 595 key set. This equates to two times the Maximum Zone TTL. 596 roll: At the rollover stage (SOA serial 2) DNSKEY 11 is used to sign 597 the data in the zone exclusively (i.e. all the signatures from 598 DNSKEY 10 are removed from the zone). DNSKEY 10 remains published 599 in the key set. This way data that was loaded into caches from 600 version 1 of the zone can still be verified with key sets fetched 601 from version 2 of the zone. 602 The minimum time that the key set including DNSKEY 10 is to be 603 published is the time that it takes for zone data from the 604 previous version of the zone to expire from old caches i.e. the 605 time it takes for this zone to propagate to all authoritative 606 servers plus the Maximum Zone TTL value of any of the data in the 607 previous version of the zone. 608 after: DNSKEY 10 is removed from the zone. The key set, now only 609 containing DNSKEY 1 and DNSKEY 11 is resigned with the DNSKEY 1. 611 The above scheme can be simplified by always publishing the "future" 612 key immediately after the rollover. The scheme would look as follows 613 (we show two rollovers); the future key is introduced in "after" as 614 DNSKEY 12 and again a newer one, numbered 13, in "2nd after": 616 normal roll after 618 SOA0 SOA2 SOA3 619 RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) 621 DNSKEY1 DNSKEY1 DNSKEY1 622 DNSKEY10 DNSKEY10 DNSKEY11 623 DNSKEY11 DNSKEY11 DNSKEY12 624 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 625 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 627 2nd roll 2nd after 629 SOA4 SOA5 630 RRSIG12(SOA4) RRSIG12(SOA5) 632 DNSKEY1 DNSKEY1 633 DNSKEY11 DNSKEY12 634 DNSKEY12 DNSKEY13 635 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 636 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 638 Note that the key introduced after the rollover is not used for 639 production yet; the private key can thus be stored in a physically 640 secure manner and does not need to be 'fetched' every time a zone 641 needs to be signed. 643 4.2.1.2 Double Signature Zone-signing Key Rollover 645 This section shows how to perform a ZSK key rollover using the double 646 zone data signature scheme, aptly named "double sig rollover". 648 During the rollover stage the new version of the zone file will need 649 to propagate to all authoritative servers and the data that exists in 650 (distant) caches will need to expire, requiring at least the maximum 651 Zone TTL. 653 normal roll after 655 SOA0 SOA1 SOA2 656 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 657 RRSIG11(SOA1) 659 DNSKEY1 DNSKEY1 DNSKEY1 660 DNSKEY10 DNSKEY10 DNSKEY11 661 DNSKEY11 662 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 663 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 664 RRSIG11(DNSKEY) 666 normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. 667 DNSKEY 10 is used to sign all the data of the zone, the zone- 668 signing key. 669 roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced 670 into the key set and all the data in the zone is signed with 671 DNSKEY 10 and DNSKEY 11. The rollover period will need to exist 672 until all data from version 0 of the zone has expired from remote 673 caches. This will take at least the maximum Zone TTL of version 0 674 of the zone. 675 after: DNSKEY 10 is removed from the zone. All the signatures from 676 DNSKEY 10 are removed from the zone. The key set, now only 677 containing DNSKEY 11, is resigned with DNSKEY 1. 679 At every instance, RRSIGs from the previous version of the zone can 680 be verified with the DNSKEY RRset from the current version and the 681 other way around. The data from the current version can be verified 682 with the data from the previous version of the zone. The duration of 683 the rollover phase and the period between rollovers should be at 684 least the "Maximum Zone TTL". 686 Making sure that the rollover phase lasts until the signature 687 expiration time of the data in version 0 of the zone is recommended. 688 This way all caches are cleared of the old signatures. However, this 689 date could be considerably longer than the Maximum Zone TTL, making 690 the rollover a lengthy procedure. 692 Note that in this example we assumed that the zone was not modified 693 during the rollover. New data can be introduced in the zone as long 694 as it is signed with both keys. 696 4.2.1.3 Pros and Cons of the Schemes 697 Pre-publish-key set rollover: This rollover does not involve signing 698 the zone data twice. Instead, before the actual rollover, the new 699 key is published in the key set and thus available for 700 cryptanalysis attacks. A small disadvantage is that this process 701 requires four steps. Also the pre-publish scheme involves more 702 parental work when used for KSK rollovers as explained in 703 Section 4.2. 704 Double signature rollover: The drawback of this signing scheme is 705 that during the rollover the number of signatures in your zone 706 doubles, this may be prohibitive if you have very big zones. An 707 advantage is that it only requires three steps. 709 4.2.2 Key-signing Key Rollovers 711 For the rollover of a key-signing key the same considerations as for 712 the rollover of a zone-signing key apply. However we can use a 713 double signature scheme to guarantee that old data (only the apex key 714 set) in caches can be verified with a new key set and vice versa. 716 Since only the key set is signed with a KSK, zone size considerations 717 do not apply. 719 normal roll after 721 SOA0 SOA1 SOA2 722 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) 724 DNSKEY1 DNSKEY1 DNSKEY2 725 DNSKEY2 726 DNSKEY10 DNSKEY10 DNSKEY10 727 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) 728 RRSIG2 (DNSKEY) 729 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) 731 normal: Version 0 of the zone. The parental DS points to DNSKEY1. 732 Before the rollover starts the child will have to verify what the 733 TTL is of the DS RR that points to DNSKEY1 - it is needed during 734 the rollover and we refer to the value as TTL_DS. 735 roll: During the rollover phase the zone administrator generates a 736 second KSK, DNSKEY2. The key is provided to the parent and the 737 child will have to wait until a new DS RR has been generated that 738 points to DNSKEY2. After that DS RR has been published on all 739 servers authoritative for the parent's zone, the zone 740 administrator has to wait at least TTL_DS to make sure that the 741 old DS RR has expired from caches. 743 after: DNSKEY1 has been removed. 745 The scenario above puts the responsibility for maintaining a valid 746 chain of trust with the child. It also is based on the premises that 747 the parent only has one DS RR (per algorithm) per zone. An 748 alternative mechanism has been considered. Using an established 749 trust relation, the interaction can be performed in-band, and the 750 removal of the keys by the child can possibly be signaled by the 751 parent. In this mechanism there are periods where there are two DS 752 RRs at the parent. Since at the moment of writing the protocol for 753 this interaction has not been developed further discussion is out of 754 scope for this document. 756 4.2.3 Difference Between ZSK and KSK Rollovers 758 Note that KSK rollovers and ZSK rollovers are different. A zone-key 759 rollover can be handled in two different ways: pre-publish (Section 760 Section 4.2.1.1) and double signature (Section Section 4.2.1.2). 762 As the KSK is used to validate the key set and because the KSK is not 763 changed during a ZSK rollover, a cache is able to validate the new 764 key set of the zone. The pre-publish method would work for a KSK 765 rollover. The record that are to be pre-published are the parental 766 DS RRs. 768 The pre-publish method has some drawbacks. We first describe the 769 rollover scheme and then indicate these drawbacks. 771 normal pre-roll roll after 772 Parent: 773 SOA0 SOA1 SOA2 SOA3 774 RRSIGpar(SOA0) RRSIGpar(SOA1) RRSIGpar(SOA2) RRSIGpar(SOA3) 775 DS1 DS1 DS1 DS2 776 DS2 DS2 777 RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) 779 Child: 780 SOA0 SOA0 SOA1 SOA1 781 RRSIG10(SOA0) RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA1) 783 DNSKEY1 DNSKEY1 DNSKEY2 DNSKEY2 785 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY10 786 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 787 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) 789 When the child zone wants to roll it notifies the parent during the 790 pre-roll phase and submits the new key to the parent. The parent 791 publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2 respectively. 792 During the rollover, which can take place as soon as the new DS set 793 propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2. 794 Immediately after that it can notify the parent that the old DS 795 record can be deleted. 797 The drawbacks of these scheme are that during the pre-roll phase the 798 parent cannot verify the match between the DS RR and DNSKEY2 using 799 the DNS. Besides, we introduce a "security lame" DS record 800 Section 4.4.3. Finally the child-parent interaction consists of two 801 steps. The "double signature" method only needs one interaction. 803 4.2.4 Automated Key Rollovers 805 As keys must be renewed periodically, there is some motivation to 806 automate the rollover process. Consider that: 808 o ZSK rollovers are easy to automate as only the local zone is 809 involved. 810 o A KSK rollover needs interaction between the parent and child. 811 Data exchange is needed to provide the new keys to the parent, 812 consequently, this data must be authenticated and integrity must 813 be guaranteed in order to avoid attacks on the rollover. 814 o All time and TTL considerations presented in Section 4.2 apply to 815 an automated rollover. 817 4.3 Planning for Emergency Key Rollover 819 This section deals with preparation for a possible key compromise. 820 Our advice is to have a documented procedure ready for when a key 821 compromise is suspected or confirmed. 823 When the private material of one of your keys is compromised it can 824 be used for as long as a valid authentication chain exists. An 825 authentication chain remains intact for: 826 o as long as a signature over the compromised key in the 827 authentication chain is valid, 828 o as long as a parental DS RR (and signature) points to the 829 compromised key, 830 o as long as the key is anchored in a resolver and is used as a 831 starting point for validation. (This is generally the hardest to 832 update.) 834 While an authentication chain to your compromised key exists, your 835 name-space is vulnerable to abuse by anyone who has obtained 836 illegitimate possession of the key.Zone operators have to make a 837 trade off if the abuse of the compromised key is worse than having 838 data in caches that cannot be validated. If the zone operator 839 chooses to break the authentication chain to the compromised key, 840 data in caches signed with this key cannot be validated. However, if 841 the zone administrator chooses to take the path of a regular roll- 842 over, the malicious key holder can spoof data so that it appears to 843 be valid. Note that this kind of attack is more likely to occur in a 844 localized part of the network topology i.e. downstream from where the 845 spoof takes place. 847 4.3.1 KSK Compromise 849 When the KSK has been compromised the parent must be notified as soon 850 as possible using secure means. The key set of the zone should be 851 resigned as soon as possible. Care must be taken to not break the 852 authentication chain. The local zone can only be resigned with the 853 new KSK after the parent's zone has created and reloaded its zone 854 with the DS created from the new KSK. Before this update takes place 855 it would be best to drop the security status of a zone all together: 856 the parent removes the DS of the child at the next zone update. 857 After that the child can be made secure again. 859 An additional danger of a key compromise is that the compromised key 860 can be used to facilitate a legitimate DNSKEY/DS and/or nameserver 861 rollover at the parent. When that happens the domain can be in 862 dispute. An authenticated out of band and secure notify mechanism to 863 contact a parent is needed in this case. 865 4.3.2 ZSK Compromise 867 Primarily because there is no parental interaction required when a 868 ZSK is compromised, the situation is less severe than with with a KSK 869 compromise. The zone must still be resigned with a new ZSK as soon 870 as possible. As this is a local operation and requires no 871 communication between the parent and child this can be achieved 872 fairly quickly. However, one has to take into account that just as 873 with a normal rollover the immediate disappearance from the old 874 compromised key may lead to verification problems. The pre- 875 publication scheme as discussed above minimizes such problems. 877 4.3.3 Compromises of Keys Anchored in Resolvers 879 A key can also be pre-configured in resolvers. For instance, if 880 DNSSEC is successfully deployed the root key may be pre-configured in 881 most security aware resolvers. 883 If trust-anchor keys are compromised, the resolvers using these keys 884 should be notified of this fact. Zone administrators may consider 885 setting up a mailing list to communicate the fact that a SEP key is 886 about to be rolled over. This communication will of course need to 887 be authenticated e.g. by using digital signatures. 889 End-users faced with the task of updating an anchored key should 890 always validate the new key. New keys should be authenticated out of 891 the DNS, for example, looking them up on an SSL secured announcement 892 website. 894 4.4 Parental Policies 896 4.4.1 Initial Key Exchanges and Parental Policies Considerations 898 The initial key exchange is always subject to the policies set by the 899 parent (or its registry). When designing a key exchange policy one 900 should take into account that the authentication and authorization 901 mechanisms used during a key exchange should be as strong as the 902 authentication and authorization mechanisms used for the exchange of 903 delegation information between parent and child. I.e. there is no 904 implicit need in DNSSEC to make the authentication process stronger 905 than it was in DNS. 907 Using the DNS itself as the source for the actual DNSKEY material, 908 with an off-band check on the validity of the DNSKEY, has the benefit 909 that it reduces the chances of user error. A parental DNSKEY 910 download tool can make use of the SEP bit [1] to select the proper 911 key from a DNSSEC key set; thereby reducing the chance that the wrong 912 DNSKEY is sent. It can validate the self-signature over a key; 913 thereby verifying the ownership of the private key material. 914 Fetching the DNSKEY from the DNS ensures that the chain of trust 915 remains intact once the parent publishes the DS RR indicating the 916 child is secure. 918 Note: the off-band verification is still needed when the key-material 919 is fetched via the DNS. The parent can never be sure whether the 920 DNSKEY RRs have been spoofed or not. 922 4.4.2 Storing Keys or Hashes? 924 When designing a registry system one should consider which of the 925 DNSKEYs and/or the corresponding DSs to store. Since a child zone 926 might wish to have a DS published using a message digest algorithm 927 not yet understood by the registry, the registry can't count on being 928 able to generate the DS record from a raw DNSKEY. Thus, we recommend 929 that registry system at least support storing DS records. 931 It may also be useful to store DNSKEYs, since having them may help 932 during troubleshooting and, so long as the child's chosen message 933 digest is supported, the overhead of generating DS records from them 934 is minimal. Having an out-of-band mechanism, such as a Whois 935 database, to find out which keys are used to generate DS Resource 936 Records for specific owners and/or zones may also help with 937 troubleshooting. 939 The storage considerations also relate the design of the customer 940 interface and the method by which data is transfered between 941 registrant and registry; Will the child zone owner be able to upload 942 DS RRs with unknown hash algorithms or does the interface only allows 943 DNSKEYs? In the registry-registrar model one can use the DNSSEC EPP 944 protocol extensions [9] which allows transfer of DS RRs and 945 optionally DNSKEY RRs. 947 4.4.3 Security Lameness 949 Security Lameness is defined as what happens when a parent has a DS 950 RR pointing to a non-existing DNSKEY RR. During key exchange a 951 parent should make sure that the child's key is actually configured 952 in the DNS before publishing a DS RR in its zone. Failure to do so 953 could cause the child's zone being marked as Bogus. 955 Child zones should be very careful removing DNSKEY material, 956 specifically SEP keys, for which a DS RR exists. 958 Once a zone is "security lame", a fix (e.g. removing a DS RR) will 959 take time to propagate through the DNS. 961 4.4.4 DS Signature Validity Period 963 Since the DS can be replayed as long as it has a valid signature, a 964 short signature validity period over the DS minimizes the time a 965 child is vulnerable in the case of a compromise of the child's 966 KSK(s). A signature validity period that is too short introduces the 967 possibility that a zone is marked Bogus in case of a configuration 968 error in the signer. There may not be enough time to fix the 969 problems before signatures expire. Something as mundane as operator 970 unavailability during weekends shows the need for DS signature 971 validity periods longer than 2 days. We recommend the minimum for a 972 DS signature validity period of a few days. 974 The maximum signature validity period of the DS record depends on how 975 long child zones are willing to be vulnerable after a key compromise. 976 Other considerations, such as how often the zone is (re)signed can 977 also be taken into account. 979 We consider a signature validity period of around one week to be a 980 good compromise between the operational constraints of the parent and 981 minimizing damage for the child. 983 In addition to the signature validity period, which sets a lower 984 bound on the amount of times the zone owner will need to sign the 985 zone data and which sets an upper bound to the time a child is 986 vulnerable after key compromise, there is the TTL value on the DS 987 RRs. By lowering the TTL, the authoritative servers will see more 988 queries, on the other hand a low TTL increases the speed with which 989 new DS RRs propagate through the DNS. As argued in Section 4.1.1, 990 the TTL should be a fraction of the signature validity period. 992 5. Security Considerations 994 DNSSEC adds data integrity to the DNS. This document tries to assess 995 the operational considerations to maintain a stable and secure DNSSEC 996 service. Not taking into account the 'data propagation' properties 997 in the DNS will cause validation failures and may make secured zones 998 unavailable to security aware resolvers. 1000 6. Acknowledgments 1002 Most of the ideas in this draft were the result of collective efforts 1003 during workshops, discussions and try outs. 1005 At the risk of forgetting individuals who were the original 1006 contributors of the ideas we would like to acknowledge people who 1007 were actively involved in the compilation of this document. In 1008 random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael 1009 Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette 1010 Olivier Courtay, Sam Weiler, Jelte Jansen and Niall O'Reilly. 1012 Some material in this document has been shamelessly copied from 1013 RFC2541 [7] by Donald Eastlake. 1015 Mike StJohns designed the key exchange between parent and child 1016 mentioned in the last paragraph of Section 4.2.2 1018 Section 4.2.4 was supplied by G. Guette and O. Courtay. 1020 Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of 1021 the spelling and style issues. 1023 Kolkman and Gieben take the blame for introducing all miscakes(SIC). 1025 7. References 1026 7.1 Normative References 1028 [1] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY 1029 (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", 1030 RFC 3757, May 2004. 1032 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1033 "DNS Security Introduction and Requirements", RFC 4033, 1034 March 2005. 1036 7.2 Informative References 1038 [3] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 1039 Recommendations for Security", RFC 1750, December 1994. 1041 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1042 Levels", BCP 14, RFC 2119, March 1997. 1044 [5] Eastlake, D., "Secure Domain Name System Dynamic Update", 1045 RFC 2137, April 1997. 1047 [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1048 RFC 2308, March 1998. 1050 [7] Eastlake, D., "DNS Security Operational Considerations", 1051 RFC 2541, March 1999. 1053 [8] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", 1054 RFC 3658, December 2003. 1056 [9] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 1057 Mapping for the Extensible Provisioning Protocol (EPP)", 1058 draft-hollenbeck-epp-secdns-07 (work in progress), March 2005. 1060 [10] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1061 Sizes", The Journal of Cryptology 14 (255-293), 2001. 1063 [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and 1064 Source Code in C", 1996. 1066 Authors' Addresses 1068 Olaf M. Kolkman 1069 RIPE NCC 1070 Singel 256 1071 Amsterdam 1016 AB 1072 The Netherlands 1074 Phone: +31 20 535 4444 1075 Email: olaf@ripe.net 1076 URI: http://www.ripe.net/ 1078 Miek Gieben 1079 NLnet Labs 1080 Kruislaan 419 1081 Amsterdam 1098 VA 1082 The Netherlands 1084 Email: miek@nlnetlabs.nl 1085 URI: http://www.nlnetlabs.nl 1087 Appendix A. Terminology 1089 In this document there is some jargon used that is defined in other 1090 documents. In most cases we have not copied the text from the 1091 documents defining the terms but given a more elaborate explanation 1092 of the meaning. Note that these explanations should not be seen as 1093 authoritative. 1095 Anchored Key: A DNSKEY configured in resolvers around the globe. 1096 This key is hard to update, hence the term anchored. 1097 Bogus: Also see Section 5 of [2]. An RRset in DNSSEC is marked 1098 "Bogus" when a signature of a RRset does not validate against a 1099 DNSKEY. 1100 Key-Signing Key or KSK: A Key-Signing Key (KSK) is a key that is used 1101 exclusively for signing the apex key set. The fact that a key is 1102 a KSK is only relevant to the signing tool. 1103 Private and Public Keys: DNSSEC secures the DNS through the use of 1104 public key cryptography. Public key cryptography is based on the 1105 existence of two keys, a public key and a private key. The public 1106 keys are published in the DNS by use of the DNSKEY Resource Record 1107 (DNSKEY RR). Private keys should remain private. 1108 Key Rollover: A key rollover (also called key supercession in some 1109 environments) is the act of replacing one key pair by another at 1110 the end of a key effectivity period. 1112 Secure Entry Point key or SEP Key: A KSK that has a parental DS 1113 record pointing to it. Note: this is not enforced in the 1114 protocol. A SEP Key with no parental DS is security lame. 1115 Singing the Zone File: The term used for the event where an 1116 administrator joyfully signs its zone file while producing melodic 1117 sound patterns. 1118 Signer: The system that has access to the private key material and 1119 signs the Resource Record sets in a zone. A signer may be 1120 configured to sign only parts of the zone e.g. only those RRsets 1121 for which existing signatures are about to expire. 1122 Zone-Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is 1123 used for signing all data in a zone. The fact that a key is a ZSK 1124 is only relevant to the signing tool. 1125 Zone Administrator: The 'role' that is responsible for signing a zone 1126 and publishing it on the primary authoritative server. 1128 Appendix B. Zone-signing Key Rollover Howto 1130 Using the pre-published signature scheme and the most conservative 1131 method to assure oneself that data does not live in caches here 1132 follows the "HOWTO". 1133 Step 0: The preparation: Create two keys and publish both in your key 1134 set. Mark one of the keys as "active" and the other as 1135 "published". Use the "active" key for signing your zone data. 1136 Store the private part of the "published" key, preferably off- 1137 line. 1138 The protocol does not provide for attributes to mark a key as 1139 active or published. This is something you have to do on your 1140 own, through the use of a notebook or key management tool. 1141 Step 1: Determine expiration: At the beginning of the rollover make a 1142 note of the highest expiration time of signatures in your zone 1143 file created with the current key marked as "active". 1144 Wait until the expiration time marked in Step 1 has passed 1145 Step 2: Then start using the key that was marked as "published" to 1146 sign your data i.e. mark it as "active". Stop using the key that 1147 was marked as "active", mark it as "rolled". 1148 Step 3: It is safe to engage in a new rollover (Step 1) after at 1149 least one "signature validity period". 1151 Appendix C. Typographic Conventions 1153 The following typographic conventions are used in this document: 1154 Key notation: A key is denoted by KEYx, where x is a number, x could 1155 be thought of as the key id. 1157 RRset notations: RRs are only denoted by the type. All other 1158 information - owner, class, rdata and TTL - is left out. Thus: 1159 "example.com 3600 IN A 192.168.1.1" is reduced to "A". RRsets are 1160 a list of RRs. A example of this would be: "A1,A2", specifying 1161 the RRset containing two "A" records. This could again be 1162 abbreviated to just "A". 1163 Signature notation: Signatures are denoted as RRSIGx(RRset), which 1164 means that RRset is signed with DNSKEYx. 1165 Zone representation: Using the above notation we have simplified the 1166 representation of a signed zone by leaving out all unnecessary 1167 details such as the names and by representing all data by "SOAx" 1168 SOA representation: SOA's are represented as SOAx, where x is the 1169 serial number. 1170 Using this notation the following zone: 1172 example.net. 600 IN SOA ns.example.net. bert.example.net. ( 1173 10 ; serial 1174 450 ; refresh (7 minutes 30 seconds) 1175 600 ; retry (10 minutes) 1176 345600 ; expire (4 days) 1177 300 ; minimum (5 minutes) 1178 ) 1179 600 RRSIG SOA 5 2 600 20130522213204 ( 1180 20130422213204 14 example.net. 1181 cmL62SI6iAX46xGNQAdQ... ) 1182 600 NS a.iana-servers.net. 1183 600 NS b.iana-servers.net. 1184 600 RRSIG NS 5 2 600 20130507213204 ( 1185 20130407213204 14 example.net. 1186 SO5epiJei19AjXoUpFnQ ... ) 1187 3600 DNSKEY 256 3 5 ( 1188 EtRB9MP5/AvOuVO0I8XDxy0... 1189 ) ; key id = 14 1190 3600 DNSKEY 256 3 5 ( 1191 gsPW/Yy19GzYIY+Gnr8HABU... 1192 ) ; key id = 15 1193 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 1194 20130422213204 14 example.net. 1195 J4zCe8QX4tXVGjV4e1r9... ) 1196 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 1197 20130422213204 15 example.net. 1198 keVDCOpsSeDReyV6O... ) 1199 600 RRSIG NSEC 5 2 600 20130507213204 ( 1200 20130407213204 14 example.net. 1201 obj3HEp1GjnmhRjX... ) 1202 a.example.net. 600 IN TXT "A label" 1203 600 RRSIG TXT 5 3 600 20130507213204 ( 1204 20130407213204 14 example.net. 1205 IkDMlRdYLmXH7QJnuF3v... ) 1206 600 NSEC b.example.com. TXT RRSIG NSEC 1207 600 RRSIG NSEC 5 3 600 20130507213204 ( 1208 20130407213204 14 example.net. 1209 bZMjoZ3bHjnEz0nIsPMM... ) 1211 ... 1213 is reduced to the following representation: 1215 SOA10 1216 RRSIG14(SOA10) 1218 DNSKEY14 1219 DNSKEY15 1221 RRSIG14(KEY) 1222 RRSIG15(KEY) 1224 The rest of the zone data has the same signature as the SOA record, 1225 i.e a RRSIG created with DNSKEY 14. 1227 Appendix D. Document Details and Changes 1229 This section is to be removed by the RFC editor if and when the 1230 document is published. 1232 $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14 1233 2005/03/21 15:51:41 dnssec Exp $ 1235 D.1 draft-ietf-dnsop-dnssec-operational-practices-00 1237 Submission as working group document. This document is a modified 1238 and updated version of draft-kolkman-dnssec-operational-practices-00. 1240 D.2 draft-ietf-dnsop-dnssec-operational-practices-01 1242 changed the definition of "Bogus" to reflect the one in the protocol 1243 draft. 1245 Bad to Bogus 1247 Style and spelling corrections 1249 KSK - SEP mapping made explicit. 1251 Updates from Sam Weiler added 1253 D.3 draft-ietf-dnsop-dnssec-operational-practices-02 1255 Style and errors corrected. 1257 Added Automatic rollover requirements from I-D.ietf-dnsop-key- 1258 rollover-requirements. 1260 D.4 draft-ietf-dnsop-dnssec-operational-practices-03 1262 Added the definition of Key effectivity period and used that term 1263 instead of Key validity period. 1265 Modified the order of the sections, based on a suggestion by Rip 1266 Loomis. 1268 Included parts from RFC2541 [7]. Most of its ground was already 1269 covered. This document obsoletes RFC2541 [7]. Section 3.1.2 1270 deserves some review as it in contrast to RFC2541 does _not_ give 1271 recomendations about root-zone keys. 1273 added a paragraph to Section 4.4.4 1275 D.5 draft-ietf-dnsop-dnssec-operational-practices-04 1277 Somewhat more details added about the pre-publish KSK rollover. Also 1278 moved that subsection down a bit. 1280 Editorial and content nits that came in during wg last call were 1281 fixed. 1283 Intellectual Property Statement 1285 The IETF takes no position regarding the validity or scope of any 1286 Intellectual Property Rights or other rights that might be claimed to 1287 pertain to the implementation or use of the technology described in 1288 this document or the extent to which any license under such rights 1289 might or might not be available; nor does it represent that it has 1290 made any independent effort to identify any such rights. Information 1291 on the procedures with respect to rights in RFC documents can be 1292 found in BCP 78 and BCP 79. 1294 Copies of IPR disclosures made to the IETF Secretariat and any 1295 assurances of licenses to be made available, or the result of an 1296 attempt made to obtain a general license or permission for the use of 1297 such proprietary rights by implementers or users of this 1298 specification can be obtained from the IETF on-line IPR repository at 1299 http://www.ietf.org/ipr. 1301 The IETF invites any interested party to bring to its attention any 1302 copyrights, patents or patent applications, or other proprietary 1303 rights that may cover technology that may be required to implement 1304 this standard. Please address the information to the IETF at 1305 ietf-ipr@ietf.org. 1307 Disclaimer of Validity 1309 This document and the information contained herein are provided on an 1310 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1311 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1312 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1313 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1314 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1315 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1317 Copyright Statement 1319 Copyright (C) The Internet Society (2005). This document is subject 1320 to the rights, licenses and restrictions contained in BCP 78, and 1321 except as set forth therein, the authors retain all their rights. 1323 Acknowledgment 1325 Funding for the RFC Editor function is currently provided by the 1326 Internet Society.