idnits 2.17.1 draft-ietf-dnsop-rfc4641bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document obsoletes RFC2541, but the abstract doesn't seem to mention this, which it should. -- The abstract seems to indicate that this document obsoletes RFC4641, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2010) is 5172 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 1789, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4310 (ref. '14') (Obsoleted by RFC 5910) -- Obsolete informational reference (is this intentional?): RFC 4641 (ref. '15') (Obsoleted by RFC 6781) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '22') (Obsoleted by RFC 8446) == Outdated reference: A later version (-02) exists of draft-morris-dnsop-dnssec-key-timing-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP O. Kolkman 3 Internet-Draft NLnet Labs 4 Obsoletes: 2541 (if approved) R. Gieben 5 Intended status: BCP 6 Expires: August 30, 2010 February 26, 2010 8 DNSSEC Operational Practices, Version 2 9 draft-ietf-dnsop-rfc4641bis-02 11 Abstract 13 This document describes a set of practices for operating the DNS with 14 security extensions (DNSSEC). The target audience is zone 15 administrators deploying DNSSEC. 17 The document discusses operational aspects of using keys and 18 signatures in the DNS. It discusses issues of key generation, key 19 storage, signature generation, key rollover, and related policies. 21 [When apporoved] This document obsoletes RFC 4641 as it covers more 22 operational ground and gives more up-to-date requirements with 23 respect to key sizes and the DNSSEC operations. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 30, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 5 78 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 79 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 80 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 81 3.1. Operational motivation for ZSKs and KSKs . . . . . . . . . 6 82 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7 83 3.1.2. Practical concequences of KSK and ZSK Separation . . . 8 84 3.1.2.1. Rolling a KSK that is not a trust-anchor . . . . . 8 85 3.1.2.2. Rolling a KSK that is a trust-anchor . . . . . . . 9 86 3.1.3. Key Effectivity Period . . . . . . . . . . . . . . . . 10 87 3.1.4. Cryptographic Considerations . . . . . . . . . . . . . 11 88 3.1.4.1. Key Algorithm . . . . . . . . . . . . . . . . . . 11 89 3.1.4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . 11 90 3.1.4.3. Private Key Storage . . . . . . . . . . . . . . . 12 91 3.1.4.4. Key Generation . . . . . . . . . . . . . . . . . . 13 92 3.1.4.5. Differentiation for 'High-Level' Zones . . . . . . 14 93 4. Signature Generation, Key Rollover, and Related Policies . . . 14 94 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 14 95 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 15 96 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 17 97 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 17 98 4.2.1.1. Pre-Publish Key Rollover . . . . . . . . . . . . . 17 99 4.2.1.2. Double Signature Zone Signing Key Rollover . . . . 19 100 4.2.1.3. Pros and Cons of the Schemes . . . . . . . . . . . 21 101 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 21 102 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 23 103 4.2.4. Key algorithm rollover . . . . . . . . . . . . . . . . 24 104 4.2.5. Automated Key Rollovers . . . . . . . . . . . . . . . 25 105 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 26 106 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 26 107 4.3.1.1. Keeping the Chain of Trust Intact . . . . . . . . 27 108 4.3.1.2. Breaking the Chain of Trust . . . . . . . . . . . 28 109 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 28 110 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 28 111 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 29 112 4.4.1. Initial Key Exchanges and Parental Policies 113 Considerations . . . . . . . . . . . . . . . . . . . . 29 114 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 29 115 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 30 116 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 30 117 4.4.5. Changing DNS Operators . . . . . . . . . . . . . . . . 31 118 4.4.5.1. Cooperationg DNS operators . . . . . . . . . . . . 31 119 4.4.5.2. Non Cooperationg DNS Operators . . . . . . . . . . 33 120 5. Next Record type . . . . . . . . . . . . . . . . . . . . . . . 34 121 5.1. Differences between NSEC and NSEC3 . . . . . . . . . . . 34 122 5.2. NSEC or NSEC3 . . . . . . . . . . . . . . . . . . . . . . 35 123 5.3. NSEC3 parameters . . . . . . . . . . . . . . . . . . . . . 35 124 5.3.1. NSEC3 Algorithm . . . . . . . . . . . . . . . . . . . 36 125 5.3.2. NSEC3 Iterations . . . . . . . . . . . . . . . . . . . 36 126 5.3.3. NSEC3 Salt . . . . . . . . . . . . . . . . . . . . . . 36 127 5.3.4. Opt-out . . . . . . . . . . . . . . . . . . . . . . . 37 128 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 129 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 37 130 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 131 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 132 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 133 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 134 Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 40 135 Appendix B. Zone Signing Key Rollover How-To . . . . . . . . . . 41 136 Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 42 137 Appendix D. Document Editing History . . . . . . . . . . . . . . 44 138 D.1. draft-ietf-dnsop-rfc4641-00 . . . . . . . . . . . . . . . 44 139 D.2. version 0->1 . . . . . . . . . . . . . . . . . . . . . . . 44 140 D.3. version 1->2 . . . . . . . . . . . . . . . . . . . . . . . 45 142 1. Introduction 144 This document describes how to run a DNS Security (DNSSEC)-enabled 145 environment. It is intended for operators who have knowledge of the 146 DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. 147 See RFC 4033 [3] for an introduction to DNSSEC, RFC 4034 [4] for the 148 newly introduced Resource Records (RRs), and RFC 4035 [5] for the 149 protocol changes. 151 During workshops and early operational deployment tests, operators 152 and system administrators have gained experience about operating the 153 DNS with security extensions (DNSSEC). This document translates 154 these experiences into a set of practices for zone administrators. 155 At the time of writing, there exists very little experience with 156 DNSSEC in production environments; this document should therefore 157 explicitly not be seen as representing 'Best Current Practices'. 158 [OK: Is this document ripe enough to shoot for BCP?] 160 The procedures herein are focused on the maintenance of signed zones 161 (i.e., signing and publishing zones on authoritative servers). It is 162 intended that maintenance of zones such as re-signing or key 163 rollovers be transparent to any verifying clients on the Internet. 165 The structure of this document is as follows. In Section 2, we 166 discuss the importance of keeping the "chain of trust" intact. 167 Aspects of key generation and storage of private keys are discussed 168 in Section 3; the focus in this section is mainly on the private part 169 of the key(s). Section 4 describes considerations concerning the 170 public part of the keys. Since these public keys appear in the DNS 171 one has to take into account all kinds of timing issues, which are 172 discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the 173 rollover, or supercession, of keys. Finally, Section 4.4 discusses 174 considerations on how parents deal with their children's public keys 175 in order to maintain chains of trust. 177 The typographic conventions used in this document are explained in 178 Appendix C. 180 Since this is a document with operational suggestions and there are 181 no protocol specifications, the RFC 2119 [6] language does not apply. 183 This document [OK: when approved] obsoletes RFC 4641 [15]. 185 [OK: Editorial comments and questions are indicated by square 186 brackets and editor innitials] 188 1.1. The Use of the Term 'key' 190 It is assumed that the reader is familiar with the concept of 191 asymmetric keys on which DNSSEC is based (public key cryptography 192 RFC4949 [16]). Therefore, this document will use the term 'key' 193 rather loosely. Where it is written that 'a key is used to sign 194 data' it is assumed that the reader understands that it is the 195 private part of the key pair that is used for signing. It is also 196 assumed that the reader understands that the public part of the key 197 pair is published in the DNSKEY Resource Record and that it is the 198 public part that is used in key exchanges. 200 1.2. Time Definitions 202 In this document, we will be using a number of time-related terms. 203 The following definitions apply: 205 o "Signature validity period" The period that a signature is valid. 206 It starts at the time specified in the signature inception field 207 of the RRSIG RR and ends at the time specified in the expiration 208 field of the RRSIG RR. 210 o "Signature publication period" Time after which a signature (made 211 with a specific key) is replaced with a new signature (made with 212 the same key). This replacement takes place by publishing the 213 relevant RRSIG in the master zone file. After one stops 214 publishing an RRSIG in a zone, it may take a while before the 215 RRSIG has expired from caches and has actually been removed from 216 the DNS. 218 o "Key effectivity period" The period during which a key pair is 219 expected to be effective. This period is defined as the time 220 between the first inception time stamp and the last expiration 221 date of any signature made with this key, regardless of any 222 discontinuity in the use of the key. The key effectivity period 223 can span multiple signature validity periods. 225 o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum 226 value of the TTLs from the complete set of RRs in a zone. Note 227 that the minimum TTL is not the same as the MINIMUM field in the 228 SOA RR. See [9] for more information. 230 2. Keeping the Chain of Trust Intact 232 Maintaining a valid chain of trust is important because broken chains 233 of trust will result in data being marked as Bogus (as defined in [3] 234 Section 5), which may cause entire (sub)domains to become invisible 235 to verifying clients. The administrators of secured zones have to 236 realize that their zone is, to verifying clients, part of a chain of 237 trust. 239 As mentioned in the introduction, the procedures herein are intended 240 to ensure that maintenance of zones, such as re-signing or key 241 rollovers, will be transparent to the verifying clients on the 242 Internet. 244 Administrators of secured zones will have to keep in mind that data 245 published on an authoritative primary server will not be immediately 246 seen by verifying clients; it may take some time for the data to be 247 transferred to other secondary authoritative nameservers and clients 248 may be fetching data from caching non-authoritative servers. In this 249 light, note that the time for a zone transfer from master to slave is 250 negligible when using NOTIFY [8] and incremental transfer (IXFR) [7]. 251 It increases when full zone transfers (AXFR) are used in combination 252 with NOTIFY. It increases even more if you rely on full zone 253 transfers based on only the SOA timing parameters for refresh. 255 For the verifying clients, it is important that data from secured 256 zones can be used to build chains of trust regardless of whether the 257 data came directly from an authoritative server, a caching 258 nameserver, or some middle box. Only by carefully using the 259 available timing parameters can a zone administrator ensure that the 260 data necessary for verification can be obtained. 262 The responsibility for maintaining the chain of trust is shared by 263 administrators of secured zones in the chain of trust. This is most 264 obvious in the case of a 'key compromise' when a trade-off between 265 maintaining a valid chain of trust and replacing the compromised keys 266 as soon as possible must be made. Then zone administrators will have 267 to make a trade-off, between keeping the chain of trust intact -- 268 thereby allowing for attacks with the compromised key -- or 269 deliberately breaking the chain of trust and making secured 270 subdomains invisible to security-aware resolvers. Also see 271 Section 4.3. 273 3. Keys Generation and Storage 275 This section describes a number of considerations with respect to the 276 security of keys. It deals with the generation, effectivity period, 277 size, and storage of private keys. 279 3.1. Operational motivation for ZSKs and KSKs 281 The DNSSEC validation protocol does not distinguish between different 282 types of DNSKEYs. All DNSKEYs can be used during the validation. 283 The motivations to differentiate between keys are purely operational. 285 In practice, operators differentiate between Key Signing and Zone 286 Signing Keys and use the so-called Secure Entry Point (SEP) [5] flag 287 to distinguish between them during operations. 289 For operational reasons, motivated below, it is possible to designate 290 one or more keys as Key Signing Keys (KSKs). These keys will only 291 sign the apex DNSKEY RRSet in a zone. Other keys can be used to sign 292 all the RRSets in a zone and are referred to as Zone Signing Keys 293 (ZSKs). Since the use of a comon convention eases troubleshooting we 294 recommend that any key that is used for key exchanges with the parent 295 and potentially for configuration as trust anchors -- the SEP keys -- 296 are treated as KSKs and have the SEP flag set. In those cases that a 297 distinction between KSK and ZSK is not made the SEP flag should be 298 set on all keys. 300 3.1.1. Motivations for the KSK and ZSK Separation 302 Differentiating between the KSK and ZSK is mostly done for 303 operational purposes. 305 If the two functions are separated then, for almost any method of key 306 management and zone signing, the KSK is used less frequently than the 307 ZSK. Once a key set is signed with the KSK, all the keys in the key 308 set can be used as ZSKs. If a ZSK is compromised, it can be simply 309 dropped from the key set. The new key set is then re-signed with the 310 KSK. 312 Changing a key with secure entry point functionality is relatively 313 expensive as it involves interaction with 3rd parties: When a key is 314 only pointed to by the parental DS one needs to complete the 315 interaction with the parental registry and wait for the transaction 316 to appear in the DNS. In the case that a SEP key that is in use as a 317 trust-anchor one has to wait until one has sufficient confidence that 318 all trust anchors have been replaced. In fact, it may be that one is 319 not able to reach the complete user-base with information about the 320 keyrolover. 322 There is also a risk that keys are compromised through theft or loss. 323 For keys that are needed to sign dynamically upated records and are 324 therefore installed on file-systems of nameservers that are connected 325 to the network that risk is relatively high. For keys that are 326 stored on Hardware Signing Modules such risk is relatively low. By 327 separating the KSK and ZSK functionality these risks can be managed 328 while making the tradeoff against the costs involved. For example, a 329 KSK can be stored off-line or with more limitation on access control 330 than ZSKs which need to be readily available for operational purposes 331 such as the addition, deletion of zone data. More concretely a KSK 332 stored on a smartcard, that is kept in a safe, combinded with a ZSK 333 stored on a filesystem accessible by operators for daily routine may 334 provide more operational flexibility and higher computational 335 performance than a combined KSK and ZSK stored on an HSM. 337 Finally there is a risk of cryptanalysis of the key material. The 338 cost of such analysis are correlated to the length of the key and the 339 amount of signed material that is available to the analyst. For 340 reasons of signing speed and DNS packet length one may want to keep 341 keylenght at a minimal responsible length and change the key 342 relatively frequently while not interacting with the parent. In 343 those cases there is a stronger motivation for differentiating 344 between a KSK and a ZSK. 346 While the arguments for differentiation between the ZSK and KSK are 347 weakest when the exposure to risk is low, e.g. when keys are stored 348 on HSMs the differentiation of KSK and ZSK allows for maximum 349 operational flexibility. Therefore we advise that the separation 350 between KSKs and ZSKs is made and that the SEP flag is exclusively 351 set on KSKs. 353 3.1.2. Practical concequences of KSK and ZSK Separation 355 Given the assumption that for KSKs the SEP flag is set, the KSK can 356 be distinguished from a ZSK by examining the flag field in the DNSKEY 357 RR: If the flag field is an odd number it is a KSK. If it is an even 358 number it is a ZSK. 360 The Zone Signing Key can be used to sign all the data in a zone on a 361 regular basis. When a Zone Signing Key is to be rolled, no 362 interaction with the parent is needed. This allows for signature 363 validity periods on the order of days. 365 The Key Signing Key is only to be used to sign the DNSKEY RRs in a 366 zone. If a Key Signing Key is to be rolled over, there will be 367 interactions with parties other than the zone administrator. If 368 there is a parent zone, these can include the registry of the parent 369 zone or administrators of verifying resolvers that have the 370 particular key configured as secure entry points. If this is a trust 371 anchor, everyone relying on the trust anchor needs to roll over to 372 the new key. The latter may be subject to stability costs if 373 automated trust-anchor rollover mechanisms (such as e.g. RFC5011 374 [17]) are not in place. Hence, the key effectivity period of these 375 keys can and should be made much longer. 377 3.1.2.1. Rolling a KSK that is not a trust-anchor 379 There are 3 schools of thought on rolling a KSK that is not a trust 380 anchor: 382 o It should be done frequently and regularly (possibly every few 383 months) so that a key rollover remains an operational routine. 385 o It should be done frequently but irregularly. Frequently meaning 386 every few monthts, again based on the argument that a rollover is 387 a practiced and common operational routine, but irregular, i.e. 388 with a large jitter, so that 3rd parties do not start to rely on 389 the key and will not be tempted to configure those as a trust- 390 anchor. 392 o It should only be done when it is known or strongly suspected that 393 the key has been compromised in order to reduce the stability 394 issues on systems where the rollover does not happen cleanly. 396 There is no widespread agreement on which of these three schools of 397 thought is better for different deployments of DNSSEC. There is a 398 stability cost every time a non-anchor KSK is rolled over, but it is 399 possibly low if the communication between the child and the parent is 400 good. On the other hand, the only completely effective way to tell 401 if the communication is good is to test it periodically. Thus, 402 rolling a KSK with a parent is only done for two reasons: to test and 403 verify the rolling system to prepare for an emergency, and in the 404 case of an actual emergency. 406 Finally, a zone ower can, in most cases, not be fully certain that 407 the zone's KSK is not in use as a trust-anchor and while the 408 configuration of trust-anchors is not the responsibility of the zone 409 owner there may be stabilty costs for the validator administrator 410 that (wrongfully) configured the trust-anchor when the zone owner 411 roles a KSK. 413 3.1.2.2. Rolling a KSK that is a trust-anchor 415 The same operational concerns apply to the rollover of KSKs that are 416 used as trust-anchors. But remember: if a trust anchor replacement 417 is done incorrectly, the entire zone that the trust anchor covers 418 will become bogus until the trust anchor is corrected. 420 One can argue that because of the difficulty of getting all users of 421 a trust anchor to replace an old trust anchor with a new one, a KSK 422 that is a trust anchor should never be rolled unless it is known or 423 strongly suspected that the key has been compromised. In other words 424 the costs of a KSK rollover are prohibitively high because some users 425 cannot be reached. 427 However, the "operational habit" argument also applies to trust 428 anchor reconfiguration at the clients validator. If a short key 429 effectivity period is used and the trust anchor configuration has to 430 be revisited on a regular basis, the odds that the configuration 431 tends to be forgotten is smaller. In fact, the costs for those users 432 can be minimized by automating the rollover RFC5011 [17] and by 433 rolling the key regularly, and advertising such, so that the 434 operators of recursive nameservers will put the appropriate mechanism 435 in place to deal with these stability costs, or, in other words, 436 budget for these costs instead of incuring them unexpectedly. 438 It is therefore recommended to regularly roll KSKs if and only if 439 those rollovers can be tracked using automated RFC5011 type 440 mechanisms. 442 The only remaining trade-off choosing an appropriatly long Key 443 Effectivity Period which guards against a system that is so dynamic 444 that administrators of the validating clients will not be able to 445 follow the modifications. 447 3.1.3. Key Effectivity Period 449 In general the available key lenght sets an upper limit on the Key 450 Effectivity Period. For all practical purposes it is sufficient to 451 define the Key Effectivity Period based on purely operational 452 requirements and match the keylength to that value; Ignoring the 453 operational perspective, a reasonable effectivity period for KSKs 454 that have a parent zone is of the order of 2 decades or longer. That 455 is, if one does not plan to test the rollover procedure, the key 456 should be effective essentially forever, and then only rolled over in 457 case of emergency. 459 From a purely operational perspective, following this documents 460 recomendation for regular key-rollover, a reasonable key effectivity 461 period for KSKs that have a parent zone is 13 months, with the intent 462 to replace them after 12 months. As argued above, this annual 463 rollover gives operational practice to rollovers for both the zone as 464 the validator administrators. Besided, in most environments a year 465 is a timespan that is easily planned and communicated. 467 If the risk of loss, theft or other compromise is the same for a zone 468 and key signing key there are little arguments to choose different 469 effectivity periods (while a separation of KSK and ZSK functionality 470 still has benefits). In case keys are stored on on-line systems and 471 the exposure to various risk is fairly high an intended key 472 effectivity period of a month is reasonable for Zone Signing Keys. 474 Key effectivity periods can be made very short, as in a few minutes. 475 But when replacing keys one has to take the considerations from 476 Section 4.1 and Section 4.2 into account. 478 The motivation for having the ZSK's effectivity period shorter than 479 the KSK's effectivity period is rooted in the operational 480 consideration that it is more likely that operators have more 481 frequent read access to the ZSK than to the KSK. If ZSK's are 482 maintained on cryptographic Hardware Security Modules (HSM) than the 483 motivation to have different key effectivity periods is weakend. 485 3.1.4. Cryptographic Considerations 487 3.1.4.1. Key Algorithm 489 There are currently two types of signature algorithms that can be 490 used in DNSSEC: RSA and DSA. Both are fully specified in many 491 freely-available documents, and both are widely considered to be 492 patent-free. The creation of signatures wiht RSA and DSA takes 493 roughly the same time, but DSA is about ten times slower for 494 signature verification. 496 We suggest the use of RSA/SHA-256 as the preferred signature 497 algorithms and RSA/SHA-1 as an alternative. Both have advantages and 498 disadvantages. RSA/SHA-1 has been deployed for many years, while 499 RSA/SHA-256 has only begun to be deployed. On the other hand, it is 500 expected that if effective attacks on either algorithm appeark, they 501 will appear for RSA/SHA-1 first. RSA/MD5 should not be considered 502 for use because RSA/MD5 will very likely be the first common-use 503 signature algorithm to have an effective attack. 505 At the time of publication, it is known that the SHA-1 hash has 506 cryptanalysis issues. There is work in progress on addressing these 507 issues. We recommend the use of public key algorithms based on 508 hashes stronger than SHA-1 (e.g., SHA-256), as soon as these 509 algorithms are available in protocol specifications (see [23] and 510 [20]) and implementations. 512 3.1.4.2. Key Sizes 514 DNSSEC signing keys should be large enough to avoid all know 515 cryptographic attacks during the lifetime of the key. To date, 516 despite huge efforts, no one has broken a regular 1024-bit key; in 517 fact, the best completed attack is estimated to be the equivalent of 518 a 700-bit key. An attacker breaking a 1024-bit signing key would 519 need expend phenominal amounts of networked computing power in a way 520 that would not be detected in order to break a single key. Because 521 of this, it is estimated that most zones can safely use 1024-bit keys 522 for at least the next ten years. A 1024-bit asymmetric key has an 523 approximate equivalent strength of a symmetric 80-bit key. 525 Keys that are used as extremely high value trust anchors, or non- 526 anchor keys that may be difficult to roll over, may want to use 527 lengths longer than 1024 bits. Typically, the next larger key size 528 used is 2048 bits, which have the approximate equivalent strength of 529 a symmetric 112-bit key. In a standard CPU, it takes about four 530 times as long to sign or verify with a 2048-bit key as it does with a 531 1024-bit key. 533 Another way to decide on the size of key to use is to remember that 534 the phenominal effort it takes for an attacker to break a 1024-bit 535 key is the same regardless of how the key is used. If an attacker 536 has the capability of breaking a 1024-bit DNSSEC key, he also has the 537 capability of breaking one of the many 1024-bit TLS trust anchor keys 538 that are installed with web browsers. If the value of a DNSSEC key 539 is lower to the attacker than the value of a TLS trust anchor, the 540 attacker will use the resources to attack the TLS trust anchor. 542 It is possible that there is a unexpected improvement in the ability 543 for attackers to beak keys, and that such an attack would make it 544 feasible to break 1024-bit keys but not 2048-bit keys. If such an 545 improvement happens, it is likely that there will be a huge amount of 546 publicity, particularly because of the large number of 1024-bit TLS 547 trust anchors build into popular web browsers. At that time, all 548 1024-bit keys (both ones with parent zones and ones that are trust 549 anchors) can be rolled over and replaced with larger keys. 551 Earlier documents (including the previous version of this document) 552 urged the use of longer keys in situations where a particular key was 553 "heavily used". That advice may have been true 15 years ago, but it 554 is not true today when using RSA or DSA algorithms and keys of 1024 555 bits or higher. 557 3.1.4.3. Private Key Storage 559 It is recommended that, where possible, zone private keys and the 560 zone file master copy that is to be signed be kept and used in off- 561 line, non-network-connected, physically secure machines only. 562 Periodically, an application can be run to add authentication to a 563 zone by adding RRSIG and NSEC RRs. Then the augmented file can be 564 transferred. 566 When relying on dynamic update to manage a signed zone [10], be aware 567 that at least one private key of the zone will have to reside on the 568 master server. This key is only as secure as the amount of exposure 569 the server receives to unknown clients and the security of the host. 570 Although not mandatory, one could administer the DNS in the following 571 way. The master that processes the dynamic updates is unavailable 572 from generic hosts on the Internet, it is not listed in the NS RRSet, 573 although its name appears in the SOA RRs MNAME field. The 574 nameservers in the NS RRSet are able to receive zone updates through 575 NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This 576 approach is known as the "hidden master" setup. 578 The ideal situation is to have a one-way information flow to the 579 network to avoid the possibility of tampering from the network. 580 Keeping the zone master file on-line on the network and simply 581 cycling it through an off-line signer does not do this. The on-line 582 version could still be tampered with if the host it resides on is 583 compromised. For maximum security, the master copy of the zone file 584 should be off-net and should not be updated based on an unsecured 585 network mediated communication. 587 The ideal situation may not be achievable because of economic 588 tradeoffs between risks and costs. For instance, keeping a zone file 589 off-line is not practical and will increase the costs of operating a 590 DNS zone. So in practice the machines on which zone files are 591 maintained will be connected to a network. Operators are advised to 592 take security measures to shield unauthorized access to the master 593 copy in order to prevent modification of DNS data before its signed. 595 Similarly the choice for storing a private key in a HSM will be 596 influenced by a tradeoff between various concerns: 598 o The risks that an unauthorized person has unnoticed read-access to 599 the private key 601 o The remaining window of opportunity for the attacker. 603 o The economic impact of the possible attacks (for a TLD that impact 604 will in most cases be higher than for an individual users). 606 o The costs of rolling the (compromised) keys: whereby the costs of 607 roling a ZSK is lowest and the costs of rolling a KSK that is in 608 wide use as a trust anchor is highest 610 o The costs of buying and maintaining an HSM. 612 For dynamically updated secured zones [10], both the master copy and 613 the private key that is used to update signatures on updated RRs will 614 need to be on-line. 616 3.1.4.4. Key Generation 618 Careful generation of all keys is a sometimes overlooked but 619 absolutely essential element in any cryptographically secure system. 620 The strongest algorithms used with the longest keys are still of no 621 use if an adversary can guess enough to lower the size of the likely 622 key space so that it can be exhaustively searched. Technical 623 suggestions for the generation of random keys will be found in RFC 624 4086 [13] and NIST SP 800-900 [19]. One should carefully assess if 625 the random number generator used during key generation adheres to 626 these suggestions. 628 Keys with a long effectivity period are particularly sensitive as 629 they will represent a more valuable target and be subject to attack 630 for a longer time than short-period keys. It is strongly recommended 631 that long-term key generation occur off-line in a manner isolated 632 from the network via an air gap or, at a minimum, high-level secure 633 hardware. 635 3.1.4.5. Differentiation for 'High-Level' Zones 637 In an earlier version of this document (RFC4641 [15]) we made a 638 differentiation between KSKs used for zones that are high in the DNS 639 hierarchy versus KSKs used for zones low in that hierarchy. 641 Longer keys are not useful because the crypto guidance is that 642 everyone should use keys that no one can break. Also, it is 643 impossible to judge which zones are more or less valuable to an 644 attacker. An attack can only be used if the compromise is unnoticed 645 and the attacker can act as an man-in-the-middle attack (MITM) in an 646 unnoticed way. If example. is compromised and the attacker forges 647 answers for somebank.example. and sends them out as an MITM, when the 648 attack is discovered it will be simple to prove that example. has 649 been compromised and the KSK will be rolled. Defining a long-term 650 successful attack is difficult for keys at any level. 652 4. Signature Generation, Key Rollover, and Related Policies 654 4.1. Time in DNSSEC 656 Without DNSSEC, all times in the DNS are relative. The SOA fields 657 REFRESH, RETRY, and EXPIRATION are timers used to determine the time 658 elapsed after a slave server synchronized with a master server. The 659 Time to Live (TTL) value and the SOA RR minimum TTL parameter [9] are 660 used to determine how long a forwarder should cache data after it has 661 been fetched from an authoritative server. By using a signature 662 validity period, DNSSEC introduces the notion of an absolute time in 663 the DNS. Signatures in DNSSEC have an expiration date after which 664 the signature is marked as invalid and the signed data is to be 665 considered Bogus. 667 The considerations in this section are all qualitative and focused on 668 the managerial issues. A more thourhough quantitative analysis of 669 rollover timing parameters can be found in 670 draft-morris-dnsop-dnssec-key-timing [24] 672 4.1.1. Time Considerations 674 Because of the expiration of signatures, one should consider the 675 following: 677 o We suggest the Maximum Zone TTL of your zone data to be a fraction 678 of your signature validity period. 680 If the TTL would be of similar order as the signature validity 681 period, then all RRSets fetched during the validity period 682 would be cached until the signature expiration time. Section 683 7.1 of [3] suggests that "the resolver may use the time 684 remaining before expiration of the signature validity period of 685 a signed RRSet as an upper bound for the TTL". As a result, 686 query load on authoritative servers would peak at signature 687 expiration time, as this is also the time at which records 688 simultaneously expire from caches. 690 To avoid query load peaks, we suggest the TTL on all the RRs in 691 your zone to be at least a few times smaller than your 692 signature validity period. 694 o We suggest the signature publication period to end at least one 695 Maximum Zone TTL duration before the end of the signature validity 696 period. 698 Re-signing a zone shortly before the end of the signature 699 validity period may cause simultaneous expiration of data from 700 caches. This in turn may lead to peaks in the load on 701 authoritative servers. 703 o We suggest the Minimum Zone TTL to be long enough to both fetch 704 and verify all the RRs in the trust chain. In workshop 705 environments, it has been demonstrated [18] that a low TTL (under 706 5 to 10 minutes) caused disruptions because of the following two 707 problems: 709 1. During validation, some data may expire before the 710 validation is complete. The validator should be able to keep 711 all data until it is completed. This applies to all RRs needed 712 to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the 713 final answers, i.e., the RRSet that is returned for the initial 714 query. 716 2. Frequent verification causes load on recursive nameservers. 717 Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit 718 from caching. The TTL on those should be relatively long. 720 o Slave servers will need to be able to fetch newly signed zones 721 well before the RRSIGs in the zone served by the slave server pass 722 their signature expiration time. 724 When a slave server is out of sync with its master and data in 725 a zone is signed by expired signatures, it may be better for 726 the slave server not to give out any answer. 728 Normally, a slave server that is not able to contact a master 729 server for an extended period will expire a zone. When that 730 happens, the server will respond differently to queries for 731 that zone. Some servers issue SERVFAIL, whereas others turn 732 off the 'AA' bit in the answers. The time of expiration is set 733 in the SOA record and is relative to the last successful 734 refresh between the master and the slave servers. There exists 735 no coupling between the signature expiration of RRSIGs in the 736 zone and the expire parameter in the SOA. 738 If the server serves a DNSSEC zone, then it may well happen 739 that the signatures expire well before the SOA expiration timer 740 counts down to zero. It is not possible to completely prevent 741 this from happening by tweaking the SOA parameters. 743 However, the effects can be minimized where the SOA expiration 744 time is equal to or shorter than the signature validity period. 746 The consequence of an authoritative server not being able to 747 update a zone, whilst that zone includes expired signatures, is 748 that non-secure resolvers will continue to be able to resolve 749 data served by the particular slave servers while security- 750 aware resolvers will experience problems because of answers 751 being marked as Bogus. 753 We suggest the SOA expiration timer being approximately one 754 third or one fourth of the signature validity period. It will 755 allow problems with transfers from the master server to be 756 noticed before the actual signature times out. 758 We also suggest that operators of nameservers that supply 759 secondary services develop 'watch dogs' to spot upcoming 760 signature expirations in zones they slave, and take appropriate 761 action. 763 When determining the value for the expiration parameter one has 764 to take the following into account: What are the chances that 765 all my secondaries expire the zone? How quickly can I reach an 766 administrator of secondary servers to load a valid zone? These 767 questions are not DNSSEC specific but may influence the choice 768 of your signature validity intervals. 770 4.2. Key Rollovers 772 Regardless of whether a zone uses periodic key rollovers in order to 773 practice for emergencies, or only rolls over keys in an emergency, 774 key rollovers are a fact of life when using DNSSEC. Zone 775 administrators who are in the process of rolling their keys have to 776 take into account that data published in previous versions of their 777 zone still lives in caches. When deploying DNSSEC, this becomes an 778 important consideration; ignoring data that may be in caches may lead 779 to loss of service for clients. 781 The most pressing example of this occurs when zone material signed 782 with an old key is being validated by a resolver that does not have 783 the old zone key cached. If the old key is no longer present in the 784 current zone, this validation fails, marking the data "Bogus". 785 Alternatively, an attempt could be made to validate data that is 786 signed with a new key against an old key that lives in a local cache, 787 also resulting in data being marked "Bogus". 789 4.2.1. Zone Signing Key Rollovers 791 For "Zone Signing Key rollovers", there are two ways to make sure 792 that during the rollover data still cached can be verified with the 793 new key sets or newly generated signatures can be verified with the 794 keys still in caches. One schema, described in Section 4.2.1.2, uses 795 double signatures; the other uses key pre-publication 796 (Section 4.2.1.1). The pros, cons, and recommendations are described 797 in Section 4.2.1.3. 799 4.2.1.1. Pre-Publish Key Rollover 801 This section shows how to perform a ZSK rollover without the need to 802 sign all the data in a zone twice -- the "pre-publish key rollover". 803 This method has advantages in the case of a key compromise. If the 804 old key is compromised, the new key has already been distributed in 805 the DNS. The zone administrator is then able to quickly switch to 806 the new key and remove the compromised key from the zone. Another 807 major advantage is that the zone size does not double, as is the case 808 with the double signature ZSK rollover. A small "how-to" for this 809 kind of rollover can be found in Appendix B. 811 Pre-publish key rollover involves four stages as follows: 813 ---------------------------------------------------------------- 814 initial new DNSKEY new RRSIGs DNSKEY removal 815 ---------------------------------------------------------------- 816 SOA0 SOA1 SOA2 SOA3 817 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 819 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 820 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 821 DNSKEY11 DNSKEY11 822 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 823 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 824 ---------------------------------------------------------------- 826 Pre-Publish Key Rollover 828 initial: Initial version of the zone: DNSKEY 1 is the Key Signing 829 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 830 Signing Key. 832 new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no 833 signatures are generated with this key yet, but this does not 834 secure against brute force attacks on the public key. The minimum 835 duration of this pre-roll phase is the time it takes for the data 836 to propagate to the authoritative servers plus TTL value of the 837 key set. 839 new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is 840 used to sign the data in the zone exclusively (i.e., all the 841 signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 842 remains published in the key set. This way data that was loaded 843 into caches from version 1 of the zone can still be verified with 844 key sets fetched from version 2 of the zone. The minimum time 845 that the key set including DNSKEY 10 is to be published is the 846 time that it takes for zone data from the previous version of the 847 zone to expire from old caches, i.e., the time it takes for this 848 zone to propagate to all authoritative servers plus the Maximum 849 Zone TTL value of any of the data in the previous version of the 850 zone. 852 DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, 853 now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the 854 DNSKEY 1. 856 The above scheme can be simplified by always publishing the "future" 857 key immediately after the rollover. The scheme would look as follows 858 (we show two rollovers); the future key is introduced in "new DNSKEY" 859 as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY 860 (II)": 862 initial new RRSIGs new DNSKEY 863 ----------------------------------------------------------------- 864 SOA0 SOA1 SOA2 865 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) 867 DNSKEY1 DNSKEY1 DNSKEY1 868 DNSKEY10 DNSKEY10 DNSKEY11 869 DNSKEY11 DNSKEY11 DNSKEY12 870 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 871 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 872 ---------------------------------------------------------------- 874 ---------------------------------------------------------------- 875 new RRSIGs (II) new DNSKEY (II) 876 ---------------------------------------------------------------- 877 SOA3 SOA4 878 RRSIG12(SOA3) RRSIG12(SOA4) 880 DNSKEY1 DNSKEY1 881 DNSKEY11 DNSKEY12 882 DNSKEY12 DNSKEY13 883 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 884 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 885 ---------------------------------------------------------------- 887 Pre-Publish Key Rollover, Showing Two Rollovers 889 Note that the key introduced in the "new DNSKEY" phase is not used 890 for production yet; the private key can thus be stored in a 891 physically secure manner and does not need to be 'fetched' every time 892 a zone needs to be signed. 894 4.2.1.2. Double Signature Zone Signing Key Rollover 896 This section shows how to perform a ZSK key rollover using the double 897 zone data signature scheme, aptly named "double signature rollover". 899 During the "new DNSKEY" stage the new version of the zone file will 900 need to propagate to all authoritative servers and the data that 901 exists in (distant) caches will need to expire, requiring at least 902 the Maximum Zone TTL. 904 Double signature ZSK rollover involves three stages as follows: 906 ---------------------------------------------------------------- 907 initial new DNSKEY DNSKEY removal 908 ---------------------------------------------------------------- 909 SOA0 SOA1 SOA2 910 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 911 RRSIG11(SOA1) 912 DNSKEY1 DNSKEY1 DNSKEY1 913 DNSKEY10 DNSKEY10 DNSKEY11 914 DNSKEY11 915 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 916 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 917 RRSIG11(DNSKEY) 918 ---------------------------------------------------------------- 920 Double Signature Zone Signing Key Rollover 922 initial: Initial Version of the zone: DNSKEY 1 is the Key Signing 923 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 924 Signing Key. 926 new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is 927 introduced into the key set and all the data in the zone is signed 928 with DNSKEY 10 and DNSKEY 11. The rollover period will need to 929 continue until all data from version 0 of the zone has expired 930 from remote caches. This will take at least the Maximum Zone TTL 931 of version 0 of the zone. 933 DNSKEY removal: DNSKEY 10 is removed from the zone. All the 934 signatures from DNSKEY 10 are removed from the zone. The key set, 935 now only containing DNSKEY 11, is re-signed with DNSKEY 1. 937 At every instance, RRSIGs from the previous version of the zone can 938 be verified with the DNSKEY RRSet from the current version and the 939 other way around. The data from the current version can be verified 940 with the data from the previous version of the zone. The duration of 941 the "new DNSKEY" phase and the period between rollovers should be at 942 least the Maximum Zone TTL. 944 Making sure that the "new DNSKEY" phase lasts until the signature 945 expiration time of the data in the initial version of the zone is 946 recommended. This way all caches are cleared of the old signatures. 947 However, this duration could be considerably longer than the Maximum 948 Zone TTL, making the rollover a lengthy procedure. 950 Note that in this example we assumed that the zone was not modified 951 during the rollover. New data can be introduced in the zone as long 952 as it is signed with both keys. 954 4.2.1.3. Pros and Cons of the Schemes 956 Pre-publish key rollover: This rollover does not involve signing the 957 zone data twice. Instead, before the actual rollover, the new key 958 is published in the key set and thus is available for 959 cryptanalysis attacks. A small disadvantage is that this process 960 requires four steps. Also the pre-publish scheme involves more 961 parental work when used for KSK rollovers as explained in 962 Section 4.2.3. 964 Double signature ZSK rollover: The drawback of this signing scheme 965 is that during the rollover the number of signatures in your zone 966 doubles; this may be prohibitive if you have very big zones. An 967 advantage is that it only requires three steps. 969 4.2.2. Key Signing Key Rollovers 971 For the rollover of a Key Signing Key, the same considerations as for 972 the rollover of a Zone Signing Key apply. However, we can use a 973 double signature scheme to guarantee that old data (only the apex key 974 set) in caches can be verified with a new key set and vice versa. 975 Since only the key set is signed with a KSK, zone size considerations 976 do not apply. 978 -------------------------------------------------------------------- 979 initial new DNSKEY DS change DNSKEY removal 980 -------------------------------------------------------------------- 981 Parent: 982 SOA0 --------> SOA1 --------> 983 RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> 984 DS1 --------> DS2 --------> 985 RRSIGpar(DS) --------> RRSIGpar(DS) --------> 987 Child: 988 SOA0 SOA1 --------> SOA2 989 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) 990 --------> 991 DNSKEY1 DNSKEY1 --------> DNSKEY2 992 DNSKEY2 --------> 993 DNSKEY10 DNSKEY10 --------> DNSKEY10 994 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) 995 RRSIG2 (DNSKEY) --------> 996 RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) 997 -------------------------------------------------------------------- 999 Stages of Deployment for a Double Signature Key Signing Key Rollover 1001 initial: Initial version of the zone. The parental DS points to 1002 DNSKEY1. Before the rollover starts, the child will have to 1003 verify what the TTL is of the DS RR that points to DNSKEY1 -- it 1004 is needed during the rollover and we refer to the value as TTL_DS. 1006 new DNSKEY: During the "new DNSKEY" phase, the zone administrator 1007 generates a second KSK, DNSKEY2. The key is provided to the 1008 parent, and the child will have to wait until a new DS RR has been 1009 generated that points to DNSKEY2. After that DS RR has been 1010 published on all servers authoritative for the parent's zone, the 1011 zone administrator has to wait at least TTL_DS to make sure that 1012 the old DS RR has expired from caches. 1014 DS change: The parent replaces DS1 with DS2. 1016 DNSKEY removal: DNSKEY1 has been removed. 1018 The scenario above puts the responsibility for maintaining a valid 1019 chain of trust with the child. It also is based on the premise that 1020 the parent only has one DS RR (per algorithm) per zone. An 1021 alternative mechanism has been considered. Using an established 1022 trust relation, the interaction can be performed in-band, and the 1023 removal of the keys by the child can possibly be signaled by the 1024 parent. In this mechanism, there are periods where there are two DS 1025 RRs at the parent. Since at the moment of writing the protocol for 1026 this interaction has not been developed, further discussion is out of 1027 scope for this document. 1029 4.2.3. Difference Between ZSK and KSK Rollovers 1031 Note that KSK rollovers and ZSK rollovers are different in the sense 1032 that a KSK rollover requires interaction with the parent (and 1033 possibly replacing of trust anchors) and the ensuing delay while 1034 waiting for it. 1036 A zone key rollover can be handled in two different ways: pre-publish 1037 (Section 4.2.1.1) and double signature (Section 4.2.1.2). 1039 As the KSK is used to validate the key set and because the KSK is not 1040 changed during a ZSK rollover, a cache is able to validate the new 1041 key set of the zone. The pre-publish method would also work for a 1042 KSK rollover. The records that are to be pre-published are the 1043 parental DS RRs. The pre-publish method has some drawbacks for KSKs. 1044 We first describe the rollover scheme and then indicate these 1045 drawbacks. 1047 -------------------------------------------------------------------- 1048 initial new DS new DNSKEY DS/DNSKEY removal 1049 -------------------------------------------------------------------- 1050 Parent: 1051 SOA0 SOA1 --------> SOA2 1052 RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) 1053 DS1 DS1 --------> DS2 1054 DS2 --------> 1055 RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) 1057 Child: 1058 SOA0 --------> SOA1 SOA1 1059 RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) 1060 --------> 1061 DNSKEY1 --------> DNSKEY2 DNSKEY2 1062 --------> 1063 DNSKEY10 --------> DNSKEY10 DNSKEY10 1064 RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 1065 RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) 1066 -------------------------------------------------------------------- 1068 Stages of Deployment for a Pre-Publish Key Signing Key Rollover 1070 When the child zone wants to roll, it notifies the parent during the 1071 "new DS" phase and submits the new key (or the corresponding DS) to 1072 the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 1073 and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), 1074 which can take place as soon as the new DS set propagated through the 1075 DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that 1076 ("DS/DNSKEY removal" phase), it can notify the parent that the old DS 1077 record can be deleted. 1079 The drawbacks of this scheme are that during the "new DS" phase the 1080 parent cannot verify the match between the DS2 RR and DNSKEY2 using 1081 the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a 1082 "security lame" key (see Section 4.4.3). Finally, the child-parent 1083 interaction consists of two steps. The "double signature" method 1084 only needs one interaction. 1086 4.2.4. Key algorithm rollover 1088 A special class of keyrollover is the rollover of key algorithms 1089 (either adding a new algorithm, removing an old algorithm, or both), 1090 additional steps are needed to retain integrity during the rollover. 1092 Because of the algorithm downgrade protection in RFC4035 section 2.2, 1093 you may not have a key of an algorithm for which you do not have 1094 signatures. 1096 When adding a new algorithm, the signatures should be added first. 1097 After the TTL has expired, and caches have dropped the old data 1098 covered by those signatures, the DNSKEY with the new algorithm can be 1099 added. When removing an old algorithm, the DNSKEY should be removed 1100 first. 1102 To do both, the following steps can be used. For simplicity, we use 1103 a zone that is only signed by one zone signing key. 1105 ---------------------------------------------------------------- 1106 1 Initial 2 New RRSIGS 3 New DNSKEY 1107 ---------------------------------------------------------------- 1108 SOA0 SOA1 SOA2 1109 RRSIG1(SOA0) RRSIG1(SOA1) RRSIG1(SOA2) 1110 RRSIG2(SOA1) RRSIG2(SOA2) 1112 DNSKEY1 DNSKEY1 DNSKEY1 1113 RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2 1114 RRSIG2(DNSKEY) RRSIG1(DNSKEY) 1115 RRSIG2(DNSKEY) 1116 ---------------------------------------------------------------- 1117 4 Remove DNSKEY 5 Remove RRSIGS 1118 ---------------------------------------------------------------- 1119 SOA3 SOA4 1120 RRSIG1(SOA3) RRSIG2(SOA4) 1121 RRSIG2(SOA3) 1123 DNSKEY2 DNSKEY2 1124 RRSIG1(DNSKEY) RRSIG2(DNSKEY) 1125 RRSIG2(DNSKEY) 1126 ---------------------------------------------------------------- 1128 Stages of Deployment during an Algorithm Rollover. 1130 In step 2, the signatures for the new key are added, but the key 1131 itself is not. While in theory, the signatures of the keyset should 1132 always be synchronized with the keyset itself, it can be possible 1133 that RRSIGS are requested separately, so it might be prudent to also 1134 sign the DNSKEY set with the new signature. 1136 After the cache data has expired, the new key can be added to the 1137 zone, as done in step 3. 1139 The next step is to remove the old algorithm. This time the key 1140 needs to be removed first, before removing the signatures. The key 1141 is removed in step 4, and after the cache data has expired, the 1142 signatures can be removed in step 5. 1144 The above steps ensure that during the rollover to a new algorithm, 1145 the integrity of the zone is never broken. 1147 4.2.5. Automated Key Rollovers 1149 As keys must be renewed periodically, there is some motivation to 1150 automate the rollover process. Consider the following: 1152 o ZSK rollovers are easy to automate as only the child zone is 1153 involved. 1155 o A KSK rollover needs interaction between parent and child. Data 1156 exchange is needed to provide the new keys to the parent; 1157 consequently, this data must be authenticated and integrity must 1158 be guaranteed in order to avoid attacks on the rollover. 1160 4.3. Planning for Emergency Key Rollover 1162 This section deals with preparation for a possible key compromise. 1163 Our advice is to have a documented procedure ready for when a key 1164 compromise is suspected or confirmed. 1166 When the private material of one of your keys is compromised it can 1167 be used for as long as a valid trust chain exists. A trust chain 1168 remains intact for 1170 o as long as a signature over the compromised key in the trust chain 1171 is valid, 1173 o as long as a parental DS RR (and signature) points to the 1174 compromised key, 1176 o as long as the key is anchored in a resolver and is used as a 1177 starting point for validation (this is generally the hardest to 1178 update). 1180 While a trust chain to your compromised key exists, your namespace is 1181 vulnerable to abuse by anyone who has obtained illegitimate 1182 possession of the key. Zone operators have to make a trade-off if 1183 the abuse of the compromised key is worse than having data in caches 1184 that cannot be validated. If the zone operator chooses to break the 1185 trust chain to the compromised key, data in caches signed with this 1186 key cannot be validated. However, if the zone administrator chooses 1187 to take the path of a regular rollover, the malicious key holder can 1188 spoof data so that it appears to be valid. 1190 4.3.1. KSK Compromise 1192 A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable 1193 as long as the compromised KSK is configured as trust anchor or a 1194 parental DS points to it. 1196 A compromised KSK can be used to sign the key set of an attacker's 1197 zone. That zone could be used to poison the DNS. 1199 Therefore, when the KSK has been compromised, the trust anchor or the 1200 parental DS should be replaced as soon as possible. It is local 1201 policy whether to break the trust chain during the emergency 1202 rollover. The trust chain would be broken when the compromised KSK 1203 is removed from the child's zone while the parent still has a DS 1204 pointing to the compromised KSK (the assumption is that there is only 1205 one DS at the parent. If there are multiple DSes this does not apply 1206 -- however the chain of trust of this particular key is broken). 1208 Note that an attacker's zone still uses the compromised KSK and the 1209 presence of a parental DS would cause the data in this zone to appear 1210 as valid. Removing the compromised key would cause the attacker's 1211 zone to appear as valid and the child's zone as Bogus. Therefore, we 1212 advise not to remove the KSK before the parent has a DS to a new KSK 1213 in place. 1215 4.3.1.1. Keeping the Chain of Trust Intact 1217 If we follow this advice, the timing of the replacement of the KSK is 1218 somewhat critical. The goal is to remove the compromised KSK as soon 1219 as the new DS RR is available at the parent. And also make sure that 1220 the signature made with a new KSK over the key set with the 1221 compromised KSK in it expires just after the new DS appears at the 1222 parent, thus removing the old cruft in one swoop. 1224 The procedure is as follows: 1226 1. Introduce a new KSK into the key set, keep the compromised KSK in 1227 the key set. 1229 2. Sign the key set, with a short validity period. The validity 1230 period should expire shortly after the DS is expected to appear 1231 in the parent and the old DSes have expired from caches. 1233 3. Upload the DS for this new key to the parent. 1235 4. Follow the procedure of the regular KSK rollover: Wait for the DS 1236 to appear in the authoritative servers and then wait as long as 1237 the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet 1238 and modify/extend the expiration time. 1240 5. Remove the compromised DNSKEY RR from the zone and re-sign the 1241 key set using your "normal" validity interval. 1243 An additional danger of a key compromise is that the compromised key 1244 could be used to facilitate a legitimate DNSKEY/DS rollover and/or 1245 nameserver changes at the parent. When that happens, the domain may 1246 be in dispute. An authenticated out-of-band and secure notify 1247 mechanism to contact a parent is needed in this case. 1249 Note that this is only a problem when the DNSKEY and or DS records 1250 are used for authentication at the parent. 1252 4.3.1.2. Breaking the Chain of Trust 1254 There are two methods to break the chain of trust. The first method 1255 causes the child zone to appear 'Bogus' to validating resolvers. The 1256 other causes the child zone to appear 'insecure'. These are 1257 described below. 1259 In the method that causes the child zone to appear 'Bogus' to 1260 validating resolvers, the child zone replaces the current KSK with a 1261 new one and re-signs the key set. Next it sends the DS of the new 1262 key to the parent. Only after the parent has placed the new DS in 1263 the zone is the child's chain of trust repaired. 1265 An alternative method of breaking the chain of trust is by removing 1266 the DS RRs from the parent zone altogether. As a result, the child 1267 zone would become insecure. 1269 4.3.2. ZSK Compromise 1271 Primarily because there is no parental interaction required when a 1272 ZSK is compromised, the situation is less severe than with a KSK 1273 compromise. The zone must still be re-signed with a new ZSK as soon 1274 as possible. As this is a local operation and requires no 1275 communication between the parent and child, this can be achieved 1276 fairly quickly. However, one has to take into account that just as 1277 with a normal rollover the immediate disappearance of the old 1278 compromised key may lead to verification problems. Also note that as 1279 long as the RRSIG over the compromised ZSK is not expired the zone 1280 may be still at risk. 1282 4.3.3. Compromises of Keys Anchored in Resolvers 1284 A key can also be pre-configured in resolvers. For instance, if 1285 DNSSEC is successfully deployed the root key may be pre-configured in 1286 most security aware resolvers. 1288 If trust-anchor keys are compromised, the resolvers using these keys 1289 should be notified of this fact. Zone administrators may consider 1290 setting up a mailing list to communicate the fact that a SEP key is 1291 about to be rolled over. This communication will of course need to 1292 be authenticated, e.g., by using digital signatures. 1294 End-users faced with the task of updating an anchored key should 1295 always validate the new key. New keys should be authenticated out- 1296 of-band, for example, through the use of an announcement website that 1297 is secured using secure sockets (TLS) [22]. 1299 4.4. Parental Policies 1301 4.4.1. Initial Key Exchanges and Parental Policies Considerations 1303 The initial key exchange is always subject to the policies set by the 1304 parent. When designing a key exchange policy one should take into 1305 account that the authentication and authorization mechanisms used 1306 during a key exchange should be as strong as the authentication and 1307 authorization mechanisms used for the exchange of delegation 1308 information between parent and child. That is, there is no implicit 1309 need in DNSSEC to make the authentication process stronger than it 1310 was in DNS. 1312 Using the DNS itself as the source for the actual DNSKEY material, 1313 with an out-of-band check on the validity of the DNSKEY, has the 1314 benefit that it reduces the chances of user error. A DNSKEY query 1315 tool can make use of the SEP bit [5] to select the proper key from a 1316 DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is 1317 sent. It can validate the self-signature over a key; thereby 1318 verifying the ownership of the private key material. Fetching the 1319 DNSKEY from the DNS ensures that the chain of trust remains intact 1320 once the parent publishes the DS RR indicating the child is secure. 1322 Note: the out-of-band verification is still needed when the key 1323 material is fetched via the DNS. The parent can never be sure 1324 whether or not the DNSKEY RRs have been spoofed. 1326 4.4.2. Storing Keys or Hashes? 1328 When designing a registry system one should consider which of the 1329 DNSKEYs and/or the corresponding DSes to store. Since a child zone 1330 might wish to have a DS published using a message digest algorithm 1331 not yet understood by the registry, the registry can't count on being 1332 able to generate the DS record from a raw DNSKEY. Thus, we recommend 1333 that registry systems at least support storing DS records. 1335 It may also be useful to store DNSKEYs, since having them may help 1336 during troubleshooting and, as long as the child's chosen message 1337 digest is supported, the overhead of generating DS records from them 1338 is minimal. Having an out-of-band mechanism, such as a registry 1339 directory (e.g., Whois), to find out which keys are used to generate 1340 DS Resource Records for specific owners and/or zones may also help 1341 with troubleshooting. 1343 The storage considerations also relate to the design of the customer 1344 interface and the method by which data is transferred between 1345 registrant and registry; Will the child zone administrator be able to 1346 upload DS RRs with unknown hash algorithms or does the interface only 1347 allow DNSKEYs? In the registry-registrar model, one can use the 1348 DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [14], 1349 which allows transfer of DS RRs and optionally DNSKEY RRs. 1351 4.4.3. Security Lameness 1353 Security lameness is defined as what happens when a parent has a DS 1354 RR pointing to a non-existing DNSKEY RR. When this happens, the 1355 child's zone may be marked "Bogus" by verifying DNS clients. 1357 As part of a comprehensive delegation check, the parent could, at key 1358 exchange time, verify that the child's key is actually configured in 1359 the DNS. However, if a parent does not understand the hashing 1360 algorithm used by child, the parental checks are limited to only 1361 comparing the key id. 1363 Child zones should be very careful in removing DNSKEY material, 1364 specifically SEP keys, for which a DS RR exists. 1366 Once a zone is "security lame", a fix (e.g., removing a DS RR) will 1367 take time to propagate through the DNS. 1369 4.4.4. DS Signature Validity Period 1371 Since the DS can be replayed as long as it has a valid signature, a 1372 short signature validity period over the DS minimizes the time a 1373 child is vulnerable in the case of a compromise of the child's 1374 KSK(s). A signature validity period that is too short introduces the 1375 possibility that a zone is marked "Bogus" in case of a configuration 1376 error in the signer. There may not be enough time to fix the 1377 problems before signatures expire. Something as mundane as operator 1378 unavailability during weekends shows the need for DS signature 1379 validity periods longer than 2 days. We recommend an absolute 1380 minimum for a DS signature validity period of a few days. 1382 The maximum signature validity period of the DS record depends on how 1383 long child zones are willing to be vulnerable after a key compromise. 1384 On the other hand, shortening the DS signature validity interval 1385 increases the operational risk for the parent. Therefore, the parent 1386 may have policy to use a signature validity interval that is 1387 considerably longer than the child would hope for. 1389 A compromise between the operational constraints of the parent and 1390 minimizing damage for the child may result in a DS signature validity 1391 period somewhere between a week and months. 1393 In addition to the signature validity period, which sets a lower 1394 bound on the number of times the zone owner will need to sign the 1395 zone data and which sets an upper bound to the time a child is 1396 vulnerable after key compromise, there is the TTL value on the DS 1397 RRs. Shortening the TTL means that the authoritative servers will 1398 see more queries. But on the other hand, a short TTL lowers the 1399 persistence of DS RRSets in caches thereby increasing the speed with 1400 which updated DS RRSets propagate through the DNS. 1402 4.4.5. Changing DNS Operators 1404 [OK: this is a second strawman, and is intended to start the 1405 discussion of the issue. By no means this is intended to be a final 1406 text.] 1408 4.4.5.1. Cooperationg DNS operators 1410 The parent-child relation is often described in terms of a (thin) 1411 registry model. Where a registry maintains the parent zone, and the 1412 registrant (the user of the child-domain name), deals with the 1413 registry through an intermediary called a registrar. (See [11] for a 1414 comprehensive definition). Registrants may out-source the 1415 maintenance of their DNS system, including the maintenance of DNSSEC 1416 key material, to the registrar or to another third party, which we 1417 will call the DNS operator. The DNS operator that has control over 1418 the DNS zone and its keys may prevent the registrant to make a timely 1419 move to a different DNS operator. 1421 Suppose that the registrant wants to move from a losing DNS operator 1422 (loosing operator for short) to a gaining DNS operator (gaining 1423 operator). Let us first look what would happen in a cooperative 1424 environment. The assumption is that the loosing operator will not 1425 hand off any private key material to the gaining operator, that would 1426 constitute a trivial case. 1428 In a cooperating environment one could proceed with a pre-publish ZSK 1429 rollover whereby the loosing operator pre-publishes the ZSK of the 1430 gaining operator, combined with a double signature KSK rollover where 1431 the two registrars exchange public KSKs and independently generate a 1432 signature over those keysets that they combine and both publish in 1433 the zone. Once that is done they can use their own private keys to 1434 sign any of the zone content. 1436 ............................................................ 1437 intitial | pre-publish | 1438 ............................................................ 1439 Parent: 1441 NSA NSA 1442 DSA DSA 1444 ............................................................ 1445 Child at A: Child at A: Child at B: 1446 ZSKA ZSKA ZSKA 1447 KSKA ZSKB ZSKB 1448 RRSIGZA(DNSKEY) KSKA KSKA 1449 RRSIGKA(DNSKEY) KSKB KSKB 1450 RRSIGZB RRSIGZB 1451 RRSIGKB RRSIGKB 1452 RRSIGZA RRSIGZA 1453 RRSIGKA RRSIGKA 1455 SOAA SOAA SOAB 1456 RRSIGZA(SOA) RRSIGZA(SOA) RRSIGZB(SOA) 1458 NSA NSA NSB 1459 RRSIGZA(NS) NSB RRSIGZB(NS) 1460 RRSIGZA(NS) 1461 ............................................................ 1463 ............................................................ 1464 Redelegation | post migration | 1465 ............................................................ 1467 NSB NSB 1468 DSB DSB 1470 ............................................................ 1471 Child at A: Child at B: Child at B: 1472 ZSKA ZSKA ZSKB 1473 ZSKB ZSKB KSKB 1474 KSKA KSKA RRSIGZB(DNSKEY) 1475 KSKB KSKB RRSIGKB(DNSKEY) 1476 RRSIGZB RRSIGZB 1477 RRSIGKB RRSIGKB 1478 RRSIGZA RRSIGZA 1479 RRSIGKA RRSIGKA 1481 SOAA SOAB SOAB 1482 RRSIGZA(SOA) RRSIGZB(SOA) RRSIGZB(SOA) 1484 NSA NSB NSB 1485 NSB RRSIGZB(NS) RRSIGZB(NS) 1486 RRSIGZA(NS) 1488 ............................................................ 1490 In this figure A denotes the loosing DNS operator and B the gaining 1491 DNS operator. RRSIGZ is the RRSIG produced by a ZSK, RRSIGK is 1492 produced with a KSK, the appendend A or B indicate the producers of 1493 the key pair. Child at A is how the zone content is represented by 1494 the loosing DNS operator and Child at B is how the zone content is 1495 represented by the gaining DNS operator. 1497 4.4.5.2. Non Cooperationg DNS Operators 1499 In the non-cooperative case matters are more complicated. The 1500 loosing operator may not cooperate and leave the data in the DNS as 1501 is. In the extreme case the loosing operator may become obstructive 1502 and publish a DNSKEY RR with a high TTL and corresponding signature 1503 validity so that registrar A's DNSKEY, would end up in caches for, in 1504 theory, tens of years. 1506 The problem arises when a validator tries to validate with the 1507 loosing operator's key and there is no signature material produced 1508 with the loosing operator available in the delegation path after 1509 redelegation from the loosing operator to the gaiing operator has 1510 taken place. One could imagine a rollover scenario where the gaining 1511 operator pulls all RRSIGs created by the loosing operator and 1512 publishes those in conjunction with its own signatures, but that 1513 would not allow any changes in the zone content. Since a 1514 redelegation took place the NS RRset has -- per definition-- changed 1515 so such rollover scenario will not work. Besides if zone transfers 1516 are not allowed by the loosing operator and NSEC3 is deployed in the 1517 loosing operator's zone then the gainging operator's zone will not 1518 have certainty that all of A's RRSIGs are transfered. 1520 The only viable option for the registrant is to publish its zone 1521 unsigned and ask the registry to remove the DS pointing to the 1522 loosing operator's DNSKEY for as long as the DNSKEY of the loosing 1523 operator, or any of the signatures produced by it are likely to 1524 disappear in caches, which as mentioned above could in theory be for 1525 tens of years. 1527 Note that some [OK: most/all ?] implementations limit the time 1528 DNSKEYs that seem to be unable to validate signatures are cached 1529 and/or will try to recover from cases where DNSKEYs do not seem to be 1530 able to validate data. Although that is not a protocol requirement 1531 it seems that that practice may limit the impact of this problem the 1532 problem of non-cooperating registrars. 1534 However, there is no operational methodology to work around this 1535 business issue and proper contractual relations ships between 1536 registrants and their registrars seem to be the only solution to cope 1537 with these problems. 1539 5. Next Record type 1541 One of the design tradeofs made during the development of DNSSEC has 1542 been to seperate the signing and serving operations instead of 1543 performing cryptographic operations on the fly. It is therefore 1544 necessry to create records that cover the very large number of non- 1545 existent names that lie between the names that do exist. 1547 There are two mechanisms to provide authenticated proof of non- 1548 existence in DNSSEC: clear text one and an obfuscated-data one. Each 1549 mechanism 1551 o includes a list of all the RRTYPEs present at the name; 1553 o stores only the name for which the zone is authoritative (that is, 1554 glue in the zone is omitted); and 1556 o uses a specific RRTYPE to store information about the RRTYPEs 1557 present at the name: the clear-text mechanism uses NSEC, and the 1558 obfuscated-data mechanism uses NSEC3. 1560 5.1. Differences between NSEC and NSEC3 1562 The clear text mechanism (NSEC) is implemented using a sorted linked 1563 list of names in the zone. The obfuscated-data mechanism (NSEC3) 1564 first hashes the names using a one-way hash function, and then sorts 1565 the resulting (hashed) strings. 1567 The NSEC record requires no cryptographic operations aside from 1568 validating its associated signature record. It is human readable and 1569 can be used in manual queries to determine correct operation. The 1570 disadvantage is that it allows for "zone walking", where one can 1571 request all the entries of a zone by following the next RRlabel 1572 pointed to in each subsequent NSEC record. 1574 Though all agree DNS data is accessible through query mechanisms, a 1575 side effect of NSEC is that it allows the contents of a zone file to 1576 be enumerated in full by sequential queries. Whilst for some 1577 operators this behaviour is acceptable or even desirable, for others 1578 it is undesirable for policy, regulatory or other reasons. This is 1579 the first difference between NSEC and NSEC3. 1581 The second difference between NSEC and NSEC3 is that NSEC requires a 1582 signature over every RR in the zonefile, thereby ensuring that any 1583 denial of existence is cryptographically signed. However, in a large 1584 zonefile containing many delegations very few of which are to signed 1585 zones, this may produce unacceptable additional overhead especially 1586 where insecure delegations are subject to frequent update (a typical 1587 example might be a TLD operator with few registrants using secure 1588 delegations). NSEC3 allows intervals between two such delegations to 1589 "Opt-out" in which case they may contain one more more insecure 1590 delegations, thus reducing the size and cryptographic complexity of 1591 the zone at the expense of the ability to cryptographically deny the 1592 existence of names in a specific span. 1594 The NSEC3 record uses a hashing method of the requested RRlabel. To 1595 increase the workload required to guess entries in the zone, the 1596 number of hashing iteration's can be specified in the NSEC3 record. 1597 Additionally, a salt can be specified that also modifies the hashes. 1598 Note that NSEC3 does not give full protection against information 1599 leakage from the zone. 1601 5.2. NSEC or NSEC3 1603 The first motivation to deploy NSEC3, prevention of zone enumeration, 1604 only makes sense when zone content is not highly structured or 1605 trivially guessable. Highly structured zones such as the in- 1606 addr.arpa, ip6.arpa and e164.arpa can be trivially enumerated using 1607 ordinary DNS properties while for small zones that only contain 1608 contain records in the APEX and a few common RRlabels such as "www" 1609 or "mail" guessing zone content and proving completeness is also 1610 trivial when using NSEC3. 1612 In those cases the use of NSEC is recommended to ease the work 1613 required by signers and validating resolvers. 1615 For large zones where there is an implication of "not readily 1616 available" RRlabels, such as those where one has to sign an NDA 1617 before obtaining it, NSEC3 is recommended. 1619 The considerations for the second reason to deploy NSEC3 are 1620 discussed below (Section 5.3.4). 1622 5.3. NSEC3 parameters 1624 The NSEC3 hashing algorithm is performed on the Fully Qualified 1625 Domain Name (FQDN) in its uncompressed form. This ensures brute 1626 force work done by an attacker for one (FQDN) RRlabel cannot be re- 1627 used for another (FQDN) RRlabel attack, as these entries are per 1628 definition unique. 1630 5.3.1. NSEC3 Algorithm 1632 The NSEC3 algorithm is specified as a version of the DNSKEY 1633 algorithm. The current options are: 1635 Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm 3, DSA. 1637 Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5, 1638 RSASHA1. 1640 The next record algorithm choice therefore depends solely on the 1641 DNSKEY algorithm picked. 1643 [Note that there is an issue here as well as mentioned in Section 3.4 1644 regarding RSASSA-PKCS1-v1_5 vs RSASSA-PSS as well as no algorithm 1645 choice for SHA-256] 1647 5.3.2. NSEC3 Iterations 1649 One of the concerns with NSEC3 is that bad actors could perform a 1650 pre-calculated dictionary attack in order to assess if certain domain 1651 names exist within the zones or not. Two mechanisms are introduced 1652 in the NSEC3 specification to increase the costs of such dictionary 1653 attacks: Iterations and Salt. 1655 RFC5155 [21] considers the trade-offs between incuring cost during 1656 the signing process, imposing costs to the validating nameserver, 1657 while still providing a reasonable barrier against dictionary 1658 attacks. It provides useful limits of iterations compared to RSA key 1659 size. These are 150 iterations for 1024 bit keys, 500 iterations for 1660 2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd 1661 of the maximum is deemed to be a sufficiently costly yet not 1662 excessive value. 1664 5.3.3. NSEC3 Salt 1666 While the NSEC3 iterations parameter increases the cost of hashing a 1667 dictionary word, the NSEC3 salt reduces the lifetime for which that 1668 calculated hash can be used. A change of the salt value by the zone 1669 owner would cause an attacker to lose all precalculated work for that 1670 zone. 1672 The FQDN RRlabel, which is part of the value that is hashed, already 1673 ensures that brute force work for one RRlabel can not be re-used to 1674 attack other RRlabel (e.g. in other domains) due to their uniqueness. 1676 The salt of all NSEC3 records in a zone needs to be the same. Since 1677 changing the salt requires all the NSEC3 records to be regenerated, 1678 and thus requires generating new RRSIG's over these NSEC3 records, it 1679 is recommended to align the change of the salt with a change of the 1680 Zone Signing Key, as that process in itself already requires all 1681 RRSIG's to be regenerated. If there is no critical dependency on 1682 incremental signing and the whole zone can be signed with little 1683 effort there is no need for such alignment. However, unlike Zone 1684 Signing Key changes, NSEC3 salt changes do not need special rollover 1685 procedures. It is possible to change the salt each time the zone is 1686 updated. 1688 5.3.4. Opt-out 1690 The Opt-Out mechanism was introduced to allow for a gradual 1691 introduction of signed records in zones that contain mostly 1692 delegation records. The use of the OPT-OUT flag changes the meaning 1693 of the NSEC3 span from authoritative denial of the existence of names 1694 within the span to a proof that DNSSEC is not available for the 1695 delegations within the span. [Editors Note: One could make this 1696 construct more correct by talking about the hashed names and the 1697 hashed span, but I believe that is overkill]. This allows for the 1698 addition or removal of the delegations covered by the span without 1699 recalculating or re- signing RRs in the NSEC3 RR chain. 1701 Opt-Out is specified to be used only over delegation points and will 1702 therefore only bring relieve in zones with a large number of zones 1703 and where the number of secure delegations is small. This 1704 consideration typically holds for large top-level-domains and similar 1705 zones, in most other circumstances Opt-Out should not be deployed. 1706 Further considerations can be found in RFC5155 section 12.2 [21]. 1708 6. Security Considerations 1710 DNSSEC adds data integrity to the DNS. This document tries to assess 1711 the operational considerations to maintain a stable and secure DNSSEC 1712 service. Not taking into account the 'data propagation' properties 1713 in the DNS will cause validation failures and may make secured zones 1714 unavailable to security-aware resolvers. 1716 7. IANA considerations 1718 There are no IANA considerations with respect to this document 1720 8. Acknowledgments 1722 Most of the text of this document is copied from RFC4641 [15] people 1723 involved in that work were in random order: Rip Loomis, Olafur 1724 Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van 1725 Rein, Tim McGinnis, Gilles Guette Olivier Courtay, Sam Weiler, Jelte 1726 Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, 1727 Marcos Sanz, Peter Koch, Mike StJohns, Emmar Bretherick, Adrian 1728 Bedford, and Lindy Foster, G. Guette, and O. Courtay. 1730 For this version of the document we would like to acknowldge a few 1731 people for significant contributions: 1733 o Paul Hoffman for his contribution on the choice of cryptographic 1734 paramenters and addressing some of the trust anchor issues. 1736 o Jelte Jansen who provided the text in Section 4.2.4 1738 o Paul Wouters who provided the initial text for Section 5 and Alex 1739 Bligh who improved it. 1741 In addition valuable contributions in the form of text, comments, or 1742 review where provided by Mark Andrews, Tony Finch, Scott Rose, Alfred 1743 Hines. 1745 [EDITOR NOTE: please let me know if there is an oversight here] 1747 9. References 1749 9.1. Normative References 1751 [1] Mockapetris, P., "Domain names - concepts and facilities", 1752 STD 13, RFC 1034, November 1987. 1754 [2] Mockapetris, P., "Domain names - implementation and 1755 specification", STD 13, RFC 1035, November 1987. 1757 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1758 "DNS Security Introduction and Requirements", RFC 4033, 1759 March 2005. 1761 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1762 "Resource Records for the DNS Security Extensions", RFC 4034, 1763 March 2005. 1765 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1766 "Protocol Modifications for the DNS Security Extensions", 1767 RFC 4035, March 2005. 1769 9.2. Informative References 1771 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1772 Levels", BCP 14, RFC 2119, March 1997. 1774 [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1775 August 1996. 1777 [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 1778 (DNS NOTIFY)", RFC 1996, August 1996. 1780 [9] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1781 RFC 2308, March 1998. 1783 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1784 Update", RFC 3007, November 2000. 1786 [11] Hollenbeck, S., "Generic Registry-Registrar Protocol 1787 Requirements", RFC 3375, September 2002. 1789 [12] Orman, H. and P. Hoffman, "Determining Strengths For Public 1790 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 1791 April 2004. 1793 [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1794 Requirements for Security", BCP 106, RFC 4086, June 2005. 1796 [14] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 1797 Mapping for the Extensible Provisioning Protocol (EPP)", 1798 RFC 4310, December 2005. 1800 [15] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1801 RFC 4641, September 2006. 1803 [16] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 1804 August 2007. 1806 [17] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust 1807 Anchors", RFC 5011, September 2007. 1809 [18] Rose, S., "NIST DNSSEC workshop notes", , June 2001. 1811 [19] Barker, E. and J. Kelsey, "Recommendation for Random Number 1812 Generation Using Deterministic Random Bit Generators 1813 (Revised)", Nist Special Publication 800-90, March 2007. 1815 [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 1816 Resource Records (RRs)", RFC 4509, May 2006. 1818 [21] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1819 Security (DNSSEC) Hashed Authenticated Denial of Existence", 1820 RFC 5155, March 2008. 1822 [22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1823 Protocol Version 1.2", RFC 5246, August 2008. 1825 [23] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and 1826 RRSIG Resource Records for DNSSEC", RFC 5702, October 2009. 1828 [24] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing 1829 Considerations", draft-morris-dnsop-dnssec-key-timing-01 (work 1830 in progress), October 2009. 1832 Appendix A. Terminology 1834 In this document, there is some jargon used that is defined in other 1835 documents. In most cases, we have not copied the text from the 1836 documents defining the terms but have given a more elaborate 1837 explanation of the meaning. Note that these explanations should not 1838 be seen as authoritative. 1840 Anchored key: A DNSKEY configured in resolvers around the globe. 1841 This key is hard to update, hence the term anchored. 1843 Bogus: Also see Section 5 of [3]. An RRSet in DNSSEC is marked 1844 "Bogus" when a signature of an RRSet does not validate against a 1845 DNSKEY. 1847 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is 1848 used exclusively for signing the apex key set. The fact that a 1849 key is a KSK is only relevant to the signing tool. 1851 Key size: The term 'key size' can be substituted by 'modulus size' 1852 throughout the document. It is mathematically more correct to use 1853 modulus size, but as this is a document directed at operators we 1854 feel more at ease with the term key size. 1856 Private and public keys: DNSSEC secures the DNS through the use of 1857 public key cryptography. Public key cryptography is based on the 1858 existence of two (mathematically related) keys, a public key and a 1859 private key. The public keys are published in the DNS by use of 1860 the DNSKEY Resource Record (DNSKEY RR). Private keys should 1861 remain private. 1863 Key rollover: A key rollover (also called key supercession in some 1864 environments) is the act of replacing one key pair with another at 1865 the end of a key effectivity period. 1867 Secure Entry Point (SEP) key: A KSK that has a parental DS record 1868 pointing to it or is configured as a trust anchor. Although not 1869 required by the protocol, we recommend that the SEP flag [5] is 1870 set on these keys. 1872 Self-signature: This only applies to signatures over DNSKEYs; a 1873 signature made with DNSKEY x, over DNSKEY x is called a self- 1874 signature. Note: without further information, self-signatures 1875 convey no trust. They are useful to check the authenticity of the 1876 DNSKEY, i.e., they can be used as a hash. 1878 Singing the zone file: The term used for the event where an 1879 administrator joyfully signs its zone file while producing melodic 1880 sound patterns. 1882 Signer: The system that has access to the private key material and 1883 signs the Resource Record sets in a zone. A signer may be 1884 configured to sign only parts of the zone, e.g., only those RRSets 1885 for which existing signatures are about to expire. 1887 Zone Signing Key (ZSK): A key that is used for signing all data in a 1888 zone (except, perhaps, the DNSKEY RRSet). The fact that a key is 1889 a ZSK is only relevant to the signing tool. 1891 Zone administrator: The 'role' that is responsible for signing a 1892 zone and publishing it on the primary authoritative server. 1894 Appendix B. Zone Signing Key Rollover How-To 1896 Using the pre-published signature scheme and the most conservative 1897 method to assure oneself that data does not live in caches, here 1898 follows the "how-to". 1900 Step 0: The preparation: Create two keys and publish both in your 1901 key set. Mark one of the keys "active" and the other "published". 1902 Use the "active" key for signing your zone data. Store the 1903 private part of the "published" key, preferably off-line. The 1904 protocol does not provide for attributes to mark a key as active 1905 or published. This is something you have to do on your own, 1906 through the use of a notebook or key management tool. 1908 Step 1: Determine expiration: At the beginning of the rollover make 1909 a note of the highest expiration time of signatures in your zone 1910 file created with the current key marked as active. Wait until 1911 the expiration time marked in Step 1 has passed. 1913 Step 2: Then start using the key that was marked "published" to sign 1914 your data (i.e., mark it "active"). Stop using the key that was 1915 marked "active"; mark it "rolled". 1917 Step 3: It is safe to engage in a new rollover (Step 1) after at 1918 least one signature validity period. 1920 Appendix C. Typographic Conventions 1922 The following typographic conventions are used in this document: 1924 Key notation: A key is denoted by DNSKEYx, where x is a number or an 1925 identifier, x could be thought of as the key id. 1927 RRSet notations: RRs are only denoted by the type. All other 1928 information -- owner, class, rdata, and TTL -- is left out. Thus: 1929 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a 1930 list of RRs. A example of this would be "A1, A2", specifying the 1931 RRSet containing two "A" records. This could again be abbreviated 1932 to just "A". 1934 Signature notation: Signatures are denoted as RRSIGx(RRSet), which 1935 means that RRSet is signed with DNSKEYx. 1937 Zone representation: Using the above notation we have simplified the 1938 representation of a signed zone by leaving out all unnecessary 1939 details such as the names and by representing all data by "SOAx" 1941 SOA representation: SOAs are represented as SOAx, where x is the 1942 serial number. 1944 Using this notation the following signed zone: 1946 example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 1947 2006022100 ; serial 1948 86400 ; refresh ( 24 hours) 1949 7200 ; retry ( 2 hours) 1950 3600000 ; expire (1000 hours) 1951 28800 ) ; minimum ( 8 hours) 1952 86400 RRSIG SOA 5 2 86400 20130522213204 ( 1953 20130422213204 14 example.net. 1954 cmL62SI6iAX46xGNQAdQ... ) 1955 86400 NS a.example.net. 1956 86400 NS b.example.net. 1957 86400 RRSIG NS 5 2 86400 20130507213204 ( 1958 20130407213204 14 example.net. 1959 SO5epiJei19AjXoUpFnQ ... ) 1960 86400 DNSKEY 256 3 5 ( 1961 EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 1962 86400 DNSKEY 257 3 5 ( 1963 gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 1964 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1965 20130422213204 14 example.net. 1966 J4zCe8QX4tXVGjV4e1r9... ) 1967 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1968 20130422213204 15 example.net. 1969 keVDCOpsSeDReyV6O... ) 1970 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 1971 20130407213204 14 example.net. 1972 obj3HEp1GjnmhRjX... ) 1973 a.example.net. 86400 IN TXT "A label" 1974 86400 RRSIG TXT 5 3 86400 20130507213204 ( 1975 20130407213204 14 example.net. 1976 IkDMlRdYLmXH7QJnuF3v... ) 1977 86400 NSEC b.example.com. TXT RRSIG NSEC 1978 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 1979 20130407213204 14 example.net. 1980 bZMjoZ3bHjnEz0nIsPMM... ) 1981 ... 1983 is reduced to the following representation: 1985 SOA2006022100 1986 RRSIG14(SOA2006022100) 1987 DNSKEY14 1988 DNSKEY15 1990 RRSIG14(KEY) 1991 RRSIG15(KEY) 1993 The rest of the zone data has the same signature as the SOA record, 1994 i.e., an RRSIG created with DNSKEY 14. 1996 Appendix D. Document Editing History 1998 [To be removed prior to publication as an RFC] 2000 D.1. draft-ietf-dnsop-rfc4641-00 2002 Version 0 was differs from RFC4641 in the following ways. 2004 o Status of this memo appropriate for I-D 2006 o TOC formatting differs. 2008 o Whitespaces, linebreaks, and pagebreaks may be slightly different 2009 because of xml2rfc generation. 2011 o References slightly reordered. 2013 o Applied the errata from 2014 http://www.rfc-editor.org/errata_search.php?rfc=4641 2016 o Inserted trivial "IANA considertations" section. 2018 In other words it should not contain substantive changes in content 2019 as intended by the workinggroup for the original RFC4641. 2021 D.2. version 0->1 2023 Cryptography details rewritten. (See http://www.nlnetlabs.nl/svn/ 2024 rfc4641bis/trunk/open-issues/cryptography_flawed) 2026 o Reference to NIST 800-90 added 2028 o RSA/SHA256 is being recommended in addition to RSA/SHA1. 2030 o Complete rewrite of Section 3.1.4.2 removing the table and 2031 suggesting a keysize of 1024 for keys in use for less than 8 2032 years, issued up to at least 2015. 2034 o Replaced the reference to Schneiers' applied cryptograpy with a 2035 reference to RFC4949. 2037 o Removed the KSK for high level zones consideration 2039 Applied some differentiation with respect of the use of a KSK for 2040 parent or trust-anchor relation http://www.nlnetlabs.nl/svn/ 2041 rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent 2042 http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 2043 rollover_assumptions 2045 Added Section 4.2.4 as suggested by Jelte Jansen in http:// 2046 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll 2048 Added Section 4.4.5.1 Issue identified by Antoin Verschuur http:// 2049 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 2050 non-cooperative-registrars 2052 In Appendix A: ZSK does not nescessarily sign the DNSKEY RRset. 2054 D.3. version 1->2 2056 o Significant rewrite of Section 3 whereby the argument is made that 2057 the timescakes for rollovers are made purely on operational 2058 arguments hopefully resolving http://www.nlnetlabs.nl/svn/ 2059 rfc4641bis/trunk/open-issues/discussion_of_timescales 2061 o Added Section 5 based on http://www.nlnetlabs.nl/svn/rfc4641bis/ 2062 trunk/open-issues/NSEC-NSEC3 2064 o Added a reference to draft-morris-dnsop-dnssec-key-timing [24] for 2065 the quantitative analysis on keyrolls 2067 o Updated Section 4.4.5 to reflect that the problem occurs when 2068 changing DNS operators, and not DNS registrars, also added the 2069 table indicating the redelegation procedure. Added text about the 2070 fact that implementations will dismiss keys that fail to validate 2071 at some point. 2073 o Updated a number of references. 2075 $Id: draft-ietf-dnsop-rfc4641bis-02.txt 41 2010-02-26 07:53:13Z olaf $ 2077 Authors' Addresses 2079 Olaf M. Kolkman 2080 NLnet Labs 2081 Kruislaan 419 2082 Amsterdam 1098 VA 2083 The Netherlands 2085 EMail: olaf@nlnetlabs.nl 2086 URI: http://www.nlnetlabs.nl 2087 Miek Gieben 2089 EMail: miek@miek.nl