idnits 2.17.1 draft-ietf-dnsop-rfc4641bis-03.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 == Line 1825 has weird spacing: '...Signing reuse...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (July 12, 2010) is 5008 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '12' is defined on line 2125, 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 (-06) exists of draft-ietf-dnsop-dnssec-key-timing-00 == Outdated reference: A later version (-11) exists of draft-ietf-dnsop-dnssec-dps-framework-01 Summary: 1 error (**), 0 flaws (~~), 7 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) July 12, 2010 5 Intended status: Informational 6 Expires: January 13, 2011 8 DNSSEC Operational Practices, Version 2 9 draft-ietf-dnsop-rfc4641bis-03 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 January 13, 2011. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 6 78 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 6 79 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 7 80 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 8 81 3.1. Operational motivation for ZSKs and KSKs . . . . . . . . . 8 82 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 8 83 3.1.2. Practical concequences of KSK and ZSK Separation . . . 10 84 3.1.2.1. Rolling a KSK that is not a trust-anchor . . . . . 10 85 3.1.2.2. Rolling a KSK that is a trust-anchor . . . . . . . 11 86 3.1.2.3. The use of the SEP flag . . . . . . . . . . . . . 12 87 3.1.3. Key Effectivity Period . . . . . . . . . . . . . . . . 12 88 3.1.4. Cryptographic Considerations . . . . . . . . . . . . . 13 89 3.1.4.1. Key Algorithm . . . . . . . . . . . . . . . . . . 13 90 3.1.4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . 14 91 3.1.4.3. Private Key Storage . . . . . . . . . . . . . . . 15 92 3.1.4.4. Key Generation . . . . . . . . . . . . . . . . . . 16 93 3.1.4.5. Differentiation for 'High-Level' Zones? . . . . . 16 94 4. Signature Generation, Key Rollover, and Related Policies . . . 17 95 4.1. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 17 96 4.1.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 17 97 4.1.1.1. Pre-Publish Key Rollover . . . . . . . . . . . . . 18 98 4.1.1.2. Double Signature Zone Signing Key Rollover . . . . 20 99 4.1.1.3. Pros and Cons of the Schemes . . . . . . . . . . . 21 100 4.1.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 21 101 4.1.3. Difference Between ZSK and KSK Rollovers . . . . . . . 23 102 4.1.4. Rollover for a Single Type Signing Key rollover . . . 24 103 4.1.5. Key algorithm rollover . . . . . . . . . . . . . . . . 26 104 4.1.6. Automated Key Rollovers . . . . . . . . . . . . . . . 28 105 4.2. Planning for Emergency Key Rollover . . . . . . . . . . . 28 106 4.2.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 29 107 4.2.1.1. Keeping the Chain of Trust Intact . . . . . . . . 29 108 4.2.1.2. Breaking the Chain of Trust . . . . . . . . . . . 30 109 4.2.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 31 110 4.2.3. Compromises of Keys Anchored in Resolvers . . . . . . 31 111 4.3. Parental Policies . . . . . . . . . . . . . . . . . . . . 31 112 4.3.1. Initial Key Exchanges and Parental Policies 113 Considerations . . . . . . . . . . . . . . . . . . . . 31 114 4.3.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 32 115 4.3.3. Security Lameness . . . . . . . . . . . . . . . . . . 32 116 4.3.4. DS Signature Validity Period . . . . . . . . . . . . . 33 117 4.3.5. Changing DNS Operators . . . . . . . . . . . . . . . . 34 118 4.3.5.1. Cooperationg DNS operators . . . . . . . . . . . . 34 119 4.3.5.2. Non Cooperationg DNS Operators . . . . . . . . . . 36 120 4.4. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 37 121 4.4.1. Time Considerations . . . . . . . . . . . . . . . . . 37 122 4.4.2. Signature Validation Periods . . . . . . . . . . . . . 39 123 4.4.2.1. Maximum Value . . . . . . . . . . . . . . . . . . 39 124 4.4.2.2. Minimum Value . . . . . . . . . . . . . . . . . . 39 125 4.4.2.3. differentiation between RR sets . . . . . . . . . 41 126 4.4.2.4. Other timing parameters in a zone . . . . . . . . 42 127 5. Next Record type . . . . . . . . . . . . . . . . . . . . . . . 42 128 5.1. Differences between NSEC and NSEC3 . . . . . . . . . . . 42 129 5.2. NSEC or NSEC3 . . . . . . . . . . . . . . . . . . . . . . 43 130 5.3. NSEC3 parameters . . . . . . . . . . . . . . . . . . . . . 44 131 5.3.1. NSEC3 Algorithm . . . . . . . . . . . . . . . . . . . 44 132 5.3.2. NSEC3 Iterations . . . . . . . . . . . . . . . . . . . 44 133 5.3.3. NSEC3 Salt . . . . . . . . . . . . . . . . . . . . . . 44 134 5.3.4. Opt-out . . . . . . . . . . . . . . . . . . . . . . . 45 135 6. Security Considerations . . . . . . . . . . . . . . . . . . . 45 136 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 45 137 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 138 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 139 9.1. Normative References . . . . . . . . . . . . . . . . . . . 46 140 9.2. Informative References . . . . . . . . . . . . . . . . . . 47 141 Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 48 142 Appendix B. Zone Signing Key Rollover How-To . . . . . . . . . . 50 143 Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 50 144 Appendix D. Document Editing History . . . . . . . . . . . . . . 52 145 D.1. draft-ietf-dnsop-rfc4641-00 . . . . . . . . . . . . . . . 52 146 D.2. version 0->1 . . . . . . . . . . . . . . . . . . . . . . . 52 147 D.3. version 1->2 . . . . . . . . . . . . . . . . . . . . . . . 53 148 D.4. version 2->3 . . . . . . . . . . . . . . . . . . . . . . . 54 150 1. Introduction 152 This document describes how to run a DNS Security (DNSSEC)-enabled 153 environment. It is intended for operators who have knowledge of the 154 DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. 155 The focus of the document is on serving authoritative DNS information 156 and concerns zone owners, name server operators, registry, registrar 157 and registrants whereby it is assumed that there is no direct 158 relation between those entities and the operators of validating 159 recursive name servers (validators). See RFC 4033 [3] for an 160 introduction to DNSSEC, RFC 4034 [4] for the newly introduced 161 Resource Records (RRs), and RFC 4035 [5] for the protocol changes. 163 During workshops and early operational deployment, operators and 164 system administrators have gained experience about operating the DNS 165 with security extensions (DNSSEC). This document translates these 166 experiences into a set of practices for zone administrators. At the 167 time of writing -the root is being signed and the first secure 168 delegations are provisioned- there exists relatively little 169 experience with DNSSEC in production environments; this document 170 should therefore explicitly not be seen as representing 'Best Current 171 Practices'. The document therefore targets to provide a number of 172 choices with the considerations that motivate a particular choice. 173 It then gives the operational guidelines that relate to a choice. 174 The document does not give strong recommendations, that may be 175 subject for a future version of this document. [OK: This is really a 176 straw-man and causes a difference in tone that I believe was the 177 instruction of the WG during the IETF 77 meeting. The document could 178 be made much shorter when particular recommendations are made? Is 179 there a general consensus that we should currently not make 180 particular recommendations?] 182 The procedures herein are focused on the maintenance of signed zones 183 (i.e., signing and publishing zones on authoritative servers). It is 184 intended that maintenance of zones such as re-signing or key 185 rollovers be transparent to any verifying clients on the Internet. 187 The structure of this document is as follows. In Section 2, we 188 discuss the importance of keeping the "chain of trust" intact. 189 Aspects of key generation and storage of private keys are discussed 190 in Section 3; the focus in this section is mainly on the private part 191 of the key(s). Section 4 describes considerations concerning the 192 public part of the keys. Since these public keys appear in the DNS 193 one has to take into account all kinds of timing issues, which are 194 discussed in Section 4.4. Section 4.1 and Section 4.2 deal with the 195 rollover, or supercession, of keys. Finally, Section 4.3 discusses 196 considerations on how parents deal with their children's public keys 197 in order to maintain chains of trust. 199 The typographic conventions used in this document are explained in 200 Appendix C. 202 Since this is a document with operational suggestions and there are 203 no protocol specifications, the RFC 2119 [6] language does not apply. 205 This document [OK: when approved] obsoletes RFC 4641 [15]. 207 [OK: Editorial comments and questions are indicated by square 208 brackets and editor innitials] 210 1.1. The Use of the Term 'key' 212 It is assumed that the reader is familiar with the concept of 213 asymmetric keys on which DNSSEC is based (public key cryptography 214 RFC4949 [16]). Therefore, this document will use the term 'key' 215 rather loosely. Where it is written that 'a key is used to sign 216 data' it is assumed that the reader understands that it is the 217 private part of the key pair that is used for signing. It is also 218 assumed that the reader understands that the public part of the key 219 pair is published in the DNSKEY Resource Record and that it is the 220 public part that is used in key exchanges. 222 1.2. Time Definitions 224 In this document, we will be using a number of time-related terms. 225 The following definitions apply: 227 o "Signature validity period" The period that a signature is valid. 228 It starts at the time specified in the signature inception field 229 of the RRSIG RR and ends at the time specified in the expiration 230 field of the RRSIG RR. 232 o "Signature publication period" Time after which a signature (made 233 with a specific key) is replaced with a new signature (made with 234 the same key). This replacement takes place by publishing the 235 relevant RRSIG in the master zone file. After one stops 236 publishing an RRSIG in a zone, it may take a while before the 237 RRSIG has expired from caches and has actually been removed from 238 the DNS. 240 o "Key effectivity period" The period during which a key pair is 241 expected to be effective. This period is defined as the time 242 between the first inception time stamp and the last expiration 243 date of any signature made with this key, regardless of any 244 discontinuity in the use of the key. The key effectivity period 245 can span multiple signature validity periods. 247 o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum 248 value of the TTLs from the complete set of RRs in a zone. Note 249 that the minimum TTL is not the same as the MINIMUM field in the 250 SOA RR. See RFC2308 [9] for more information. 252 2. Keeping the Chain of Trust Intact 254 Maintaining a valid chain of trust is important because broken chains 255 of trust will result in data being marked as Bogus (as defined in 256 RFC4033 [3] Section 5), which may cause entire (sub)domains to become 257 invisible to verifying clients. The administrators of secured zones 258 have to realize that their zone is, to verifying clients, part of a 259 chain of trust. 261 As mentioned in the introduction, the procedures herein are intended 262 to ensure that maintenance of zones, such as re-signing or key 263 rollovers, will be transparent to the verifying clients on the 264 Internet. 266 Administrators of secured zones will have to keep in mind that data 267 published on an authoritative primary server will not be immediately 268 seen by verifying clients; it may take some time for the data to be 269 transferred to other secondary authoritative nameservers and clients 270 may be fetching data from caching non-authoritative servers. In this 271 light, note that the time for a zone transfer from master to slave is 272 negligible when using NOTIFY [8] and incremental transfer (IXFR) [7]. 273 It increases when full zone transfers (AXFR) are used in combination 274 with NOTIFY. It increases even more if you rely on full zone 275 transfers based on only the SOA timing parameters for refresh. 277 For the verifying clients, it is important that data from secured 278 zones can be used to build chains of trust regardless of whether the 279 data came directly from an authoritative server, a caching 280 nameserver, or some middle box. Only by carefully using the 281 available timing parameters can a zone administrator ensure that the 282 data necessary for verification can be obtained. 284 The responsibility for maintaining the chain of trust is shared by 285 administrators of secured zones in the chain of trust. This is most 286 obvious in the case of a 'key compromise' when a trade-off between 287 maintaining a valid chain of trust and replacing the compromised keys 288 as soon as possible must be made. Then zone administrators will have 289 to make a trade-off, between keeping the chain of trust intact -- 290 thereby allowing for attacks with the compromised key -- or 291 deliberately breaking the chain of trust and making secured 292 subdomains invisible to security-aware resolvers. Also see 293 Section 4.2. 295 3. Keys Generation and Storage 297 This section describes a number of considerations with respect to the 298 use of keys. For the desgin of a operational procedure for key 299 generation and storage the following decisions need to be taken in 300 order: 302 o Does one differentiate between Zone Signing and Key Signing Keys 303 or is the use of one type of key sufficient; 305 o Are Key Signing Keys (likely to be) in use as Trust Anchors; 307 o What are the timing parameters that are allowed by the operational 308 requirements; and finally 310 o What are the cryptographic parameters that fit the operational 311 need? 313 Below are the considerations that need to be taken into account when 314 making decisions. 316 3.1. Operational motivation for ZSKs and KSKs 318 The DNSSEC validation protocol does not distinguish between different 319 types of DNSKEYs. All DNSKEYs can be used during the validation. 320 The motivations to differentiate between keys are purely operational. 322 For operational reasons, motivated below, it is possible to designate 323 one or more keys as Key Signing Keys (KSKs). These keys will only 324 sign the apex DNSKEY RRSet in a zone. Other keys can be used to sign 325 all the RRSets in a zone and are referred to as Zone Signing Keys 326 (ZSKs). In case the differentiation between KSK and ZSK is not made 327 we talk about a Single Type signing scheme 329 3.1.1. Motivations for the KSK and ZSK Separation 331 Differentiating between the KSK and ZSK is mostly done for 332 operational purposes whereby 334 If the two functions are separated then, for almost any method of key 335 management and zone signing, the KSK is used less frequently then the 336 ZSK. Once a key set is signed with the KSK, all the keys in the key 337 set can be used as ZSKs. If there has been an event that increases 338 the risk that a ZSK is compromised it can be simply dropped from the 339 key set. The new key set is then re-signed with the KSK. 341 Changing a key with secure entry point (SEP) functionality can be 342 relatively expensive as it involves interaction with 3rd parties: 344 When a key is only pointed to by the parental DS one needs to 345 complete the interaction with the parental registry and wait for the 346 transaction to appear in the DNS. In the case that a SEP key that is 347 in use as a trust-anchor one has to wait until one has sufficient 348 confidence that all trust anchors have been replaced. In fact, it 349 may be that one is not able to reach the complete user-base with 350 information about the key rollover. 352 There is also a risk that keys are compromised through theft or loss. 353 For keys that are needed to sign dynamically updated records and are 354 therefore installed on file-systems of nameservers that are connected 355 to the network that risk is relatively high. For keys that are 356 stored on Hardware Signing Modules such risk is relatively low. By 357 separating the KSK and ZSK functionality these risks can be managed 358 while making the tradeoff against the costs involved. For example, a 359 KSK can be stored off-line or with more limitation on access control 360 than ZSKs which need to be readily available for operational purposes 361 such as the addition or deletion of zone data. More concretely a KSK 362 stored on a smartcard, that is kept in a safe, combinded with a ZSK 363 stored on a filesystem accessible by operators for daily routine may 364 provide more operational flexibility and higher computational 365 performance than a single key (with combined KSK and ZSK 366 functionality) stored on an HSM. 368 [OK: The following paragraph is new in version 3 of the draft, does 369 it need to be more detailed e.g. by referring to RFC 3766? Also the 370 argument is made on http://www.educatedguesswork.org/2009/10/ 371 on_the_security_of_zsk_rollove.html, not sure about how about 372 providing a stable reference to that. Should we add an informative 373 reference here? ] 375 Finally there is a risk of cryptanalysis of the key material. The 376 costs of such analysis are correlated to the length of the key. 377 However, cryptanalysis arguments provide no strong motivation for a 378 KSK/ZSK split. Suppose one differentiates between a KSK and a ZSK 379 whereby the KSK effectivity period is X times the ZSK effectivity 380 period. Then, in order for the resistance to cryptanalysis to be the 381 same for the KSK and the ZSK, the KSK needs to be X times stronger 382 than the ZSK. Since for all practical purposes X will somewhere of 383 the order of 10 to 100 the associated key sizes will vary only about 384 a byte in size for symmetric keys. Which, translated to asymmetric 385 keys, is still an insignificant enough size difference to warrant a 386 key-split; not for packet size or signing speed arguments. 388 The arguments for differentiation between the ZSK and KSK are weakest 389 when: 391 the exposure to risk is low (e.g. when keys are stored on HSMs); 393 if one can be certain that a key is not used as a trust-anchor; 395 maintenance of the various keys cannot be performed through tools 396 (is prone to human error); and 398 the interaction through the registrar-registry provisioning chain 399 -- in particular the timely appearance of a new DS record in the 400 parent zone in emergency situations -- is predictable. 402 If the above holds then the costs of the operational complexity of a 403 KSK-ZSK split may outweigh the costs of operational flexibility and 404 choosing for a single type signing scheme is then a reasonable 405 option. In other cases we advise that the separation between KSKs 406 and ZSKs is made and that the SEP flag is exclusively set on KSKs. 408 3.1.2. Practical concequences of KSK and ZSK Separation 410 Given the assumption that for KSKs the SEP flag is set, the KSK can 411 be distinguished from a ZSK by examining the flag field in the DNSKEY 412 RR: If the flag field is an odd number it is a KSK. If it is an even 413 number it is a ZSK. 415 The Zone Signing Key can be used to sign all the data in a zone on a 416 regular basis. When a Zone Signing Key is to be rolled, no 417 interaction with the parent is needed. This allows for signature 418 validity periods on the order of days. 420 The Key Signing Key is only to be used to sign the DNSKEY RRs in a 421 zone. If a Key Signing Key is to be rolled over, there will be 422 interactions with parties other than the zone administrator. If 423 there is a parent zone, these can include the registry of the parent 424 zone or administrators of verifying resolvers that have the 425 particular key configured as secure entry points. If this is a trust 426 anchor, everyone relying on the trust anchor needs to roll over to 427 the new key. The latter may be subject to stability costs if 428 automated trust-anchor rollover mechanisms (such as e.g. RFC5011 429 [17]) are not in place. Hence, the key effectivity period of these 430 keys can and should be made much longer. 432 3.1.2.1. Rolling a KSK that is not a trust-anchor 434 There are 3 schools of thought on rolling a KSK that is not a trust 435 anchor: 437 o It should be done frequently and regularly (possibly every few 438 months) so that a key rollover remains an operational routine. 440 o It should be done frequently but irregularly. Frequently meaning 441 every few monthts, again based on the argument that a rollover is 442 a practiced and common operational routine, but irregular, i.e. 443 with a large jitter, so that 3rd parties do not start to rely on 444 the key and will not be tempted to configure those as a trust- 445 anchor. 447 o It should only be done when it is known or strongly suspected that 448 the key can be or has been compromised. 450 There is no widespread agreement on which of these three schools of 451 thought is better for different deployments of DNSSEC. There is a 452 stability cost every time a non-anchor KSK is rolled over, but it is 453 possibly low if the communication between the child and the parent is 454 good. On the other hand, the only completely effective way to tell 455 if the communication is good is to test it periodically. Thus, 456 rolling a KSK with a parent is only done for two reasons: to test and 457 verify the rolling system to prepare for an emergency, and in the 458 case of (preventing) an actual emergency. 460 Finally, a zone ower can, in most cases, not be fully certain that 461 the zone's KSK is not in use as a trust-anchor and while the 462 configuration of trust-anchors is not the responsibility of the zone 463 owner there may be stabilty costs for the validator administrator 464 that (wrongfully) configured the trust-anchor when the zone owner 465 roles a KSK. 467 3.1.2.2. Rolling a KSK that is a trust-anchor 469 The same operational concerns apply to the rollover of KSKs that are 470 used as trust-anchors. But remember: if a trust anchor replacement 471 is done incorrectly, the entire zone that the trust anchor covers 472 will become bogus until the trust anchor is corrected. 474 In a large number of cases it will be safe to work from the 475 assumption that ones keys are not in use as trust-anchors. If a zone 476 owner publishes a "DNSSEC Signing Policy and Practice Statement" [25] 477 that should be explicit about the fact whether the existence of trust 478 anchors will be taken into account in any way or not. There may be 479 cases where local policies enforce the configuration of trust-anchors 480 on zones which are mission critical (e.g. in enterprises where the 481 trust-anchor for the enterprise domain is configured in the 482 enterprise's validator) It is expected that the zone owners are aware 483 of such circumstances. 485 One can argue that because of the difficulty of getting all users of 486 a trust anchor to replace an old trust anchor with a new one, a KSK 487 that is a trust anchor should never be rolled unless it is known or 488 strongly suspected that the key has been compromised. In other words 489 the costs of a KSK rollover are prohibitively high because some users 490 cannot be reached. 492 However, the "operational habit" argument also applies to trust 493 anchor reconfiguration at the clients validator. If a short key 494 effectivity period is used and the trust anchor configuration has to 495 be revisited on a regular basis, the odds that the configuration 496 tends to be forgotten is smaller. In fact, the costs for those users 497 can be minimized by automating the rollover RFC5011 [17] and by 498 rolling the key regularly, and advertising such, so that the 499 operators of recursive nameservers will put the appropriate mechanism 500 in place to deal with these stability costs, or, in other words, 501 budget for these costs instead of incuring them unexpectedly. 503 It is therefore recommended to roll KSKs (that are likely to be used 504 as trust-anchors) if and only if those rollovers can be tracked using 505 standardized (e.g. RFC5011) mechanisms. 507 3.1.2.3. The use of the SEP flag 509 The so-called Secure Entry Point (SEP) [5] flag can be used to 510 distinguish between keys that are intended to be used as the secure 511 entry point into the zone when building chains of trust, e.g they are 512 (to be) pointed to by parental DS RRs or configured as a trust- 513 anchor. 515 While the SEP flag does not play any role in the validation failure 516 it is used in parctice for operational purposes such as for the 517 rollover mechanism discribed in RFC5011 [17]. The comon convention 518 is to set the SEP flag on any key that is used for key exchanges with 519 the parent and potentially for configuration as trust anchors. 520 Therefore it is recomended that the SEP flag is set on KSKs and not 521 on ZSKs while in those cases that a distinction between KSK and ZSK 522 is not made (i.e. for a Single Type signing scheme) the SEP flag is 523 recommended be set on all keys. 525 Note that signing tools may assume a KSK/ZSK split and use the (non) 526 presence of the SEP flag to determine which key is to be used for 527 signing zone data, these tools may get confused when a single type 528 signing scheme is used. 530 3.1.3. Key Effectivity Period 532 In general the available key lenght sets an upper limit on the Key 533 Effectivity Period. For all practical purposes it is sufficient to 534 define the Key Effectivity Period based on purely operational 535 requirements and match the keylength to that value; Ignoring the 536 operational perspective, a reasonable effectivity period for KSKs 537 that have a parent zone is of the order of 2 decades or longer. That 538 is, if one does not plan to test the rollover procedure, the key 539 should be effective essentially forever, and then only rolled over in 540 case of emergency. 542 When one chooses for a regular key-rollover, a reasonable key 543 effectivity period for KSKs that have a parent zone is 13 months, 544 with the intent to replace them after 12 months. As argued above, 545 this annual rollover gives operational practice to rollovers for both 546 the zone as the validator administrators. Besided, in most 547 environments a year is a timespan that is easily planned and 548 communicated. 550 In case keys are stored on on-line systems and the exposure to 551 various threats of compromise is fairly high an intended key 552 effectivity period of a month is reasonable for Zone Signing Keys. 554 Key effectivity periods can be made very short, as in a few minutes. 555 But when replacing keys one has to take the considerations from 556 Section 4.4 and Section 4.1 into account. 558 The motivation for having the ZSK's effectivity period shorter than 559 the KSK's effectivity period is rooted in the operational 560 consideration that it is more likely that operators have more 561 frequent read access to the ZSK than to the KSK. If ZSK's are 562 maintained on cryptographic Hardware Security Modules (HSM) than the 563 motivation to have different key effectivity periods is weakend. 565 However, if the risk of loss, theft or other compromise is the same 566 for a zone and key signing key there are little arguments to choose 567 different effectivity periods for ZSKs and KSKs. And in fact, when 568 the split between ZSKs and KSKs is not made than all considerations 569 above apply. 571 There are certainly cases (e.g. where the the costs and risk of 572 compromise, and the costs and risks involved with having to perform 573 an emergency roll are also low) that the use of a single type signing 574 scheme with a long key effectivity period is a good choice. 576 3.1.4. Cryptographic Considerations 578 3.1.4.1. Key Algorithm 580 There are currently two types of signature algorithms that can be 581 used in DNSSEC: RSA and DSA. Both are fully specified in many 582 freely-available documents, and both are widely considered to be 583 patent-free. The creation of signatures wiht RSA and DSA takes 584 roughly the same time, but DSA is about ten times slower for 585 signature verification. 587 We suggest the use of RSA/SHA-256 as the preferred signature 588 algorithms and RSA/SHA-1 as an alternative. Both have advantages and 589 disadvantages. RSA/SHA-1 has been deployed for many years, while 590 RSA/SHA-256 has only begun to be deployed. On the other hand, it is 591 expected that if effective attacks on either algorithm appeark, they 592 will appear for RSA/SHA-1 first. RSA/MD5 should not be considered 593 for use because RSA/MD5 will very likely be the first common-use 594 signature algorithm to have an effective attack. 596 At the time of publication, it is known that the SHA-1 hash has 597 cryptanalysis issues. There is work in progress on addressing these 598 issues. We recommend the use of public key algorithms based on 599 hashes stronger than SHA-1 (e.g., SHA-256), as soon as these 600 algorithms are available in protocol specifications (see RFC5702 [23] 601 and RFC4509 [20]) and implementations. 603 3.1.4.2. Key Sizes 605 DNSSEC signing keys should be large enough to avoid all know 606 cryptographic attacks during the lifetime of the key. To date, 607 despite huge efforts, no one has broken a regular 1024-bit key; in 608 fact, the best completed attack is estimated to be the equivalent of 609 a 700-bit key. An attacker breaking a 1024-bit signing key would 610 need expend phenominal amounts of networked computing power in a way 611 that would not be detected in order to break a single key. Because 612 of this, it is estimated that most zones can safely use 1024-bit keys 613 for at least the next ten years. A 1024-bit asymmetric key has an 614 approximate equivalent strength of a symmetric 80-bit key. 616 Keys that are used as extremely high value trust anchors, or non- 617 anchor keys that may be difficult to roll over, may want to use 618 lengths longer than 1024 bits. Typically, the next larger key size 619 used is 2048 bits, which have the approximate equivalent strength of 620 a symmetric 112-bit key. In a standard CPU, it takes about four 621 times as long to sign or verify with a 2048-bit key as it does with a 622 1024-bit key. 624 Another way to decide on the size of key to use is to remember that 625 the phenominal effort it takes for an attacker to break a 1024-bit 626 key is the same regardless of how the key is used. If an attacker 627 has the capability of breaking a 1024-bit DNSSEC key, he also has the 628 capability of breaking one of the many 1024-bit TLS trust anchor keys 629 that are installed with web browsers. If the value of a DNSSEC key 630 is lower to the attacker than the value of a TLS trust anchor, the 631 attacker will use the resources to attack the TLS trust anchor. 633 It is possible that there is a unexpected improvement in the ability 634 for attackers to beak keys, and that such an attack would make it 635 feasible to break 1024-bit keys but not 2048-bit keys. If such an 636 improvement happens, it is likely that there will be a huge amount of 637 publicity, particularly because of the large number of 1024-bit TLS 638 trust anchors build into popular web browsers. At that time, all 639 1024-bit keys (both ones with parent zones and ones that are trust 640 anchors) can be rolled over and replaced with larger keys. 642 Earlier documents (including the previous version of this document) 643 urged the use of longer keys in situations where a particular key was 644 "heavily used". That advice may have been true 15 years ago, but it 645 is not true today when using RSA or DSA algorithms and keys of 1024 646 bits or higher. 648 3.1.4.3. Private Key Storage 650 It is recommended that, where possible, zone private keys and the 651 zone file master copy that is to be signed be kept and used in off- 652 line, non-network-connected, physically secure machines only. 653 Periodically, an application can be run to add authentication to a 654 zone by adding RRSIG and NSEC RRs. Then the augmented file can be 655 transferred. 657 When relying on dynamic update [10] to manage a signed zone, be aware 658 that at least one private key of the zone will have to reside on the 659 master server. This key is only as secure as the amount of exposure 660 the server receives to unknown clients and the security of the host. 661 Although not mandatory, one could administer the DNS in the following 662 way. The master that processes the dynamic updates is unavailable 663 from generic hosts on the Internet, it is not listed in the NS RRSet, 664 although its name appears in the SOA RRs MNAME field. The 665 nameservers in the NS RRSet are able to receive zone updates through 666 NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This 667 approach is known as the "hidden master" setup. 669 The ideal situation is to have a one-way information flow to the 670 network to avoid the possibility of tampering from the network. 671 Keeping the zone master file on-line on the network and simply 672 cycling it through an off-line signer does not do this. The on-line 673 version could still be tampered with if the host it resides on is 674 compromised. For maximum security, the master copy of the zone file 675 should be off-net and should not be updated based on an unsecured 676 network mediated communication. 678 The ideal situation may not be achievable because of economic 679 tradeoffs between risks and costs. For instance, keeping a zone file 680 off-line is not practical and will increase the costs of operating a 681 DNS zone. So in practice the machines on which zone files are 682 maintained will be connected to a network. Operators are advised to 683 take security measures to shield unauthorized access to the master 684 copy in order to prevent modification of DNS data before its signed. 686 Similarly the choice for storing a private key in a HSM will be 687 influenced by a tradeoff between various concerns: 689 o The risks that an unauthorized person has unnoticed read-access to 690 the private key 692 o The remaining window of opportunity for the attacker. 694 o The economic impact of the possible attacks (for a TLD that impact 695 will in most cases be higher than for an individual users). 697 o The costs of rolling the (compromised) keys: whereby the costs of 698 roling a ZSK is lowest and the costs of rolling a KSK that is in 699 wide use as a trust anchor is highest 701 o The costs of buying and maintaining an HSM. 703 For dynamically updated secured zones [10], both the master copy and 704 the private key that is used to update signatures on updated RRs will 705 need to be on-line. 707 3.1.4.4. Key Generation 709 Careful generation of all keys is a sometimes overlooked but 710 absolutely essential element in any cryptographically secure system. 711 The strongest algorithms used with the longest keys are still of no 712 use if an adversary can guess enough to lower the size of the likely 713 key space so that it can be exhaustively searched. Technical 714 suggestions for the generation of random keys will be found in RFC 715 4086 [13] and NIST SP 800-900 [19]. One should carefully assess if 716 the random number generator used during key generation adheres to 717 these suggestions. 719 Keys with a long effectivity period are particularly sensitive as 720 they will represent a more valuable target and be subject to attack 721 for a longer time than short-period keys. It is strongly recommended 722 that long-term key generation occur off-line in a manner isolated 723 from the network via an air gap or, at a minimum, high-level secure 724 hardware. 726 3.1.4.5. Differentiation for 'High-Level' Zones? 728 In an earlier version of this document (RFC4641 [15]) we made a 729 differentiation between KSKs used for zones that are high in the DNS 730 hierarchy versus KSKs used for zones low in that hierarchy. 732 Longer keys are not useful because the crypto guidance is that 733 everyone should use keys that no one can break. Also, it is 734 impossible to judge which zones are more or less valuable to an 735 attacker. An attack can only be used if the compromise is unnoticed 736 and the attacker can act as an man-in-the-middle attack (MITM) in an 737 unnoticed way. If example. is compromised and the attacker forges 738 answers for somebank.example. and sends them out as an MITM, when the 739 attack is discovered it will be simple to prove that example. has 740 been compromised and the KSK will be rolled. Defining a long-term 741 successful attack is difficult for keys at any level. 743 4. Signature Generation, Key Rollover, and Related Policies 745 4.1. Key Rollovers 747 Regardless of whether a zone uses periodic key rollovers in order to 748 practice for emergencies, or only rolls over keys in an emergency, 749 key rollovers are a fact of life when using DNSSEC. Zone 750 administrators who are in the process of rolling their keys have to 751 take into account that data published in previous versions of their 752 zone still lives in caches. When deploying DNSSEC, this becomes an 753 important consideration; ignoring data that may be in caches may lead 754 to loss of service for clients. 756 The most pressing example of this occurs when zone material signed 757 with an old key is being validated by a resolver that does not have 758 the old zone key cached. If the old key is no longer present in the 759 current zone, this validation fails, marking the data "Bogus". 760 Alternatively, an attempt could be made to validate data that is 761 signed with a new key against an old key that lives in a local cache, 762 also resulting in data being marked "Bogus". 764 4.1.1. Zone Signing Key Rollovers 766 If the choice for splitting zone and key signing keys has been made 767 than those two types of keys can be rolled seperatly and zone signing 768 keys can be rolled without taking into acount DS records from the 769 parent or the configuration of such a key as trust-anchor. 771 For "Zone Signing Key rollovers", there are two ways to make sure 772 that during the rollover data still cached can be verified with the 773 new key sets or newly generated signatures can be verified with the 774 keys still in caches. One schema, described in Section 4.1.1.2, uses 775 double signatures; the other uses key pre-publication 776 (Section 4.1.1.1). The pros, cons, and recommendations are described 777 in Section 4.1.1.3. 779 4.1.1.1. Pre-Publish Key Rollover 781 This section shows how to perform a ZSK rollover without the need to 782 sign all the data in a zone twice -- the "pre-publish key rollover". 783 This method has advantages in the case of a key compromise. If the 784 old key is compromised, the new key has already been distributed in 785 the DNS. The zone administrator is then able to quickly switch to 786 the new key and remove the compromised key from the zone. Another 787 major advantage is that the zone size does not double, as is the case 788 with the double signature ZSK rollover. A small "how-to" for this 789 kind of rollover can be found in Appendix B. 791 Pre-publish key rollover involves four stages as follows: 793 ---------------------------------------------------------------- 794 initial new DNSKEY new RRSIGs DNSKEY removal 795 ---------------------------------------------------------------- 796 SOA0 SOA1 SOA2 SOA3 797 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 799 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 800 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 801 DNSKEY11 DNSKEY11 802 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 803 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 804 ---------------------------------------------------------------- 806 Pre-Publish Key Rollover 808 initial: Initial version of the zone: DNSKEY 1 is the Key Signing 809 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 810 Signing Key. 812 new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no 813 signatures are generated with this key yet, but this does not 814 secure against brute force attacks on the public key. The minimum 815 duration of this pre-roll phase is the time it takes for the data 816 to propagate to the authoritative servers plus TTL value of the 817 key set. 819 new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is 820 used to sign the data in the zone exclusively (i.e., all the 821 signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 822 remains published in the key set. This way data that was loaded 823 into caches from version 1 of the zone can still be verified with 824 key sets fetched from version 2 of the zone. The minimum time 825 that the key set including DNSKEY 10 is to be published is the 826 time that it takes for zone data from the previous version of the 827 zone to expire from old caches, i.e., the time it takes for this 828 zone to propagate to all authoritative servers plus the Maximum 829 Zone TTL value of any of the data in the previous version of the 830 zone. 832 DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, 833 now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the 834 DNSKEY 1. 836 The above scheme can be simplified by always publishing the "future" 837 key immediately after the rollover. The scheme would look as follows 838 (we show two rollovers); the future key is introduced in "new DNSKEY" 839 as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY 840 (II)": 842 initial new RRSIGs new DNSKEY 843 ----------------------------------------------------------------- 844 SOA0 SOA1 SOA2 845 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) 847 DNSKEY1 DNSKEY1 DNSKEY1 848 DNSKEY10 DNSKEY10 DNSKEY11 849 DNSKEY11 DNSKEY11 DNSKEY12 850 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 851 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 852 ---------------------------------------------------------------- 854 ---------------------------------------------------------------- 855 new RRSIGs (II) new DNSKEY (II) 856 ---------------------------------------------------------------- 857 SOA3 SOA4 858 RRSIG12(SOA3) RRSIG12(SOA4) 860 DNSKEY1 DNSKEY1 861 DNSKEY11 DNSKEY12 862 DNSKEY12 DNSKEY13 863 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 864 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 865 ---------------------------------------------------------------- 867 Pre-Publish Key Rollover, Showing Two Rollovers 869 Note that the key introduced in the "new DNSKEY" phase is not used 870 for production yet; the private key can thus be stored in a 871 physically secure manner and does not need to be 'fetched' every time 872 a zone needs to be signed. 874 4.1.1.2. Double Signature Zone Signing Key Rollover 876 This section shows how to perform a ZSK key rollover using the double 877 zone data signature scheme, aptly named "double signature rollover". 879 During the "new DNSKEY" stage the new version of the zone file will 880 need to propagate to all authoritative servers and the data that 881 exists in (distant) caches will need to expire, requiring at least 882 the Maximum Zone TTL. 884 Double signature ZSK rollover involves three stages as follows: 886 ---------------------------------------------------------------- 887 initial new DNSKEY DNSKEY removal 888 ---------------------------------------------------------------- 889 SOA0 SOA1 SOA2 890 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 891 RRSIG11(SOA1) 892 DNSKEY1 DNSKEY1 DNSKEY1 893 DNSKEY10 DNSKEY10 DNSKEY11 894 DNSKEY11 895 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 896 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 897 RRSIG11(DNSKEY) 898 ---------------------------------------------------------------- 900 Double Signature Zone Signing Key Rollover 902 initial: Initial Version of the zone: DNSKEY 1 is the Key Signing 903 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 904 Signing Key. 906 new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is 907 introduced into the key set and all the data in the zone is signed 908 with DNSKEY 10 and DNSKEY 11. The rollover period will need to 909 continue until all data from version 0 of the zone has expired 910 from remote caches. This will take at least the Maximum Zone TTL 911 of version 0 of the zone. 913 DNSKEY removal: DNSKEY 10 is removed from the zone. All the 914 signatures from DNSKEY 10 are removed from the zone. The key set, 915 now only containing DNSKEY 11, is re-signed with DNSKEY 1. 917 At every instance, RRSIGs from the previous version of the zone can 918 be verified with the DNSKEY RRSet from the current version and the 919 other way around. The data from the current version can be verified 920 with the data from the previous version of the zone. The duration of 921 the "new DNSKEY" phase and the period between rollovers should be at 922 least the Maximum Zone TTL. 924 Making sure that the "new DNSKEY" phase lasts until the signature 925 expiration time of the data in the initial version of the zone is 926 recommended. This way all caches are cleared of the old signatures. 927 However, this duration could be considerably longer than the Maximum 928 Zone TTL, making the rollover a lengthy procedure. 930 Note that in this example we assumed that the zone was not modified 931 during the rollover. New data can be introduced in the zone as long 932 as it is signed with both keys. 934 4.1.1.3. Pros and Cons of the Schemes 936 Pre-publish key rollover: This rollover does not involve signing the 937 zone data twice. Instead, before the actual rollover, the new key 938 is published in the key set and thus is available for 939 cryptanalysis attacks. A small disadvantage is that this process 940 requires four steps. Also the pre-publish scheme involves more 941 parental work when used for KSK rollovers as explained in 942 Section 4.1.3. 944 Double signature ZSK rollover: The drawback of this signing scheme 945 is that during the rollover the number of signatures in your zone 946 doubles; this may be prohibitive if you have very big zones. An 947 advantage is that it only requires three steps. 949 4.1.2. Key Signing Key Rollovers 951 For the rollover of a Key Signing Key, the same considerations as for 952 the rollover of a Zone Signing Key apply. However, we can use a 953 double signature scheme to guarantee that old data (only the apex key 954 set) in caches can be verified with a new key set and vice versa. 955 Since only the key set is signed with a KSK, zone size considerations 956 do not apply. 958 -------------------------------------------------------------------- 959 initial new DNSKEY DS change DNSKEY removal 960 -------------------------------------------------------------------- 961 Parent: 962 SOA0 --------> SOA1 --------> 963 RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> 964 DS1 --------> DS2 --------> 965 RRSIGpar(DS) --------> RRSIGpar(DS) --------> 967 Child: 968 SOA0 SOA1 --------> SOA2 969 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) 970 --------> 971 DNSKEY1 DNSKEY1 --------> DNSKEY2 972 DNSKEY2 --------> 973 DNSKEY10 DNSKEY10 --------> DNSKEY10 974 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) 975 RRSIG2 (DNSKEY) --------> 976 RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) 977 -------------------------------------------------------------------- 979 Stages of Deployment for a Double Signature Key Signing Key Rollover 981 initial: Initial version of the zone. The parental DS points to 982 DNSKEY1. Before the rollover starts, the child will have to 983 verify what the TTL is of the DS RR that points to DNSKEY1 -- it 984 is needed during the rollover and we refer to the value as TTL_DS. 986 new DNSKEY: During the "new DNSKEY" phase, the zone administrator 987 generates a second KSK, DNSKEY2. The key is provided to the 988 parent, and the child will have to wait until a new DS RR has been 989 generated that points to DNSKEY2. After that DS RR has been 990 published on all servers authoritative for the parent's zone, the 991 zone administrator has to wait at least TTL_DS to make sure that 992 the old DS RR has expired from caches. 994 DS change: The parent replaces DS1 with DS2. 996 DNSKEY removal: DNSKEY1 has been removed. 998 The scenario above puts the responsibility for maintaining a valid 999 chain of trust with the child. It also is based on the premise that 1000 the parent only has one DS RR (per algorithm) per zone. An 1001 alternative mechanism has been considered. Using an established 1002 trust relation, the interaction can be performed in-band, and the 1003 removal of the keys by the child can possibly be signaled by the 1004 parent. In this mechanism, there are periods where there are two DS 1005 RRs at the parent. Since at the moment of writing the protocol for 1006 this interaction has not been developed, further discussion is out of 1007 scope for this document. 1009 The scenario scetched above assumes that the KSK is not in use as a 1010 trust-anchor too. If that is the case then special care need to be 1011 taken. For instance, when RFC5011 type rollover is in use then the 1012 DNSKEY1 removal phase above is the moment that the revoke flag is set 1013 on DNSKEY1 while it is still published, at least as long as the 1014 RFC5011 holdback timer proscribes. Only after that timer expired 1015 DNSKEY1 can be removed. 1017 4.1.3. Difference Between ZSK and KSK Rollovers 1019 Note that KSK rollovers and ZSK rollovers are different in the sense 1020 that a KSK rollover requires interaction with the parent (and 1021 possibly replacing of trust anchors) and the ensuing delay while 1022 waiting for it. 1024 A zone key rollover can be handled in two different ways: pre-publish 1025 (Section 4.1.1.1) and double signature (Section 4.1.1.2). 1027 As the KSK is used to validate the key set and because the KSK is not 1028 changed during a ZSK rollover, a cache is able to validate the new 1029 key set of the zone. The pre-publish method would also work for a 1030 KSK rollover. The records that are to be pre-published are the 1031 parental DS RRs. The pre-publish method has some drawbacks for KSKs. 1032 We first describe the rollover scheme and then indicate these 1033 drawbacks. 1035 -------------------------------------------------------------------- 1036 initial new DS new DNSKEY DS/DNSKEY removal 1037 -------------------------------------------------------------------- 1038 Parent: 1039 SOA0 SOA1 --------> SOA2 1040 RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) 1041 DS1 DS1 --------> DS2 1042 DS2 --------> 1043 RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) 1045 Child: 1046 SOA0 --------> SOA1 SOA1 1047 RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) 1048 --------> 1049 DNSKEY1 --------> DNSKEY2 DNSKEY2 1050 --------> 1051 DNSKEY10 --------> DNSKEY10 DNSKEY10 1052 RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 1053 RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) 1054 -------------------------------------------------------------------- 1056 Stages of Deployment for a Pre-Publish Key Signing Key Rollover 1058 When the child zone wants to roll, it notifies the parent during the 1059 "new DS" phase and submits the new key (or the corresponding DS) to 1060 the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 1061 and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), 1062 which can take place as soon as the new DS set propagated through the 1063 DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that 1064 ("DS/DNSKEY removal" phase), it can notify the parent that the old DS 1065 record can be deleted. 1067 The drawbacks of this scheme are that during the "new DS" phase the 1068 parent cannot verify the match between the DS2 RR and DNSKEY2 using 1069 the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a 1070 "security lame" key (see Section 4.3.3). Finally, the child-parent 1071 interaction consists of two steps. The "double signature" method 1072 only needs one interaction. 1074 4.1.4. Rollover for a Single Type Signing Key rollover 1076 The rollover of a DNSKEY when a Single Type Signing scheme is used is 1077 subject to the same requirement as the rollover of a KSK or ZSK: 1078 During any stage of the rollover the chain of trust needs to continue 1079 to validate for any combination of data in the zone as well as data 1080 that may still live in distant caches. 1082 There are two variants for this rollover. Since the choice for a 1083 Single Type Signing scheme is motivated by operational simplicity we 1084 first describe the most straightforward rollover scheme first. 1086 ----------------------------------------------------------------- 1087 initial new DNSKEY DS change DNSKEY removal 1088 ----------------------------------------------------------------- 1089 Parent: 1090 SOA0 --------> SOA1 --------> 1091 RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> 1092 DS1 --------> DS2 --------> 1093 RRSIGpar(DS) --------> RRSIGpar(DS) --------> 1095 Child: 1096 SOA0 SOA1 ------------> SOA2 1097 RRSIG1(SOA0) RRSIG1(SOA1) ------------> RRSIG2(SOA2) 1098 RRSIG2(SOA1) ------------> 1099 DNSKEY1 DNSKEY1 ------------> DNSKEY2 1100 DNSKEY2 ------------> 1101 RRSIG1(DNSKEY) RRSIG1(DNSKEY) ------------> RRSIG2(DNSKEY) 1102 RRSIG2(DNSKEY) ------------> 1103 ----------------------------------------------------------------- 1105 Stages of the Straightforward rollover in a Single Type Signing 1106 scheme. 1108 initial: Parental DS points to DNSKEY1. All RR sets in the zone are 1109 signed with DNSKEY1. 1111 new DNSKEY: A new key (DNSKEY2) is introduced and all the RR sets 1112 are signed with both DNSKEY1 and DNSKEY2. 1114 DS change: After the DNSKEY RRset with the two keys had time to 1115 propagate into distant caches (that is the key set exclusively 1116 containing DNSKEY1 has been expired) the parental DS record can be 1117 changed. 1119 DNSKEY removal: After the DS RRset containing DS1 has expired from 1120 distant caches DNSKEY1 can be removed from the DNSKEY RRset . 1122 There is a second variety of this rollover during which one 1123 introduces a new DNSKEY into the key set and signs the keyset with 1124 both keys while signing the zone data with only the original DNSKEY1. 1125 One replaces the DNSKEY1 signatures with signatures made with DNSKEY2 1126 at the moment of DNSKEY1 removal. 1128 The second variety of this rollover can be considered when zone size 1129 considerations prevent the introduction of double signatures over all 1130 of the zone data although in that case choosing for a KSK/ZSK split 1131 may be a better option. 1133 A double DS rollover scheme is compatible with a rollover using a 1134 Single Type signing scheme although in order to maintain a valid 1135 chain of trust the zone data would need to be published with a double 1136 signatures or a double key key set would need to be published. Since 1137 this leads to increase in zone and packet size at both child and 1138 parent there are little benefits to a double DS rollover with a 1139 Single Type signing scheme. 1141 4.1.5. Key algorithm rollover 1143 A special class of keyrollover is the rollover of key algorithms 1144 (either adding a new algorithm, removing an old algorithm, or both), 1145 additional steps are needed to retain integrity during the rollover. 1147 Because of the algorithm downgrade protection in RFC4035 section 2.2, 1148 you may not have a key of an algorithm for which you do not have 1149 signatures. 1151 When adding a new algorithm, the signatures should be added first. 1152 After the TTL has expired, and caches have dropped the old data 1153 covered by those signatures, the DNSKEY with the new algorithm can be 1154 added. When removing an old algorithm, the DNSKEY should be removed 1155 first. 1157 The following figure describes the steps. Whereby the trailing 1158 underscored number indicates the algorithm and ZSK and KSK indicate 1159 the obvious difference in key use. For example DNSKEY_KSK_1 is a the 1160 DNSKEY RR representing the public part of a key signing key of 1161 algorithm type 1 while RRSIG_ZSK_2(SOA3) is the RRSIG RR made with 1162 the private part of a zone signing key of algorithm type 2 over a SOA 1163 RR (that has serialnumber 3). 1165 ---------------------------------------------------------------- 1166 1 Initial 2 New RRSIGS 3 New DNSKEY 1167 ---------------------------------------------------------------- 1168 SOA0 SOA1 SOA2 1169 RRSIG_ZSK_1(SOA0) RRSIG_ZSK_1(SOA1) RRSIG_ZSK_1(SOA2) 1170 RRSIG_ZSK_2(SOA1) RRSIG_ZSK_2(SOA2) 1172 DNSKEY_KSK_1 DNSKEY_KSK_1 DNSKEY_KSK_1 1173 DNSKEY_ZSK_1 DNSKEY_ZSK_1 DNSKEY_ZSK_1 1174 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_1(DNSKEY) DNSKEY_KSK_2 1175 RRSIG_KSK_2(DNSKEY) DNSKEY_ZKS_2 1176 RRSIG_KSK_1(DNSKEY) 1177 RRSIG_KSK_2(DNSKEY) 1178 ---------------------------------------------------------------- 1179 4 Remove DNSKEY 5 Remove RRSIGS 1180 ---------------------------------------------------------------- 1181 SOA3 SOA4 1182 RRSIG_ZSK_1(SOA3) RRSIG_ZSK_2(SOA4) 1183 RRSIG_ZSK_2(SOA3) 1185 DNSKEY_KSK_2 DNSKEY_KSK_2 1186 DNSKEY_ZSK_2 DNSKEY_ZSK_2 1187 RRSIG_KSK_1(DNSKEY) RRSIG_KSK_2(DNSKEY) 1188 RRSIG_KSK_2(DNSKEY) 1189 ---------------------------------------------------------------- 1191 Stages of Deployment during an Algorithm Rollover. 1193 In step 2, the signatures for the new key are added, but the key 1194 itself is not. While in theory, the signatures of the keyset should 1195 always be synchronized with the keyset itself, it can be possible 1196 that RRSIGS are requested separately, so it might be prudent to also 1197 sign the DNSKEY set with the new signature. 1199 After the cache data has expired, the new key can be added to the 1200 zone, as done in step 3. 1202 The next step is to remove the old algorithm. This time the key 1203 needs to be removed first, before removing the signatures. The key 1204 is removed in step 4, and after the cache data has expired, the 1205 signatures can be removed in step 5. 1207 If a parent needs to roll a DS record that step can be done during 1208 stage 3. First one has to wait until caches are populated with the 1209 content of the DNSKEY RRset that was created at the beginning of 1210 stage 3, then the parent can swap the DS from pointing to 1211 DNSKEY_KSK_1 to DNSKEY_KSK_2, and then one has to wait for the old DS 1212 to expire from distant caches before taking step 4. 1214 [OK:The following paragrapgh is provisional and needs careful 1215 review.] 1217 A special case is the rollover from an NSEC signed zone to an NSEC3 1218 signed zone. In this case algortihm numbers are used to signal 1219 support for NSEC3 but they do not mandate the use of NSEC3. 1220 Therefore NSEC records should remain to be served untill the rollover 1221 to a new algorithm has completed and the new DNSKEY RR set has 1222 populated distant caches(at least one TTL into stage 4, or at any 1223 time during stage 5). At that stage the validators that have not 1224 implemented NSEC3 will treat the zone as unsecured as soon as they 1225 follow the chain of trust to DS that points to a DNSKEY of the new 1226 algorithm while validators that support NSEC3 will happily validate 1227 using NSEC. Turning on NSEC3 can then be done when moving from one 1228 serial to another, realizing that that involves a resigning of the 1229 zone and the introduction of the NSECPARAM record in order to signal 1230 authoritative servers to start serving NSEC3 authenticated denial of 1231 existence. 1233 4.1.6. Automated Key Rollovers 1235 As keys must be renewed periodically, there is some motivation to 1236 automate the rollover process. Consider the following: 1238 o ZSK rollovers are easy to automate as only the child zone is 1239 involved. 1241 o A KSK rollover needs interaction between parent and child. Data 1242 exchange is needed to provide the new keys to the parent; 1243 consequently, this data must be authenticated and integrity must 1244 be guaranteed in order to avoid attacks on the rollover. 1246 4.2. Planning for Emergency Key Rollover 1248 This section deals with preparation for a possible key compromise. 1249 Our advice is to have a documented procedure ready for when a key 1250 compromise is suspected or confirmed. 1252 When the private material of one of your keys is compromised it can 1253 be used for as long as a valid trust chain exists. A trust chain 1254 remains intact for 1256 o as long as a signature over the compromised key in the trust chain 1257 is valid, 1259 o as long as a parental DS RR (and signature) points to the 1260 compromised key, 1262 o as long as the key is anchored in a resolver and is used as a 1263 starting point for validation (this is generally the hardest to 1264 update). 1266 While a trust chain to your compromised key exists, your namespace is 1267 vulnerable to abuse by anyone who has obtained illegitimate 1268 possession of the key. Zone operators have to make a trade-off if 1269 the abuse of the compromised key is worse than having data in caches 1270 that cannot be validated. If the zone operator chooses to break the 1271 trust chain to the compromised key, data in caches signed with this 1272 key cannot be validated. However, if the zone administrator chooses 1273 to take the path of a regular rollover, the malicious key holder can 1274 spoof data so that it appears to be valid. 1276 4.2.1. KSK Compromise 1278 A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable 1279 as long as the compromised KSK is configured as trust anchor or a 1280 parental DS points to it. 1282 A compromised KSK can be used to sign the key set of an attacker's 1283 zone. That zone could be used to poison the DNS. 1285 Therefore, when the KSK has been compromised, the trust anchor or the 1286 parental DS should be replaced as soon as possible. It is local 1287 policy whether to break the trust chain during the emergency 1288 rollover. The trust chain would be broken when the compromised KSK 1289 is removed from the child's zone while the parent still has a DS 1290 pointing to the compromised KSK (the assumption is that there is only 1291 one DS at the parent. If there are multiple DSes this does not apply 1292 -- however the chain of trust of this particular key is broken). 1294 Note that an attacker's zone still uses the compromised KSK and the 1295 presence of a parental DS would cause the data in this zone to appear 1296 as valid. Removing the compromised key would cause the attacker's 1297 zone to appear as valid and the child's zone as Bogus. Therefore, we 1298 advise not to remove the KSK before the parent has a DS to a new KSK 1299 in place. 1301 4.2.1.1. Keeping the Chain of Trust Intact 1303 If we follow this advice, the timing of the replacement of the KSK is 1304 somewhat critical. The goal is to remove the compromised KSK as soon 1305 as the new DS RR is available at the parent. And also make sure that 1306 the signature made with a new KSK over the key set with the 1307 compromised KSK in it expires just after the new DS appears at the 1308 parent, thus removing the old cruft in one swoop. 1310 The procedure is as follows: 1312 1. Introduce a new KSK into the key set, keep the compromised KSK in 1313 the key set. 1315 2. Sign the key set, with a short validity period. The validity 1316 period should expire shortly after the DS is expected to appear 1317 in the parent and the old DSes have expired from caches. 1319 3. Upload the DS for this new key to the parent. 1321 4. Follow the procedure of the regular KSK rollover: Wait for the DS 1322 to appear in the authoritative servers and then wait as long as 1323 the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet 1324 and modify/extend the expiration time. 1326 5. Remove the compromised DNSKEY RR from the zone and re-sign the 1327 key set using your "normal" validity interval. 1329 An additional danger of a key compromise is that the compromised key 1330 could be used to facilitate a legitimate DNSKEY/DS rollover and/or 1331 nameserver changes at the parent. When that happens, the domain may 1332 be in dispute. An authenticated out-of-band and secure notify 1333 mechanism to contact a parent is needed in this case. 1335 Note that this is only a problem when the DNSKEY and or DS records 1336 are used for authentication at the parent. 1338 4.2.1.2. Breaking the Chain of Trust 1340 There are two methods to break the chain of trust. The first method 1341 causes the child zone to appear 'Bogus' to validating resolvers. The 1342 other causes the child zone to appear 'insecure'. These are 1343 described below. 1345 In the method that causes the child zone to appear 'Bogus' to 1346 validating resolvers, the child zone replaces the current KSK with a 1347 new one and re-signs the key set. Next it sends the DS of the new 1348 key to the parent. Only after the parent has placed the new DS in 1349 the zone is the child's chain of trust repaired. 1351 An alternative method of breaking the chain of trust is by removing 1352 the DS RRs from the parent zone altogether. As a result, the child 1353 zone would become insecure. 1355 4.2.2. ZSK Compromise 1357 Primarily because there is no parental interaction required when a 1358 ZSK is compromised, the situation is less severe than with a KSK 1359 compromise. The zone must still be re-signed with a new ZSK as soon 1360 as possible. As this is a local operation and requires no 1361 communication between the parent and child, this can be achieved 1362 fairly quickly. However, one has to take into account that just as 1363 with a normal rollover the immediate disappearance of the old 1364 compromised key may lead to verification problems. Also note that as 1365 long as the RRSIG over the compromised ZSK is not expired the zone 1366 may be still at risk. 1368 4.2.3. Compromises of Keys Anchored in Resolvers 1370 A key can also be pre-configured in resolvers. For instance, if 1371 DNSSEC is successfully deployed the root key may be pre-configured in 1372 most security aware resolvers. 1374 If trust-anchor keys are compromised, the resolvers using these keys 1375 should be notified of this fact. Zone administrators may consider 1376 setting up a mailing list to communicate the fact that a SEP key is 1377 about to be rolled over. This communication will of course need to 1378 be authenticated, e.g., by using digital signatures. 1380 End-users faced with the task of updating an anchored key should 1381 always validate the new key. New keys should be authenticated out- 1382 of-band, for example, through the use of an announcement website that 1383 is secured using secure sockets (TLS) [22]. 1385 4.3. Parental Policies 1387 4.3.1. Initial Key Exchanges and Parental Policies Considerations 1389 The initial key exchange is always subject to the policies set by the 1390 parent. The initial key exchange is always subject to the policies 1391 set by the parent. This is specifically important in a registry- 1392 registrar model where the key material is to be passed from the DNS 1393 operator, via a registrar to the (parent) registry, where both DNS 1394 operator and registrar is selected by the registrant and they might 1395 be different organisations. When designing a key exchange policy one 1396 should take into account that the authentication and authorization 1397 mechanisms used during a key exchange should be as strong as the 1398 authentication and authorization mechanisms used for the exchange of 1399 delegation information between parent and child. That is, there is 1400 no implicit need in DNSSEC to make the authentication process 1401 stronger than it was in DNS. 1403 Using the DNS itself as the source for the actual DNSKEY material, 1404 with an out-of-band check on the validity of the DNSKEY, has the 1405 benefit that it reduces the chances of user error. A DNSKEY query 1406 tool can make use of the SEP bit [5] to select the proper key from a 1407 DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is 1408 sent. It can validate the self-signature over a key; thereby 1409 verifying the ownership of the private key material. Fetching the 1410 DNSKEY from the DNS ensures that the chain of trust remains intact 1411 once the parent publishes the DS RR indicating the child is secure. 1413 Note: the out-of-band verification is still needed when the key 1414 material is fetched via the DNS. The parent can never be sure 1415 whether or not the DNSKEY RRs have been spoofed. 1417 4.3.2. Storing Keys or Hashes? 1419 When designing a registry system one should consider which of the 1420 DNSKEYs and/or the corresponding DSes to store. Since a child zone 1421 might wish to have a DS published using a message digest algorithm 1422 not yet understood by the registry, the registry can't count on being 1423 able to generate the DS record from a raw DNSKEY. Thus, we recommend 1424 that registry systems at least support storing DS records. 1426 It may also be useful to store DNSKEYs, since having them may help 1427 during troubleshooting and, as long as the child's chosen message 1428 digest is supported, the overhead of generating DS records from them 1429 is minimal. Having an out-of-band mechanism, such as a registry 1430 directory (e.g., Whois), to find out which keys are used to generate 1431 DS Resource Records for specific owners and/or zones may also help 1432 with troubleshooting. 1434 The storage considerations also relate to the design of the customer 1435 interface and the method by which data is transferred between 1436 registrant and registry; Will the child zone administrator be able to 1437 upload DS RRs with unknown hash algorithms or does the interface only 1438 allow DNSKEYs? When Registries support the Extensible Provisioning 1439 Protocol (EPP) [14] then that can be used for registrar-registry 1440 interactions since that protocol allows the transfer of DS and 1441 optionally DNSKEY RRs. For moving data between DNS operator and 1442 registrar there is no standardized way for moving the data. 1443 Different registrars have different mechanisms, ranging from simple 1444 web interfaces to various APIs. In some cases the use of the DNSSEC 1445 extentions to EPP may be aplicable to. 1447 4.3.3. Security Lameness 1449 Security lameness is defined as what happens when a parent has a DS 1450 RR pointing to a non-existing DNSKEY RR. When this happens, the 1451 child's zone may be marked "Bogus" by verifying DNS clients. 1453 As part of a comprehensive delegation check, the parent could, at key 1454 exchange time, verify that the child's key is actually configured in 1455 the DNS. However, if a parent does not understand the hashing 1456 algorithm used by child, the parental checks are limited to only 1457 comparing the key id. 1459 Child zones should be very careful in removing DNSKEY material, 1460 specifically SEP keys, for which a DS RR exists. 1462 Once a zone is "security lame", a fix (e.g., removing a DS RR) will 1463 take time to propagate through the DNS. 1465 4.3.4. DS Signature Validity Period 1467 Since the DS can be replayed as long as it has a valid signature, a 1468 short signature validity period over the DS minimizes the time a 1469 child is vulnerable in the case of a compromise of the child's 1470 KSK(s). A signature validity period that is too short introduces the 1471 possibility that a zone is marked "Bogus" in case of a configuration 1472 error in the signer. There may not be enough time to fix the 1473 problems before signatures expire. Something as mundane as operator 1474 unavailability during weekends shows the need for DS signature 1475 validity periods longer than 2 days. We recommend an absolute 1476 minimum for a DS signature validity period of a few days. 1478 The maximum signature validity period of the DS record depends on how 1479 long child zones are willing to be vulnerable after a key compromise. 1480 On the other hand, shortening the DS signature validity interval 1481 increases the operational risk for the parent. Therefore, the parent 1482 may have policy to use a signature validity interval that is 1483 considerably longer than the child would hope for. 1485 A compromise between the operational constraints of the parent and 1486 minimizing damage for the child may result in a DS signature validity 1487 period somewhere between a week and months. 1489 In addition to the signature validity period, which sets a lower 1490 bound on the number of times the zone owner will need to sign the 1491 zone data and which sets an upper bound to the time a child is 1492 vulnerable after key compromise, there is the TTL value on the DS 1493 RRs. Shortening the TTL means that the authoritative servers will 1494 see more queries. But on the other hand, a short TTL lowers the 1495 persistence of DS RRSets in caches thereby increasing the speed with 1496 which updated DS RRSets propagate through the DNS. 1498 4.3.5. Changing DNS Operators 1500 [OK: No feedback received between version 2 and 3. This is likely to 1501 remain] 1503 4.3.5.1. Cooperationg DNS operators 1505 The parent-child relation is often described in terms of a (thin) 1506 registry model. Where a registry maintains the parent zone, and the 1507 registrant (the user of the child-domain name), deals with the 1508 registry through an intermediary called a registrar. (See [11] for a 1509 comprehensive definition). Registrants may out-source the 1510 maintenance of their DNS system, including the maintenance of DNSSEC 1511 key material, to the registrar or to another third party, which we 1512 will call the DNS operator. The DNS operator that has control over 1513 the DNS zone and its keys may prevent the registrant to make a timely 1514 move to a different DNS operator. 1516 Suppose that the registrant wants to move from a losing DNS operator 1517 (loosing operator for short) to a gaining DNS operator (gaining 1518 operator). Let us first look what would happen in a cooperative 1519 environment. The assumption is that the loosing operator will not 1520 hand off any private key material to the gaining operator, that would 1521 constitute a trivial case. 1523 In a cooperating environment one could proceed with a pre-publish ZSK 1524 rollover whereby the loosing operator pre-publishes the ZSK of the 1525 gaining operator, combined with a double signature KSK rollover where 1526 the two registrars exchange public KSKs and independently generate a 1527 signature over those keysets that they combine and both publish in 1528 their copy of the zone. Once that is done they can use their own 1529 private keys to sign any of their zone content during the transfer. 1531 ............................................................ 1532 intitial | pre-publish | 1533 ............................................................ 1534 Parent: 1535 NSA NSA 1536 DSA DSA 1538 ............................................................ 1539 Child at A: Child at A: Child at B: 1540 ZSKA ZSKA ZSKA 1541 KSKA ZSKB ZSKB 1542 RRSIGZA(DNSKEY) KSKA KSKA 1543 RRSIGKA(DNSKEY) KSKB KSKB 1544 RRSIGZB RRSIGZB 1545 RRSIGKB RRSIGKB 1546 RRSIGZA RRSIGZA 1547 RRSIGKA RRSIGKA 1549 SOAA SOAA SOAB 1550 RRSIGZA(SOA) RRSIGZA(SOA) RRSIGZB(SOA) 1552 NSA NSA NSB 1553 RRSIGZA(NS) NSB RRSIGZB(NS) 1554 RRSIGZA(NS) 1555 ............................................................ 1557 ............................................................ 1558 Redelegation | post migration | 1559 ............................................................ 1561 NSB NSB 1562 DSB DSB 1564 ............................................................ 1565 Child at A: Child at B: Child at B: 1566 ZSKA ZSKA ZSKB 1567 ZSKB ZSKB KSKB 1568 KSKA KSKA RRSIGZB(DNSKEY) 1569 KSKB KSKB RRSIGKB(DNSKEY) 1570 RRSIGZB RRSIGZB 1571 RRSIGKB RRSIGKB 1572 RRSIGZA RRSIGZA 1573 RRSIGKA RRSIGKA 1575 SOAA SOAB SOAB 1576 RRSIGZA(SOA) RRSIGZB(SOA) RRSIGZB(SOA) 1578 NSA NSB NSB 1579 NSB RRSIGZB(NS) RRSIGZB(NS) 1580 RRSIGZA(NS) 1581 ............................................................ 1583 In this figure A denotes the loosing DNS operator and B the gaining 1584 DNS operator. RRSIGZ is the RRSIG produced by a ZSK, RRSIGK is 1585 produced with a KSK, the appendend A or B indicate the producers of 1586 the key pair. Child at A is how the zone content is represented by 1587 the loosing DNS operator and Child at B is how the zone content is 1588 represented by the gaining DNS operator. 1590 4.3.5.2. Non Cooperationg DNS Operators 1592 In the non-cooperative case matters are more complicated. The 1593 loosing operator may not cooperate and leave the data in the DNS as 1594 is. In the extreme case the loosing operator may become obstructive 1595 and publish a DNSKEY RR with a high TTL and corresponding signature 1596 validity so that registrar A's DNSKEY, would end up in caches for, in 1597 theory, tens of years. 1599 The problem arises when a validator tries to validate with the 1600 loosing operator's key and there is no signature material produced 1601 with the loosing operator available in the delegation path after 1602 redelegation from the loosing operator to the gaiing operator has 1603 taken place. One could imagine a rollover scenario where the gaining 1604 operator pulls all RRSIGs created by the loosing operator and 1605 publishes those in conjunction with its own signatures, but that 1606 would not allow any changes in the zone content. Since a 1607 redelegation took place the NS RRset has -- per definition-- changed 1608 so such rollover scenario will not work. Besides if zone transfers 1609 are not allowed by the loosing operator and NSEC3 is deployed in the 1610 loosing operator's zone then the gainging operator's zone will not 1611 have certainty that all of A's RRSIGs are transfered. 1613 The only viable option for the registrant is to publish its zone 1614 unsigned and ask the registry to remove the DS pointing to the 1615 loosing operator's DNSKEY for as long as the DNSKEY of the loosing 1616 operator, or any of the signatures produced by it are likely to 1617 disappear in caches, which as mentioned above could in theory be for 1618 tens of years. 1620 Note that some [OK: most/all ?] implementations limit the time 1621 DNSKEYs that seem to be unable to validate signatures are cached 1622 and/or will try to recover from cases where DNSKEYs do not seem to be 1623 able to validate data. Although that is not a protocol requirement 1624 it seems that that practice may limit the impact of this problem the 1625 problem of non-cooperating registrars. 1627 However, there is no operational methodology to work around this 1628 business issue, and proper contractual relationships between all 1629 involved parties seems to be the only solution to cope with these 1630 problems. It should be noted that in many cases, the problem with 1631 temporary broken delegations already exists when a zone changes from 1632 one DNS operator to another. Besides, it is often the case that when 1633 the DNS moves from one operator to another the services that that 1634 zone references also change operator, possibly involving some 1635 downtime. 1637 In any case. To minimise such problems, the classic recommendation 1638 is to have relative short TTL on all involved resource records. That 1639 will solve many of the problems regarding changes to a zone 1640 regardless of whether DNSSEC is used. 1642 4.4. Time in DNSSEC 1644 Without DNSSEC, all times in the DNS are relative. The SOA fields 1645 REFRESH, RETRY, and EXPIRATION are timers used to determine the time 1646 elapsed after a slave server synchronized with a master server. The 1647 Time to Live (TTL) value and the SOA RR minimum TTL parameter [9] are 1648 used to determine how long a forwarder should cache data after it has 1649 been fetched from an authoritative server. By using a signature 1650 validity period, DNSSEC introduces the notion of an absolute time in 1651 the DNS. Signatures in DNSSEC have an expiration date after which 1652 the signature is marked as invalid and the signed data is to be 1653 considered Bogus. 1655 The considerations in this section are all qualitative and focused on 1656 the operational and managerial issues. A more thourhough 1657 quantitative analysis of rollover timing parameters can be found in 1658 draft-ietf-dnsop-dnssec-key-timing [24] 1660 4.4.1. Time Considerations 1662 Because of the expiration of signatures, one should consider the 1663 following: 1665 o We suggest the Maximum Zone TTL of your zone data to be a fraction 1666 of your signature validity period. 1668 If the TTL would be of similar order as the signature validity 1669 period, then all RRSets fetched during the validity period 1670 would be cached until the signature expiration time. Section 1671 7.1 of RFC4033 [3] suggests that "the resolver may use the time 1672 remaining before expiration of the signature validity period of 1673 a signed RRSet as an upper bound for the TTL". As a result, 1674 query load on authoritative servers would peak at signature 1675 expiration time, as this is also the time at which records 1676 simultaneously expire from caches. 1678 To avoid query load peaks, we suggest the TTL on all the RRs in 1679 your zone to be at least a few times smaller than your 1680 signature validity period. 1682 o We suggest the signature publication period to end at least one 1683 Maximum Zone TTL duration before the end of the signature validity 1684 period. 1686 Re-signing a zone shortly before the end of the signature 1687 validity period may cause simultaneous expiration of data from 1688 caches. This in turn may lead to peaks in the load on 1689 authoritative servers. To avoid this schemes are deployed 1690 whereby the zone is periodically visited for a resigning 1691 operation and those signatures that are within a so called 1692 refresh intervall from signature expiration are recreated. 1693 Also see Section 4.4.2 below. 1695 o We suggest the Minimum Zone TTL to be long enough to both fetch 1696 and verify all the RRs in the trust chain. In workshop 1697 environments, it has been demonstrated [18] that a low TTL (under 1698 5 to 10 minutes) caused disruptions because of the following two 1699 problems: 1701 1. During validation, some data may expire before the 1702 validation is complete. The validator should be able to keep 1703 all data until it is completed. This applies to all RRs needed 1704 to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the 1705 final answers, i.e., the RRSet that is returned for the initial 1706 query. 1708 2. Frequent verification causes load on recursive nameservers. 1709 Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit 1710 from caching. The TTL on those should be relatively long. 1712 o Slave servers will need to be able to fetch newly signed zones 1713 well before the RRSIGs in the zone served by the slave server pass 1714 their signature expiration time. 1716 When a slave server is out of sync with its master and data in 1717 a zone is signed by expired signatures, it may be better for 1718 the slave server not to give out any answer. 1720 Normally, a slave server that is not able to contact a master 1721 server for an extended period will expire a zone. When that 1722 happens, the server will respond differently to queries for 1723 that zone. Some servers issue SERVFAIL, whereas others turn 1724 off the 'AA' bit in the answers. The time of expiration is set 1725 in the SOA record and is relative to the last successful 1726 refresh between the master and the slave servers. There exists 1727 no coupling between the signature expiration of RRSIGs in the 1728 zone and the expire parameter in the SOA. 1730 If the server serves a DNSSEC zone, then it may well happen 1731 that the signatures expire well before the SOA expiration timer 1732 counts down to zero. It is not possible to completely prevent 1733 this from happening by tweaking the SOA parameters. 1735 However, the effects can be minimized where the SOA expiration 1736 time is equal to or shorter than the signature validity period. 1738 The consequence of an authoritative server not being able to 1739 update a zone, whilst that zone includes expired signatures, is 1740 that non-secure resolvers will continue to be able to resolve 1741 data served by the particular slave servers while security- 1742 aware resolvers will experience problems because of answers 1743 being marked as Bogus. 1745 We suggest the SOA expiration timer being approximately one 1746 third or one fourth of the signature validity period. It will 1747 allow problems with transfers from the master server to be 1748 noticed before the actual signature times out. 1750 We also suggest that operators of nameservers that supply 1751 secondary services develop 'watch dogs' to spot upcoming 1752 signature expirations in zones they slave, and take appropriate 1753 action. 1755 When determining the value for the expiration parameter one has 1756 to take the following into account: What are the chances that 1757 all my secondaries expire the zone? How quickly can I reach an 1758 administrator of secondary servers to load a valid zone? These 1759 questions are not DNSSEC specific but may influence the choice 1760 of your signature validity intervals. 1762 4.4.2. Signature Validation Periods 1764 [OK: This section is newly introduced and needs a check on 1765 consistency with the rest of the document] 1767 4.4.2.1. Maximum Value 1769 The first consideration for choosing a maximum signature validity 1770 period is the risk of a replay attack. For low-value, long-term 1771 stable resources the risks may be minimal and the signature validity 1772 period may be multiple months. Although signature validity periods 1773 of many years are allowed the same operational habit arguments as in 1774 Section 3.1.2.2 play a role: when a zone is resigned with some 1775 regularity then operators remain conscious about the operational 1776 necessity of resigning. 1778 4.4.2.2. Minimum Value 1780 The minimum value of the signature validity period is set by the time 1781 by which one would like to survive operational failure in 1782 provisioning: what is the time that a failure will be noticed, what 1783 is the time that action is expected to be taken? By answering these 1784 questions availability of operators during (long) weekends or access 1785 to backup media needs to be taken into account which could easily 1786 suggest a minimum Signature Validity period of a few days. 1788 Note however, the argument above is assuming that zone data has just 1789 been signed and published when the problem occurred. In practice it 1790 may be that a zone is signed according to a frequency set by the 1791 Resign Period whereby the signer visits the zone content and only 1792 refreshes signatures that are close to expiring: the signer will only 1793 refresh signatures if they are within the Refresh Period from the 1794 signature expiration time. The Resign Period must be smaller than 1795 the Refresh Period in order for zone data to be signed timely. 1797 If an operational problem occurs during resigning then the signatures 1798 in the zone wich will expire first are the ones that have been 1799 generated longest ago. And in the worst case these signatures are 1800 the Refresh Period minus the Resign Period away from signature 1801 validation. 1803 In other words, the minimum Signature Validity intervall is set by 1804 first choosing the Refresh Period (usually a few days), then defining 1805 the Resign period in such a way that the Refresh Period minus the 1806 Resign period sets the time in which operational havoc can be 1807 resolved. 1809 To make matters slightly mor complicated. Some signers apply some 1810 jitter to the signature expiry time so that not all signatures expire 1811 at the same time. The jitter should not influence your calculation 1812 as long as it is smaller than the refresh period and the resign 1813 period is at least half the refresh period [OK: The above needs 1814 careful review] 1815 Inception Signing Expiration 1816 time time time 1817 | | | | | 1818 |------------------|------------------------------|.......|.......| 1819 | | | | | 1820 +/- jitter 1822 | Inception offset | Validity Period | 1823 | <--------------->|<------------------------------------>| 1825 Inception Signing reuse reuse reuse new Expiration 1826 time time signature time 1827 | | | | | | | 1828 |------------------|-----------------------------------------| 1829 | | | | | | | 1830 <----> <----> <----> <----> 1831 Resign Period 1833 | | 1834 |<-Refresh Period->| 1835 | | 1837 4.4.2.3. differentiation between RR sets 1839 It is possible to vary signature validity periods between signatures 1840 over different RR sets in the zone. In practice this could be done 1841 when zones contain highly volatile data (which may be the case in 1842 dynamic update environments). Note however that the risk of replay 1843 (e.g. by stale secondary servers) is what should be leading in 1844 determining the signature validity period since the TTL on the data 1845 itself still are the primary parameter for cache expiry. [OK: are 1846 there strong arguments besides replay risks for varying signature 1847 validity] 1849 In some cases the risk of replaying existing data might be different 1850 from the risk of replaying the denial of data. In those cases the 1851 signature validity period on NSEC or NSEC3 records may be tweaked 1852 accordingly. 1854 When a zone contains secure delegations then a relatively short 1855 signature validity interval protects the child agains replay attacks, 1856 in the case the child's key is compromised (see Section 4.3.4). 1857 Since there is a higher operational risk for the parent registry when 1858 choosing a short validity intervall and a higher operational risk for 1859 the child when choosing a long validity period some (price) 1860 differentiation may occur for validity periods between individual DS 1861 RRs in a single zone. 1863 There seem to be no other arguments for differentiation in validity 1864 periods. 1866 4.4.2.4. Other timing parameters in a zone 1868 [OK: Isn't the following not to vague? Is it sufficient?] 1870 The arguments for tuning minimum signature validity period are 1871 remarkably similar to the arguments used to set the SOA expiration 1872 timer. It is advised to set the expiration time longer than the 1873 signature validity period. 1875 5. Next Record type 1877 One of the design tradeofs made during the development of DNSSEC has 1878 been to seperate the signing and serving operations instead of 1879 performing cryptographic operations on the fly. It is therefore 1880 necessry to create records that cover the very large number of non- 1881 existent names that lie between the names that do exist. 1883 There are two mechanisms to provide authenticated proof of non- 1884 existence of domain names in DNSSEC: clear text one and an 1885 obfuscated-data one. Each mechanism 1887 o includes a list of all the RRTYPEs present which can be used to 1888 prove the non-existence of RRTYPEs at a certain name; 1890 o stores only the name for which the zone is authoritative (that is, 1891 glue in the zone is omitted); and 1893 o uses a specific RRTYPE to store information about the RRTYPEs 1894 present at the name: the clear-text mechanism uses NSEC, and the 1895 obfuscated-data mechanism uses NSEC3. 1897 5.1. Differences between NSEC and NSEC3 1899 The clear text mechanism (NSEC) is implemented using a sorted linked 1900 list of names in the zone. The obfuscated-data mechanism (NSEC3) 1901 first hashes the names using a one-way hash function, and then sorts 1902 the resulting (hashed) strings. 1904 The NSEC record requires no cryptographic operations aside from 1905 validating its associated signature record. It is human readable and 1906 can be used in manual queries to determine correct operation. The 1907 disadvantage is that it allows for "zone walking", where one can 1908 request all the entries of a zone by following the next RRlabel 1909 pointed to in each subsequent NSEC record. 1911 Though all agree DNS data is accessible through query mechanisms, a 1912 side effect of NSEC is that it allows the contents of a zone file to 1913 be enumerated in full by sequential queries. Whilst for some 1914 operators this behaviour is acceptable or even desirable, for others 1915 it is undesirable for policy, regulatory or other reasons. This is 1916 the first difference between NSEC and NSEC3. 1918 The second difference between NSEC and NSEC3 is that NSEC requires a 1919 signature over every RR in the zonefile, thereby ensuring that any 1920 denial of existence is cryptographically signed. However, in a large 1921 zonefile containing many delegations very few of which are to signed 1922 zones, this may produce unacceptable additional overhead especially 1923 where insecure delegations are subject to frequent update (a typical 1924 example might be a TLD operator with few registrants using secure 1925 delegations). NSEC3 allows intervals between two such delegations to 1926 "Opt-out" in which case they may contain one more more insecure 1927 delegations, thus reducing the size and cryptographic complexity of 1928 the zone at the expense of the ability to cryptographically deny the 1929 existence of names in a specific span. 1931 The NSEC3 record uses a hashing method of the requested RRlabel. To 1932 increase the workload required to guess entries in the zone, the 1933 number of hashing iteration's can be specified in the NSEC3 record. 1934 Additionally, a salt can be specified that also modifies the hashes. 1935 Note that NSEC3 does not give full protection against information 1936 leakage from the zone. 1938 5.2. NSEC or NSEC3 1940 The first motivation to deploy NSEC3, prevention of zone enumeration, 1941 only makes sense when zone content is not highly structured or 1942 trivially guessable. Highly structured zones such as the in- 1943 addr.arpa, ip6.arpa and e164.arpa can be trivially enumerated using 1944 ordinary DNS properties while for small zones that only contain 1945 contain records in the APEX and a few common RRlabels such as "www" 1946 or "mail" guessing zone content and proving completeness is also 1947 trivial when using NSEC3. 1949 In those cases the use of NSEC is recommended to ease the work 1950 required by signers and validating resolvers. 1952 For large zones where there is an implication of "not readily 1953 available" RRlabels, such as those where one has to sign an NDA 1954 before obtaining it, NSEC3 is recommended. 1956 The considerations for the second reason to deploy NSEC3 are 1957 discussed below (Section 5.3.4). 1959 5.3. NSEC3 parameters 1961 The NSEC3 hashing algorithm is performed on the Fully Qualified 1962 Domain Name (FQDN) in its uncompressed form. This ensures brute 1963 force work done by an attacker for one (FQDN) RRlabel cannot be re- 1964 used for another (FQDN) RRlabel attack, as these entries are per 1965 definition unique. 1967 5.3.1. NSEC3 Algorithm 1969 At the moment of writing there is only one NSEC3 Hashing algorithm 1970 defined. [21] specifically calls out that when a new hash algorithm 1971 for use with NSEC3 is specified, a transition mechanism MUST also be 1972 defined. Therefore this document does not considder NSEC3 hash 1973 algorithm transition. 1975 5.3.2. NSEC3 Iterations 1977 One of the concerns with NSEC3 is that bad actors could perform a 1978 pre-calculated dictionary attack in order to assess if certain domain 1979 names exist within the zones or not. Two mechanisms are introduced 1980 in the NSEC3 specification to increase the costs of such dictionary 1981 attacks: Iterations and Salt. 1983 RFC5155 [21] considers the trade-offs between incuring cost during 1984 the signing process, imposing costs to the validating nameserver, 1985 while still providing a reasonable barrier against dictionary 1986 attacks. It provides useful limits of iterations compared to RSA key 1987 size. These are 150 iterations for 1024 bit keys, 500 iterations for 1988 2048 bit keys and 2,500 iterations for 4096 bit keys. Choosing 2/3rd 1989 of the maximum is deemed to be a sufficiently costly yet not 1990 excessive value. 1992 5.3.3. NSEC3 Salt 1994 While the NSEC3 iterations parameter increases the cost of hashing a 1995 dictionary word, the NSEC3 salt reduces the lifetime for which that 1996 calculated hash can be used. A change of the salt value by the zone 1997 owner would cause an attacker to lose all precalculated work for that 1998 zone. 2000 The FQDN RRlabel, which is part of the value that is hashed, already 2001 ensures that brute force work for one RRlabel can not be re-used to 2002 attack other RRlabel (e.g. in other domains) due to their uniqueness. 2004 The salt of all NSEC3 records in a zone needs to be the same. Since 2005 changing the salt requires all the NSEC3 records to be regenerated, 2006 and thus requires generating new RRSIG's over these NSEC3 records, it 2007 is recommended to align the change of the salt with a change of the 2008 Zone Signing Key, as that process in itself already requires all 2009 RRSIG's to be regenerated. If there is no critical dependency on 2010 incremental signing and the whole zone can be signed with little 2011 effort there is no need for such alignment. However, unlike Zone 2012 Signing Key changes, NSEC3 salt changes do not need special rollover 2013 procedures. It is possible to change the salt each time the zone is 2014 updated. 2016 5.3.4. Opt-out 2018 The Opt-Out mechanism was introduced to allow for a gradual 2019 introduction of signed records in zones that contain mostly 2020 delegation records. The use of the OPT-OUT flag changes the meaning 2021 of the NSEC3 span from authoritative denial of the existence of names 2022 within the span to a proof that DNSSEC is not available for the 2023 delegations within the span. [Editors Note: One could make this 2024 construct more correct by talking about the hashed names and the 2025 hashed span, but I believe that is overkill]. This allows for the 2026 addition or removal of the delegations covered by the span without 2027 recalculating or re- signing RRs in the NSEC3 RR chain. 2029 Opt-Out is specified to be used only over delegation points and will 2030 therefore only bring relieve in zones with a large number of zones 2031 and where the number of secure delegations is small. This 2032 consideration typically holds for large top-level-domains and similar 2033 zones, in most other circumstances Opt-Out should not be deployed. 2034 Further considerations can be found in RFC5155 section 12.2 [21]. 2036 6. Security Considerations 2038 DNSSEC adds data integrity to the DNS. This document tries to assess 2039 the operational considerations to maintain a stable and secure DNSSEC 2040 service. Not taking into account the 'data propagation' properties 2041 in the DNS will cause validation failures and may make secured zones 2042 unavailable to security-aware resolvers. 2044 7. IANA considerations 2046 There are no IANA considerations with respect to this document 2048 8. Acknowledgments 2050 Most of the text of this document is copied from RFC4641 [15]. That 2051 document was edited by Olaf Kolkman and Miek Gieben. Other people 2052 that contributed or where otherwise involved in that work were in 2053 random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael 2054 Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette 2055 Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger 2056 Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, Peter Koch, Mike 2057 StJohns, Emma Bretherick, Adrian Bedford, and Lindy Foster, G. 2058 Guette, and O. Courtay. 2060 For this version of the document we would like to acknowldge a few 2061 people for significant contributions: 2063 o Paul Hoffman for his contribution on the choice of cryptographic 2064 paramenters and addressing some of the trust anchor issues. 2066 o Jelte Jansen who provided the text in Section 4.1.5 2068 o Paul Wouters who provided the initial text for Section 5 and Alex 2069 Bligh who improved it. 2071 o Erik Rescorla's blogpost on "the Security of ZSK rollovers" 2072 inspired text in Section 3.1.1. 2074 o The figure in Section 4.4.2 was adapted from the OpenDNSSEC user 2075 documentation. 2077 In addition valuable contributions in the form of text, comments, or 2078 review where provided by Mark Andrews, Patrik Faltstrom, Tony Finch, 2079 Olafur Gudmundsson, Alfred Hines, Bill Manning, Scott Rose. 2081 [EDITOR NOTE: please let me know if there is an oversight here] 2083 9. References 2085 9.1. Normative References 2087 [1] Mockapetris, P., "Domain names - concepts and facilities", 2088 STD 13, RFC 1034, November 1987. 2090 [2] Mockapetris, P., "Domain names - implementation and 2091 specification", STD 13, RFC 1035, November 1987. 2093 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 2094 "DNS Security Introduction and Requirements", RFC 4033, 2095 March 2005. 2097 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 2098 "Resource Records for the DNS Security Extensions", RFC 4034, 2099 March 2005. 2101 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 2102 "Protocol Modifications for the DNS Security Extensions", 2103 RFC 4035, March 2005. 2105 9.2. Informative References 2107 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2108 Levels", BCP 14, RFC 2119, March 1997. 2110 [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 2111 August 1996. 2113 [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 2114 (DNS NOTIFY)", RFC 1996, August 1996. 2116 [9] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 2117 RFC 2308, March 1998. 2119 [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic 2120 Update", RFC 3007, November 2000. 2122 [11] Hollenbeck, S., "Generic Registry-Registrar Protocol 2123 Requirements", RFC 3375, September 2002. 2125 [12] Orman, H. and P. Hoffman, "Determining Strengths For Public 2126 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 2127 April 2004. 2129 [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 2130 Requirements for Security", BCP 106, RFC 4086, June 2005. 2132 [14] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 2133 Mapping for the Extensible Provisioning Protocol (EPP)", 2134 RFC 4310, December 2005. 2136 [15] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 2137 RFC 4641, September 2006. 2139 [16] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 2140 August 2007. 2142 [17] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust 2143 Anchors", RFC 5011, September 2007. 2145 [18] Rose, S., "NIST DNSSEC workshop notes", , June 2001. 2147 [19] Barker, E. and J. Kelsey, "Recommendation for Random Number 2148 Generation Using Deterministic Random Bit Generators 2149 (Revised)", Nist Special Publication 800-90, March 2007. 2151 [20] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 2152 Resource Records (RRs)", RFC 4509, May 2006. 2154 [21] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 2155 Security (DNSSEC) Hashed Authenticated Denial of Existence", 2156 RFC 5155, March 2008. 2158 [22] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 2159 Protocol Version 1.2", RFC 5246, August 2008. 2161 [23] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and 2162 RRSIG Resource Records for DNSSEC", RFC 5702, October 2009. 2164 [24] Morris, S., Ihren, J., and J. Dickinson, "DNSSEC Key Timing 2165 Considerations", draft-ietf-dnsop-dnssec-key-timing-00 (work in 2166 progress), July 2010. 2168 [25] Ljunggren, F., Eklund-Lowinder, A., and T. Okubo, "DNSSEC 2169 Signing Policy & Practice Statement Framework", 2170 draft-ietf-dnsop-dnssec-dps-framework-01 (work in progress), 2171 March 2010. 2173 Appendix A. Terminology 2175 In this document, there is some jargon used that is defined in other 2176 documents. In most cases, we have not copied the text from the 2177 documents defining the terms but have given a more elaborate 2178 explanation of the meaning. Note that these explanations should not 2179 be seen as authoritative. 2181 Anchored key: A DNSKEY configured in resolvers around the globe. 2182 This key is hard to update, hence the term anchored. 2184 Bogus: Also see Section 5 of RFC4033 [3]. An RRSet in DNSSEC is 2185 marked "Bogus" when a signature of an RRSet does not validate 2186 against a DNSKEY. 2188 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is 2189 used exclusively for signing the apex key set. The fact that a 2190 key is a KSK is only relevant to the signing tool. 2192 Key size: The term 'key size' can be substituted by 'modulus size' 2193 throughout the document. It is mathematically more correct to use 2194 modulus size, but as this is a document directed at operators we 2195 feel more at ease with the term key size. 2197 Private and public keys: DNSSEC secures the DNS through the use of 2198 public key cryptography. Public key cryptography is based on the 2199 existence of two (mathematically related) keys, a public key and a 2200 private key. The public keys are published in the DNS by use of 2201 the DNSKEY Resource Record (DNSKEY RR). Private keys should 2202 remain private. 2204 Key rollover: A key rollover (also called key supercession in some 2205 environments) is the act of replacing one key pair with another at 2206 the end of a key effectivity period. 2208 Refresh Period: The time at the end of the Signature Validity Period 2209 during which signatures are refreshed. 2211 Resinging frequency: Frequency with wich a signing pass on the zone 2212 is performed. Alternatively expressed as "Resigning Period". It 2213 defines when the zone is exposed to the signer. During a signing 2214 pass not all signatures in the zone may be refreshed, that depend 2215 refresh frequency/intervall. 2217 Secure Entry Point (SEP) key: A KSK that has a parental DS record 2218 pointing to it or is configured as a trust anchor. Although not 2219 required by the protocol, we recommend that the SEP flag [5] is 2220 set on these keys. 2222 Self-signature: This only applies to signatures over DNSKEYs; a 2223 signature made with DNSKEY x, over DNSKEY x is called a self- 2224 signature. Note: without further information, self-signatures 2225 convey no trust. They are useful to check the authenticity of the 2226 DNSKEY, i.e., they can be used as a hash. 2228 Signing Jitter: Jitter applied to the signature validty intervall. 2230 Signer: The system that has access to the private key material and 2231 signs the Resource Record sets in a zone. A signer may be 2232 configured to sign only parts of the zone, e.g., only those RRSets 2233 for which existing signatures are about to expire. 2235 Single Type Signing Scheme: A signing scheme whereby the distinction 2236 between Zone Signing Keys and Key Singing Keys is not made. 2238 Zone Signing Key (ZSK): A key that is used for signing all data in a 2239 zone (except, perhaps, the DNSKEY RRSet). The fact that a key is 2240 a ZSK is only relevant to the signing tool. 2242 Singing the zone file: The term used for the event where an 2243 administrator joyfully signs its zone file while producing melodic 2244 sound patterns. 2246 Zone administrator: The 'role' that is responsible for signing a 2247 zone and publishing it on the primary authoritative server. 2249 Appendix B. Zone Signing Key Rollover How-To 2251 Using the pre-published signature scheme and the most conservative 2252 method to assure oneself that data does not live in caches, here 2253 follows the "how-to". 2255 Step 0: The preparation: Create two keys and publish both in your 2256 key set. Mark one of the keys "active" and the other "published". 2257 Use the "active" key for signing your zone data. Store the 2258 private part of the "published" key, preferably off-line. The 2259 protocol does not provide for attributes to mark a key as active 2260 or published. This is something you have to do on your own, 2261 through the use of a notebook or key management tool. 2263 Step 1: Determine expiration: At the beginning of the rollover make 2264 a note of the highest expiration time of signatures in your zone 2265 file created with the current key marked as active. Wait until 2266 the expiration time marked in Step 1 has passed. 2268 Step 2: Then start using the key that was marked "published" to sign 2269 your data (i.e., mark it "active"). Stop using the key that was 2270 marked "active"; mark it "rolled". 2272 Step 3: It is safe to engage in a new rollover (Step 1) after at 2273 least one signature validity period. 2275 Appendix C. Typographic Conventions 2277 The following typographic conventions are used in this document: 2279 Key notation: A key is denoted by DNSKEYx, where x is a number or an 2280 identifier, x could be thought of as the key id. 2282 RRSet notations: RRs are only denoted by the type. All other 2283 information -- owner, class, rdata, and TTL -- is left out. Thus: 2284 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a 2285 list of RRs. A example of this would be "A1, A2", specifying the 2286 RRSet containing two "A" records. This could again be abbreviated 2287 to just "A". 2289 Signature notation: Signatures are denoted as RRSIGx(RRSet), which 2290 means that RRSet is signed with DNSKEYx. 2292 Zone representation: Using the above notation we have simplified the 2293 representation of a signed zone by leaving out all unnecessary 2294 details such as the names and by representing all data by "SOAx" 2296 SOA representation: SOAs are represented as SOAx, where x is the 2297 serial number. 2299 Using this notation the following signed zone: 2301 example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 2302 2006022100 ; serial 2303 86400 ; refresh ( 24 hours) 2304 7200 ; retry ( 2 hours) 2305 3600000 ; expire (1000 hours) 2306 28800 ) ; minimum ( 8 hours) 2307 86400 RRSIG SOA 5 2 86400 20130522213204 ( 2308 20130422213204 14 example.net. 2309 cmL62SI6iAX46xGNQAdQ... ) 2310 86400 NS a.example.net. 2311 86400 NS b.example.net. 2312 86400 RRSIG NS 5 2 86400 20130507213204 ( 2313 20130407213204 14 example.net. 2314 SO5epiJei19AjXoUpFnQ ... ) 2315 86400 DNSKEY 256 3 5 ( 2316 EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 2317 86400 DNSKEY 257 3 5 ( 2318 gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 2319 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 2320 20130422213204 14 example.net. 2321 J4zCe8QX4tXVGjV4e1r9... ) 2322 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 2323 20130422213204 15 example.net. 2324 keVDCOpsSeDReyV6O... ) 2325 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 2326 20130407213204 14 example.net. 2327 obj3HEp1GjnmhRjX... ) 2328 a.example.net. 86400 IN TXT "A label" 2329 86400 RRSIG TXT 5 3 86400 20130507213204 ( 2330 20130407213204 14 example.net. 2331 IkDMlRdYLmXH7QJnuF3v... ) 2332 86400 NSEC b.example.com. TXT RRSIG NSEC 2333 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 2334 20130407213204 14 example.net. 2335 bZMjoZ3bHjnEz0nIsPMM... ) 2336 ... 2338 is reduced to the following representation: 2340 SOA2006022100 2341 RRSIG14(SOA2006022100) 2342 DNSKEY14 2343 DNSKEY15 2345 RRSIG14(KEY) 2346 RRSIG15(KEY) 2348 The rest of the zone data has the same signature as the SOA record, 2349 i.e., an RRSIG created with DNSKEY 14. 2351 Appendix D. Document Editing History 2353 [To be removed prior to publication as an RFC] 2355 D.1. draft-ietf-dnsop-rfc4641-00 2357 Version 0 was differs from RFC4641 in the following ways. 2359 o Status of this memo appropriate for I-D 2361 o TOC formatting differs. 2363 o Whitespaces, linebreaks, and pagebreaks may be slightly different 2364 because of xml2rfc generation. 2366 o References slightly reordered. 2368 o Applied the errata from 2369 http://www.rfc-editor.org/errata_search.php?rfc=4641 2371 o Inserted trivial "IANA considertations" section. 2373 In other words it should not contain substantive changes in content 2374 as intended by the workinggroup for the original RFC4641. 2376 D.2. version 0->1 2378 Cryptography details rewritten. (See http://www.nlnetlabs.nl/svn/ 2379 rfc4641bis/trunk/open-issues/cryptography_flawed) 2381 o Reference to NIST 800-90 added 2383 o RSA/SHA256 is being recommended in addition to RSA/SHA1. 2385 o Complete rewrite of Section 3.1.4.2 removing the table and 2386 suggesting a keysize of 1024 for keys in use for less than 8 2387 years, issued up to at least 2015. 2389 o Replaced the reference to Schneiers' applied cryptograpy with a 2390 reference to RFC4949. 2392 o Removed the KSK for high level zones consideration 2394 Applied some differentiation with respect of the use of a KSK for 2395 parent or trust-anchor relation http://www.nlnetlabs.nl/svn/ 2396 rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent 2398 http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 2399 rollover_assumptions 2401 Added Section 4.1.5 as suggested by Jelte Jansen in http:// 2402 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll 2404 Added Section 4.3.5.1 Issue identified by Antoin Verschuur http:// 2405 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 2406 non-cooperative-registrars 2408 In Appendix A: ZSK does not nescessarily sign the DNSKEY RRset. 2410 D.3. version 1->2 2412 o Significant rewrite of Section 3 whereby the argument is made that 2413 the timescakes for rollovers are made purely on operational 2414 arguments hopefully resolving http://www.nlnetlabs.nl/svn/ 2415 rfc4641bis/trunk/open-issues/discussion_of_timescales 2417 o Added Section 5 based on http://www.nlnetlabs.nl/svn/rfc4641bis/ 2418 trunk/open-issues/NSEC-NSEC3 2420 o Added a reference to draft-morris-dnsop-dnssec-key-timing [24] for 2421 the quantitative analysis on keyrolls 2423 o Updated Section 4.3.5 to reflect that the problem occurs when 2424 changing DNS operators, and not DNS registrars, also added the 2425 table indicating the redelegation procedure. Added text about the 2426 fact that implementations will dismiss keys that fail to validate 2427 at some point. 2429 o Updated a number of references. 2431 D.4. version 2->3 2433 o Added bulleted list to serve as an introduction on the decision 2434 tree in Section 3. 2436 o In section Section 3.1.1: 2438 * tried to motivate that keylength is not a strong motivation for 2439 KSK ZSK split (based on http://www.educatedguesswork.org/2009/ 2440 10/on_the_security_of_zsk_rollove.html) 2442 * Introduced Common Signing Key terminology and made the 2443 arguments for the choice of a Common Signing Key more explicit. 2445 * Moved the SEP flag considerations to its own paragraph 2447 o In a few places in the document, but section Section 4 in 2448 particular the comments from Patrik Faltstrom (On Mar 24, 2010) on 2449 the clarity on the roles of the registrant, dns operator, 2450 registrar and registry was addressed. 2452 o Added some terms based on http://www.nlnetlabs.nl/svn/rfc4641bis/ 2453 trunk/open-issues/timing_terminology 2455 o Added paragrap 2 and clarified the second but last paragraph of 2456 Section 3.1.2.2. 2458 o Clarified the table and some text in Section 4.1.5. Also added 2459 some text on what happens when the algorithm rollover also 2460 involves a roll from NSEC to NSEC3. 2462 o Added a paragraph about rolling KSKs that are also configured as 2463 trust-anchors in Section 4.1.2 2465 o Added Section 4.1.4. 2467 o Added Section 4.4.2 to address issue "Signature_validity" 2469 $Id: draft-ietf-dnsop-rfc4641bis-03.txt 60 2010-07-12 19:33:51Z olaf $ 2471 Author's Address 2473 Olaf M. Kolkman 2474 NLnet Labs 2475 Kruislaan 419 2476 Amsterdam 1098 VA 2477 The Netherlands 2479 EMail: olaf@nlnetlabs.nl 2480 URI: http://www.nlnetlabs.nl