1 2 3 4DNSOP O. Kolkman 5Internet-Draft NLnet Labs 6Obsoletes: 2541 (if approved) R. Gieben 7Intended status: BCP 8Expires: September 8, 2009 March 7, 2009 9 10 11 DNSSEC Operational Practices, Version 2 12 draft-ietf-dnsop-rfc4641bis-01 13 14Status of This Memo 15 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 28 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 33 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 38 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 41 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 44 45 This Internet-Draft will expire on September 8, 2009. 46 47Copyright Notice 48 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 51 52 53 54 55Kolkman & Gieben Expires September 8, 2009 [Page 1] 56 57Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 58 59 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents in effect on the date of 62 publication of this document (http://trustee.ietf.org/license-info). 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. 65 66Abstract 67 68 This document describes a set of practices for operating the DNS with 69 security extensions (DNSSEC). The target audience is zone 70 administrators deploying DNSSEC. 71 72 The document discusses operational aspects of using keys and 73 signatures in the DNS. It discusses issues of key generation, key 74 storage, signature generation, key rollover, and related policies. 75 76 This document obsoletes RFC 2541, as it covers more operational 77 ground and gives more up-to-date requirements with respect to key 78 sizes and the new DNSSEC specification. 79 80Table of Contents 81 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 5 84 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 85 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 86 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 87 3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 88 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7 89 3.1.2. Differentiation for 'High-Level' Zones . . . . . . . . 9 90 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 9 91 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 9 92 3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 10 93 3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10 94 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 11 95 4. Signature Generation, Key Rollover, and Related Policies . . . 12 96 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12 97 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 13 98 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 15 99 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 15 100 4.2.1.1. Pre-Publish Key Rollover . . . . . . . . . . . . . 15 101 4.2.1.2. Double Signature Zone Signing Key Rollover . . . . 17 102 4.2.1.3. Pros and Cons of the Schemes . . . . . . . . . . . 19 103 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 19 104 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 21 105 4.2.4. Key algorithm rollover . . . . . . . . . . . . . . . . 22 106 4.2.5. Automated Key Rollovers . . . . . . . . . . . . . . . 23 107 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 24 108 109 110 111Kolkman & Gieben Expires September 8, 2009 [Page 2] 112 113Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 114 115 116 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 24 117 4.3.1.1. Keeping the Chain of Trust Intact . . . . . . . . 25 118 4.3.1.2. Breaking the Chain of Trust . . . . . . . . . . . 26 119 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 26 120 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 26 121 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 27 122 4.4.1. Initial Key Exchanges and Parental Policies 123 Considerations . . . . . . . . . . . . . . . . . . . . 27 124 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 27 125 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 28 126 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 28 127 4.4.5. (Non) Cooperating Registrars . . . . . . . . . . . . . 29 128 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 129 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 130 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 131 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 132 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 133 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 134 Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 32 135 Appendix B. Zone Signing Key Rollover How-To . . . . . . . . . . 34 136 Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 34 137 Appendix D. Document Editing History . . . . . . . . . . . . . . 37 138 D.1. draft-ietf-dnsop-rfc4641-00 . . . . . . . . . . . . . . . 37 139 D.2. version 0->1 . . . . . . . . . . . . . . . . . . . . . . . 37 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Kolkman & Gieben Expires September 8, 2009 [Page 3] 168 169Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 170 171 1721. Introduction 173 174 This document describes how to run a DNS Security (DNSSEC)-enabled 175 environment. It is intended for operators who have knowledge of the 176 DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. 177 See RFC 4033 [3] for an introduction to DNSSEC, RFC 4034 [4] for the 178 newly introduced Resource Records (RRs), and RFC 4035 [5] for the 179 protocol changes. 180 181 During workshops and early operational deployment tests, operators 182 and system administrators have gained experience about operating the 183 DNS with security extensions (DNSSEC). This document translates 184 these experiences into a set of practices for zone administrators. 185 At the time of writing, there exists very little experience with 186 DNSSEC in production environments; this document should therefore 187 explicitly not be seen as representing 'Best Current Practices'. 188 [OK: Is this document ripe enough to shoot for BCP?] 189 190 The procedures herein are focused on the maintenance of signed zones 191 (i.e., signing and publishing zones on authoritative servers). It is 192 intended that maintenance of zones such as re-signing or key 193 rollovers be transparent to any verifying clients on the Internet. 194 195 The structure of this document is as follows. In Section 2, we 196 discuss the importance of keeping the "chain of trust" intact. 197 Aspects of key generation and storage of private keys are discussed 198 in Section 3; the focus in this section is mainly on the private part 199 of the key(s). Section 4 describes considerations concerning the 200 public part of the keys. Since these public keys appear in the DNS 201 one has to take into account all kinds of timing issues, which are 202 discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the 203 rollover, or supercession, of keys. Finally, Section 4.4 discusses 204 considerations on how parents deal with their children's public keys 205 in order to maintain chains of trust. 206 207 The typographic conventions used in this document are explained in 208 Appendix C. 209 210 Since this is a document with operational suggestions and there are 211 no protocol specifications, the RFC 2119 [6] language does not apply. 212 213 This document [OK: when approved] obsoletes RFC 4641 [16]. 214 215 [OK: Editorial comments and questions are indicated by square 216 brackets and editor innitials] 217 218 219 220 221 222 223Kolkman & Gieben Expires September 8, 2009 [Page 4] 224 225Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 226 227 2281.1. The Use of the Term 'key' 229 230 It is assumed that the reader is familiar with the concept of 231 asymmetric keys on which DNSSEC is based (public key cryptography 232 RFC4949 [17]). Therefore, this document will use the term 'key' 233 rather loosely. Where it is written that 'a key is used to sign 234 data' it is assumed that the reader understands that it is the 235 private part of the key pair that is used for signing. It is also 236 assumed that the reader understands that the public part of the key 237 pair is published in the DNSKEY Resource Record and that it is the 238 public part that is used in key exchanges. 239 2401.2. Time Definitions 241 242 In this document, we will be using a number of time-related terms. 243 The following definitions apply: 244 245 o "Signature validity period" The period that a signature is valid. 246 It starts at the time specified in the signature inception field 247 of the RRSIG RR and ends at the time specified in the expiration 248 field of the RRSIG RR. 249 250 o "Signature publication period" Time after which a signature (made 251 with a specific key) is replaced with a new signature (made with 252 the same key). This replacement takes place by publishing the 253 relevant RRSIG in the master zone file. After one stops 254 publishing an RRSIG in a zone, it may take a while before the 255 RRSIG has expired from caches and has actually been removed from 256 the DNS. 257 258 o "Key effectivity period" The period during which a key pair is 259 expected to be effective. This period is defined as the time 260 between the first inception time stamp and the last expiration 261 date of any signature made with this key, regardless of any 262 discontinuity in the use of the key. The key effectivity period 263 can span multiple signature validity periods. 264 265 o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum 266 value of the TTLs from the complete set of RRs in a zone. Note 267 that the minimum TTL is not the same as the MINIMUM field in the 268 SOA RR. See [9] for more information. 269 2702. Keeping the Chain of Trust Intact 271 272 Maintaining a valid chain of trust is important because broken chains 273 of trust will result in data being marked as Bogus (as defined in [3] 274 Section 5), which may cause entire (sub)domains to become invisible 275 to verifying clients. The administrators of secured zones have to 276 277 278 279Kolkman & Gieben Expires September 8, 2009 [Page 5] 280 281Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 282 283 284 realize that their zone is, to verifying clients, part of a chain of 285 trust. 286 287 As mentioned in the introduction, the procedures herein are intended 288 to ensure that maintenance of zones, such as re-signing or key 289 rollovers, will be transparent to the verifying clients on the 290 Internet. 291 292 Administrators of secured zones will have to keep in mind that data 293 published on an authoritative primary server will not be immediately 294 seen by verifying clients; it may take some time for the data to be 295 transferred to other secondary authoritative nameservers and clients 296 may be fetching data from caching non-authoritative servers. In this 297 light, note that the time for a zone transfer from master to slave is 298 negligible when using NOTIFY [8] and incremental transfer (IXFR) [7]. 299 It increases when full zone transfers (AXFR) are used in combination 300 with NOTIFY. It increases even more if you rely on full zone 301 transfers based on only the SOA timing parameters for refresh. 302 303 For the verifying clients, it is important that data from secured 304 zones can be used to build chains of trust regardless of whether the 305 data came directly from an authoritative server, a caching 306 nameserver, or some middle box. Only by carefully using the 307 available timing parameters can a zone administrator ensure that the 308 data necessary for verification can be obtained. 309 310 The responsibility for maintaining the chain of trust is shared by 311 administrators of secured zones in the chain of trust. This is most 312 obvious in the case of a 'key compromise' when a trade-off between 313 maintaining a valid chain of trust and replacing the compromised keys 314 as soon as possible must be made. Then zone administrators will have 315 to make a trade-off, between keeping the chain of trust intact -- 316 thereby allowing for attacks with the compromised key -- or 317 deliberately breaking the chain of trust and making secured 318 subdomains invisible to security-aware resolvers. Also see 319 Section 4.3. 320 3213. Keys Generation and Storage 322 323 This section describes a number of considerations with respect to the 324 security of keys. It deals with the generation, effectivity period, 325 size, and storage of private keys. 326 3273.1. Zone and Key Signing Keys 328 329 The DNSSEC validation protocol does not distinguish between different 330 types of DNSKEYs. All DNSKEYs can be used during the validation. In 331 practice, operators use Key Signing and Zone Signing Keys and use the 332 333 334 335Kolkman & Gieben Expires September 8, 2009 [Page 6] 336 337Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 338 339 340 so-called Secure Entry Point (SEP) [5] flag to distinguish between 341 them during operations. The dynamics and considerations are 342 discussed below. 343 344 To make zone re-signing and key rollover procedures easier to 345 implement, it is possible to use one or more keys as Key Signing Keys 346 (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. 347 Other keys can be used to sign all the RRSets in a zone and are 348 referred to as Zone Signing Keys (ZSKs). In this document, we assume 349 that KSKs are the subset of keys that are used for key exchanges with 350 the parent and potentially for configuration as trusted anchors -- 351 the SEP keys. In this document, we assume a one-to-one mapping 352 between KSK and SEP keys and we assume the SEP flag to be set on all 353 KSKs. 354 3553.1.1. Motivations for the KSK and ZSK Separation 356 357 Differentiating between the KSK and ZSK functions has several 358 advantages: 359 360 o No parent/child interaction is required when ZSKs are updated. 361 362 o [OK: Bullet removed, strawman Paul Hoffman] 363 364 o As the KSK is only used to sign a key set, which is most probably 365 updated less frequently than other data in the zone, it can be 366 stored separately from and in a safer location than the ZSK. 367 368 o A KSK can have a longer key effectivity period. 369 370 For almost any method of key management and zone signing, the KSK is 371 used less frequently than the ZSK. Once a key set is signed with the 372 KSK, all the keys in the key set can be used as ZSKs. If a ZSK is 373 compromised, it can be simply dropped from the key set. The new key 374 set is then re-signed with the KSK. 375 376 Given the assumption that for KSKs the SEP flag is set, the KSK can 377 be distinguished from a ZSK by examining the flag field in the DNSKEY 378 RR. If the flag field is an odd number it is a KSK. If it is an 379 even number it is a ZSK. 380 381 The Zone Signing Key can be used to sign all the data in a zone on a 382 regular basis. When a Zone Signing Key is to be rolled, no 383 interaction with the parent is needed. This allows for signature 384 validity periods on the order of days. 385 386 The Key Signing Key is only to be used to sign the DNSKEY RRs in a 387 zone. If a Key Signing Key is to be rolled over, there will be 388 389 390 391Kolkman & Gieben Expires September 8, 2009 [Page 7] 392 393Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 394 395 396 interactions with parties other than the zone administrator. If 397 there is a parent zone, these can include the registry of the parent 398 zone or administrators of verifying resolvers that have the 399 particular key configured as secure entry points. If this is a trust 400 anchor, everyone relying on the trust anchor needs to roll over to 401 the new key. The latter may be subject to stability costs if 402 automated trust-anchor rollover mechanisms (such as e.g. RFC5011 403 [18]) are not in place. Hence, the key effectivity period of these 404 keys can and should be made much longer. 405 406 There are two schools of thought on rolling a KSK that is not a trust 407 anchor [OK: One can never be sure a KSK is _not_ a trust anchor]: 408 409 o It should be done regularly (possibly every few months) so that a 410 key rollover remains an operational routine. 411 412 o It should only be done when it is known or strongly suspected that 413 the key has been compromised in order to reduce the stability 414 issues on systems where the rollover does not happen cleanly. 415 416 There is no widespread agreement on which of these two schools of 417 thought is better for different deployments of DNSSEC. There is a 418 stability cost every time a non-anchor KSK is rolled over, but it is 419 possibly low if the communication between the child and the parent is 420 good. On the other hand, the only completely effective way to tell 421 if the communication is good is to test it periodically. Thus, 422 rolling a KSK with a parent is only done for two reasons: to test and 423 verify the rolling system to prepare for an emergency, and in the 424 case of an actual emergency. 425 426 [OK: The paragraph below is a straw-man by Paul Hoffman] Because of 427 the difficulty of getting all users of a trust anchor to replace an 428 old trust anchor with a new one, a KSK that is a trust anchor should 429 never be rolled unless it is known or strongly suspected that the key 430 has been compromised. 431 432 [OK: This is an alternative straw-man by Olaf Kolkman] The same 433 operational concerns apply to the rollover of KSKs that are used as 434 trust-anchors. Since the administrator of a zone can not be certain 435 that the zone's KSK is in use as a trust-anchor she will have to 436 assume that a rollover will cause a stability cost for the users that 437 did configure her key as a trust-anchor. Those costs can be 438 minimized by automating the rollover RFC5011 [18] and by rolling the 439 key regularly, and advertising such, so that the operators of 440 recursive nameservers will put the appropriate mechanism in place to 441 deal with these stability costs, or, in other words, budget for these 442 costs instead of incuring them unexpectedly. 443 444 445 446 447Kolkman & Gieben Expires September 8, 2009 [Page 8] 448 449Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 450 451 4523.1.2. Differentiation for 'High-Level' Zones 453 454 In an earlier version of this document we made a differentiation 455 between KSKs used for zones that are high in the DNS hierarchy versus 456 KSKs used for zones low in that hierarchy. We have come to realize 457 that there are other considerations that argue such differentiation 458 does not need to be made. 459 460 Longer keys are not useful because the crypto guidance is that 461 everyone should use keys that no one can break. Also, it is 462 impossible to judge which zones are more or less valuable to an 463 attacker. An attack can only be used if the compromise is unnoticed 464 and the attacker can act as an man-in-the-middle attack (MITM) in an 465 unnoticed way. If .example is compromised and the attacker forges 466 answers for somebank.example and sends them out as an MITM, when the 467 attack is discovered it will be simple to prove that .example has 468 been compromised and the KSK will be rolled. Defining a long-term 469 successful attack is difficult for keys at any level. 470 4713.2. Key Generation 472 473 Careful generation of all keys is a sometimes overlooked but 474 absolutely essential element in any cryptographically secure system. 475 The strongest algorithms used with the longest keys are still of no 476 use if an adversary can guess enough to lower the size of the likely 477 key space so that it can be exhaustively searched. Technical 478 suggestions for the generation of random keys will be found in RFC 479 4086 [14] and NIST SP 800-900 [20]. One should carefully assess if 480 the random number generator used during key generation adheres to 481 these suggestions. 482 483 Keys with a long effectivity period are particularly sensitive as 484 they will represent a more valuable target and be subject to attack 485 for a longer time than short-period keys. It is strongly recommended 486 that long-term key generation occur off-line in a manner isolated 487 from the network via an air gap or, at a minimum, high-level secure 488 hardware. 489 4903.3. Key Effectivity Period 491 492 From a purely operational perspective, a reasonable key effectivity 493 period for KSKs that have a parent zone is 13 months, with the intent 494 to replace them after 12 months. An intended key effectivity period 495 of a month is reasonable for Zone Signing Keys. This annual rollover 496 gives operational practice to rollovers. 497 498 Ignoring the operational perspective, a reasonable effectivity period 499 for KSKs that have a parent zone is of the order of 2 decades or 500 501 502 503Kolkman & Gieben Expires September 8, 2009 [Page 9] 504 505Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 506 507 508 longer. That is, if one does not plan to test the rollover 509 procedure, the key should be effective essentially forever, and then 510 only rolled over in case of emergency. 511 512 The "operational habit" argument also applies to trust anchor 513 reconfiguration. If a short key effectivity period is used and the 514 trust anchor configuration has to be revisited on a regular basis, 515 the odds that the configuration tends to be forgotten is smaller. 516 The trade-off is against a system that is so dynamic that 517 administrators of the validating clients will not be able to follow 518 the modifications.Note that if a trust anchor replacement is done 519 incorrectly, the entire zone that the trust anchor covers will become 520 bogus until the trust anchor is corrected. 521 522 Key effectivity periods can be made very short, as in a few minutes. 523 But when replacing keys one has to take the considerations from 524 Section 4.1 and Section 4.2 into account. 525 5263.4. Key Algorithm 527 528 There are currently two types of signature algorithms that can be 529 used in DNSSEC: RSA and DSA. Both are fully specified in many 530 freely-available documents, and both are widely considered to be 531 patent-free. The creation of signatures wiht RSA and DSA takes 532 roughly the same time, but DSA is about ten times slower for 533 signature verification. 534 535 We suggest the use of either RSA/SHA-1 or RSA/SHA-256 as the 536 preferred signature algorithms. Both have advantages and 537 disadvantages. RSA/SHA-1 has been deployed for many years, while 538 RSA/SHA-256 has only begun to be deployed. On the other hand, it is 539 expected that if effective attacks on either algorithm appeark, they 540 will appear for RSA/SHA-1 first. RSA/MD5 should not be considered 541 for use because RSA/MD5 will very likely be the first common-use 542 signature algorithm to have an effective attack. 543 544 At the time of publication, it is known that the SHA-1 hash has 545 cryptanalysis issues. There is work in progress on addressing these 546 issues. We recommend the use of public key algorithms based on 547 hashes stronger than SHA-1 (e.g., SHA-256), as soon as these 548 algorithms are available in protocol specifications (see [21] and 549 [22]) and implementations. 550 5513.5. Key Sizes 552 553 DNSSEC signing keys should be large enough to avoid all know 554 cryptographic attacks during the lifetime of the key. To date, 555 despite huge efforts, no one has broken a regular 1024-bit key; in 556 557 558 559Kolkman & Gieben Expires September 8, 2009 [Page 10] 560 561Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 562 563 564 fact, the best completed attack is estimated to be the equivalent of 565 a 700-bit key. An attacker breaking a 1024-bit signing key would 566 need expend phenominal amounts of networked computing power in a way 567 that would not be detected in order to break a single key. Because 568 of this, it is estimated that most zones can safely use 1024-bit keys 569 for at least the next ten years. A 1024-bit asymmetric key has an 570 approximate equivalent strength of a symmetric 80-bit key. 571 572 Keys that are used as extremely high value trust anchors, or non- 573 anchor keys that may be difficult to roll over, may want to use 574 lengths longer than 1024 bits. Typically, the next larger key size 575 used is 2048 bits, which have the approximate equivalent strength of 576 a symmetric 112-bit key. In a standard CPU, it takes about four 577 times as long to sign or verify with a 2048-bit key as it does with a 578 1024-bit key. 579 580 Another way to decide on the size of key to use is to remember that 581 the phenominal effort it takes for an attacker to break a 1024-bit 582 key is the same regardless of how the key is used. If an attacker 583 has the capability of breaking a 1024-bit DNSSEC key, he also has the 584 capability of breaking one of the many 1024-bit TLS trust anchor keys 585 that are installed with web browsers. If the value of a DNSSEC key 586 is lower to the attacker than the value of a TLS trust anchor, the 587 attacker will use the resources to attack the TLS trust anchor. 588 589 It is possible that there is a unexpected improvement in the ability 590 for attackers to beak keys, and that such an attack would make it 591 feasible to break 1024-bit keys but not 2048-bit keys. If such an 592 improvement happens, it is likely that there will be a huge amount of 593 publicity, particularly because of the large number of 1024-bit TLS 594 trust anchors build into popular web browsers. At that time, all 595 1024-bit keys (both ones with parent zones and ones that are trust 596 anchors) can be rolled over and replaced with larger keys. 597 598 Earlier documents (including the previous version of this document) 599 urged the use of longer keys in situations where a particular key was 600 "heavily used". That advice may have been true 15 years ago, but it 601 is not true today when using RSA or DSA algorithms and keys of 1024 602 bits or higher. 603 6043.6. Private Key Storage 605 606 It is recommended that, where possible, zone private keys and the 607 zone file master copy that is to be signed be kept and used in off- 608 line, non-network-connected, physically secure machines only. 609 Periodically, an application can be run to add authentication to a 610 zone by adding RRSIG and NSEC RRs. Then the augmented file can be 611 transferred. 612 613 614 615Kolkman & Gieben Expires September 8, 2009 [Page 11] 616 617Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 618 619 620 When relying on dynamic update to manage a signed zone [11], be aware 621 that at least one private key of the zone will have to reside on the 622 master server. This key is only as secure as the amount of exposure 623 the server receives to unknown clients and the security of the host. 624 Although not mandatory, one could administer the DNS in the following 625 way. The master that processes the dynamic updates is unavailable 626 from generic hosts on the Internet, it is not listed in the NS RRSet, 627 although its name appears in the SOA RRs MNAME field. The 628 nameservers in the NS RRSet are able to receive zone updates through 629 NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This 630 approach is known as the "hidden master" setup. 631 632 The ideal situation is to have a one-way information flow to the 633 network to avoid the possibility of tampering from the network. 634 Keeping the zone master file on-line on the network and simply 635 cycling it through an off-line signer does not do this. The on-line 636 version could still be tampered with if the host it resides on is 637 compromised. For maximum security, the master copy of the zone file 638 should be off-net and should not be updated based on an unsecured 639 network mediated communication. 640 641 In general, keeping a zone file off-line will not be practical and 642 the machines on which zone files are maintained will be connected to 643 a network. Operators are advised to take security measures to shield 644 unauthorized access to the master copy. 645 646 For dynamically updated secured zones [11], both the master copy and 647 the private key that is used to update signatures on updated RRs will 648 need to be on-line. 649 6504. Signature Generation, Key Rollover, and Related Policies 651 6524.1. Time in DNSSEC 653 654 Without DNSSEC, all times in the DNS are relative. The SOA fields 655 REFRESH, RETRY, and EXPIRATION are timers used to determine the time 656 elapsed after a slave server synchronized with a master server. The 657 Time to Live (TTL) value and the SOA RR minimum TTL parameter [9] are 658 used to determine how long a forwarder should cache data after it has 659 been fetched from an authoritative server. By using a signature 660 validity period, DNSSEC introduces the notion of an absolute time in 661 the DNS. Signatures in DNSSEC have an expiration date after which 662 the signature is marked as invalid and the signed data is to be 663 considered Bogus. 664 665 666 667 668 669 670 671Kolkman & Gieben Expires September 8, 2009 [Page 12] 672 673Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 674 675 6764.1.1. Time Considerations 677 678 Because of the expiration of signatures, one should consider the 679 following: 680 681 o We suggest the Maximum Zone TTL of your zone data to be a fraction 682 of your signature validity period. 683 684 If the TTL would be of similar order as the signature validity 685 period, then all RRSets fetched during the validity period 686 would be cached until the signature expiration time. Section 687 7.1 of [3] suggests that "the resolver may use the time 688 remaining before expiration of the signature validity period of 689 a signed RRSet as an upper bound for the TTL". As a result, 690 query load on authoritative servers would peak at signature 691 expiration time, as this is also the time at which records 692 simultaneously expire from caches. 693 694 To avoid query load peaks, we suggest the TTL on all the RRs in 695 your zone to be at least a few times smaller than your 696 signature validity period. 697 698 o We suggest the signature publication period to end at least one 699 Maximum Zone TTL duration before the end of the signature validity 700 period. 701 702 Re-signing a zone shortly before the end of the signature 703 validity period may cause simultaneous expiration of data from 704 caches. This in turn may lead to peaks in the load on 705 authoritative servers. 706 707 o We suggest the Minimum Zone TTL to be long enough to both fetch 708 and verify all the RRs in the trust chain. In workshop 709 environments, it has been demonstrated [19] that a low TTL (under 710 5 to 10 minutes) caused disruptions because of the following two 711 problems: 712 713 1. During validation, some data may expire before the 714 validation is complete. The validator should be able to keep 715 all data until it is completed. This applies to all RRs needed 716 to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the 717 final answers, i.e., the RRSet that is returned for the initial 718 query. 719 720 2. Frequent verification causes load on recursive nameservers. 721 Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit 722 from caching. The TTL on those should be relatively long. 723 724 725 726 727Kolkman & Gieben Expires September 8, 2009 [Page 13] 728 729Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 730 731 732 o Slave servers will need to be able to fetch newly signed zones 733 well before the RRSIGs in the zone served by the slave server pass 734 their signature expiration time. 735 736 When a slave server is out of sync with its master and data in 737 a zone is signed by expired signatures, it may be better for 738 the slave server not to give out any answer. 739 740 Normally, a slave server that is not able to contact a master 741 server for an extended period will expire a zone. When that 742 happens, the server will respond differently to queries for 743 that zone. Some servers issue SERVFAIL, whereas others turn 744 off the 'AA' bit in the answers. The time of expiration is set 745 in the SOA record and is relative to the last successful 746 refresh between the master and the slave servers. There exists 747 no coupling between the signature expiration of RRSIGs in the 748 zone and the expire parameter in the SOA. 749 750 If the server serves a DNSSEC zone, then it may well happen 751 that the signatures expire well before the SOA expiration timer 752 counts down to zero. It is not possible to completely prevent 753 this from happening by tweaking the SOA parameters. 754 755 However, the effects can be minimized where the SOA expiration 756 time is equal to or shorter than the signature validity period. 757 758 The consequence of an authoritative server not being able to 759 update a zone, whilst that zone includes expired signatures, is 760 that non-secure resolvers will continue to be able to resolve 761 data served by the particular slave servers while security- 762 aware resolvers will experience problems because of answers 763 being marked as Bogus. 764 765 We suggest the SOA expiration timer being approximately one 766 third or one fourth of the signature validity period. It will 767 allow problems with transfers from the master server to be 768 noticed before the actual signature times out. 769 770 We also suggest that operators of nameservers that supply 771 secondary services develop 'watch dogs' to spot upcoming 772 signature expirations in zones they slave, and take appropriate 773 action. 774 775 When determining the value for the expiration parameter one has 776 to take the following into account: What are the chances that 777 all my secondaries expire the zone? How quickly can I reach an 778 administrator of secondary servers to load a valid zone? These 779 questions are not DNSSEC specific but may influence the choice 780 781 782 783Kolkman & Gieben Expires September 8, 2009 [Page 14] 784 785Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 786 787 788 of your signature validity intervals. 789 7904.2. Key Rollovers 791 792 Regardless of whether a zone uses periodic key rollovers in order to 793 practice for emergencies, or only rolls over keys in an emergency, 794 key rollovers are a fact of life when using DNSSEC. Zone 795 administrators who are in the process of rolling their keys have to 796 take into account that data published in previous versions of their 797 zone still lives in caches. When deploying DNSSEC, this becomes an 798 important consideration; ignoring data that may be in caches may lead 799 to loss of service for clients. 800 801 The most pressing example of this occurs when zone material signed 802 with an old key is being validated by a resolver that does not have 803 the old zone key cached. If the old key is no longer present in the 804 current zone, this validation fails, marking the data "Bogus". 805 Alternatively, an attempt could be made to validate data that is 806 signed with a new key against an old key that lives in a local cache, 807 also resulting in data being marked "Bogus". 808 8094.2.1. Zone Signing Key Rollovers 810 811 For "Zone Signing Key rollovers", there are two ways to make sure 812 that during the rollover data still cached can be verified with the 813 new key sets or newly generated signatures can be verified with the 814 keys still in caches. One schema, described in Section 4.2.1.2, uses 815 double signatures; the other uses key pre-publication 816 (Section 4.2.1.1). The pros, cons, and recommendations are described 817 in Section 4.2.1.3. 818 8194.2.1.1. Pre-Publish Key Rollover 820 821 This section shows how to perform a ZSK rollover without the need to 822 sign all the data in a zone twice -- the "pre-publish key rollover". 823 This method has advantages in the case of a key compromise. If the 824 old key is compromised, the new key has already been distributed in 825 the DNS. The zone administrator is then able to quickly switch to 826 the new key and remove the compromised key from the zone. Another 827 major advantage is that the zone size does not double, as is the case 828 with the double signature ZSK rollover. A small "how-to" for this 829 kind of rollover can be found in Appendix B. 830 831 832 833 834 835 836 837 838 839Kolkman & Gieben Expires September 8, 2009 [Page 15] 840 841Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 842 843 844 Pre-publish key rollover involves four stages as follows: 845 846 ---------------------------------------------------------------- 847 initial new DNSKEY new RRSIGs DNSKEY removal 848 ---------------------------------------------------------------- 849 SOA0 SOA1 SOA2 SOA3 850 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 851 852 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 853 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 854 DNSKEY11 DNSKEY11 855 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 856 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 857 ---------------------------------------------------------------- 858 859 Pre-Publish Key Rollover 860 861 initial: Initial version of the zone: DNSKEY 1 is the Key Signing 862 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 863 Signing Key. 864 865 new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no 866 signatures are generated with this key yet, but this does not 867 secure against brute force attacks on the public key. The minimum 868 duration of this pre-roll phase is the time it takes for the data 869 to propagate to the authoritative servers plus TTL value of the 870 key set. 871 872 new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is 873 used to sign the data in the zone exclusively (i.e., all the 874 signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 875 remains published in the key set. This way data that was loaded 876 into caches from version 1 of the zone can still be verified with 877 key sets fetched from version 2 of the zone. The minimum time 878 that the key set including DNSKEY 10 is to be published is the 879 time that it takes for zone data from the previous version of the 880 zone to expire from old caches, i.e., the time it takes for this 881 zone to propagate to all authoritative servers plus the Maximum 882 Zone TTL value of any of the data in the previous version of the 883 zone. 884 885 DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, 886 now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the 887 DNSKEY 1. 888 889 The above scheme can be simplified by always publishing the "future" 890 key immediately after the rollover. The scheme would look as follows 891 (we show two rollovers); the future key is introduced in "new DNSKEY" 892 893 894 895Kolkman & Gieben Expires September 8, 2009 [Page 16] 896 897Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 898 899 900 as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY 901 (II)": 902 903 904 initial new RRSIGs new DNSKEY 905 ----------------------------------------------------------------- 906 SOA0 SOA1 SOA2 907 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) 908 909 DNSKEY1 DNSKEY1 DNSKEY1 910 DNSKEY10 DNSKEY10 DNSKEY11 911 DNSKEY11 DNSKEY11 DNSKEY12 912 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 913 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 914 ---------------------------------------------------------------- 915 916 ---------------------------------------------------------------- 917 new RRSIGs (II) new DNSKEY (II) 918 ---------------------------------------------------------------- 919 SOA3 SOA4 920 RRSIG12(SOA3) RRSIG12(SOA4) 921 922 DNSKEY1 DNSKEY1 923 DNSKEY11 DNSKEY12 924 DNSKEY12 DNSKEY13 925 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 926 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 927 ---------------------------------------------------------------- 928 929 Pre-Publish Key Rollover, Showing Two Rollovers 930 931 Note that the key introduced in the "new DNSKEY" phase is not used 932 for production yet; the private key can thus be stored in a 933 physically secure manner and does not need to be 'fetched' every time 934 a zone needs to be signed. 935 9364.2.1.2. Double Signature Zone Signing Key Rollover 937 938 This section shows how to perform a ZSK key rollover using the double 939 zone data signature scheme, aptly named "double signature rollover". 940 941 During the "new DNSKEY" stage the new version of the zone file will 942 need to propagate to all authoritative servers and the data that 943 exists in (distant) caches will need to expire, requiring at least 944 the Maximum Zone TTL. 945 946 947 948 949 950 951Kolkman & Gieben Expires September 8, 2009 [Page 17] 952 953Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 954 955 956 Double signature ZSK rollover involves three stages as follows: 957 958 ---------------------------------------------------------------- 959 initial new DNSKEY DNSKEY removal 960 ---------------------------------------------------------------- 961 SOA0 SOA1 SOA2 962 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 963 RRSIG11(SOA1) 964 DNSKEY1 DNSKEY1 DNSKEY1 965 DNSKEY10 DNSKEY10 DNSKEY11 966 DNSKEY11 967 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 968 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 969 RRSIG11(DNSKEY) 970 ---------------------------------------------------------------- 971 972 Double Signature Zone Signing Key Rollover 973 974 initial: Initial Version of the zone: DNSKEY 1 is the Key Signing 975 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 976 Signing Key. 977 978 new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is 979 introduced into the key set and all the data in the zone is signed 980 with DNSKEY 10 and DNSKEY 11. The rollover period will need to 981 continue until all data from version 0 of the zone has expired 982 from remote caches. This will take at least the Maximum Zone TTL 983 of version 0 of the zone. 984 985 DNSKEY removal: DNSKEY 10 is removed from the zone. All the 986 signatures from DNSKEY 10 are removed from the zone. The key set, 987 now only containing DNSKEY 11, is re-signed with DNSKEY 1. 988 989 At every instance, RRSIGs from the previous version of the zone can 990 be verified with the DNSKEY RRSet from the current version and the 991 other way around. The data from the current version can be verified 992 with the data from the previous version of the zone. The duration of 993 the "new DNSKEY" phase and the period between rollovers should be at 994 least the Maximum Zone TTL. 995 996 Making sure that the "new DNSKEY" phase lasts until the signature 997 expiration time of the data in the initial version of the zone is 998 recommended. This way all caches are cleared of the old signatures. 999 However, this duration could be considerably longer than the Maximum 1000 Zone TTL, making the rollover a lengthy procedure. 1001 1002 Note that in this example we assumed that the zone was not modified 1003 during the rollover. New data can be introduced in the zone as long 1004 1005 1006 1007Kolkman & Gieben Expires September 8, 2009 [Page 18] 1008 1009Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1010 1011 1012 as it is signed with both keys. 1013 10144.2.1.3. Pros and Cons of the Schemes 1015 1016 Pre-publish key rollover: This rollover does not involve signing the 1017 zone data twice. Instead, before the actual rollover, the new key 1018 is published in the key set and thus is available for 1019 cryptanalysis attacks. A small disadvantage is that this process 1020 requires four steps. Also the pre-publish scheme involves more 1021 parental work when used for KSK rollovers as explained in 1022 Section 4.2.3. 1023 1024 Double signature ZSK rollover: The drawback of this signing scheme 1025 is that during the rollover the number of signatures in your zone 1026 doubles; this may be prohibitive if you have very big zones. An 1027 advantage is that it only requires three steps. 1028 10294.2.2. Key Signing Key Rollovers 1030 1031 For the rollover of a Key Signing Key, the same considerations as for 1032 the rollover of a Zone Signing Key apply. However, we can use a 1033 double signature scheme to guarantee that old data (only the apex key 1034 set) in caches can be verified with a new key set and vice versa. 1035 Since only the key set is signed with a KSK, zone size considerations 1036 do not apply. 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063Kolkman & Gieben Expires September 8, 2009 [Page 19] 1064 1065Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1066 1067 1068 -------------------------------------------------------------------- 1069 initial new DNSKEY DS change DNSKEY removal 1070 -------------------------------------------------------------------- 1071 Parent: 1072 SOA0 --------> SOA1 --------> 1073 RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> 1074 DS1 --------> DS2 --------> 1075 RRSIGpar(DS) --------> RRSIGpar(DS) --------> 1076 1077 1078 Child: 1079 SOA0 SOA1 --------> SOA2 1080 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) 1081 --------> 1082 DNSKEY1 DNSKEY1 --------> DNSKEY2 1083 DNSKEY2 --------> 1084 DNSKEY10 DNSKEY10 --------> DNSKEY10 1085 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) 1086 RRSIG2 (DNSKEY) --------> 1087 RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) 1088 -------------------------------------------------------------------- 1089 1090 Stages of Deployment for a Double Signature Key Signing Key Rollover 1091 1092 initial: Initial version of the zone. The parental DS points to 1093 DNSKEY1. Before the rollover starts, the child will have to 1094 verify what the TTL is of the DS RR that points to DNSKEY1 -- it 1095 is needed during the rollover and we refer to the value as TTL_DS. 1096 1097 new DNSKEY: During the "new DNSKEY" phase, the zone administrator 1098 generates a second KSK, DNSKEY2. The key is provided to the 1099 parent, and the child will have to wait until a new DS RR has been 1100 generated that points to DNSKEY2. After that DS RR has been 1101 published on all servers authoritative for the parent's zone, the 1102 zone administrator has to wait at least TTL_DS to make sure that 1103 the old DS RR has expired from caches. 1104 1105 DS change: The parent replaces DS1 with DS2. 1106 1107 DNSKEY removal: DNSKEY1 has been removed. 1108 1109 The scenario above puts the responsibility for maintaining a valid 1110 chain of trust with the child. It also is based on the premise that 1111 the parent only has one DS RR (per algorithm) per zone. An 1112 alternative mechanism has been considered. Using an established 1113 trust relation, the interaction can be performed in-band, and the 1114 removal of the keys by the child can possibly be signaled by the 1115 parent. In this mechanism, there are periods where there are two DS 1116 1117 1118 1119Kolkman & Gieben Expires September 8, 2009 [Page 20] 1120 1121Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1122 1123 1124 RRs at the parent. Since at the moment of writing the protocol for 1125 this interaction has not been developed, further discussion is out of 1126 scope for this document. 1127 11284.2.3. Difference Between ZSK and KSK Rollovers 1129 1130 Note that KSK rollovers and ZSK rollovers are different in the sense 1131 that a KSK rollover requires interaction with the parent (and 1132 possibly replacing of trust anchors) and the ensuing delay while 1133 waiting for it. 1134 1135 A zone key rollover can be handled in two different ways: pre-publish 1136 (Section 4.2.1.1) and double signature (Section 4.2.1.2). 1137 1138 As the KSK is used to validate the key set and because the KSK is not 1139 changed during a ZSK rollover, a cache is able to validate the new 1140 key set of the zone. The pre-publish method would also work for a 1141 KSK rollover. The records that are to be pre-published are the 1142 parental DS RRs. The pre-publish method has some drawbacks for KSKs. 1143 We first describe the rollover scheme and then indicate these 1144 drawbacks. 1145 1146 1147 -------------------------------------------------------------------- 1148 initial new DS new DNSKEY DS/DNSKEY removal 1149 -------------------------------------------------------------------- 1150 Parent: 1151 SOA0 SOA1 --------> SOA2 1152 RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) 1153 DS1 DS1 --------> DS2 1154 DS2 --------> 1155 RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) 1156 1157 Child: 1158 SOA0 --------> SOA1 SOA1 1159 RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) 1160 --------> 1161 DNSKEY1 --------> DNSKEY2 DNSKEY2 1162 --------> 1163 DNSKEY10 --------> DNSKEY10 DNSKEY10 1164 RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 1165 RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) 1166 -------------------------------------------------------------------- 1167 1168 Stages of Deployment for a Pre-Publish Key Signing Key Rollover 1169 1170 When the child zone wants to roll, it notifies the parent during the 1171 "new DS" phase and submits the new key (or the corresponding DS) to 1172 1173 1174 1175Kolkman & Gieben Expires September 8, 2009 [Page 21] 1176 1177Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1178 1179 1180 the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 1181 and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), 1182 which can take place as soon as the new DS set propagated through the 1183 DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that 1184 ("DS/DNSKEY removal" phase), it can notify the parent that the old DS 1185 record can be deleted. 1186 1187 The drawbacks of this scheme are that during the "new DS" phase the 1188 parent cannot verify the match between the DS2 RR and DNSKEY2 using 1189 the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a 1190 "security lame" key (see Section 4.4.3). Finally, the child-parent 1191 interaction consists of two steps. The "double signature" method 1192 only needs one interaction. 1193 11944.2.4. Key algorithm rollover 1195 1196 [OK: The txt of this section is a strawman for the issue in: http:// 1197 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll 1198 ] 1199 1200 A special class of keyrollover is the rollover of key algorithms 1201 (either adding a new algorithm, removing an old algorithm, or both), 1202 additional steps are needed to retain integrity during the rollover. 1203 1204 Because of the algorithm downgrade protection in RFC4035 section 2.2, 1205 you may not have a key of an algorithm for which you do not have 1206 signatures. 1207 1208 When adding a new algorithm, the signatures should be added first. 1209 After the TTL has expired, and caches have dropped the old data 1210 covered by those signatures, the DNSKEY with the new algorithm can be 1211 added. When removing an old algorithm, the DNSKEY should be removed 1212 first. 1213 1214 To do both, the following steps can be used. For simplicity, we use 1215 a zone that is only signed by one zone signing key. 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231Kolkman & Gieben Expires September 8, 2009 [Page 22] 1232 1233Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1234 1235 1236 ---------------------------------------------------------------- 1237 1 Initial 2 New RRSIGS 3 New DNSKEY 1238 ---------------------------------------------------------------- 1239 SOA0 SOA1 SOA2 1240 RRSIG1(SOA0) RRSIG1(SOA1) RRSIG1(SOA2) 1241 RRSIG2(SOA1) RRSIG2(SOA2) 1242 1243 DNSKEY1 DNSKEY1 DNSKEY1 1244 RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2 1245 RRSIG2(DNSKEY) RRSIG1(DNSKEY) 1246 RRSIG2(DNSKEY) 1247 ---------------------------------------------------------------- 1248 4 Remove DNSKEY 5 Remove RRSIGS 1249 ---------------------------------------------------------------- 1250 SOA3 SOA4 1251 RRSIG1(SOA3) RRSIG2(SOA4) 1252 RRSIG2(SOA3) 1253 1254 DNSKEY2 DNSKEY2 1255 RRSIG1(DNSKEY) RRSIG2(DNSKEY) 1256 RRSIG2(DNSKEY) 1257 ---------------------------------------------------------------- 1258 1259 Stages of Deployment during an Algorithm Rollover. 1260 1261 In step 2, the signatures for the new key are added, but the key 1262 itself is not. While in theory, the signatures of the keyset should 1263 always be synchronized with the keyset itself, it can be possible 1264 that RRSIGS are requested separately, so it might be prudent to also 1265 sign the DNSKEY set with the new signature. 1266 1267 After the cache data has expired, the new key can be added to the 1268 zone, as done in step 3. 1269 1270 The next step is to remove the old algorithm. This time the key 1271 needs to be removed first, before removing the signatures. The key 1272 is removed in step 4, and after the cache data has expired, the 1273 signatures can be removed in step 5. 1274 1275 The above steps ensure that during the rollover to a new algorithm, 1276 the integrity of the zone is never broken. 1277 12784.2.5. Automated Key Rollovers 1279 1280 As keys must be renewed periodically, there is some motivation to 1281 automate the rollover process. Consider the following: 1282 1283 1284 1285 1286 1287Kolkman & Gieben Expires September 8, 2009 [Page 23] 1288 1289Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1290 1291 1292 o ZSK rollovers are easy to automate as only the child zone is 1293 involved. 1294 1295 o A KSK rollover needs interaction between parent and child. Data 1296 exchange is needed to provide the new keys to the parent; 1297 consequently, this data must be authenticated and integrity must 1298 be guaranteed in order to avoid attacks on the rollover. 1299 13004.3. Planning for Emergency Key Rollover 1301 1302 This section deals with preparation for a possible key compromise. 1303 Our advice is to have a documented procedure ready for when a key 1304 compromise is suspected or confirmed. 1305 1306 When the private material of one of your keys is compromised it can 1307 be used for as long as a valid trust chain exists. A trust chain 1308 remains intact for 1309 1310 o as long as a signature over the compromised key in the trust chain 1311 is valid, 1312 1313 o as long as a parental DS RR (and signature) points to the 1314 compromised key, 1315 1316 o as long as the key is anchored in a resolver and is used as a 1317 starting point for validation (this is generally the hardest to 1318 update). 1319 1320 While a trust chain to your compromised key exists, your namespace is 1321 vulnerable to abuse by anyone who has obtained illegitimate 1322 possession of the key. Zone operators have to make a trade-off if 1323 the abuse of the compromised key is worse than having data in caches 1324 that cannot be validated. If the zone operator chooses to break the 1325 trust chain to the compromised key, data in caches signed with this 1326 key cannot be validated. However, if the zone administrator chooses 1327 to take the path of a regular rollover, the malicious key holder can 1328 spoof data so that it appears to be valid. 1329 13304.3.1. KSK Compromise 1331 1332 A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable 1333 as long as the compromised KSK is configured as trust anchor or a 1334 parental DS points to it. 1335 1336 A compromised KSK can be used to sign the key set of an attacker's 1337 zone. That zone could be used to poison the DNS. 1338 1339 Therefore, when the KSK has been compromised, the trust anchor or the 1340 1341 1342 1343Kolkman & Gieben Expires September 8, 2009 [Page 24] 1344 1345Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1346 1347 1348 parental DS should be replaced as soon as possible. It is local 1349 policy whether to break the trust chain during the emergency 1350 rollover. The trust chain would be broken when the compromised KSK 1351 is removed from the child's zone while the parent still has a DS 1352 pointing to the compromised KSK (the assumption is that there is only 1353 one DS at the parent. If there are multiple DSes this does not apply 1354 -- however the chain of trust of this particular key is broken). 1355 1356 Note that an attacker's zone still uses the compromised KSK and the 1357 presence of a parental DS would cause the data in this zone to appear 1358 as valid. Removing the compromised key would cause the attacker's 1359 zone to appear as valid and the child's zone as Bogus. Therefore, we 1360 advise not to remove the KSK before the parent has a DS to a new KSK 1361 in place. 1362 13634.3.1.1. Keeping the Chain of Trust Intact 1364 1365 If we follow this advice, the timing of the replacement of the KSK is 1366 somewhat critical. The goal is to remove the compromised KSK as soon 1367 as the new DS RR is available at the parent. And also make sure that 1368 the signature made with a new KSK over the key set with the 1369 compromised KSK in it expires just after the new DS appears at the 1370 parent, thus removing the old cruft in one swoop. 1371 1372 The procedure is as follows: 1373 1374 1. Introduce a new KSK into the key set, keep the compromised KSK in 1375 the key set. 1376 1377 2. Sign the key set, with a short validity period. The validity 1378 period should expire shortly after the DS is expected to appear 1379 in the parent and the old DSes have expired from caches. 1380 1381 3. Upload the DS for this new key to the parent. 1382 1383 4. Follow the procedure of the regular KSK rollover: Wait for the DS 1384 to appear in the authoritative servers and then wait as long as 1385 the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet 1386 and modify/extend the expiration time. 1387 1388 5. Remove the compromised DNSKEY RR from the zone and re-sign the 1389 key set using your "normal" validity interval. 1390 1391 An additional danger of a key compromise is that the compromised key 1392 could be used to facilitate a legitimate DNSKEY/DS rollover and/or 1393 nameserver changes at the parent. When that happens, the domain may 1394 be in dispute. An authenticated out-of-band and secure notify 1395 mechanism to contact a parent is needed in this case. 1396 1397 1398 1399Kolkman & Gieben Expires September 8, 2009 [Page 25] 1400 1401Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1402 1403 1404 Note that this is only a problem when the DNSKEY and or DS records 1405 are used for authentication at the parent. 1406 14074.3.1.2. Breaking the Chain of Trust 1408 1409 There are two methods to break the chain of trust. The first method 1410 causes the child zone to appear 'Bogus' to validating resolvers. The 1411 other causes the child zone to appear 'insecure'. These are 1412 described below. 1413 1414 In the method that causes the child zone to appear 'Bogus' to 1415 validating resolvers, the child zone replaces the current KSK with a 1416 new one and re-signs the key set. Next it sends the DS of the new 1417 key to the parent. Only after the parent has placed the new DS in 1418 the zone is the child's chain of trust repaired. 1419 1420 An alternative method of breaking the chain of trust is by removing 1421 the DS RRs from the parent zone altogether. As a result, the child 1422 zone would become insecure. 1423 14244.3.2. ZSK Compromise 1425 1426 Primarily because there is no parental interaction required when a 1427 ZSK is compromised, the situation is less severe than with a KSK 1428 compromise. The zone must still be re-signed with a new ZSK as soon 1429 as possible. As this is a local operation and requires no 1430 communication between the parent and child, this can be achieved 1431 fairly quickly. However, one has to take into account that just as 1432 with a normal rollover the immediate disappearance of the old 1433 compromised key may lead to verification problems. Also note that as 1434 long as the RRSIG over the compromised ZSK is not expired the zone 1435 may be still at risk. 1436 14374.3.3. Compromises of Keys Anchored in Resolvers 1438 1439 A key can also be pre-configured in resolvers. For instance, if 1440 DNSSEC is successfully deployed the root key may be pre-configured in 1441 most security aware resolvers. 1442 1443 If trust-anchor keys are compromised, the resolvers using these keys 1444 should be notified of this fact. Zone administrators may consider 1445 setting up a mailing list to communicate the fact that a SEP key is 1446 about to be rolled over. This communication will of course need to 1447 be authenticated, e.g., by using digital signatures. 1448 1449 End-users faced with the task of updating an anchored key should 1450 always validate the new key. New keys should be authenticated out- 1451 of-band, for example, through the use of an announcement website that 1452 1453 1454 1455Kolkman & Gieben Expires September 8, 2009 [Page 26] 1456 1457Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1458 1459 1460 is secured using secure sockets (TLS) [23]. 1461 14624.4. Parental Policies 1463 14644.4.1. Initial Key Exchanges and Parental Policies Considerations 1465 1466 The initial key exchange is always subject to the policies set by the 1467 parent. When designing a key exchange policy one should take into 1468 account that the authentication and authorization mechanisms used 1469 during a key exchange should be as strong as the authentication and 1470 authorization mechanisms used for the exchange of delegation 1471 information between parent and child. That is, there is no implicit 1472 need in DNSSEC to make the authentication process stronger than it 1473 was in DNS. 1474 1475 Using the DNS itself as the source for the actual DNSKEY material, 1476 with an out-of-band check on the validity of the DNSKEY, has the 1477 benefit that it reduces the chances of user error. A DNSKEY query 1478 tool can make use of the SEP bit [5] to select the proper key from a 1479 DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is 1480 sent. It can validate the self-signature over a key; thereby 1481 verifying the ownership of the private key material. Fetching the 1482 DNSKEY from the DNS ensures that the chain of trust remains intact 1483 once the parent publishes the DS RR indicating the child is secure. 1484 1485 Note: the out-of-band verification is still needed when the key 1486 material is fetched via the DNS. The parent can never be sure 1487 whether or not the DNSKEY RRs have been spoofed. 1488 14894.4.2. Storing Keys or Hashes? 1490 1491 When designing a registry system one should consider which of the 1492 DNSKEYs and/or the corresponding DSes to store. Since a child zone 1493 might wish to have a DS published using a message digest algorithm 1494 not yet understood by the registry, the registry can't count on being 1495 able to generate the DS record from a raw DNSKEY. Thus, we recommend 1496 that registry systems at least support storing DS records. 1497 1498 It may also be useful to store DNSKEYs, since having them may help 1499 during troubleshooting and, as long as the child's chosen message 1500 digest is supported, the overhead of generating DS records from them 1501 is minimal. Having an out-of-band mechanism, such as a registry 1502 directory (e.g., Whois), to find out which keys are used to generate 1503 DS Resource Records for specific owners and/or zones may also help 1504 with troubleshooting. 1505 1506 The storage considerations also relate to the design of the customer 1507 interface and the method by which data is transferred between 1508 1509 1510 1511Kolkman & Gieben Expires September 8, 2009 [Page 27] 1512 1513Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1514 1515 1516 registrant and registry; Will the child zone administrator be able to 1517 upload DS RRs with unknown hash algorithms or does the interface only 1518 allow DNSKEYs? In the registry-registrar model, one can use the 1519 DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], 1520 which allows transfer of DS RRs and optionally DNSKEY RRs. 1521 15224.4.3. Security Lameness 1523 1524 Security lameness is defined as what happens when a parent has a DS 1525 RR pointing to a non-existing DNSKEY RR. When this happens, the 1526 child's zone may be marked "Bogus" by verifying DNS clients. 1527 1528 As part of a comprehensive delegation check, the parent could, at key 1529 exchange time, verify that the child's key is actually configured in 1530 the DNS. However, if a parent does not understand the hashing 1531 algorithm used by child, the parental checks are limited to only 1532 comparing the key id. 1533 1534 Child zones should be very careful in removing DNSKEY material, 1535 specifically SEP keys, for which a DS RR exists. 1536 1537 Once a zone is "security lame", a fix (e.g., removing a DS RR) will 1538 take time to propagate through the DNS. 1539 15404.4.4. DS Signature Validity Period 1541 1542 Since the DS can be replayed as long as it has a valid signature, a 1543 short signature validity period over the DS minimizes the time a 1544 child is vulnerable in the case of a compromise of the child's 1545 KSK(s). A signature validity period that is too short introduces the 1546 possibility that a zone is marked "Bogus" in case of a configuration 1547 error in the signer. There may not be enough time to fix the 1548 problems before signatures expire. Something as mundane as operator 1549 unavailability during weekends shows the need for DS signature 1550 validity periods longer than 2 days. We recommend an absolute 1551 minimum for a DS signature validity period of a few days. 1552 1553 The maximum signature validity period of the DS record depends on how 1554 long child zones are willing to be vulnerable after a key compromise. 1555 On the other hand, shortening the DS signature validity interval 1556 increases the operational risk for the parent. Therefore, the parent 1557 may have policy to use a signature validity interval that is 1558 considerably longer than the child would hope for. 1559 1560 A compromise between the operational constraints of the parent and 1561 minimizing damage for the child may result in a DS signature validity 1562 period somewhere between a week and months. 1563 1564 1565 1566 1567Kolkman & Gieben Expires September 8, 2009 [Page 28] 1568 1569Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1570 1571 1572 In addition to the signature validity period, which sets a lower 1573 bound on the number of times the zone owner will need to sign the 1574 zone data and which sets an upper bound to the time a child is 1575 vulnerable after key compromise, there is the TTL value on the DS 1576 RRs. Shortening the TTL means that the authoritative servers will 1577 see more queries. But on the other hand, a short TTL lowers the 1578 persistence of DS RRSets in caches thereby increasing the speed with 1579 which updated DS RRSets propagate through the DNS. 1580 15814.4.5. (Non) Cooperating Registrars 1582 1583 [OK: this is a first strawman, and is intended to start the 1584 discussion of the issue. By no means this is intended to be a final 1585 text.] 1586 1587 The parent-child relation is often described in terms of a (thin) 1588 registry model. Where a registry maintains the parent zone, and the 1589 registrant (the user of the child-domain name), deals with the 1590 registry through an intermediary called a registrar. (See [12] for a 1591 comprehensive definition). Registrants may out-source the 1592 maintenance of their DNS system, including the maintenance of DNSSEC 1593 key material, to the registrar or to another third party. The entity 1594 that has control over the DNS zone and its keys may prevent the 1595 registrant to make a timely move to a different registrar. [OK: I 1596 use the term registrar below while it is the operator of the DNS zone 1597 who is the actual culprit. For instance, the case also applies when 1598 a registrant passes a zone to another registrant. Should I just use 1599 "DNS Administrator"?] 1600 1601 Suppose that the registrant wants to move from losing registrar A to 1602 gaining registrar B. Let us first look what would happen in a 1603 cooperative environment. The assumption is that registrar A will not 1604 hand off any private key material to registrar B because that would 1605 be a trivial case. 1606 1607 In a cooperating environment one could proceed with a pre-publish ZSK 1608 rollover whereby registrar A pre-publishes the ZSK of registrar B, 1609 combined with a double signature KSK rollover where the two 1610 registrars exchange public keys and independently generate a 1611 signature over the keysets that they combine and both publish in the 1612 zone. 1613 1614 In the non-cooperative case matters are more complicated. The 1615 loosing registrar A may not cooperate and leave the data in the DNS 1616 as is. In the extreme case registrar A may become obstructive and 1617 publish a DNSKEY RR with a high TTL and corresponding signature 1618 validity so that registrar A's DNSKEY, would end up in caches for, in 1619 theory, tens of years. 1620 1621 1622 1623Kolkman & Gieben Expires September 8, 2009 [Page 29] 1624 1625Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1626 1627 1628 The problem arises when a validator tries to validate with A's key 1629 and there is no signature material produced with Registrars A 1630 available in the delegation path after redelegation from registrar A 1631 to registrar B has taken place. One could imagine a rollover 1632 scenario where registrar B pulls all RRSIGs created by registar A and 1633 publishes those in conjunction with its own signatures, but that 1634 would not allow any changes in the zone content. Since a 1635 redelegation took place the NS RRset has -- per definition-- changed 1636 so such rollover scenario will not work. Besides if zone transfers 1637 are not allowed by A and NSEC3 is deployed in the A's zone then 1638 registrar B will not have certainty that all of A's RRSIGs are 1639 transfered. 1640 1641 The only viable option for the registrant is to publish its zone 1642 unsigned and ask the registry to remove the DS pointing to registrar 1643 A for as long as the DNSKEY of registrar A, or any of the signatures 1644 produced by registrar A are likely to appear in caches, which as 1645 mentioned above could in theory be for tens of years. [OK: Some 1646 implementations limit the time data is cached. Although that is not 1647 a protocol requirement (and may even be considered a protocol 1648 violation) it seems that that practice may limit the impact of this 1649 problem, is that worth mentioning?] 1650 1651 [OK: This is really the point that I'm trying to make, is the above 1652 text needed?] There is no operational methodology to work around 1653 this business issue and proper contractual relations ships between 1654 registrants and their registrars seem to be the only solution to cope 1655 with these problems. 1656 16575. Security Considerations 1658 1659 DNSSEC adds data integrity to the DNS. This document tries to assess 1660 the operational considerations to maintain a stable and secure DNSSEC 1661 service. Not taking into account the 'data propagation' properties 1662 in the DNS will cause validation failures and may make secured zones 1663 unavailable to security-aware resolvers. 1664 16656. IANA considerations 1666 1667 There are no IANA considerations with respect to this document 1668 16697. Acknowledgments 1670 1671 Most of the text of this document is copied from RFC4641 [16] people 1672 involved in that work were in random order: Rip Loomis, Olafur 1673 Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van 1674 Rein, Tim McGinnis, Gilles Guette Olivier Courtay, Sam Weiler, Jelte 1675 Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, 1676 1677 1678 1679Kolkman & Gieben Expires September 8, 2009 [Page 30] 1680 1681Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1682 1683 1684 Marcos Sanz, Peter Koch, Mike StJohns, Emmar Bretherick, Adrian 1685 Bedford, and Lindy Foster, G. Guette, and O. Courtay. 1686 1687 For this version of the document we would like to acknowldge: 1688 1689 o Paul Hoffman for his contribution on the choice of cryptographic 1690 paramenters and addressing some of the trust anchor issues. 1691 1692 o Jelte Jansen provided the text in Section 4.2.4 1693 16948. References 1695 16968.1. Normative References 1697 1698 [1] Mockapetris, P., "Domain names - concepts and facilities", 1699 STD 13, RFC 1034, November 1987. 1700 1701 [2] Mockapetris, P., "Domain names - implementation and 1702 specification", STD 13, RFC 1035, November 1987. 1703 1704 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1705 "DNS Security Introduction and Requirements", RFC 4033, 1706 March 2005. 1707 1708 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1709 "Resource Records for the DNS Security Extensions", RFC 4034, 1710 March 2005. 1711 1712 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1713 "Protocol Modifications for the DNS Security Extensions", 1714 RFC 4035, March 2005. 1715 17168.2. Informative References 1717 1718 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1719 Levels", BCP 14, RFC 2119, March 1997. 1720 1721 [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1722 August 1996. 1723 1724 [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 1725 (DNS NOTIFY)", RFC 1996, August 1996. 1726 1727 [9] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1728 RFC 2308, March 1998. 1729 1730 [10] Eastlake, D., "DNS Security Operational Considerations", 1731 RFC 2541, March 1999. 1732 1733 1734 1735Kolkman & Gieben Expires September 8, 2009 [Page 31] 1736 1737Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1738 1739 1740 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1741 Update", RFC 3007, November 2000. 1742 1743 [12] Hollenbeck, S., "Generic Registry-Registrar Protocol 1744 Requirements", RFC 3375, September 2002. 1745 1746 [13] Orman, H. and P. Hoffman, "Determining Strengths For Public 1747 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 1748 April 2004. 1749 1750 [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1751 Requirements for Security", BCP 106, RFC 4086, June 2005. 1752 1753 [15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 1754 Mapping for the Extensible Provisioning Protocol (EPP)", 1755 RFC 4310, December 2005. 1756 1757 [16] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1758 RFC 4641, September 2006. 1759 1760 [17] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 1761 August 2007. 1762 1763 [18] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust 1764 Anchors", RFC 5011, September 2007. 1765 1766 [19] Rose, S., "NIST DNSSEC workshop notes", , June 2001. 1767 1768 [20] Barker, E. and J. Kelsey, "Recommendation for Random Number 1769 Generation Using Deterministic Random Bit Generators 1770 (Revised)", Nist Special Publication 800-90, March 2007. 1771 1772 [21] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY and 1773 RRSIG Resource Records for DNSSEC", 1774 draft-ietf-dnsext-dnssec-rsasha256-05 (work in progress), 1775 July 2008. 1776 1777 [22] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 1778 Resource Records (RRs)", RFC 4509, May 2006. 1779 1780 [23] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1781 T. Wright, "Transport Layer Security (TLS) Extensions", 1782 RFC 4366, April 2006. 1783 1784Appendix A. Terminology 1785 1786 In this document, there is some jargon used that is defined in other 1787 documents. In most cases, we have not copied the text from the 1788 1789 1790 1791Kolkman & Gieben Expires September 8, 2009 [Page 32] 1792 1793Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1794 1795 1796 documents defining the terms but have given a more elaborate 1797 explanation of the meaning. Note that these explanations should not 1798 be seen as authoritative. 1799 1800 Anchored key: A DNSKEY configured in resolvers around the globe. 1801 This key is hard to update, hence the term anchored. 1802 1803 Bogus: Also see Section 5 of [3]. An RRSet in DNSSEC is marked 1804 "Bogus" when a signature of an RRSet does not validate against a 1805 DNSKEY. 1806 1807 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is 1808 used exclusively for signing the apex key set. The fact that a 1809 key is a KSK is only relevant to the signing tool. 1810 1811 Key size: The term 'key size' can be substituted by 'modulus size' 1812 throughout the document. It is mathematically more correct to use 1813 modulus size, but as this is a document directed at operators we 1814 feel more at ease with the term key size. 1815 1816 Private and public keys: DNSSEC secures the DNS through the use of 1817 public key cryptography. Public key cryptography is based on the 1818 existence of two (mathematically related) keys, a public key and a 1819 private key. The public keys are published in the DNS by use of 1820 the DNSKEY Resource Record (DNSKEY RR). Private keys should 1821 remain private. 1822 1823 Key rollover: A key rollover (also called key supercession in some 1824 environments) is the act of replacing one key pair with another at 1825 the end of a key effectivity period. 1826 1827 Secure Entry Point (SEP) key: A KSK that has a parental DS record 1828 pointing to it or is configured as a trust anchor. Although not 1829 required by the protocol, we recommend that the SEP flag [5] is 1830 set on these keys. 1831 1832 Self-signature: This only applies to signatures over DNSKEYs; a 1833 signature made with DNSKEY x, over DNSKEY x is called a self- 1834 signature. Note: without further information, self-signatures 1835 convey no trust. They are useful to check the authenticity of the 1836 DNSKEY, i.e., they can be used as a hash. 1837 1838 Singing the zone file: The term used for the event where an 1839 administrator joyfully signs its zone file while producing melodic 1840 sound patterns. 1841 1842 1843 1844 1845 1846 1847Kolkman & Gieben Expires September 8, 2009 [Page 33] 1848 1849Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1850 1851 1852 Signer: The system that has access to the private key material and 1853 signs the Resource Record sets in a zone. A signer may be 1854 configured to sign only parts of the zone, e.g., only those RRSets 1855 for which existing signatures are about to expire. 1856 1857 Zone Signing Key (ZSK): A key that is used for signing all data in a 1858 zone (except, perhaps, the DNSKEY RRSet). The fact that a key is 1859 a ZSK is only relevant to the signing tool. 1860 1861 Zone administrator: The 'role' that is responsible for signing a 1862 zone and publishing it on the primary authoritative server. 1863 1864Appendix B. Zone Signing Key Rollover How-To 1865 1866 Using the pre-published signature scheme and the most conservative 1867 method to assure oneself that data does not live in caches, here 1868 follows the "how-to". 1869 1870 Step 0: The preparation: Create two keys and publish both in your 1871 key set. Mark one of the keys "active" and the other "published". 1872 Use the "active" key for signing your zone data. Store the 1873 private part of the "published" key, preferably off-line. The 1874 protocol does not provide for attributes to mark a key as active 1875 or published. This is something you have to do on your own, 1876 through the use of a notebook or key management tool. 1877 1878 Step 1: Determine expiration: At the beginning of the rollover make 1879 a note of the highest expiration time of signatures in your zone 1880 file created with the current key marked as active. Wait until 1881 the expiration time marked in Step 1 has passed. 1882 1883 Step 2: Then start using the key that was marked "published" to sign 1884 your data (i.e., mark it "active"). Stop using the key that was 1885 marked "active"; mark it "rolled". 1886 1887 Step 3: It is safe to engage in a new rollover (Step 1) after at 1888 least one signature validity period. 1889 1890Appendix C. Typographic Conventions 1891 1892 The following typographic conventions are used in this document: 1893 1894 Key notation: A key is denoted by DNSKEYx, where x is a number or an 1895 identifier, x could be thought of as the key id. 1896 1897 1898 1899 1900 1901 1902 1903Kolkman & Gieben Expires September 8, 2009 [Page 34] 1904 1905Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1906 1907 1908 RRSet notations: RRs are only denoted by the type. All other 1909 information -- owner, class, rdata, and TTL -- is left out. Thus: 1910 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a 1911 list of RRs. A example of this would be "A1, A2", specifying the 1912 RRSet containing two "A" records. This could again be abbreviated 1913 to just "A". 1914 1915 Signature notation: Signatures are denoted as RRSIGx(RRSet), which 1916 means that RRSet is signed with DNSKEYx. 1917 1918 Zone representation: Using the above notation we have simplified the 1919 representation of a signed zone by leaving out all unnecessary 1920 details such as the names and by representing all data by "SOAx" 1921 1922 SOA representation: SOAs are represented as SOAx, where x is the 1923 serial number. 1924 1925 Using this notation the following signed zone: 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959Kolkman & Gieben Expires September 8, 2009 [Page 35] 1960 1961Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 1962 1963 1964 example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 1965 2006022100 ; serial 1966 86400 ; refresh ( 24 hours) 1967 7200 ; retry ( 2 hours) 1968 3600000 ; expire (1000 hours) 1969 28800 ) ; minimum ( 8 hours) 1970 86400 RRSIG SOA 5 2 86400 20130522213204 ( 1971 20130422213204 14 example.net. 1972 cmL62SI6iAX46xGNQAdQ... ) 1973 86400 NS a.example.net. 1974 86400 NS b.example.net. 1975 86400 RRSIG NS 5 2 86400 20130507213204 ( 1976 20130407213204 14 example.net. 1977 SO5epiJei19AjXoUpFnQ ... ) 1978 86400 DNSKEY 256 3 5 ( 1979 EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 1980 86400 DNSKEY 257 3 5 ( 1981 gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 1982 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1983 20130422213204 14 example.net. 1984 J4zCe8QX4tXVGjV4e1r9... ) 1985 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1986 20130422213204 15 example.net. 1987 keVDCOpsSeDReyV6O... ) 1988 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 1989 20130407213204 14 example.net. 1990 obj3HEp1GjnmhRjX... ) 1991 a.example.net. 86400 IN TXT "A label" 1992 86400 RRSIG TXT 5 3 86400 20130507213204 ( 1993 20130407213204 14 example.net. 1994 IkDMlRdYLmXH7QJnuF3v... ) 1995 86400 NSEC b.example.com. TXT RRSIG NSEC 1996 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 1997 20130407213204 14 example.net. 1998 bZMjoZ3bHjnEz0nIsPMM... ) 1999 ... 2000 2001 is reduced to the following representation: 2002 2003 SOA2006022100 2004 RRSIG14(SOA2006022100) 2005 DNSKEY14 2006 DNSKEY15 2007 2008 RRSIG14(KEY) 2009 RRSIG15(KEY) 2010 2011 The rest of the zone data has the same signature as the SOA record, 2012 2013 2014 2015Kolkman & Gieben Expires September 8, 2009 [Page 36] 2016 2017Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 2018 2019 2020 i.e., an RRSIG created with DNSKEY 14. 2021 2022Appendix D. Document Editing History 2023 2024 [To be removed prior to publication as an RFC] 2025 2026D.1. draft-ietf-dnsop-rfc4641-00 2027 2028 Version 0 was differs from RFC4641 in the following ways. 2029 2030 o Status of this memo appropriate for I-D 2031 2032 o TOC formatting differs. 2033 2034 o Whitespaces, linebreaks, and pagebreaks may be slightly different 2035 because of xml2rfc generation. 2036 2037 o References slightly reordered. 2038 2039 o Applied the errata from 2040 http://www.rfc-editor.org/errata_search.php?rfc=4641 2041 2042 o Inserted trivial "IANA considertations" section. 2043 2044 In other words it should not contain substantive changes in content 2045 as intended by the workinggroup for the original RFC4641. 2046 2047D.2. version 0->1 2048 2049 Cryptography details rewritten. (See http://www.nlnetlabs.nl/svn/ 2050 rfc4641bis/trunk/open-issues/cryptography_flawed) 2051 2052 o Reference to NIST 800-90 added 2053 2054 o RSA/SHA256 is being recommended in addition to RSA/SHA1. 2055 2056 o Complete rewrite of Section 3.5 removing the table and suggesting 2057 a keysize of 1024 for keys in use for less than 8 years, issued up 2058 to at least 2015. 2059 2060 o Replaced the reference to Schneiers' applied cryptograpy with a 2061 reference to RFC4949. 2062 2063 o Removed the KSK for high level zones consideration 2064 2065 Applied some differentiation with respect of the use of a KSK for 2066 parent or trust-anchor relation http://www.nlnetlabs.nl/svn/ 2067 rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent 2068 2069 2070 2071Kolkman & Gieben Expires September 8, 2009 [Page 37] 2072 2073Internet-Draft DNSSEC Operational Practices, Version 2 March 2009 2074 2075 2076 http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 2077 rollover_assumptions 2078 2079 Added Section 4.2.4 as suggested by Jelte Jansen in http:// 2080 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll 2081 2082 Added Section 4.4.5 Issue identified by Antoin Verschuur http:// 2083 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 2084 non-cooperative-registrars 2085 2086 In Appendix A: ZSK does not nescessarily sign the DNSKEY RRset. 2087 2088 Id: draft-ietf-dnsop-rfc4641bis-01.txt 28 2009-03-06 14:03:57Z olaf 2089 2090Authors' Addresses 2091 2092 Olaf M. Kolkman 2093 NLnet Labs 2094 Kruislaan 419 2095 Amsterdam 1098 VA 2096 The Netherlands 2097 2098 EMail: olaf@nlnetlabs.nl 2099 URI: http://www.nlnetlabs.nl 2100 2101 2102 Miek Gieben 2103 2104 2105 EMail: miek@miek.nl 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127Kolkman & Gieben Expires September 8, 2009 [Page 38] 2128 2129