idnits 2.17.1 draft-ietf-dnsop-dnssec-operational-practices-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** There are 31 instances of lines with control characters in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7528 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 717, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 723, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 742, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2541 (ref. '2') (Obsoleted by RFC 4641) ** Obsolete normative reference: RFC 3090 (ref. '3') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-12) exists of draft-ietf-dnsext-keyrr-key-signing-flag-06 == Outdated reference: A later version (-15) exists of draft-ietf-dnsext-delegation-signer-13 == Outdated reference: A later version (-09) exists of draft-ietf-dnsext-dnssec-protocol-01 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP O. Kolkman 3 Internet-Draft RIPE NCC 4 Expires: March 1, 2004 R. Gieben 5 NLnet Labs 6 September 2003 8 DNSSEC Operational Practices 9 draft-ietf-dnsop-dnssec-operational-practices-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 1, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document intends to describe a set of practices for operating a 40 DNSSEC aware enviroment. Its target audience is zone administrators 41 who are deploying DNSSEC and need a guide to help them chose sensible 42 values for DNSSEC parameters. Is also discusses operational matters 43 like key rollovers, KSK and ZSK considerations and more. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 The use of the term 'key' . . . . . . . . . . . . . . . . . 3 49 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1 Time definitions . . . . . . . . . . . . . . . . . . . . . . 3 51 2.2 Time considerations . . . . . . . . . . . . . . . . . . . . 4 52 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1 Motivations for the KSK and ZSK functions . . . . . . . . . 6 54 3.2 Key security considerations . . . . . . . . . . . . . . . . 7 55 3.3 Key rollovers . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.3.1 Zone-signing key rollovers . . . . . . . . . . . . . . . . . 9 57 3.3.2 Key-signing key rollovers . . . . . . . . . . . . . . . . . 12 58 4. Planning for emergency key rollover. . . . . . . . . . . . . 13 59 4.1 KSK compromise . . . . . . . . . . . . . . . . . . . . . . . 13 60 4.2 ZSK compromise . . . . . . . . . . . . . . . . . . . . . . . 14 61 4.3 Compromises of keys anchored in resolvers . . . . . . . . . 14 62 5. Parental policies. . . . . . . . . . . . . . . . . . . . . . 14 63 5.1 Initial key exchanges and parental policies 64 considerations. . . . . . . . . . . . . . . . . . . . . . . 14 65 5.2 Storing keys so hashes can be regenerated . . . . . . . . . 15 66 5.3 Security lameness checks. . . . . . . . . . . . . . . . . . 15 67 5.4 SIG DS validity period. . . . . . . . . . . . . . . . . . . 15 68 6. Security considerations . . . . . . . . . . . . . . . . . . 16 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 70 Normative References . . . . . . . . . . . . . . . . . . . . 16 71 Informative References . . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 73 A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 17 74 B. Zone-signing key rollover howto . . . . . . . . . . . . . . 18 75 C. Typographic conventions . . . . . . . . . . . . . . . . . . 19 76 D. Document Details and Changes . . . . . . . . . . . . . . . . 20 77 D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . . 21 78 Intellectual Property and Copyright Statements . . . . . . . 22 80 1. Introduction 82 During workshops and early operational deployment tests, operators 83 and system administrators gained knowledge about operating DNSSEC 84 aware DNS services. This document describes these practices. 86 The structure of the document is as follows. It starts with 87 discussing some of the considerations with respect to timing 88 parameters of DNS in relation to DNSSEC (Section 2). Aspects of key 89 management such as key rollover schemes are described in Section 3. 90 Emergency rollover considerations are addressed in Section 4. The 91 Typographic conventions used in this document are explained in 92 Appendix C. 94 Since this is a document with operational suggestions and there is no 95 protocol specifications the RFC2119 [5] language does not apply. 97 1.1 The use of the term 'key' 99 It is assumed that the reader is familiar with the concept of 100 asymmetric keys on which DNSSEC is based. Therefore this document 101 will use the term key rather loosely. Wherever we write that 'a key 102 is used to sign data' it is assumed that the reader knows that it is 103 the private part of the key-pair that is used for signing. It is also 104 assumed that the reader will know that the public part of the 105 key-pair is published in the DNSKEY resource record and that it is 106 the public part of a key-pair that is used in key-exchanges. 108 2. Time in DNSSEC 110 Without DNSSEC all times in DNS are relative. The SOA's refresh, 111 retry and expiration timers are counters that are being used to 112 determine the time elapsed after a slave server synced (or tried to 113 sync) with a master server. The TTL value and the SOA minimum TTL 114 parameter [6] are used to to determine how long a forwarder should 115 cache data after it has been fetched from an authoritative server. 116 DNSSEC introduces the notion of an absolute time in the DNS. 117 Signatures in DNSSEC have an expiration date after which the 118 signature is invalid and the signed data is to be considered BAD. 120 2.1 Time definitions 122 In this document we will be using a number of time related terms. 123 Within the context of this document the following definitions apply: 125 o "Signature validity period" 126 The period that a signature is valid. It starts at the time 127 specified in the signature inception field of the RRSIG RR and 128 ends at the time specified in the expiration field of the RRSIG 129 RR. 131 o "Signature publication period" 133 Time after which a signature made with a key is replaced with a 134 new signature made with the same key. This replacement takes 135 place by publishing the relevant RRSIG in the master zone file. 136 If a signature is published on time T0 and a new signature is 137 published on time T1, the signature publication period is T1 - 138 T0. If all signatures are refreshed at zone (re)signing then 139 the signature publication period is equal to the period between 140 two consecutive zone signing operations. 142 o "Key publication period" 144 The period for which the public part of the key is published in 145 the DNS. The public part of the key can be published in the DNS 146 while it has not yet been used to sign data. As soon as a 147 public key is published a brute force attack can be attempted 148 to recover the private key. Publishing the public key in 149 advance (and not signing any data with it) does not guard 150 against this attack. 152 [Editor's Note: We don't use this term in the doc yet, is it 153 needed elsewhere and handy to define here? No:1 Yes:0] 155 o "Maximum/Minimum Zone TTL" 157 The maximum or minimum value of all the TTLs in a zone. 159 2.2 Time considerations 161 Because of the expiration of signatures one should consider the 162 following. 164 o The Maximum zone TTL of your zone data should be a fraction of 165 your signature validity period. 167 If the TTL would be of similar order as the signature validity 168 period then all RRsets fetched during the validity period would 169 be cached until the signature expiration time. As a result 170 query behavior might become bursty. 172 We suggest the TTL on all the RRs in your zone to be at least 173 an order of magnitude smaller than your signature validity 174 period. 176 o The signature publication period should at least be one maximum 177 TTL smaller than the signature validity period. 179 If a zone is resigned shortly before the end of the signature 180 validity period this may cause simultaneous expiration of data 181 from caches which leads to bursty query behavior and increase 182 the load on authoritative servers. 184 o The Minimum zone TTL should be long enough to fetch and verify all 185 the RRs in the authentication chain. 187 1. During validation, some data may expire before validation 188 is complete. The validator should be able to keep all the 189 data, until validation is complete. This applies to all data 190 in the chain of trust: DSs, DNSKEYs, RRSIGs, and the final 191 answers i.e. the RR that is returned for the initial query. 193 2. Frequent verification causes load on recursive 194 nameservers. Data at delegation points, DSs, DNSKEYs and 195 RRSIGs benefit from caching. The TTL on those should be 196 relatively long. 198 We have seen events where data needed for verification of an 199 authentication chain had expired from caches. 201 We suggest the TTL on DNSKEY and DSs to be at least of the 202 order 10 minutes to an hour and all the other RRs in your zone 203 to be at least 30 seconds. These are absolute minimum, we 204 recommend zone administrators to chose longer ones. 206 [Editor's Note: this observation could be implementation 207 specific. We are not sure if we should leave this item] 209 o Slave servers will need to be able to fetch newly signed zones 210 well before the data expires from your zone. 212 If a properly implemented slave server is not able to contact a 213 master server for an extended period the data will at some 214 point expire and the slave server will not hand out any data. 215 If the server serves a DNSSEC zone than it may well happen that 216 the signatures expire well before the SOA expiration timer 217 counted down to zero. It is not possible to fully prevent this 218 from happening by tweaking the SOA parameters. But the effects 219 can be minimized if the SOA expiration time is of the same of 220 order of magnitude as or smaller than the signature validity 221 period. 223 When a zone cannot be updated while signatures in that zone 224 have expired non-secure resolvers will continue to be able to 225 resolve the data served by the particular slave servers. Only 226 security aware resolvers that receive data with expired 227 signatures will experience problems. 229 We suggest the SOA expiration timer being approximately one 230 third or one fourth of the signature validity period. 232 We also suggest that operators of nameservers with slave zones 233 develop watchdogs to be able to spot these upcoming signature 234 expirations in slave zones, so that appropriate action can be 235 taken. 237 o [Editor's Note: Need examples here] 239 3. Keys 241 3.1 Motivations for the KSK and ZSK functions 243 Delegation Signer [7] introduced the concept of key-signing and 244 zone-signing keys.The Key-signing-flag [4] introduced the concept of 245 a key with the Secure Entry Point flag set; a key that is the first 246 key from the zone when following an authentication chain. When using 247 a key-signing key with the SEP flag set (the parent has a DS RR 248 pointing to that DNSKEY) and when using zone-signing keys without the 249 SEP flag set (a practice which we recommend ) one can use the 250 following operational procedures. 252 The zone-signing key can be used to sign all the data in a zone on a 253 regular basis. When a zone-signing key is to be rolled over no 254 interactions with the parent is needed. This allows for relatively 255 short "Signature Validity Periods" (order of days). 257 The key-signing key (with the SEP flag set) is only to be used to 258 sign the Key RR set from the zone apex. If a key-signing key is to be 259 rolled over, there will be interactions with parties other than the 260 zone maintainer such as the registry of the parent zone or 261 administrators of verifying resolvers that have the particular key 262 configured as trusted entry points. Hence, the "Key Usage Time" of 263 these keys can and should be made much longer. Although, given a long 264 enough key, the "Key Usage Time" can be on the order of years we 265 suggest to plan for a "Key Usage Time" of the order of a few months 266 so that a key rollover remains an operational routine. 268 3.2 Key security considerations 270 In RFC2541 [2] a number of considerations with respect to the 271 security of keys are described. That document deals with the 272 generation, lifetime, size and storage of private keys. 274 In Section 3 of RFC2541 [2], Eastlake does have some suggestions: 13 275 months for long-lived keys and 36 days for transaction keys but 276 suggestions for key sizes are not made. 278 If we read the long-lived key being a key that is used as key-signing 279 key and transaction keys being zone signing keys, then these 280 recommendations are good starting points for an operational 281 procedure. These recommendations will lead to rollovers occurring 282 frequently enough so that they can become part of 'operational 283 habits' and the procedure does not have to be reinvented every time a 284 key is replaced. 286 When choosing a key sizes, zone administrators will need to take into 287 account how long a key will be used and how much data will be signed 288 during the key publication period. It is hard to give precise 289 recommendations but Lenstra and Verheul [9] supplied the following 290 table with lower bound estimates for cryptographic key sizes. Their 291 recommendations are based on a set of explicitly formulated parameter 292 settings, combined with existing data points about cryptosystems. For 293 details we refer to the original paper. 295 Year RSA key sizes Elliptic Curve Key Size 296 2000 952 132 297 2001 990 135 298 2002 1028 139 299 2003 1068 140 300 2004 1108 143 302 2005 1149 147 303 2006 1191 148 304 2007 1235 152 305 2008 1279 155 306 2009 1323 157 308 2010 1369 160 309 2011 1416 163 310 2012 1464 165 311 2013 1513 168 312 2014 1562 172 314 2015 1613 173 315 2016 1664 177 316 2017 1717 180 317 2018 1771 181 318 2019 1825 185 320 2020 1881 188 321 2021 1937 190 322 2022 1995 193 323 2023 2054 197 324 2024 2113 198 326 2025 2174 202 327 2026 2236 205 328 2027 2299 207 329 2028 2362 210 330 2029 2427 213 332 Suppose you want your key to last 3 years and the current year is 333 2003. Add 3 to 2003 equals 2006 and read of the sizes: 1191 for 334 asymmetric keys and 148 bits for elliptic curve keys. 336 Note that adding only a "handful of bits" to the key size will 337 increase the key's resistance against brute force attacks. 339 3.3 Key rollovers 341 Key rollovers are a fact of life when using DNSSEC. A DNSSEC key 342 cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone 343 maintainers who are in the process of rolling their keys have to take 344 into account that data they have published in previous versions of 345 their zone still lives in caches. When deploying DNSSEC this becomes 346 an important consideration; ignoring data that may be in caches may 347 lead to loss of service for clients. 349 The most pressing example of this is when zone material which is 350 signed with an old key is being validated by a resolver which does 351 not have the old zone key cached. If the old key is no longer present 352 in the current zone, this validation fails, marking the data BAD. 353 Alternatively, an attempt could be made to validate data which is 354 signed with a new key against an old key that lives in a local cache, 355 also resulting in data being marked BAD. 357 To appreciate the situation one could think of a number of 358 authoritative servers that may not be instantaneously running the 359 same version of a zone and a security aware non-recursive resolver 360 that sits behind security aware caching forwarders. 362 Note that KSK rollovers and ZSK rollovers are different. A zone-key 363 rollover can be handled in two different way: pre-publish and 364 [Editors note: ref please] double-sig. The pre-publish technique 365 works because the key-signing key stays the same during this ZSK 366 rollover. With this KSK a cache is able to validate the new keyset of 367 a zone. With a KSK rollover a cache can not validate the new keyset, 368 because it does not trust the new KSK. 370 [Editors note: This needs more verbose explanation, nobody will 371 appreciate the situation just yet. Help with text and examples is 372 appreciated] 374 3.3.1 Zone-signing key rollovers 376 For zone-signing key rollovers there are two ways to make sure that 377 during the rollover the data still in caches can be verified with the 378 new keysets or the newly generated signatures can be verified with 379 the keys still in caches. One schema uses double signatures, it is 380 described in Section 3.3.1.1, the other uses key pre-publication 381 (Section 3.3.1.2). The pros, cons and recommendations are described 382 in Section 3.3.1.3. 384 3.3.1.1 A double signature zone-signing key rollover 386 This section shows how to perform a ZSK key rollover using the double 387 zone data signature scheme. 389 During the rollover stage the new version of the zone file will need 390 to propagate to all authoritative servers and the data that exists in 391 (distant) caches will need to expire, this will take at least the 392 maximum Zone TTL . 394 normal roll after 396 SOA0 SOA1 SOA2 397 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) 398 RRSIG11(SOA1) 400 DNSKEY1 DNSKEY1 DNSKEY1 401 DNSKEY10 DNSKEY10 DNSKEY11 402 DNSKEY11 403 RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 404 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) 405 RRSIG11(DNSKEY) 407 normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY 408 10 is used to sign all the data of the zone, it is the 409 zone-signing key. 411 roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced 412 into the keyset and all the data in the zone is signed with DNSKEY 413 10 and DNSKEY 11. The rollover period will need to exist until all 414 data from version 0 of the zone has expired from remote caches. 415 This will take at least the Maximum Zone TTL of the version 0 of 416 the zone. 418 after: DNSKEY 10 is removed from the zone. All the signatures from 419 DNSKEY 10 are removed from the zone. The keyset, now only 420 containing DNSKEY 11 is resigned with the DNSKEY 1. 422 At every instance the data from the previous version of the zone can 423 be verified with the key from the current version. And vice verse, 424 the data from the current version can be verified with the data from 425 the previous version of the zone. The duration of the rollover phase 426 and the period between rollovers should be at least the "Maximum Zone 427 TTL". 429 To be on the safe side one could make sure that the rollover phase 430 lasts until the signature expiration time of the data in version 0 of 431 the zone. But this date could be considerable longer than the Maximum 432 Zone TTL, making the rollover a lengthly procedure. 434 Note that in this example we assumed that the zone did not get 435 modified during the rollover. New data can be introduced in the zone 436 as long as it is signed with both keys. 438 3.3.1.2 Pre-publish keyset rollover 440 This section shows how to perform a ZSK rollover without the need to 441 sign all the data in a zone twice. We recommend this method because 442 it has advantages in the case of key compromises. If the old key gets 443 compromised the new key is already distributed in the DNS. The zone 444 administrator is then able to quickly switch to the new key and 445 remove the compromised key from the zone. Another major advantage is 446 that the zone size does not double, as is the case with the double 447 signature ZSK rollover. A small "HOWTO" for this kind of rollover can 448 be found in Appendix B. 450 normal pre-roll roll after 452 SOA0 SOA1 SOA2 SOA3 453 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) 454 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 455 DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 456 DNSKEY11 DNSKEY11 457 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) 458 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) 460 normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY 461 10 is used to sign all the data of the zone, its the zone-signing 462 key. 464 pre-roll: DNSKEY 11 is introduced in the keyset. Note that no 465 signatures are generated with this key yet, but this will not 466 prevent brute force attacks on the public key. The minimum 467 duration of this pre-roll phase is the time it takes for the data 468 to propagate to the authoritative servers plus TTL value on the 469 keyset. This would boil down to two times the Maximum Zone TTL. 471 roll: 473 At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign the 474 data in the zone (exclusively i.e. all the signatures from DNSKEY 475 10 are removed from the zone.). DNSKEY 10 remains published in the 476 keyset. This way data that was loaded into caches from version 1 477 of the zone can still be verified with key sets fetched from 478 version 2 of the zone. 480 The minimum time that the keyset that includes DNSKEY 10 is to be 481 published is the time that it takes for zone data from the 482 previous version of the zone to expire from old caches i.e. the 483 time it takes for this zone to propagate to all authoritative 484 servers plus the Maximum Zone TTL value of any of the data in the 485 previous version of the zone. 487 after: DNSKEY 10 is removed from the zone. The keyset, now only 488 containing DNSKEY 11 is resigned with the DNSKEY 1. 490 The above scheme can be simplified a bit by always publishing the 491 "future" key immediately after the rollover. The scheme would look 492 like this (we show 2 rollovers); the future key is introduced in 493 "after" as DNSKEY 12 and again a newer one, numbered 13, in "2nd 494 after": 496 normal roll after 2nd roll 2nd after 498 SOA0 SOA2 SOA3 SOA4 SOA5 499 RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5) 500 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 501 DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12 502 DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13 503 RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) 504 RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY) 506 Note that the key introduced after the rollover is not used for 507 production yet; the private key can thus be stored in a physically 508 secure manner and does not need to be 'fetched' every time a zone 509 needs to be signed. 511 This scheme has the benefit that the key that is intended for future 512 use, can immediately be used during an emergency rollover under the 513 assumption that it was stored in a physically secure manner. 515 3.3.1.3 Pros and cons of the schemes 517 A double signature rollover: The drawback of this signing scheme is 518 that during the rollover the number of signatures in your zone 519 doubles, which may be prohibitive if you have very big zones. An 520 advantage is that it only requires three steps. 522 Prepublish-keyset rollover: This rollover does not involve signing 523 the zone data twice. Instead, just before the actual rollover the 524 new key is published in the keyset and thus available for 525 cryptanalysis attacks. A small disavantage is that this process 526 requires four steps. Also the prepublish scheme is useless for 527 KSKs as explained in Section 3.3. 529 3.3.2 Key-signing key rollovers 531 For the rollover of a key-signing key the same considerations as for 532 the rollover of a zone-signing key apply. However we can use a double 533 signature scheme to guarantee that old data (only the apex keyset) in 534 caches can be verified with a new keyset and vice versa. Since only 535 the keyset is signed with a KSK, size considerations do not apply. 537 normal roll after 539 SOA0 SOA1 SOA2 540 RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) 542 DNSKEY1 DNSKEY1 DNSKEY2 543 DNSKEY2 544 DNSKEY10 DNSKEY10 DNSKEY10 545 RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) 546 RRSIG2 (DNSKEY) 547 RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) 549 4. Planning for emergency key rollover. 551 This section deals with preparation for a possible key compromise. 552 Our advice is to have a documented procedure ready for when a key 553 compromise is suspected or confirmed. 555 [Editors note: We are much in favor of a rollover tactic that keeps 556 the authentication chain intact as long as possible. This has as a 557 result that one has to take all the regular rollover properties into 558 account.] 560 When the private material of one of your keys is compromised it can 561 be used by 'blackhats' for as long as a valid authentication chain 562 exists. A authentication chain remains intact for: 564 as long as a signature over the compromised key in the 565 authentication chain is valid, 567 as long as a parental DS RR (and signature) points to the 568 compromised key, 570 as long as the key is anchored in a resolver and is used as a 571 starting point for validation. (This is the hardest to update.) 573 While an authentication chain to your compromised key exists your 574 name-space is vulnerable to abuse by the "blackhat". Zone operators 575 have to make a trade off if the abuse of the compromised key is worse 576 than having data in caches that cannot be validated. If the zone 577 operator chooses to break the authentication chain to the compromised 578 key, data in caches signed with this key can not be validated. On the 579 other hand if the zone administrator chooses to take the path of a 580 regular roll-over the "blackhat" can spoof data so that it appears to 581 be valid, note that this kind of attack will usually be localized in 582 the Internet topology. 584 4.1 KSK compromise 586 When the KSK has been compromised the parent must be notified as soon 587 as possible and through secure means. The keyset of the zone should 588 be resigned as soon as possible. Care must be taken to not break the 589 authentication chain. The local zone can only be resigned with the 590 new KSK after the parent's zone has been updated with the new KSK. 592 Before this update takes place it would be best to drop the security 593 status of a zone all together: the parent removes the DS of the child 594 at the next zone update. After that the child can be made secure 595 again. An additional danger of a key compromise is that the 596 compromised key can be used to facilitate a legitemate DNSKEY/DS and/ 597 or nameserver rollover at the parent. When that happens the domain 598 can be in dispute. An out of band and secure notify mechanism to 599 contact a parent is needed in this case. 601 4.2 ZSK compromise 603 Mainly because there is no parental interaction required when a ZSK 604 is compromised the situation is less severe than with with a KSK 605 compromise. The zone must still be resigned with a new ZSK as soon 606 as possible. As this is a local operation and requires no 607 communication between the parent and child this can be achieved 608 fairly quickly. One has to take into account though that just as with 609 a normal rollover the immediate disappearance from the old 610 compromised key may lead to verification problems. The 611 pre-publication scheme as discussed above minimizes that problem. 613 4.3 Compromises of keys anchored in resolvers 615 A key can also be pre-configured in resolvers. If DNSSEC is rolled 616 out as planned the root key should be pre-configured in every secure 617 aware resolver on the planet. [Editors Note: add more about 618 authentication of a newly received resolver key] 620 If that key is compromised all the resolvers should be notified of 621 this fact. Zone administrators may consider setting up a mailing list 622 to communicate the fact that a SEP key is about to be rolled over. 623 This communication will of course need to be authenticated e.g. by 624 using digital signatures. 626 5. Parental policies. 628 5.1 Initial key exchanges and parental policies considerations. 630 The initial key exchange is always subject to the policies set by the 631 parent (or its registry). When designing a key exchange policy one 632 should take into account that the authentication and authorization 633 mechanisms used during a key exchange should be as strong as the 634 authentication and authorization mechanisms used for the exchange of 635 delegation information between parent and child. 637 Using the DNS itself as the source for the actual DNSKEY material 638 with an off-band check on the validity of the DNSKEY has the benefit 639 that it reduces the changes of operator error. A parental DNSKEY 640 download tool can make use of the SEP bit [4] to select the proper 641 key from a DNSSEC keyset; thereby reducing the change that the wrong 642 DNSKEY is sent. It can validate the self-signature over a key; 643 thereby verifying the ownership of the private key material. Besides, 644 by fetching the DNSKEY from the DNS one can be sure that the child 645 will not become invisible once the parent indicates the child is 646 secure by publishing the DS RR. 648 Note: the off-band verification is still needed when the keymaterial 649 is fetched by a tool. The parent can not be sure if the DNSKEY RRs 650 where not spoofed. 652 5.2 Storing keys so hashes can be regenerated 654 When designing a registry system one should consider if the DNSKEYs 655 or the corresponding DSs are stored. Storing DNSKEYs will help during 656 troubleshooting while the overhead of calculating DS records from 657 them is minimal. 659 Having a out-of-band mechanism, such as a WHOIS database, to find out 660 which keys are used to generate DS Resource Records for specific 661 owners may also help with troubleshooting. 663 5.3 Security lameness checks. 665 Security lameness is defined as the event that a parent has a DS 666 Resource Record that points to a non-existing DNSKEY RR. At key 667 exchange a parent should make sure that the childs key is actually 668 configured in the DNS before publishing a DS RR in its zone. Failure 669 to do so would render the child's zone marked "BAD". 671 Child zones should be very careful removing DNSKEY material, 672 specifically SEP keys, for which a DS RR exist. 674 Once a zone is "security lame" a fix (e.g. by removing a DS RR) will 675 take time to propagate through the DNS. 677 5.4 SIG DS validity period. 679 Since the DS can be replayed as long as it has a valid signature a 680 short signature validity period over the DS minimizes the time a 681 child is vulnerable in the case of a compromise of the child's KSK. 682 A signature validity period that is too short introduces the 683 possibility that a zone is marked BAD in case of a configuration 684 error in the signer; there may not be enough time to fix the problems 685 before signatures expire. Something as mundane as weekends show the 686 need for a DS signature lifetimes longer than 2 days. We recommend 687 the minimum for a DS signature validity period to be about a few 688 days. 690 The maximum signature lifetime of the DS record depends on how long 691 child zones are willing to be vulnerable after a key compromise. We 692 consider a signature validity period of the order of one week a good 693 compromise between the operational constraints of the parent and 694 minimizing damage for the child. 696 6. Security considerations 698 DNSSEC adds data integrity to the DNS. This document tries to assess 699 considerations to operate a stable and secure DNSSEC service. 701 7. Acknowledgments 703 We, the folk mentioned as authors, only acted as editors. Most of the 704 ideas in this draft where the result of collective efforts during 705 workshops and discussions and try outs. 707 At the risk of forgetting individuals who where the original 708 contributors of the ideas we like to acknowledge people who where 709 actively involved in the compilation of this document. In 710 alphabetical order: Olafur Gudmundsson, Wesley Griffin, Michael 711 Richardson, Scott Rose, Rick van Rein, Tim McGinnis. 713 Kolkman and Gieben take the blame for all mistakes. 715 Normative References 717 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 718 2535, March 1999. 720 [2] Eastlake, D., "DNS Security Operational Considerations", RFC 721 2541, March 1999. 723 [3] Lewis, E., "DNS Security Extension Clarification on Zone 724 Status", RFC 3090, March 2001. 726 [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key 727 (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work 728 in progress), February 2003. 730 Informative References 732 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 733 Levels", BCP 14, RFC 2119, March 1997. 735 [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 736 2308, March 1998. 738 [7] Gudmundsson, O., "Delegation Signer Resource Record", 739 draft-ietf-dnsext-delegation-signer-13 (work in progress), March 740 2003. 742 [8] Arends, R., "Protocol Modifications for the DNS Security 743 Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in 744 progress), March 2003. 746 [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", 747 The Journal of Cryptology 14 (255-293), 2001. 749 Authors' Addresses 751 Olaf M. Kolkman 752 RIPE NCC 753 Singel 256 754 Amsterdam 1016 AB 755 NL 757 Phone: +31 20 535 4444 758 EMail: olaf@ripe.net 759 URI: http://www.ripe.net/ 761 Miek Gieben 762 NLnet Labs 763 Kruislaan 419 764 Amsterdam 1098 VA 765 NL 767 EMail: miek@nlnetlabs.nl 768 URI: http://www.nlnetlabs.nl 770 Appendix A. Terminology 772 In this document there is some jargon used that is defined in other 773 documents. In most cases we have not copied the text from the 774 documents defining the terms but give a more elaborate explanation of 775 the meaning. Note that these explanations should not be seen as 776 authoritative. 778 Private and Public Keys: DNSSEC secures the DNS through the use of 779 public key cryptography. Public key cryptography is based on the 780 existence of 2 keys, a public key and a private key. The public 781 keys are published in the DNS by use of the DNSKEY Resource Record 782 (DNSKEY RR). Private keys are supposed to remain private i.e. 783 should not be exposed to parties not-authorized to do the actual 784 signing. 786 Signer: The system that has access to the private key material and 787 signs the Resource Record sets in a zone. A signer may be 788 configured to sign only parts of the zone e.g. only those RRsets 789 for which existing signatures are about to expire. 791 KSK: A Key-Signing key (KSK) is a key that is used for exclusively 792 signing the apex keyset. The fact that a key is a KSK is only 793 relevant to the signing tool. 795 ZSK: A Zone signing key (ZSK) is a key that is used for signing all 796 data in a zone. The fact that a key is a ZSK is only relevant to 797 the signing tool. 799 BAD: [Editors Note: a reference here] A RRset in DNSSEC is marked 800 "bad" when a signature of a RRset does not validate against the 801 DNSKEY. Even is the key itself was not marked BAD. BAD data is not 802 cached. 804 Singing the Zone File: The term used for the event where an 805 administrator joyfully signs its zone file while producing melodic 806 sound patterns. 808 Appendix B. Zone-signing key rollover howto 810 Using the pre-published signature scheme and the most conservative 811 method to assure oneself that data does not live in distant caches 812 here follows the "HOWTO". [WES: has some comments about this] 814 STEP 0, the preparation: Create two keys and publish them both in 815 your keyset. Mark one of the keys as "active" and the other as 816 "published". Use the "active" key for signing your zone data. 817 Store the private part of the "published" key, preferably 818 off-line. 820 STEP 1, determine expiration: At the beginning of the rollover: 821 make a note of the highest expiration time of signatures in your 822 zonefile created with the current key currently marked as 823 "active". 825 Wait until the expiration time marked in STEP 1 826 STEP 2 Then start using the key that was marked as "published" to 827 sign your data i.e. mark it as "active". Stop using the key that 828 was marked as "active", mark it as "rolled". 830 STEP 3: It is safe to engage in a new rollover (STEP 1) after at 831 least one "signature validity period". 833 Appendix C. Typographic conventions 835 The following typographic conventions are used in this document: 837 Key notation: A key is denoted by KEYx, where x is a number, x could 838 be thought of as the key id. 840 RRset notations: RRs are only denoted by the type all other 841 information, owner, class, rdata and TTL is left out. Thus: 842 example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a 843 list of RRs. A example of this would be: A1,A2, specifying the 844 RRset containing two A records. This could again be abreviated to 845 just: A. 847 Signature notation: Signatures are denoted as SIGx(RRset), which 848 means that RRset is signed with KEYx. 850 Zone representation: Using the above notation we have simplify the 851 representation of a signed zone by leaving out all unneeded 852 details such as the names and by just representing all data by 853 "SOAx" 855 SOA representation: Soa's are represented as SOA x, where x is the 856 serial number. 858 Using this notation the following zone : 860 example.net. 600 IN SOA ns.example.net. ernie.example.net. ( 861 10 ; serial 862 450 ; refresh (7 minutes 30 seconds) 863 600 ; retry (10 minutes) 864 345600 ; expire (4 days) 865 300 ; minimum (5 minutes) 866 ) 867 600 RRSIG SOA 5 2 600 20130522213204 ( 868 20130422213204 14 example.net. 869 cmL62SI6iAX46xGNQAdQ... ) 870 600 NS a.iana-servers.net. 871 600 NS b.iana-servers.net. 873 600 RRSIG NS 5 2 600 20130507213204 ( 874 20130407213204 14 example.net. 875 SO5epiJei19AjXoUpFnQ ... ) 876 3600 DNSKEY 256 3 5 ( 877 EtRB9MP5/AvOuVO0I8XDxy0... 878 ) ; key id = 14 879 3600 DNSKEY 256 3 5 ( 880 gsPW/Yy19GzYIY+Gnr8HABU... 881 ) ; key id = 15 882 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 883 20130422213204 14 example.net. 884 J4zCe8QX4tXVGjV4e1r9... ) 885 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( 886 20130422213204 15 example.net. 887 keVDCOpsSeDReyV6O... ) 888 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC 889 600 RRSIG NSEC 5 2 600 20130507213204 ( 890 20130407213204 14 example.net. 891 obj3HEp1GjnmhRjX... ) 892 a.example.net. 600 IN TXT "A label" 893 600 RRSIG TXT 5 3 600 20130507213204 ( 894 20130407213204 14 example.net. 895 IkDMlRdYLmXH7QJnuF3v... ) 896 600 NSEC b.example.com. TXT RRSIG NSEC 897 600 RRSIG NSEC 5 3 600 20130507213204 ( 898 20130407213204 14 example.net. 899 bZMjoZ3bHjnEz0nIsPMM... ) 901 ... 903 is reduced to the following represenation: 905 SOA10 906 RRSIG14(SOA10) 908 DNSKEY14 909 DNSKEY15 911 RRSIG14(KEY) 912 RRSIG15(KEY) 914 The rest of the zone data has the same signature as the SOA record, 915 i.e a RRSIG created with DNSKEY 14. 917 Appendix D. Document Details and Changes 919 This section is to be removed by the RFC editor if and when the 920 document is published. 922 $Header: /var/cvs/dnssec-key/ 923 draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.5 2003/10/10 924 09:49:07 dnssec Exp $ 926 D.1 draft-ietf-dnsop-dnssec-operational-practices-00 928 Submission as working group document. This document is a modified and 929 updated version of draft-kolkman-dnssec-operational-practices-00. 931 Intellectual Property Statement 933 The IETF takes no position regarding the validity or scope of any 934 intellectual property or other rights that might be claimed to 935 pertain to the implementation or use of the technology described in 936 this document or the extent to which any license under such rights 937 might or might not be available; neither does it represent that it 938 has made any effort to identify any such rights. Information on the 939 IETF's procedures with respect to rights in standards-track and 940 standards-related documentation can be found in BCP-11. Copies of 941 claims of rights made available for publication and any assurances of 942 licenses to be made available, or the result of an attempt made to 943 obtain a general license or permission for the use of such 944 proprietary rights by implementors or users of this specification can 945 be obtained from the IETF Secretariat. 947 The IETF invites any interested party to bring to its attention any 948 copyrights, patents or patent applications, or other proprietary 949 rights which may cover technology that may be required to practice 950 this standard. Please address the information to the IETF Executive 951 Director. 953 Full Copyright Statement 955 Copyright (C) The Internet Society (2003). All Rights Reserved. 957 This document and translations of it may be copied and furnished to 958 others, and derivative works that comment on or otherwise explain it 959 or assist in its implementation may be prepared, copied, published 960 and distributed, in whole or in part, without restriction of any 961 kind, provided that the above copyright notice and this paragraph are 962 included on all such copies and derivative works. However, this 963 document itself may not be modified in any way, such as by removing 964 the copyright notice or references to the Internet Society or other 965 Internet organizations, except as needed for the purpose of 966 developing Internet standards in which case the procedures for 967 copyrights defined in the Internet Standards process must be 968 followed, or as required to translate it into languages other than 969 English. 971 The limited permissions granted above are perpetual and will not be 972 revoked by the Internet Society or its successors or assignees. 974 This document and the information contained herein is provided on an 975 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 976 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 977 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 978 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 979 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 981 Acknowledgment 983 Funding for the RFC Editor function is currently provided by the 984 Internet Society.