idnits 2.17.1 draft-ietf-dnsext-trustupdate-timers-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 600. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 14, 2006) is 6465 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. StJohns 3 Internet-Draft Nominum, Inc. 4 Intended status: Informational August 14, 2006 5 Expires: February 15, 2007 7 Automated Updates of DNSSEC Trust Anchors 8 draft-ietf-dnsext-trustupdate-timers-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 15, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes a means for automated, authenticated and 42 authorized updating of DNSSEC "trust anchors". The method provides 43 protection against single key compromise of a key in the trust point 44 key set. Based on the trust established by the presence of a current 45 anchor, other anchors may be added at the same place in the 46 hierarchy, and, ultimately, supplant the existing anchor. 48 This mechanism will require changes to resolver management behavior 49 (but not resolver resolution behavior), and the addition of a single 50 flag bit to the DNSKEY record. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 56 1.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 4 57 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 6 61 2.4. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 62 2.5. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 63 2.5.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 64 2.5.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 7 65 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 7 66 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 7 67 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 9 71 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9 72 6.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 10 73 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 10 74 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 75 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 76 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 11 77 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 11 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 81 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 12 82 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 12 83 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 84 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 Intellectual Property and Copyright Statements . . . . . . . . . . 14 88 1. Introduction 90 As part of the reality of fielding DNSSEC (Domain Name System 91 Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the 92 community has come to the realization that there will not be one 93 signed name space, but rather islands of signed name space each 94 originating from specific points (i.e. 'trust points') in the DNS 95 tree. Each of those islands will be identified by the trust point 96 name, and validated by at least one associated public key. For the 97 purpose of this document we'll call the association of that name and 98 a particular key a 'trust anchor'. A particular trust point can have 99 more than one key designated as a trust anchor. 101 For a DNSSEC-aware resolver to validate information in a DNSSEC 102 protected branch of the hierarchy, it must have knowledge of a trust 103 anchor applicable to that branch. It may also have more than one 104 trust anchor for any given trust point. Under current rules, a chain 105 of trust for DNSSEC-protected data that chains its way back to ANY 106 known trust anchor is considered 'secure'. 108 Because of the probable balkanization of the DNSSEC tree due to 109 signing voids at key locations, a resolver may need to know literally 110 thousands of trust anchors to perform its duties. (e.g. Consider an 111 unsigned ".COM".) Requiring the owner of the resolver to manually 112 manage this many relationships is problematic. It's even more 113 problematic when considering the eventual requirement for key 114 replacement/update for a given trust anchor. The mechanism described 115 herein won't help with the initial configuration of the trust anchors 116 in the resolvers, but should make trust point key replacement/ 117 rollover more viable. 119 As mentioned above, this document describes a mechanism whereby a 120 resolver can update the trust anchors for a given trust point, mainly 121 without human intervention at the resolver. There are some corner 122 cases discussed (e.g. multiple key compromise) that may require 123 manual intervention, but they should be few and far between. This 124 document DOES NOT discuss the general problem of the initial 125 configuration of trust anchors for the resolver. 127 1.1. Compliance Nomenclature 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in BCP 14, [RFC2119]. 133 1.2. Changes since -00 135 N.B. This section to be deleted prior to submission to RFC editor. 137 Added the concept of timer triggered resolver queries to refresh the 138 resolvers view of the trust anchor key RRSet. 140 Re-submitted expired draft as -01. Updated DNSSEC RFC References. 142 Draft -02. Added the IANA Considerations section. Added text to 143 describe what happens if all trust anchors at a trust point are 144 deleted. 146 Draft -03. Revised the trust point deletion language to note 147 limitations. 149 Draft -04. Restructured section 4.3 (Trust point deletion) and 5 150 (Scenarios). Section 4.3 is now section 5. Section 5 is now section 151 6 and "Informative" 153 2. Theory of Operation 155 The general concept of this mechanism is that existing trust anchors 156 can be used to authenticate new trust anchors at the same point in 157 the DNS hierarchy. When a new SEP key (see [RFC4034] section 2.1.1) 158 is added to a trust point DNSKEY RRSet, and when that RRSet is 159 validated by an existing trust anchor, then the new key can be added 160 to the set of trust anchors. 162 There are some issues with this approach which need to be mitigated. 163 For example, a compromise of one of the existing keys could allow an 164 attacker to add their own 'valid' data. This implies a need for a 165 method to revoke an existing key regardless of whether or not that 166 key is compromised. As another example assuming a single key 167 compromise, an attacker could add a new key and revoke all the other 168 old keys. 170 2.1. Revocation 172 Assume two trust anchor keys A and B. Assume that B has been 173 compromised. Without a specific revocation bit, B could invalidate A 174 simply by sending out a signed trust point key set which didn't 175 contain A. To fix this, we add a mechanism which requires knowledge 176 of the private key of a DNSKEY to revoke that DNSKEY. 178 A key is considered revoked when the resolver sees the key in a self- 179 signed RRSet and the key has the REVOKE bit (see Section 7 below) set 180 to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this 181 key as a trust anchor or for any other purposes except validating the 182 RRSIG over the DNSKEY RRSet specifically for the purpose of 183 validating the revocation. Unlike the 'Add' operation below, 184 revocation is immediate and permanent upon receipt of a valid 185 revocation at the resolver. 187 A self-signed RRSet is a DNSKEY RRSet which contains the specific 188 DNSKey and for which there is a corresponding validated RRSIG record. 189 It's not a special DNSKEY RRSet, just a way of describing the 190 validation requirements for that RRSet. 192 N.B. A DNSKEY with the REVOKE bit set has a different fingerprint 193 than one without the bit set. This affects the matching of a DNSKEY 194 to DS records in the parent, or the fingerprint stored at a resolver 195 used to configure a trust point. 197 In the given example, the attacker could revoke B because it has 198 knowledge of B's private key, but could not revoke A. 200 2.2. Add Hold-Down 202 Assume two trust point keys A and B. Assume that B has been 203 compromised. An attacker could generate and add a new trust anchor 204 key - C (by adding C to the DNSKEY RRSet and signing it with B), and 205 then invalidate the compromised key. This would result in the both 206 the attacker and owner being able to sign data in the zone and have 207 it accepted as valid by resolvers. 209 To mitigate, but not completely solve, this problem, we add a hold- 210 down time to the addition of the trust anchor. When the resolver 211 sees a new SEP key in a validated trust point DNSKEY RRSet, the 212 resolver starts an acceptance timer, and remembers all the keys that 213 validated the RRSet. If the resolver ever sees the DNSKEY RRSet 214 without the new key but validly signed, it stops the acceptance 215 process and resets the acceptance timer. If all of the keys which 216 were originally used to validate this key are revoked prior to the 217 timer expiring, the resolver stops the acceptance process and resets 218 the timer. 220 Once the timer expires, the new key will be added as a trust anchor 221 the next time the validated RRSet with the new key is seen at the 222 resolver. The resolver MUST NOT treat the new key as a trust anchor 223 until the hold down time expires AND it has retrieved and validated a 224 DNSKEY RRSet after the hold down time which contains the new key. 226 N.B.: Once the resolver has accepted a key as a trust anchor, the key 227 MUST be considered a valid trust anchor by that resolver until 228 explictly revoked as described above. 230 In the given example, the zone owner can recover from a compromise by 231 revoking B and adding a new key D and signing the DNSKEY RRSet with 232 both A and B. 234 The reason this does not completely solve the problem has to do with 235 the distributed nature of DNS. The resolver only knows what it sees. 236 A determined attacker who holds one compromised key could keep a 237 single resolver from realizing that key had been compromised by 238 intercepting 'real' data from the originating zone and substituting 239 their own (e.g. using the example, signed only by B). This is no 240 worse than the current situation assuming a compromised key. 242 2.3. Remove Hold-down 244 A new key which has been seen by the resolver, but hasn't reached 245 it's add hold-down time, MAY be removed from the DNSKEY RRSet by the 246 zone owner. If the resolver sees a validated DNSKEY RRSet without 247 this key, it waits for the remove hold-down time and then, if the key 248 hasn't reappeared, SHOULD discard any information about the key. 250 2.4. Active Refresh 252 A resolver which has been configured for automatic update of keys 253 from a particular trust point MUST query that trust point (e.g. do a 254 lookup for the DNSKEY RRSet and related RRSIG records) no less often 255 than the lesser of 15 days or half the original TTL for the DNSKEY 256 RRSet or half the RRSIG expiration interval. The expiration interval 257 is the amount of time from when the RRSIG was last retrieved until 258 the expiration time in the RRSIG. 260 If the query fails, the resolver MUST repeat the query until 261 satisfied no more often than once an hour and no less often than the 262 lesser of 1 day or 10% of the original TTL or 10% of the original 263 expiration interval. 265 2.5. Resolver Parameters 267 2.5.1. Add Hold-Down Time 269 The add hold-down time is 30 days or the expiration time of the TTL 270 of the first trust point DNSKEY RRSet which contained the key, 271 whichever is greater. This ensures that at least two validated 272 DNSKEY RRSets which contain the new key MUST be seen by the resolver 273 prior to the key's acceptance. 275 2.5.2. Remove Hold-Down Time 277 The remove hold-down time is 30 days. 279 2.5.3. Minimum Trust Anchors per Trust Point 281 A compliant resolver MUST be able to manage at least five SEP keys 282 per trust point. 284 3. Changes to DNSKEY RDATA Wire Format 286 Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' 287 flag. If this bit is set to '1', AND the resolver sees an 288 RRSIG(DNSKEY) signed by the associated key, then the resolver MUST 289 consider this key permanently invalid for all purposes except for 290 validing the revocation. 292 4. State Table 294 The most important thing to understand is the resolver's view of any 295 key at a trust point. The following state table describes that view 296 at various points in the key's lifetime. The table is a normative 297 part of this specification. The initial state of the key is 'Start'. 298 The resolver's view of the state of the key changes as various events 299 occur. 301 This is the state of a trust point key as seen from the resolver. 302 The column on the left indicates the current state. The header at 303 the top shows the next state. The intersection of the two shows the 304 event that will cause the state to transition from the current state 305 to the next. 307 NEXT STATE 308 -------------------------------------------------- 309 FROM |Start |AddPend |Valid |Missing|Revoked|Removed| 310 ---------------------------------------------------------- 311 Start | |NewKey | | | | | 312 ---------------------------------------------------------- 313 AddPend |KeyRem | |AddTime| | | 314 ---------------------------------------------------------- 315 Valid | | | |KeyRem |Revbit | | 316 ---------------------------------------------------------- 317 Missing | | |KeyPres| |Revbit | | 318 ---------------------------------------------------------- 319 Revoked | | | | | |RemTime| 320 ---------------------------------------------------------- 321 Removed | | | | | | | 322 ---------------------------------------------------------- 324 State Table 326 4.1. Events 327 NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. 328 That key will become a new trust anchor for the named trust point 329 after its been present in the RRSet for at least 'add time'. 330 KeyPres The key has returned to the valid DNSKEY RRSet. 331 KeyRem The resolver sees a valid DNSKEY RRSet that does not contain 332 this key. 333 AddTime The key has been in every valid DNSKEY RRSet seen for at 334 least the 'add time'. 335 RemTime A revoked key has been missing from the trust point DNSKEY 336 RRSet for sufficient time to be removed from the trust set. 337 RevBit The key has appeared in the trust anchor DNSKEY RRSet with 338 its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet 339 signed by this key. 341 4.2. States 342 Start The key doesn't yet exist as a trust anchor at the resolver. 343 It may or may not exist at the zone server, but hasn't yet been 344 seen at the resolver. 345 AddPend The key has been seen at the resolver, has its 'SEP' bit 346 set, and has been included in a validated DNSKEY RRSet. There is 347 a hold-down time for the key before it can be used as a trust 348 anchor. 349 Valid The key has been seen at the resolver and has been included in 350 all validated DNSKEY RRSets from the time it was first seen up 351 through the hold-down time. It is now valid for verifying RRSets 352 that arrive after the hold down time. Clarification: The DNSKEY 353 RRSet does not need to be continuously present at the resolver 354 (e.g. its TTL might expire). If the RRSet is seen, and is 355 validated (i.e. verifies against an existing trust anchor), this 356 key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. 357 Missing This is an abnormal state. The key remains as a valid trust 358 point key, but was not seen at the resolver in the last validated 359 DNSKEY RRSet. This is an abnormal state because the zone operator 360 should be using the REVOKE bit prior to removal. [Discussion 361 item: Should a missing key be considered revoked after some period 362 of time?] 363 Revoked This is the state a key moves to once the resolver sees an 364 RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains 365 this key with its REVOKE bit set to '1'. Once in this state, this 366 key MUST permanently be considered invalid as a trust anchor. 367 Removed After a fairly long hold-down time, information about this 368 key may be purged from the resolver. A key in the removed state 369 MUST NOT be considered a valid trust anchor. 371 5. Trust Point Deletion 373 A trust point which has all of its trust anchors revoked is 374 considered deleted and is treated as if the trust point was never 375 configured. If there are no superior configured trust points, data 376 at and below the deleted trust point are considered insecure by the 377 resolver. If there ARE superior configured trust points, data at and 378 below the deleted trust point are evaluated with respect to the 379 superior trust point. 381 Alternately, a trust point which is subordinate to another configured 382 trust point MAY be deleted by a resolver after 180 days where such 383 trust point validly chains to a superior trust point. The decision 384 to delete the subordinate trust anchor is a local configuration 385 decision. Once the subordinate trust point is deleted, validation of 386 the subordinate zone is dependent on validating the chain of trust to 387 the superior trust point. 389 6. Scenarios - Informative 391 The suggested model for operation is to have one active key and one 392 stand-by key at each trust point. The active key will be used to 393 sign the DNSKEY RRSet. The stand-by key will not normally sign this 394 RRSet, but the resolver will accept it as a trust anchor if/when it 395 sees the signature on the trust point DNSKEY RRSet. 397 Since the stand-by key is not in active signing use, the associated 398 private key may (and should) be provided with additional protections 399 not normally available to a key that must be used frequently. E.g. 400 locked in a safe, split among many parties, etc. Notionally, the 401 stand-by key should be less subject to compromise than an active key, 402 but that will be dependent on operational concerns not addressed 403 here. 405 6.1. Adding A Trust Anchor 407 Assume an existing trust anchor key 'A'. 408 1. Generate a new key pair. 409 2. Create a DNSKEY record from the key pair and set the SEP and Zone 410 Key bits. 411 3. Add the DNSKEY to the RRSet. 412 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 413 'A'. 414 5. Wait a while. 415 6. The new trust anchor will be populated at the resolvers on the 416 schedule described by the state table and update algorithm - see 417 Section 2 above 419 6.2. Deleting a Trust Anchor 421 Assume existing trust anchors 'A' and 'B' and that you want to revoke 422 and delete 'A'. 423 1. Set the revolcation bit on key 'A'. 424 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 425 'A' is now revoked. The operator SHOULD include the revoked 'A' in 426 the RRSet for at least the remove hold-down time, but then may remove 427 it from the DNSKEY RRSet. 429 6.3. Key Roll-Over 431 Assume existing keys A and B. 'A' is actively in use (i.e. has been 432 signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been 433 in the DNSKEY RRSet and is a valid trust anchor, but wasn't being 434 used to sign the RRSet.) 435 1. Generate a new key pair 'C'. 436 2. Add 'C' to the DNSKEY RRSet. 437 3. Set the revocation bit on key 'A'. 438 4. Sign the RRSet with 'A' and 'B'. 439 'A' is now revoked, 'B' is now the active key, and 'C' will be the 440 stand-by key once the hold-down expires. The operator SHOULD include 441 the revoked 'A' in the RRSet for at least the remove hold-down time, 442 but may then remove it from the DNSKEY RRSet. 444 6.4. Active Key Compromised 446 This is the same as the mechanism for Key Roll-Over (Section 6.3) 447 above assuming 'A' is the active key. 449 6.5. Stand-by Key Compromised 451 Using the same assumptions and naming conventions as Key Roll-Over 452 (Section 6.3) above: 453 1. Generate a new key pair 'C'. 454 2. Add 'C' to the DNSKEY RRSet. 455 3. Set the revocation bit on key 'B'. 456 4. Sign the RRSet with 'A' and 'B'. 457 'B' is now revoked, 'A' remains the active key, and 'C' will be the 458 stand-by key once the hold-down expires. 'B' SHOULD continue to be 459 included in the RRSet for the remove hold-down time. 461 6.6. Trust Point Deletion 463 To delete a trust point which is subordinate to another configured 464 trust point (e.g. example.com to .com) requires some juggling of the 465 data. The specific process is: 466 1. Generate a new DNSKEY and DS record and provide the DS record to 467 the parent along with DS records for the old keys 468 2. Once the parent has published the DSs, add the new DNSKEY to the 469 RRSet and revoke ALL of the old keys at the same time while 470 signing the DNSKEY RRSet with all of the old and new keys. 471 3. After 30 days stop publishing the old, revoked keys and remove 472 any corresponding DS records in the parent. 473 Revoking the old trust point keys at the same time as adding new keys 474 that chain to a superior trust prevents the resolver from adding the 475 new keys as trust anchors. Adding DS records for the old keys avoids 476 a race condition where either the subordinate zone becomes unsecure 477 (because the trust point was deleted) or becomes bogus (because it 478 didn't chain to the superior zone). 480 7. IANA Considerations 482 The IANA will need to assign a bit in the DNSKEY flags field (see 483 section 4.3 of [RFC3755]) for the REVOKE bit. There are no other 484 IANA actions required. 486 8. Security Considerations 488 8.1. Key Ownership vs Acceptance Policy 490 The reader should note that, while the zone owner is responsible 491 creating and distributing keys, it's wholly the decision of the 492 resolver owner as to whether to accept such keys for the 493 authentication of the zone information. This implies the decision 494 update trust anchor keys based on trust for a current trust anchor 495 key is also the resolver owner's decision. 497 The resolver owner (and resolver implementers) MAY choose to permit 498 or prevent key status updates based on this mechanism for specific 499 trust points. If they choose to prevent the automated updates, they 500 will need to establish a mechanism for manual or other out-of-band 501 updates outside the scope of this document. 503 8.2. Multiple Key Compromise 505 This scheme permits recovery as long as at least one valid trust 506 anchor key remains uncompromised. E.g. if there are three keys, you 507 can recover if two of them are compromised. The zone owner should 508 determine their own level of comfort with respect to the number of 509 active valid trust anchors in a zone and should be prepared to 510 implement recovery procedures once they detect a compromise. A 511 manual or other out-of-band update of all resolvers will be required 512 if all trust anchor keys at a trust point are compromised. 514 8.3. Dynamic Updates 516 Allowing a resolver to update its trust anchor set based in-band key 517 information is potentially less secure than a manual process. 518 However, given the nature of the DNS, the number of resolvers that 519 would require update if a trust anchor key were compromised, and the 520 lack of a standard management framework for DNS, this approach is no 521 worse than the existing situation. 523 9. Normative References 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, March 1997. 528 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 529 RFC 2535, March 1999. 531 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 532 Signer (DS)", RFC 3755, May 2004. 534 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 535 Rose, "DNS Security Introduction and Requirements", 536 RFC 4033, March 2005. 538 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 539 Rose, "Resource Records for the DNS Security Extensions", 540 RFC 4034, March 2005. 542 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 543 Rose, "Protocol Modifications for the DNS Security 544 Extensions", RFC 4035, March 2005. 546 Editorial Comments 548 [msj2] msj: To be assigned. 550 Author's Address 552 Michael StJohns 553 Nominum, Inc. 554 2385 Bay Road 555 Redwood City, CA 94063 556 USA 558 Phone: +1-301-528-4729 559 Email: Mike.StJohns@nominum.com 560 URI: www.nominum.com 562 Full Copyright Statement 564 Copyright (C) The Internet Society (2006). 566 This document is subject to the rights, licenses and restrictions 567 contained in BCP 78, and except as set forth therein, the authors 568 retain all their rights. 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 573 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 574 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 575 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Intellectual Property 580 The IETF takes no position regarding the validity or scope of any 581 Intellectual Property Rights or other rights that might be claimed to 582 pertain to the implementation or use of the technology described in 583 this document or the extent to which any license under such rights 584 might or might not be available; nor does it represent that it has 585 made any independent effort to identify any such rights. Information 586 on the procedures with respect to rights in RFC documents can be 587 found in BCP 78 and BCP 79. 589 Copies of IPR disclosures made to the IETF Secretariat and any 590 assurances of licenses to be made available, or the result of an 591 attempt made to obtain a general license or permission for the use of 592 such proprietary rights by implementers or users of this 593 specification can be obtained from the IETF on-line IPR repository at 594 http://www.ietf.org/ipr. 596 The IETF invites any interested party to bring to its attention any 597 copyrights, patents or patent applications, or other proprietary 598 rights that may cover technology that may be required to implement 599 this standard. Please address the information to the IETF at 600 ietf-ipr@ietf.org. 602 Acknowledgment 604 Funding for the RFC Editor function is provided by the IETF 605 Administrative Support Activity (IASA).