idnits 2.17.1 draft-ietf-dnsop-rfc4641bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2009) is 5501 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1418, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1427, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2541 (ref. '10') (Obsoleted by RFC 4641) -- Obsolete informational reference (is this intentional?): RFC 4310 (ref. '15') (Obsoleted by RFC 5910) -- Obsolete informational reference (is this intentional?): RFC 4641 (ref. '16') (Obsoleted by RFC 6781) == Outdated reference: A later version (-14) exists of draft-ietf-dnsext-dnssec-rsasha256-05 -- Obsolete informational reference (is this intentional?): RFC 4366 (ref. '23') (Obsoleted by RFC 5246, RFC 6066) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP O. Kolkman 3 Internet-Draft NLnet Labs 4 Obsoletes: 2541 (if approved) R. Gieben 5 Intended status: BCP 6 Expires: September 8, 2009 March 7, 2009 8 DNSSEC Operational Practices, Version 2 9 draft-ietf-dnsop-rfc4641bis-01 11 Status of This Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 8, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document describes a set of practices for operating the DNS with 58 security extensions (DNSSEC). The target audience is zone 59 administrators deploying DNSSEC. 61 The document discusses operational aspects of using keys and 62 signatures in the DNS. It discusses issues of key generation, key 63 storage, signature generation, key rollover, and related policies. 65 This document obsoletes RFC 2541, as it covers more operational 66 ground and gives more up-to-date requirements with respect to key 67 sizes and the new DNSSEC specification. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 5 73 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 74 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 75 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 76 3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 77 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7 78 3.1.2. Differentiation for 'High-Level' Zones . . . . . . . . 9 79 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 9 80 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 9 81 3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 10 82 3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10 83 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 11 84 4. Signature Generation, Key Rollover, and Related Policies . . . 12 85 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12 86 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 13 87 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 15 88 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 15 89 4.2.1.1. Pre-Publish Key Rollover . . . . . . . . . . . . . 15 90 4.2.1.2. Double Signature Zone Signing Key Rollover . . . . 17 91 4.2.1.3. Pros and Cons of the Schemes . . . . . . . . . . . 19 92 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 19 93 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 21 94 4.2.4. Key algorithm rollover . . . . . . . . . . . . . . . . 22 95 4.2.5. Automated Key Rollovers . . . . . . . . . . . . . . . 23 96 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 24 97 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 24 98 4.3.1.1. Keeping the Chain of Trust Intact . . . . . . . . 25 99 4.3.1.2. Breaking the Chain of Trust . . . . . . . . . . . 26 100 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 26 101 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 26 102 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 27 103 4.4.1. Initial Key Exchanges and Parental Policies 104 Considerations . . . . . . . . . . . . . . . . . . . . 27 105 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 27 106 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 28 107 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 28 108 4.4.5. (Non) Cooperating Registrars . . . . . . . . . . . . . 29 109 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 110 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 111 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 112 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 113 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 114 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 115 Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 32 116 Appendix B. Zone Signing Key Rollover How-To . . . . . . . . . . 34 117 Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 34 118 Appendix D. Document Editing History . . . . . . . . . . . . . . 37 119 D.1. draft-ietf-dnsop-rfc4641-00 . . . . . . . . . . . . . . . 37 120 D.2. version 0->1 . . . . . . . . . . . . . . . . . . . . . . . 37 122 1. Introduction 124 This document describes how to run a DNS Security (DNSSEC)-enabled 125 environment. It is intended for operators who have knowledge of the 126 DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC. 127 See RFC 4033 [3] for an introduction to DNSSEC, RFC 4034 [4] for the 128 newly introduced Resource Records (RRs), and RFC 4035 [5] for the 129 protocol changes. 131 During workshops and early operational deployment tests, operators 132 and system administrators have gained experience about operating the 133 DNS with security extensions (DNSSEC). This document translates 134 these experiences into a set of practices for zone administrators. 135 At the time of writing, there exists very little experience with 136 DNSSEC in production environments; this document should therefore 137 explicitly not be seen as representing 'Best Current Practices'. 138 [OK: Is this document ripe enough to shoot for BCP?] 140 The procedures herein are focused on the maintenance of signed zones 141 (i.e., signing and publishing zones on authoritative servers). It is 142 intended that maintenance of zones such as re-signing or key 143 rollovers be transparent to any verifying clients on the Internet. 145 The structure of this document is as follows. In Section 2, we 146 discuss the importance of keeping the "chain of trust" intact. 147 Aspects of key generation and storage of private keys are discussed 148 in Section 3; the focus in this section is mainly on the private part 149 of the key(s). Section 4 describes considerations concerning the 150 public part of the keys. Since these public keys appear in the DNS 151 one has to take into account all kinds of timing issues, which are 152 discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the 153 rollover, or supercession, of keys. Finally, Section 4.4 discusses 154 considerations on how parents deal with their children's public keys 155 in order to maintain chains of trust. 157 The typographic conventions used in this document are explained in 158 Appendix C. 160 Since this is a document with operational suggestions and there are 161 no protocol specifications, the RFC 2119 [6] language does not apply. 163 This document [OK: when approved] obsoletes RFC 4641 [16]. 165 [OK: Editorial comments and questions are indicated by square 166 brackets and editor innitials] 168 1.1. The Use of the Term 'key' 170 It is assumed that the reader is familiar with the concept of 171 asymmetric keys on which DNSSEC is based (public key cryptography 172 RFC4949 [17]). Therefore, this document will use the term 'key' 173 rather loosely. Where it is written that 'a key is used to sign 174 data' it is assumed that the reader understands that it is the 175 private part of the key pair that is used for signing. It is also 176 assumed that the reader understands that the public part of the key 177 pair is published in the DNSKEY Resource Record and that it is the 178 public part that is used in key exchanges. 180 1.2. Time Definitions 182 In this document, we will be using a number of time-related terms. 183 The following definitions apply: 185 o "Signature validity period" The period that a signature is valid. 186 It starts at the time specified in the signature inception field 187 of the RRSIG RR and ends at the time specified in the expiration 188 field of the RRSIG RR. 190 o "Signature publication period" Time after which a signature (made 191 with a specific key) is replaced with a new signature (made with 192 the same key). This replacement takes place by publishing the 193 relevant RRSIG in the master zone file. After one stops 194 publishing an RRSIG in a zone, it may take a while before the 195 RRSIG has expired from caches and has actually been removed from 196 the DNS. 198 o "Key effectivity period" The period during which a key pair is 199 expected to be effective. This period is defined as the time 200 between the first inception time stamp and the last expiration 201 date of any signature made with this key, regardless of any 202 discontinuity in the use of the key. The key effectivity period 203 can span multiple signature validity periods. 205 o "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum 206 value of the TTLs from the complete set of RRs in a zone. Note 207 that the minimum TTL is not the same as the MINIMUM field in the 208 SOA RR. See [9] for more information. 210 2. Keeping the Chain of Trust Intact 212 Maintaining a valid chain of trust is important because broken chains 213 of trust will result in data being marked as Bogus (as defined in [3] 214 Section 5), which may cause entire (sub)domains to become invisible 215 to verifying clients. The administrators of secured zones have to 216 realize that their zone is, to verifying clients, part of a chain of 217 trust. 219 As mentioned in the introduction, the procedures herein are intended 220 to ensure that maintenance of zones, such as re-signing or key 221 rollovers, will be transparent to the verifying clients on the 222 Internet. 224 Administrators of secured zones will have to keep in mind that data 225 published on an authoritative primary server will not be immediately 226 seen by verifying clients; it may take some time for the data to be 227 transferred to other secondary authoritative nameservers and clients 228 may be fetching data from caching non-authoritative servers. In this 229 light, note that the time for a zone transfer from master to slave is 230 negligible when using NOTIFY [8] and incremental transfer (IXFR) [7]. 231 It increases when full zone transfers (AXFR) are used in combination 232 with NOTIFY. It increases even more if you rely on full zone 233 transfers based on only the SOA timing parameters for refresh. 235 For the verifying clients, it is important that data from secured 236 zones can be used to build chains of trust regardless of whether the 237 data came directly from an authoritative server, a caching 238 nameserver, or some middle box. Only by carefully using the 239 available timing parameters can a zone administrator ensure that the 240 data necessary for verification can be obtained. 242 The responsibility for maintaining the chain of trust is shared by 243 administrators of secured zones in the chain of trust. This is most 244 obvious in the case of a 'key compromise' when a trade-off between 245 maintaining a valid chain of trust and replacing the compromised keys 246 as soon as possible must be made. Then zone administrators will have 247 to make a trade-off, between keeping the chain of trust intact -- 248 thereby allowing for attacks with the compromised key -- or 249 deliberately breaking the chain of trust and making secured 250 subdomains invisible to security-aware resolvers. Also see 251 Section 4.3. 253 3. Keys Generation and Storage 255 This section describes a number of considerations with respect to the 256 security of keys. It deals with the generation, effectivity period, 257 size, and storage of private keys. 259 3.1. Zone and Key Signing Keys 261 The DNSSEC validation protocol does not distinguish between different 262 types of DNSKEYs. All DNSKEYs can be used during the validation. In 263 practice, operators use Key Signing and Zone Signing Keys and use the 264 so-called Secure Entry Point (SEP) [5] flag to distinguish between 265 them during operations. The dynamics and considerations are 266 discussed below. 268 To make zone re-signing and key rollover procedures easier to 269 implement, it is possible to use one or more keys as Key Signing Keys 270 (KSKs). These keys will only sign the apex DNSKEY RRSet in a zone. 271 Other keys can be used to sign all the RRSets in a zone and are 272 referred to as Zone Signing Keys (ZSKs). In this document, we assume 273 that KSKs are the subset of keys that are used for key exchanges with 274 the parent and potentially for configuration as trusted anchors -- 275 the SEP keys. In this document, we assume a one-to-one mapping 276 between KSK and SEP keys and we assume the SEP flag to be set on all 277 KSKs. 279 3.1.1. Motivations for the KSK and ZSK Separation 281 Differentiating between the KSK and ZSK functions has several 282 advantages: 284 o No parent/child interaction is required when ZSKs are updated. 286 o [OK: Bullet removed, strawman Paul Hoffman] 288 o As the KSK is only used to sign a key set, which is most probably 289 updated less frequently than other data in the zone, it can be 290 stored separately from and in a safer location than the ZSK. 292 o A KSK can have a longer key effectivity period. 294 For almost any method of key management and zone signing, the KSK is 295 used less frequently than the ZSK. Once a key set is signed with the 296 KSK, all the keys in the key set can be used as ZSKs. If a ZSK is 297 compromised, it can be simply dropped from the key set. The new key 298 set is then re-signed with the KSK. 300 Given the assumption that for KSKs the SEP flag is set, the KSK can 301 be distinguished from a ZSK by examining the flag field in the DNSKEY 302 RR. If the flag field is an odd number it is a KSK. If it is an 303 even number it is a ZSK. 305 The Zone Signing Key can be used to sign all the data in a zone on a 306 regular basis. When a Zone Signing Key is to be rolled, no 307 interaction with the parent is needed. This allows for signature 308 validity periods on the order of days. 310 The Key Signing Key is only to be used to sign the DNSKEY RRs in a 311 zone. If a Key Signing Key is to be rolled over, there will be 312 interactions with parties other than the zone administrator. If 313 there is a parent zone, these can include the registry of the parent 314 zone or administrators of verifying resolvers that have the 315 particular key configured as secure entry points. If this is a trust 316 anchor, everyone relying on the trust anchor needs to roll over to 317 the new key. The latter may be subject to stability costs if 318 automated trust-anchor rollover mechanisms (such as e.g. RFC5011 319 [18]) are not in place. Hence, the key effectivity period of these 320 keys can and should be made much longer. 322 There are two schools of thought on rolling a KSK that is not a trust 323 anchor [OK: One can never be sure a KSK is _not_ a trust anchor]: 325 o It should be done regularly (possibly every few months) so that a 326 key rollover remains an operational routine. 328 o It should only be done when it is known or strongly suspected that 329 the key has been compromised in order to reduce the stability 330 issues on systems where the rollover does not happen cleanly. 332 There is no widespread agreement on which of these two schools of 333 thought is better for different deployments of DNSSEC. There is a 334 stability cost every time a non-anchor KSK is rolled over, but it is 335 possibly low if the communication between the child and the parent is 336 good. On the other hand, the only completely effective way to tell 337 if the communication is good is to test it periodically. Thus, 338 rolling a KSK with a parent is only done for two reasons: to test and 339 verify the rolling system to prepare for an emergency, and in the 340 case of an actual emergency. 342 [OK: The paragraph below is a straw-man by Paul Hoffman] Because of 343 the difficulty of getting all users of a trust anchor to replace an 344 old trust anchor with a new one, a KSK that is a trust anchor should 345 never be rolled unless it is known or strongly suspected that the key 346 has been compromised. 348 [OK: This is an alternative straw-man by Olaf Kolkman] The same 349 operational concerns apply to the rollover of KSKs that are used as 350 trust-anchors. Since the administrator of a zone can not be certain 351 that the zone's KSK is in use as a trust-anchor she will have to 352 assume that a rollover will cause a stability cost for the users that 353 did configure her key as a trust-anchor. Those costs can be 354 minimized by automating the rollover RFC5011 [18] and by rolling the 355 key regularly, and advertising such, so that the operators of 356 recursive nameservers will put the appropriate mechanism in place to 357 deal with these stability costs, or, in other words, budget for these 358 costs instead of incuring them unexpectedly. 360 3.1.2. Differentiation for 'High-Level' Zones 362 In an earlier version of this document we made a differentiation 363 between KSKs used for zones that are high in the DNS hierarchy versus 364 KSKs used for zones low in that hierarchy. We have come to realize 365 that there are other considerations that argue such differentiation 366 does not need to be made. 368 Longer keys are not useful because the crypto guidance is that 369 everyone should use keys that no one can break. Also, it is 370 impossible to judge which zones are more or less valuable to an 371 attacker. An attack can only be used if the compromise is unnoticed 372 and the attacker can act as an man-in-the-middle attack (MITM) in an 373 unnoticed way. If .example is compromised and the attacker forges 374 answers for somebank.example and sends them out as an MITM, when the 375 attack is discovered it will be simple to prove that .example has 376 been compromised and the KSK will be rolled. Defining a long-term 377 successful attack is difficult for keys at any level. 379 3.2. Key Generation 381 Careful generation of all keys is a sometimes overlooked but 382 absolutely essential element in any cryptographically secure system. 383 The strongest algorithms used with the longest keys are still of no 384 use if an adversary can guess enough to lower the size of the likely 385 key space so that it can be exhaustively searched. Technical 386 suggestions for the generation of random keys will be found in RFC 387 4086 [14] and NIST SP 800-900 [20]. One should carefully assess if 388 the random number generator used during key generation adheres to 389 these suggestions. 391 Keys with a long effectivity period are particularly sensitive as 392 they will represent a more valuable target and be subject to attack 393 for a longer time than short-period keys. It is strongly recommended 394 that long-term key generation occur off-line in a manner isolated 395 from the network via an air gap or, at a minimum, high-level secure 396 hardware. 398 3.3. Key Effectivity Period 400 From a purely operational perspective, a reasonable key effectivity 401 period for KSKs that have a parent zone is 13 months, with the intent 402 to replace them after 12 months. An intended key effectivity period 403 of a month is reasonable for Zone Signing Keys. This annual rollover 404 gives operational practice to rollovers. 406 Ignoring the operational perspective, a reasonable effectivity period 407 for KSKs that have a parent zone is of the order of 2 decades or 408 longer. That is, if one does not plan to test the rollover 409 procedure, the key should be effective essentially forever, and then 410 only rolled over in case of emergency. 412 The "operational habit" argument also applies to trust anchor 413 reconfiguration. If a short key effectivity period is used and the 414 trust anchor configuration has to be revisited on a regular basis, 415 the odds that the configuration tends to be forgotten is smaller. 416 The trade-off is against a system that is so dynamic that 417 administrators of the validating clients will not be able to follow 418 the modifications.Note that if a trust anchor replacement is done 419 incorrectly, the entire zone that the trust anchor covers will become 420 bogus until the trust anchor is corrected. 422 Key effectivity periods can be made very short, as in a few minutes. 423 But when replacing keys one has to take the considerations from 424 Section 4.1 and Section 4.2 into account. 426 3.4. Key Algorithm 428 There are currently two types of signature algorithms that can be 429 used in DNSSEC: RSA and DSA. Both are fully specified in many 430 freely-available documents, and both are widely considered to be 431 patent-free. The creation of signatures wiht RSA and DSA takes 432 roughly the same time, but DSA is about ten times slower for 433 signature verification. 435 We suggest the use of either RSA/SHA-1 or RSA/SHA-256 as the 436 preferred signature algorithms. Both have advantages and 437 disadvantages. RSA/SHA-1 has been deployed for many years, while 438 RSA/SHA-256 has only begun to be deployed. On the other hand, it is 439 expected that if effective attacks on either algorithm appeark, they 440 will appear for RSA/SHA-1 first. RSA/MD5 should not be considered 441 for use because RSA/MD5 will very likely be the first common-use 442 signature algorithm to have an effective attack. 444 At the time of publication, it is known that the SHA-1 hash has 445 cryptanalysis issues. There is work in progress on addressing these 446 issues. We recommend the use of public key algorithms based on 447 hashes stronger than SHA-1 (e.g., SHA-256), as soon as these 448 algorithms are available in protocol specifications (see [21] and 449 [22]) and implementations. 451 3.5. Key Sizes 453 DNSSEC signing keys should be large enough to avoid all know 454 cryptographic attacks during the lifetime of the key. To date, 455 despite huge efforts, no one has broken a regular 1024-bit key; in 456 fact, the best completed attack is estimated to be the equivalent of 457 a 700-bit key. An attacker breaking a 1024-bit signing key would 458 need expend phenominal amounts of networked computing power in a way 459 that would not be detected in order to break a single key. Because 460 of this, it is estimated that most zones can safely use 1024-bit keys 461 for at least the next ten years. A 1024-bit asymmetric key has an 462 approximate equivalent strength of a symmetric 80-bit key. 464 Keys that are used as extremely high value trust anchors, or non- 465 anchor keys that may be difficult to roll over, may want to use 466 lengths longer than 1024 bits. Typically, the next larger key size 467 used is 2048 bits, which have the approximate equivalent strength of 468 a symmetric 112-bit key. In a standard CPU, it takes about four 469 times as long to sign or verify with a 2048-bit key as it does with a 470 1024-bit key. 472 Another way to decide on the size of key to use is to remember that 473 the phenominal effort it takes for an attacker to break a 1024-bit 474 key is the same regardless of how the key is used. If an attacker 475 has the capability of breaking a 1024-bit DNSSEC key, he also has the 476 capability of breaking one of the many 1024-bit TLS trust anchor keys 477 that are installed with web browsers. If the value of a DNSSEC key 478 is lower to the attacker than the value of a TLS trust anchor, the 479 attacker will use the resources to attack the TLS trust anchor. 481 It is possible that there is a unexpected improvement in the ability 482 for attackers to beak keys, and that such an attack would make it 483 feasible to break 1024-bit keys but not 2048-bit keys. If such an 484 improvement happens, it is likely that there will be a huge amount of 485 publicity, particularly because of the large number of 1024-bit TLS 486 trust anchors build into popular web browsers. At that time, all 487 1024-bit keys (both ones with parent zones and ones that are trust 488 anchors) can be rolled over and replaced with larger keys. 490 Earlier documents (including the previous version of this document) 491 urged the use of longer keys in situations where a particular key was 492 "heavily used". That advice may have been true 15 years ago, but it 493 is not true today when using RSA or DSA algorithms and keys of 1024 494 bits or higher. 496 3.6. Private Key Storage 498 It is recommended that, where possible, zone private keys and the 499 zone file master copy that is to be signed be kept and used in off- 500 line, non-network-connected, physically secure machines only. 501 Periodically, an application can be run to add authentication to a 502 zone by adding RRSIG and NSEC RRs. Then the augmented file can be 503 transferred. 505 When relying on dynamic update to manage a signed zone [11], be aware 506 that at least one private key of the zone will have to reside on the 507 master server. This key is only as secure as the amount of exposure 508 the server receives to unknown clients and the security of the host. 509 Although not mandatory, one could administer the DNS in the following 510 way. The master that processes the dynamic updates is unavailable 511 from generic hosts on the Internet, it is not listed in the NS RRSet, 512 although its name appears in the SOA RRs MNAME field. The 513 nameservers in the NS RRSet are able to receive zone updates through 514 NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism. This 515 approach is known as the "hidden master" setup. 517 The ideal situation is to have a one-way information flow to the 518 network to avoid the possibility of tampering from the network. 519 Keeping the zone master file on-line on the network and simply 520 cycling it through an off-line signer does not do this. The on-line 521 version could still be tampered with if the host it resides on is 522 compromised. For maximum security, the master copy of the zone file 523 should be off-net and should not be updated based on an unsecured 524 network mediated communication. 526 In general, keeping a zone file off-line will not be practical and 527 the machines on which zone files are maintained will be connected to 528 a network. Operators are advised to take security measures to shield 529 unauthorized access to the master copy. 531 For dynamically updated secured zones [11], both the master copy and 532 the private key that is used to update signatures on updated RRs will 533 need to be on-line. 535 4. Signature Generation, Key Rollover, and Related Policies 537 4.1. Time in DNSSEC 539 Without DNSSEC, all times in the DNS are relative. The SOA fields 540 REFRESH, RETRY, and EXPIRATION are timers used to determine the time 541 elapsed after a slave server synchronized with a master server. The 542 Time to Live (TTL) value and the SOA RR minimum TTL parameter [9] are 543 used to determine how long a forwarder should cache data after it has 544 been fetched from an authoritative server. By using a signature 545 validity period, DNSSEC introduces the notion of an absolute time in 546 the DNS. Signatures in DNSSEC have an expiration date after which 547 the signature is marked as invalid and the signed data is to be 548 considered Bogus. 550 4.1.1. Time Considerations 552 Because of the expiration of signatures, one should consider the 553 following: 555 o We suggest the Maximum Zone TTL of your zone data to be a fraction 556 of your signature validity period. 558 If the TTL would be of similar order as the signature validity 559 period, then all RRSets fetched during the validity period 560 would be cached until the signature expiration time. Section 561 7.1 of [3] suggests that "the resolver may use the time 562 remaining before expiration of the signature validity period of 563 a signed RRSet as an upper bound for the TTL". As a result, 564 query load on authoritative servers would peak at signature 565 expiration time, as this is also the time at which records 566 simultaneously expire from caches. 568 To avoid query load peaks, we suggest the TTL on all the RRs in 569 your zone to be at least a few times smaller than your 570 signature validity period. 572 o We suggest the signature publication period to end at least one 573 Maximum Zone TTL duration before the end of the signature validity 574 period. 576 Re-signing a zone shortly before the end of the signature 577 validity period may cause simultaneous expiration of data from 578 caches. This in turn may lead to peaks in the load on 579 authoritative servers. 581 o We suggest the Minimum Zone TTL to be long enough to both fetch 582 and verify all the RRs in the trust chain. In workshop 583 environments, it has been demonstrated [19] that a low TTL (under 584 5 to 10 minutes) caused disruptions because of the following two 585 problems: 587 1. During validation, some data may expire before the 588 validation is complete. The validator should be able to keep 589 all data until it is completed. This applies to all RRs needed 590 to complete the chain of trust: DSes, DNSKEYs, RRSIGs, and the 591 final answers, i.e., the RRSet that is returned for the initial 592 query. 594 2. Frequent verification causes load on recursive nameservers. 595 Data at delegation points, DSes, DNSKEYs, and RRSIGs benefit 596 from caching. The TTL on those should be relatively long. 598 o Slave servers will need to be able to fetch newly signed zones 599 well before the RRSIGs in the zone served by the slave server pass 600 their signature expiration time. 602 When a slave server is out of sync with its master and data in 603 a zone is signed by expired signatures, it may be better for 604 the slave server not to give out any answer. 606 Normally, a slave server that is not able to contact a master 607 server for an extended period will expire a zone. When that 608 happens, the server will respond differently to queries for 609 that zone. Some servers issue SERVFAIL, whereas others turn 610 off the 'AA' bit in the answers. The time of expiration is set 611 in the SOA record and is relative to the last successful 612 refresh between the master and the slave servers. There exists 613 no coupling between the signature expiration of RRSIGs in the 614 zone and the expire parameter in the SOA. 616 If the server serves a DNSSEC zone, then it may well happen 617 that the signatures expire well before the SOA expiration timer 618 counts down to zero. It is not possible to completely prevent 619 this from happening by tweaking the SOA parameters. 621 However, the effects can be minimized where the SOA expiration 622 time is equal to or shorter than the signature validity period. 624 The consequence of an authoritative server not being able to 625 update a zone, whilst that zone includes expired signatures, is 626 that non-secure resolvers will continue to be able to resolve 627 data served by the particular slave servers while security- 628 aware resolvers will experience problems because of answers 629 being marked as Bogus. 631 We suggest the SOA expiration timer being approximately one 632 third or one fourth of the signature validity period. It will 633 allow problems with transfers from the master server to be 634 noticed before the actual signature times out. 636 We also suggest that operators of nameservers that supply 637 secondary services develop 'watch dogs' to spot upcoming 638 signature expirations in zones they slave, and take appropriate 639 action. 641 When determining the value for the expiration parameter one has 642 to take the following into account: What are the chances that 643 all my secondaries expire the zone? How quickly can I reach an 644 administrator of secondary servers to load a valid zone? These 645 questions are not DNSSEC specific but may influence the choice 646 of your signature validity intervals. 648 4.2. Key Rollovers 650 Regardless of whether a zone uses periodic key rollovers in order to 651 practice for emergencies, or only rolls over keys in an emergency, 652 key rollovers are a fact of life when using DNSSEC. Zone 653 administrators who are in the process of rolling their keys have to 654 take into account that data published in previous versions of their 655 zone still lives in caches. When deploying DNSSEC, this becomes an 656 important consideration; ignoring data that may be in caches may lead 657 to loss of service for clients. 659 The most pressing example of this occurs when zone material signed 660 with an old key is being validated by a resolver that does not have 661 the old zone key cached. If the old key is no longer present in the 662 current zone, this validation fails, marking the data "Bogus". 663 Alternatively, an attempt could be made to validate data that is 664 signed with a new key against an old key that lives in a local cache, 665 also resulting in data being marked "Bogus". 667 4.2.1. Zone Signing Key Rollovers 669 For "Zone Signing Key rollovers", there are two ways to make sure 670 that during the rollover data still cached can be verified with the 671 new key sets or newly generated signatures can be verified with the 672 keys still in caches. One schema, described in Section 4.2.1.2, uses 673 double signatures; the other uses key pre-publication 674 (Section 4.2.1.1). The pros, cons, and recommendations are described 675 in Section 4.2.1.3. 677 4.2.1.1. Pre-Publish Key Rollover 679 This section shows how to perform a ZSK rollover without the need to 680 sign all the data in a zone twice -- the "pre-publish key rollover". 681 This method has advantages in the case of a key compromise. If the 682 old key is compromised, the new key has already been distributed in 683 the DNS. The zone administrator is then able to quickly switch to 684 the new key and remove the compromised key from the zone. Another 685 major advantage is that the zone size does not double, as is the case 686 with the double signature ZSK rollover. A small "how-to" for this 687 kind of rollover can be found in Appendix B. 689 Pre-publish key rollover involves four stages as follows: 691 ---------------------------------------------------------------- 692 initial new DNSKEY new RRSIGs DNSKEY removal 693 ---------------------------------------------------------------- 694 SOA0 SOA1 SOA2 SOA3 695 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 697 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 698 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 699 DNSKEY11 DNSKEY11 700 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 701 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 702 ---------------------------------------------------------------- 704 Pre-Publish Key Rollover 706 initial: Initial version of the zone: DNSKEY 1 is the Key Signing 707 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 708 Signing Key. 710 new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no 711 signatures are generated with this key yet, but this does not 712 secure against brute force attacks on the public key. The minimum 713 duration of this pre-roll phase is the time it takes for the data 714 to propagate to the authoritative servers plus TTL value of the 715 key set. 717 new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is 718 used to sign the data in the zone exclusively (i.e., all the 719 signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 720 remains published in the key set. This way data that was loaded 721 into caches from version 1 of the zone can still be verified with 722 key sets fetched from version 2 of the zone. The minimum time 723 that the key set including DNSKEY 10 is to be published is the 724 time that it takes for zone data from the previous version of the 725 zone to expire from old caches, i.e., the time it takes for this 726 zone to propagate to all authoritative servers plus the Maximum 727 Zone TTL value of any of the data in the previous version of the 728 zone. 730 DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, 731 now only containing DNSKEY 1 and DNSKEY 11, is re-signed with the 732 DNSKEY 1. 734 The above scheme can be simplified by always publishing the "future" 735 key immediately after the rollover. The scheme would look as follows 736 (we show two rollovers); the future key is introduced in "new DNSKEY" 737 as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY 738 (II)": 740 initial new RRSIGs new DNSKEY 741 ----------------------------------------------------------------- 742 SOA0 SOA1 SOA2 743 RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) 745 DNSKEY1 DNSKEY1 DNSKEY1 746 DNSKEY10 DNSKEY10 DNSKEY11 747 DNSKEY11 DNSKEY11 DNSKEY12 748 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) 749 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 750 ---------------------------------------------------------------- 752 ---------------------------------------------------------------- 753 new RRSIGs (II) new DNSKEY (II) 754 ---------------------------------------------------------------- 755 SOA3 SOA4 756 RRSIG12(SOA3) RRSIG12(SOA4) 758 DNSKEY1 DNSKEY1 759 DNSKEY11 DNSKEY12 760 DNSKEY12 DNSKEY13 761 RRSIG1(DNSKEY) RRSIG1(DNSKEY) 762 RRSIG12(DNSKEY) RRSIG12(DNSKEY) 763 ---------------------------------------------------------------- 765 Pre-Publish Key Rollover, Showing Two Rollovers 767 Note that the key introduced in the "new DNSKEY" phase is not used 768 for production yet; the private key can thus be stored in a 769 physically secure manner and does not need to be 'fetched' every time 770 a zone needs to be signed. 772 4.2.1.2. Double Signature Zone Signing Key Rollover 774 This section shows how to perform a ZSK key rollover using the double 775 zone data signature scheme, aptly named "double signature rollover". 777 During the "new DNSKEY" stage the new version of the zone file will 778 need to propagate to all authoritative servers and the data that 779 exists in (distant) caches will need to expire, requiring at least 780 the Maximum Zone TTL. 782 Double signature ZSK rollover involves three stages as follows: 784 ---------------------------------------------------------------- 785 initial new DNSKEY DNSKEY removal 786 ---------------------------------------------------------------- 787 SOA0 SOA1 SOA2 788 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 789 RRSIG11(SOA1) 790 DNSKEY1 DNSKEY1 DNSKEY1 791 DNSKEY10 DNSKEY10 DNSKEY11 792 DNSKEY11 793 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 794 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 795 RRSIG11(DNSKEY) 796 ---------------------------------------------------------------- 798 Double Signature Zone Signing Key Rollover 800 initial: Initial Version of the zone: DNSKEY 1 is the Key Signing 801 Key. DNSKEY 10 is used to sign all the data of the zone, the Zone 802 Signing Key. 804 new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is 805 introduced into the key set and all the data in the zone is signed 806 with DNSKEY 10 and DNSKEY 11. The rollover period will need to 807 continue until all data from version 0 of the zone has expired 808 from remote caches. This will take at least the Maximum Zone TTL 809 of version 0 of the zone. 811 DNSKEY removal: DNSKEY 10 is removed from the zone. All the 812 signatures from DNSKEY 10 are removed from the zone. The key set, 813 now only containing DNSKEY 11, is re-signed with DNSKEY 1. 815 At every instance, RRSIGs from the previous version of the zone can 816 be verified with the DNSKEY RRSet from the current version and the 817 other way around. The data from the current version can be verified 818 with the data from the previous version of the zone. The duration of 819 the "new DNSKEY" phase and the period between rollovers should be at 820 least the Maximum Zone TTL. 822 Making sure that the "new DNSKEY" phase lasts until the signature 823 expiration time of the data in the initial version of the zone is 824 recommended. This way all caches are cleared of the old signatures. 825 However, this duration could be considerably longer than the Maximum 826 Zone TTL, making the rollover a lengthy procedure. 828 Note that in this example we assumed that the zone was not modified 829 during the rollover. New data can be introduced in the zone as long 830 as it is signed with both keys. 832 4.2.1.3. Pros and Cons of the Schemes 834 Pre-publish key rollover: This rollover does not involve signing the 835 zone data twice. Instead, before the actual rollover, the new key 836 is published in the key set and thus is available for 837 cryptanalysis attacks. A small disadvantage is that this process 838 requires four steps. Also the pre-publish scheme involves more 839 parental work when used for KSK rollovers as explained in 840 Section 4.2.3. 842 Double signature ZSK rollover: The drawback of this signing scheme 843 is that during the rollover the number of signatures in your zone 844 doubles; this may be prohibitive if you have very big zones. An 845 advantage is that it only requires three steps. 847 4.2.2. Key Signing Key Rollovers 849 For the rollover of a Key Signing Key, the same considerations as for 850 the rollover of a Zone Signing Key apply. However, we can use a 851 double signature scheme to guarantee that old data (only the apex key 852 set) in caches can be verified with a new key set and vice versa. 853 Since only the key set is signed with a KSK, zone size considerations 854 do not apply. 856 -------------------------------------------------------------------- 857 initial new DNSKEY DS change DNSKEY removal 858 -------------------------------------------------------------------- 859 Parent: 860 SOA0 --------> SOA1 --------> 861 RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> 862 DS1 --------> DS2 --------> 863 RRSIGpar(DS) --------> RRSIGpar(DS) --------> 865 Child: 866 SOA0 SOA1 --------> SOA2 867 RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) 868 --------> 869 DNSKEY1 DNSKEY1 --------> DNSKEY2 870 DNSKEY2 --------> 871 DNSKEY10 DNSKEY10 --------> DNSKEY10 872 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) 873 RRSIG2 (DNSKEY) --------> 874 RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) 875 -------------------------------------------------------------------- 877 Stages of Deployment for a Double Signature Key Signing Key Rollover 879 initial: Initial version of the zone. The parental DS points to 880 DNSKEY1. Before the rollover starts, the child will have to 881 verify what the TTL is of the DS RR that points to DNSKEY1 -- it 882 is needed during the rollover and we refer to the value as TTL_DS. 884 new DNSKEY: During the "new DNSKEY" phase, the zone administrator 885 generates a second KSK, DNSKEY2. The key is provided to the 886 parent, and the child will have to wait until a new DS RR has been 887 generated that points to DNSKEY2. After that DS RR has been 888 published on all servers authoritative for the parent's zone, the 889 zone administrator has to wait at least TTL_DS to make sure that 890 the old DS RR has expired from caches. 892 DS change: The parent replaces DS1 with DS2. 894 DNSKEY removal: DNSKEY1 has been removed. 896 The scenario above puts the responsibility for maintaining a valid 897 chain of trust with the child. It also is based on the premise that 898 the parent only has one DS RR (per algorithm) per zone. An 899 alternative mechanism has been considered. Using an established 900 trust relation, the interaction can be performed in-band, and the 901 removal of the keys by the child can possibly be signaled by the 902 parent. In this mechanism, there are periods where there are two DS 903 RRs at the parent. Since at the moment of writing the protocol for 904 this interaction has not been developed, further discussion is out of 905 scope for this document. 907 4.2.3. Difference Between ZSK and KSK Rollovers 909 Note that KSK rollovers and ZSK rollovers are different in the sense 910 that a KSK rollover requires interaction with the parent (and 911 possibly replacing of trust anchors) and the ensuing delay while 912 waiting for it. 914 A zone key rollover can be handled in two different ways: pre-publish 915 (Section 4.2.1.1) and double signature (Section 4.2.1.2). 917 As the KSK is used to validate the key set and because the KSK is not 918 changed during a ZSK rollover, a cache is able to validate the new 919 key set of the zone. The pre-publish method would also work for a 920 KSK rollover. The records that are to be pre-published are the 921 parental DS RRs. The pre-publish method has some drawbacks for KSKs. 922 We first describe the rollover scheme and then indicate these 923 drawbacks. 925 -------------------------------------------------------------------- 926 initial new DS new DNSKEY DS/DNSKEY removal 927 -------------------------------------------------------------------- 928 Parent: 929 SOA0 SOA1 --------> SOA2 930 RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) 931 DS1 DS1 --------> DS2 932 DS2 --------> 933 RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) 935 Child: 936 SOA0 --------> SOA1 SOA1 937 RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) 938 --------> 939 DNSKEY1 --------> DNSKEY2 DNSKEY2 940 --------> 941 DNSKEY10 --------> DNSKEY10 DNSKEY10 942 RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) 943 RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) 944 -------------------------------------------------------------------- 946 Stages of Deployment for a Pre-Publish Key Signing Key Rollover 948 When the child zone wants to roll, it notifies the parent during the 949 "new DS" phase and submits the new key (or the corresponding DS) to 950 the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 951 and DNSKEY2, respectively. During the rollover ("new DNSKEY" phase), 952 which can take place as soon as the new DS set propagated through the 953 DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that 954 ("DS/DNSKEY removal" phase), it can notify the parent that the old DS 955 record can be deleted. 957 The drawbacks of this scheme are that during the "new DS" phase the 958 parent cannot verify the match between the DS2 RR and DNSKEY2 using 959 the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a 960 "security lame" key (see Section 4.4.3). Finally, the child-parent 961 interaction consists of two steps. The "double signature" method 962 only needs one interaction. 964 4.2.4. Key algorithm rollover 966 [OK: The txt of this section is a strawman for the issue in: http:// 967 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll 968 ] 970 A special class of keyrollover is the rollover of key algorithms 971 (either adding a new algorithm, removing an old algorithm, or both), 972 additional steps are needed to retain integrity during the rollover. 974 Because of the algorithm downgrade protection in RFC4035 section 2.2, 975 you may not have a key of an algorithm for which you do not have 976 signatures. 978 When adding a new algorithm, the signatures should be added first. 979 After the TTL has expired, and caches have dropped the old data 980 covered by those signatures, the DNSKEY with the new algorithm can be 981 added. When removing an old algorithm, the DNSKEY should be removed 982 first. 984 To do both, the following steps can be used. For simplicity, we use 985 a zone that is only signed by one zone signing key. 987 ---------------------------------------------------------------- 988 1 Initial 2 New RRSIGS 3 New DNSKEY 989 ---------------------------------------------------------------- 990 SOA0 SOA1 SOA2 991 RRSIG1(SOA0) RRSIG1(SOA1) RRSIG1(SOA2) 992 RRSIG2(SOA1) RRSIG2(SOA2) 994 DNSKEY1 DNSKEY1 DNSKEY1 995 RRSIG1(DNSKEY) RRSIG1(DNSKEY) DNSKEY2 996 RRSIG2(DNSKEY) RRSIG1(DNSKEY) 997 RRSIG2(DNSKEY) 998 ---------------------------------------------------------------- 999 4 Remove DNSKEY 5 Remove RRSIGS 1000 ---------------------------------------------------------------- 1001 SOA3 SOA4 1002 RRSIG1(SOA3) RRSIG2(SOA4) 1003 RRSIG2(SOA3) 1005 DNSKEY2 DNSKEY2 1006 RRSIG1(DNSKEY) RRSIG2(DNSKEY) 1007 RRSIG2(DNSKEY) 1008 ---------------------------------------------------------------- 1010 Stages of Deployment during an Algorithm Rollover. 1012 In step 2, the signatures for the new key are added, but the key 1013 itself is not. While in theory, the signatures of the keyset should 1014 always be synchronized with the keyset itself, it can be possible 1015 that RRSIGS are requested separately, so it might be prudent to also 1016 sign the DNSKEY set with the new signature. 1018 After the cache data has expired, the new key can be added to the 1019 zone, as done in step 3. 1021 The next step is to remove the old algorithm. This time the key 1022 needs to be removed first, before removing the signatures. The key 1023 is removed in step 4, and after the cache data has expired, the 1024 signatures can be removed in step 5. 1026 The above steps ensure that during the rollover to a new algorithm, 1027 the integrity of the zone is never broken. 1029 4.2.5. Automated Key Rollovers 1031 As keys must be renewed periodically, there is some motivation to 1032 automate the rollover process. Consider the following: 1034 o ZSK rollovers are easy to automate as only the child zone is 1035 involved. 1037 o A KSK rollover needs interaction between parent and child. Data 1038 exchange is needed to provide the new keys to the parent; 1039 consequently, this data must be authenticated and integrity must 1040 be guaranteed in order to avoid attacks on the rollover. 1042 4.3. Planning for Emergency Key Rollover 1044 This section deals with preparation for a possible key compromise. 1045 Our advice is to have a documented procedure ready for when a key 1046 compromise is suspected or confirmed. 1048 When the private material of one of your keys is compromised it can 1049 be used for as long as a valid trust chain exists. A trust chain 1050 remains intact for 1052 o as long as a signature over the compromised key in the trust chain 1053 is valid, 1055 o as long as a parental DS RR (and signature) points to the 1056 compromised key, 1058 o as long as the key is anchored in a resolver and is used as a 1059 starting point for validation (this is generally the hardest to 1060 update). 1062 While a trust chain to your compromised key exists, your namespace is 1063 vulnerable to abuse by anyone who has obtained illegitimate 1064 possession of the key. Zone operators have to make a trade-off if 1065 the abuse of the compromised key is worse than having data in caches 1066 that cannot be validated. If the zone operator chooses to break the 1067 trust chain to the compromised key, data in caches signed with this 1068 key cannot be validated. However, if the zone administrator chooses 1069 to take the path of a regular rollover, the malicious key holder can 1070 spoof data so that it appears to be valid. 1072 4.3.1. KSK Compromise 1074 A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable 1075 as long as the compromised KSK is configured as trust anchor or a 1076 parental DS points to it. 1078 A compromised KSK can be used to sign the key set of an attacker's 1079 zone. That zone could be used to poison the DNS. 1081 Therefore, when the KSK has been compromised, the trust anchor or the 1082 parental DS should be replaced as soon as possible. It is local 1083 policy whether to break the trust chain during the emergency 1084 rollover. The trust chain would be broken when the compromised KSK 1085 is removed from the child's zone while the parent still has a DS 1086 pointing to the compromised KSK (the assumption is that there is only 1087 one DS at the parent. If there are multiple DSes this does not apply 1088 -- however the chain of trust of this particular key is broken). 1090 Note that an attacker's zone still uses the compromised KSK and the 1091 presence of a parental DS would cause the data in this zone to appear 1092 as valid. Removing the compromised key would cause the attacker's 1093 zone to appear as valid and the child's zone as Bogus. Therefore, we 1094 advise not to remove the KSK before the parent has a DS to a new KSK 1095 in place. 1097 4.3.1.1. Keeping the Chain of Trust Intact 1099 If we follow this advice, the timing of the replacement of the KSK is 1100 somewhat critical. The goal is to remove the compromised KSK as soon 1101 as the new DS RR is available at the parent. And also make sure that 1102 the signature made with a new KSK over the key set with the 1103 compromised KSK in it expires just after the new DS appears at the 1104 parent, thus removing the old cruft in one swoop. 1106 The procedure is as follows: 1108 1. Introduce a new KSK into the key set, keep the compromised KSK in 1109 the key set. 1111 2. Sign the key set, with a short validity period. The validity 1112 period should expire shortly after the DS is expected to appear 1113 in the parent and the old DSes have expired from caches. 1115 3. Upload the DS for this new key to the parent. 1117 4. Follow the procedure of the regular KSK rollover: Wait for the DS 1118 to appear in the authoritative servers and then wait as long as 1119 the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet 1120 and modify/extend the expiration time. 1122 5. Remove the compromised DNSKEY RR from the zone and re-sign the 1123 key set using your "normal" validity interval. 1125 An additional danger of a key compromise is that the compromised key 1126 could be used to facilitate a legitimate DNSKEY/DS rollover and/or 1127 nameserver changes at the parent. When that happens, the domain may 1128 be in dispute. An authenticated out-of-band and secure notify 1129 mechanism to contact a parent is needed in this case. 1131 Note that this is only a problem when the DNSKEY and or DS records 1132 are used for authentication at the parent. 1134 4.3.1.2. Breaking the Chain of Trust 1136 There are two methods to break the chain of trust. The first method 1137 causes the child zone to appear 'Bogus' to validating resolvers. The 1138 other causes the child zone to appear 'insecure'. These are 1139 described below. 1141 In the method that causes the child zone to appear 'Bogus' to 1142 validating resolvers, the child zone replaces the current KSK with a 1143 new one and re-signs the key set. Next it sends the DS of the new 1144 key to the parent. Only after the parent has placed the new DS in 1145 the zone is the child's chain of trust repaired. 1147 An alternative method of breaking the chain of trust is by removing 1148 the DS RRs from the parent zone altogether. As a result, the child 1149 zone would become insecure. 1151 4.3.2. ZSK Compromise 1153 Primarily because there is no parental interaction required when a 1154 ZSK is compromised, the situation is less severe than with a KSK 1155 compromise. The zone must still be re-signed with a new ZSK as soon 1156 as possible. As this is a local operation and requires no 1157 communication between the parent and child, this can be achieved 1158 fairly quickly. However, one has to take into account that just as 1159 with a normal rollover the immediate disappearance of the old 1160 compromised key may lead to verification problems. Also note that as 1161 long as the RRSIG over the compromised ZSK is not expired the zone 1162 may be still at risk. 1164 4.3.3. Compromises of Keys Anchored in Resolvers 1166 A key can also be pre-configured in resolvers. For instance, if 1167 DNSSEC is successfully deployed the root key may be pre-configured in 1168 most security aware resolvers. 1170 If trust-anchor keys are compromised, the resolvers using these keys 1171 should be notified of this fact. Zone administrators may consider 1172 setting up a mailing list to communicate the fact that a SEP key is 1173 about to be rolled over. This communication will of course need to 1174 be authenticated, e.g., by using digital signatures. 1176 End-users faced with the task of updating an anchored key should 1177 always validate the new key. New keys should be authenticated out- 1178 of-band, for example, through the use of an announcement website that 1179 is secured using secure sockets (TLS) [23]. 1181 4.4. Parental Policies 1183 4.4.1. Initial Key Exchanges and Parental Policies Considerations 1185 The initial key exchange is always subject to the policies set by the 1186 parent. When designing a key exchange policy one should take into 1187 account that the authentication and authorization mechanisms used 1188 during a key exchange should be as strong as the authentication and 1189 authorization mechanisms used for the exchange of delegation 1190 information between parent and child. That is, there is no implicit 1191 need in DNSSEC to make the authentication process stronger than it 1192 was in DNS. 1194 Using the DNS itself as the source for the actual DNSKEY material, 1195 with an out-of-band check on the validity of the DNSKEY, has the 1196 benefit that it reduces the chances of user error. A DNSKEY query 1197 tool can make use of the SEP bit [5] to select the proper key from a 1198 DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is 1199 sent. It can validate the self-signature over a key; thereby 1200 verifying the ownership of the private key material. Fetching the 1201 DNSKEY from the DNS ensures that the chain of trust remains intact 1202 once the parent publishes the DS RR indicating the child is secure. 1204 Note: the out-of-band verification is still needed when the key 1205 material is fetched via the DNS. The parent can never be sure 1206 whether or not the DNSKEY RRs have been spoofed. 1208 4.4.2. Storing Keys or Hashes? 1210 When designing a registry system one should consider which of the 1211 DNSKEYs and/or the corresponding DSes to store. Since a child zone 1212 might wish to have a DS published using a message digest algorithm 1213 not yet understood by the registry, the registry can't count on being 1214 able to generate the DS record from a raw DNSKEY. Thus, we recommend 1215 that registry systems at least support storing DS records. 1217 It may also be useful to store DNSKEYs, since having them may help 1218 during troubleshooting and, as long as the child's chosen message 1219 digest is supported, the overhead of generating DS records from them 1220 is minimal. Having an out-of-band mechanism, such as a registry 1221 directory (e.g., Whois), to find out which keys are used to generate 1222 DS Resource Records for specific owners and/or zones may also help 1223 with troubleshooting. 1225 The storage considerations also relate to the design of the customer 1226 interface and the method by which data is transferred between 1227 registrant and registry; Will the child zone administrator be able to 1228 upload DS RRs with unknown hash algorithms or does the interface only 1229 allow DNSKEYs? In the registry-registrar model, one can use the 1230 DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15], 1231 which allows transfer of DS RRs and optionally DNSKEY RRs. 1233 4.4.3. Security Lameness 1235 Security lameness is defined as what happens when a parent has a DS 1236 RR pointing to a non-existing DNSKEY RR. When this happens, the 1237 child's zone may be marked "Bogus" by verifying DNS clients. 1239 As part of a comprehensive delegation check, the parent could, at key 1240 exchange time, verify that the child's key is actually configured in 1241 the DNS. However, if a parent does not understand the hashing 1242 algorithm used by child, the parental checks are limited to only 1243 comparing the key id. 1245 Child zones should be very careful in removing DNSKEY material, 1246 specifically SEP keys, for which a DS RR exists. 1248 Once a zone is "security lame", a fix (e.g., removing a DS RR) will 1249 take time to propagate through the DNS. 1251 4.4.4. DS Signature Validity Period 1253 Since the DS can be replayed as long as it has a valid signature, a 1254 short signature validity period over the DS minimizes the time a 1255 child is vulnerable in the case of a compromise of the child's 1256 KSK(s). A signature validity period that is too short introduces the 1257 possibility that a zone is marked "Bogus" in case of a configuration 1258 error in the signer. There may not be enough time to fix the 1259 problems before signatures expire. Something as mundane as operator 1260 unavailability during weekends shows the need for DS signature 1261 validity periods longer than 2 days. We recommend an absolute 1262 minimum for a DS signature validity period of a few days. 1264 The maximum signature validity period of the DS record depends on how 1265 long child zones are willing to be vulnerable after a key compromise. 1266 On the other hand, shortening the DS signature validity interval 1267 increases the operational risk for the parent. Therefore, the parent 1268 may have policy to use a signature validity interval that is 1269 considerably longer than the child would hope for. 1271 A compromise between the operational constraints of the parent and 1272 minimizing damage for the child may result in a DS signature validity 1273 period somewhere between a week and months. 1275 In addition to the signature validity period, which sets a lower 1276 bound on the number of times the zone owner will need to sign the 1277 zone data and which sets an upper bound to the time a child is 1278 vulnerable after key compromise, there is the TTL value on the DS 1279 RRs. Shortening the TTL means that the authoritative servers will 1280 see more queries. But on the other hand, a short TTL lowers the 1281 persistence of DS RRSets in caches thereby increasing the speed with 1282 which updated DS RRSets propagate through the DNS. 1284 4.4.5. (Non) Cooperating Registrars 1286 [OK: this is a first strawman, and is intended to start the 1287 discussion of the issue. By no means this is intended to be a final 1288 text.] 1290 The parent-child relation is often described in terms of a (thin) 1291 registry model. Where a registry maintains the parent zone, and the 1292 registrant (the user of the child-domain name), deals with the 1293 registry through an intermediary called a registrar. (See [12] for a 1294 comprehensive definition). Registrants may out-source the 1295 maintenance of their DNS system, including the maintenance of DNSSEC 1296 key material, to the registrar or to another third party. The entity 1297 that has control over the DNS zone and its keys may prevent the 1298 registrant to make a timely move to a different registrar. [OK: I 1299 use the term registrar below while it is the operator of the DNS zone 1300 who is the actual culprit. For instance, the case also applies when 1301 a registrant passes a zone to another registrant. Should I just use 1302 "DNS Administrator"?] 1304 Suppose that the registrant wants to move from losing registrar A to 1305 gaining registrar B. Let us first look what would happen in a 1306 cooperative environment. The assumption is that registrar A will not 1307 hand off any private key material to registrar B because that would 1308 be a trivial case. 1310 In a cooperating environment one could proceed with a pre-publish ZSK 1311 rollover whereby registrar A pre-publishes the ZSK of registrar B, 1312 combined with a double signature KSK rollover where the two 1313 registrars exchange public keys and independently generate a 1314 signature over the keysets that they combine and both publish in the 1315 zone. 1317 In the non-cooperative case matters are more complicated. The 1318 loosing registrar A may not cooperate and leave the data in the DNS 1319 as is. In the extreme case registrar A may become obstructive and 1320 publish a DNSKEY RR with a high TTL and corresponding signature 1321 validity so that registrar A's DNSKEY, would end up in caches for, in 1322 theory, tens of years. 1324 The problem arises when a validator tries to validate with A's key 1325 and there is no signature material produced with Registrars A 1326 available in the delegation path after redelegation from registrar A 1327 to registrar B has taken place. One could imagine a rollover 1328 scenario where registrar B pulls all RRSIGs created by registar A and 1329 publishes those in conjunction with its own signatures, but that 1330 would not allow any changes in the zone content. Since a 1331 redelegation took place the NS RRset has -- per definition-- changed 1332 so such rollover scenario will not work. Besides if zone transfers 1333 are not allowed by A and NSEC3 is deployed in the A's zone then 1334 registrar B will not have certainty that all of A's RRSIGs are 1335 transfered. 1337 The only viable option for the registrant is to publish its zone 1338 unsigned and ask the registry to remove the DS pointing to registrar 1339 A for as long as the DNSKEY of registrar A, or any of the signatures 1340 produced by registrar A are likely to appear in caches, which as 1341 mentioned above could in theory be for tens of years. [OK: Some 1342 implementations limit the time data is cached. Although that is not 1343 a protocol requirement (and may even be considered a protocol 1344 violation) it seems that that practice may limit the impact of this 1345 problem, is that worth mentioning?] 1347 [OK: This is really the point that I'm trying to make, is the above 1348 text needed?] There is no operational methodology to work around 1349 this business issue and proper contractual relations ships between 1350 registrants and their registrars seem to be the only solution to cope 1351 with these problems. 1353 5. Security Considerations 1355 DNSSEC adds data integrity to the DNS. This document tries to assess 1356 the operational considerations to maintain a stable and secure DNSSEC 1357 service. Not taking into account the 'data propagation' properties 1358 in the DNS will cause validation failures and may make secured zones 1359 unavailable to security-aware resolvers. 1361 6. IANA considerations 1363 There are no IANA considerations with respect to this document 1365 7. Acknowledgments 1367 Most of the text of this document is copied from RFC4641 [16] people 1368 involved in that work were in random order: Rip Loomis, Olafur 1369 Gudmundsson, Wesley Griffin, Michael Richardson, Scott Rose, Rick van 1370 Rein, Tim McGinnis, Gilles Guette Olivier Courtay, Sam Weiler, Jelte 1371 Jansen, Niall O'Reilly, Holger Zuleger, Ed Lewis, Hilarie Orman, 1372 Marcos Sanz, Peter Koch, Mike StJohns, Emmar Bretherick, Adrian 1373 Bedford, and Lindy Foster, G. Guette, and O. Courtay. 1375 For this version of the document we would like to acknowldge: 1377 o Paul Hoffman for his contribution on the choice of cryptographic 1378 paramenters and addressing some of the trust anchor issues. 1380 o Jelte Jansen provided the text in Section 4.2.4 1382 8. References 1384 8.1. Normative References 1386 [1] Mockapetris, P., "Domain names - concepts and facilities", 1387 STD 13, RFC 1034, November 1987. 1389 [2] Mockapetris, P., "Domain names - implementation and 1390 specification", STD 13, RFC 1035, November 1987. 1392 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1393 "DNS Security Introduction and Requirements", RFC 4033, 1394 March 2005. 1396 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1397 "Resource Records for the DNS Security Extensions", RFC 4034, 1398 March 2005. 1400 [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1401 "Protocol Modifications for the DNS Security Extensions", 1402 RFC 4035, March 2005. 1404 8.2. Informative References 1406 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1407 Levels", BCP 14, RFC 2119, March 1997. 1409 [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 1410 August 1996. 1412 [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes 1413 (DNS NOTIFY)", RFC 1996, August 1996. 1415 [9] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", 1416 RFC 2308, March 1998. 1418 [10] Eastlake, D., "DNS Security Operational Considerations", 1419 RFC 2541, March 1999. 1421 [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1422 Update", RFC 3007, November 2000. 1424 [12] Hollenbeck, S., "Generic Registry-Registrar Protocol 1425 Requirements", RFC 3375, September 2002. 1427 [13] Orman, H. and P. Hoffman, "Determining Strengths For Public 1428 Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 1429 April 2004. 1431 [14] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1432 Requirements for Security", BCP 106, RFC 4086, June 2005. 1434 [15] Hollenbeck, S., "Domain Name System (DNS) Security Extensions 1435 Mapping for the Extensible Provisioning Protocol (EPP)", 1436 RFC 4310, December 2005. 1438 [16] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 1439 RFC 4641, September 2006. 1441 [17] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 1442 August 2007. 1444 [18] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust 1445 Anchors", RFC 5011, September 2007. 1447 [19] Rose, S., "NIST DNSSEC workshop notes", , June 2001. 1449 [20] Barker, E. and J. Kelsey, "Recommendation for Random Number 1450 Generation Using Deterministic Random Bit Generators 1451 (Revised)", Nist Special Publication 800-90, March 2007. 1453 [21] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY and 1454 RRSIG Resource Records for DNSSEC", 1455 draft-ietf-dnsext-dnssec-rsasha256-05 (work in progress), 1456 July 2008. 1458 [22] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 1459 Resource Records (RRs)", RFC 4509, May 2006. 1461 [23] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1462 T. Wright, "Transport Layer Security (TLS) Extensions", 1463 RFC 4366, April 2006. 1465 Appendix A. Terminology 1467 In this document, there is some jargon used that is defined in other 1468 documents. In most cases, we have not copied the text from the 1469 documents defining the terms but have given a more elaborate 1470 explanation of the meaning. Note that these explanations should not 1471 be seen as authoritative. 1473 Anchored key: A DNSKEY configured in resolvers around the globe. 1474 This key is hard to update, hence the term anchored. 1476 Bogus: Also see Section 5 of [3]. An RRSet in DNSSEC is marked 1477 "Bogus" when a signature of an RRSet does not validate against a 1478 DNSKEY. 1480 Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is 1481 used exclusively for signing the apex key set. The fact that a 1482 key is a KSK is only relevant to the signing tool. 1484 Key size: The term 'key size' can be substituted by 'modulus size' 1485 throughout the document. It is mathematically more correct to use 1486 modulus size, but as this is a document directed at operators we 1487 feel more at ease with the term key size. 1489 Private and public keys: DNSSEC secures the DNS through the use of 1490 public key cryptography. Public key cryptography is based on the 1491 existence of two (mathematically related) keys, a public key and a 1492 private key. The public keys are published in the DNS by use of 1493 the DNSKEY Resource Record (DNSKEY RR). Private keys should 1494 remain private. 1496 Key rollover: A key rollover (also called key supercession in some 1497 environments) is the act of replacing one key pair with another at 1498 the end of a key effectivity period. 1500 Secure Entry Point (SEP) key: A KSK that has a parental DS record 1501 pointing to it or is configured as a trust anchor. Although not 1502 required by the protocol, we recommend that the SEP flag [5] is 1503 set on these keys. 1505 Self-signature: This only applies to signatures over DNSKEYs; a 1506 signature made with DNSKEY x, over DNSKEY x is called a self- 1507 signature. Note: without further information, self-signatures 1508 convey no trust. They are useful to check the authenticity of the 1509 DNSKEY, i.e., they can be used as a hash. 1511 Singing the zone file: The term used for the event where an 1512 administrator joyfully signs its zone file while producing melodic 1513 sound patterns. 1515 Signer: The system that has access to the private key material and 1516 signs the Resource Record sets in a zone. A signer may be 1517 configured to sign only parts of the zone, e.g., only those RRSets 1518 for which existing signatures are about to expire. 1520 Zone Signing Key (ZSK): A key that is used for signing all data in a 1521 zone (except, perhaps, the DNSKEY RRSet). The fact that a key is 1522 a ZSK is only relevant to the signing tool. 1524 Zone administrator: The 'role' that is responsible for signing a 1525 zone and publishing it on the primary authoritative server. 1527 Appendix B. Zone Signing Key Rollover How-To 1529 Using the pre-published signature scheme and the most conservative 1530 method to assure oneself that data does not live in caches, here 1531 follows the "how-to". 1533 Step 0: The preparation: Create two keys and publish both in your 1534 key set. Mark one of the keys "active" and the other "published". 1535 Use the "active" key for signing your zone data. Store the 1536 private part of the "published" key, preferably off-line. The 1537 protocol does not provide for attributes to mark a key as active 1538 or published. This is something you have to do on your own, 1539 through the use of a notebook or key management tool. 1541 Step 1: Determine expiration: At the beginning of the rollover make 1542 a note of the highest expiration time of signatures in your zone 1543 file created with the current key marked as active. Wait until 1544 the expiration time marked in Step 1 has passed. 1546 Step 2: Then start using the key that was marked "published" to sign 1547 your data (i.e., mark it "active"). Stop using the key that was 1548 marked "active"; mark it "rolled". 1550 Step 3: It is safe to engage in a new rollover (Step 1) after at 1551 least one signature validity period. 1553 Appendix C. Typographic Conventions 1555 The following typographic conventions are used in this document: 1557 Key notation: A key is denoted by DNSKEYx, where x is a number or an 1558 identifier, x could be thought of as the key id. 1560 RRSet notations: RRs are only denoted by the type. All other 1561 information -- owner, class, rdata, and TTL -- is left out. Thus: 1562 "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a 1563 list of RRs. A example of this would be "A1, A2", specifying the 1564 RRSet containing two "A" records. This could again be abbreviated 1565 to just "A". 1567 Signature notation: Signatures are denoted as RRSIGx(RRSet), which 1568 means that RRSet is signed with DNSKEYx. 1570 Zone representation: Using the above notation we have simplified the 1571 representation of a signed zone by leaving out all unnecessary 1572 details such as the names and by representing all data by "SOAx" 1574 SOA representation: SOAs are represented as SOAx, where x is the 1575 serial number. 1577 Using this notation the following signed zone: 1579 example.net. 86400 IN SOA ns.example.net. bert.example.net. ( 1580 2006022100 ; serial 1581 86400 ; refresh ( 24 hours) 1582 7200 ; retry ( 2 hours) 1583 3600000 ; expire (1000 hours) 1584 28800 ) ; minimum ( 8 hours) 1585 86400 RRSIG SOA 5 2 86400 20130522213204 ( 1586 20130422213204 14 example.net. 1587 cmL62SI6iAX46xGNQAdQ... ) 1588 86400 NS a.example.net. 1589 86400 NS b.example.net. 1590 86400 RRSIG NS 5 2 86400 20130507213204 ( 1591 20130407213204 14 example.net. 1592 SO5epiJei19AjXoUpFnQ ... ) 1593 86400 DNSKEY 256 3 5 ( 1594 EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 1595 86400 DNSKEY 257 3 5 ( 1596 gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 1597 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1598 20130422213204 14 example.net. 1599 J4zCe8QX4tXVGjV4e1r9... ) 1600 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( 1601 20130422213204 15 example.net. 1602 keVDCOpsSeDReyV6O... ) 1603 86400 RRSIG NSEC 5 2 86400 20130507213204 ( 1604 20130407213204 14 example.net. 1605 obj3HEp1GjnmhRjX... ) 1606 a.example.net. 86400 IN TXT "A label" 1607 86400 RRSIG TXT 5 3 86400 20130507213204 ( 1608 20130407213204 14 example.net. 1609 IkDMlRdYLmXH7QJnuF3v... ) 1610 86400 NSEC b.example.com. TXT RRSIG NSEC 1611 86400 RRSIG NSEC 5 3 86400 20130507213204 ( 1612 20130407213204 14 example.net. 1613 bZMjoZ3bHjnEz0nIsPMM... ) 1614 ... 1616 is reduced to the following representation: 1618 SOA2006022100 1619 RRSIG14(SOA2006022100) 1620 DNSKEY14 1621 DNSKEY15 1623 RRSIG14(KEY) 1624 RRSIG15(KEY) 1626 The rest of the zone data has the same signature as the SOA record, 1627 i.e., an RRSIG created with DNSKEY 14. 1629 Appendix D. Document Editing History 1631 [To be removed prior to publication as an RFC] 1633 D.1. draft-ietf-dnsop-rfc4641-00 1635 Version 0 was differs from RFC4641 in the following ways. 1637 o Status of this memo appropriate for I-D 1639 o TOC formatting differs. 1641 o Whitespaces, linebreaks, and pagebreaks may be slightly different 1642 because of xml2rfc generation. 1644 o References slightly reordered. 1646 o Applied the errata from 1647 http://www.rfc-editor.org/errata_search.php?rfc=4641 1649 o Inserted trivial "IANA considertations" section. 1651 In other words it should not contain substantive changes in content 1652 as intended by the workinggroup for the original RFC4641. 1654 D.2. version 0->1 1656 Cryptography details rewritten. (See http://www.nlnetlabs.nl/svn/ 1657 rfc4641bis/trunk/open-issues/cryptography_flawed) 1659 o Reference to NIST 800-90 added 1661 o RSA/SHA256 is being recommended in addition to RSA/SHA1. 1663 o Complete rewrite of Section 3.5 removing the table and suggesting 1664 a keysize of 1024 for keys in use for less than 8 years, issued up 1665 to at least 2015. 1667 o Replaced the reference to Schneiers' applied cryptograpy with a 1668 reference to RFC4949. 1670 o Removed the KSK for high level zones consideration 1672 Applied some differentiation with respect of the use of a KSK for 1673 parent or trust-anchor relation http://www.nlnetlabs.nl/svn/ 1674 rfc4641bis/trunk/open-issues/differentiation_trustanchor_parent 1675 http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 1676 rollover_assumptions 1678 Added Section 4.2.4 as suggested by Jelte Jansen in http:// 1679 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/Key_algorithm_roll 1681 Added Section 4.4.5 Issue identified by Antoin Verschuur http:// 1682 www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ 1683 non-cooperative-registrars 1685 In Appendix A: ZSK does not nescessarily sign the DNSKEY RRset. 1687 $Id: draft-ietf-dnsop-rfc4641bis-01.txt 28 2009-03-06 14:03:57Z olaf $ 1689 Authors' Addresses 1691 Olaf M. Kolkman 1692 NLnet Labs 1693 Kruislaan 419 1694 Amsterdam 1098 VA 1695 The Netherlands 1697 EMail: olaf@nlnetlabs.nl 1698 URI: http://www.nlnetlabs.nl 1700 Miek Gieben 1702 EMail: miek@miek.nl