idnits 2.17.1 draft-ietf-dnsext-trustupdate-timers-06.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 567. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 573. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (April 2, 2007) is 6205 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: 'RFC3755' is defined on line 513, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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 Independent 4 Expires: October 4, 2007 April 2, 2007 6 Automated Updates of DNSSEC Trust Anchors 7 draft-ietf-dnsext-trustupdate-timers-06 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 4, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document describes a means for automated, authenticated and 41 authorized updating of DNSSEC "trust anchors". The method provides 42 protection against N-1 key compromises of N keys in the trust point 43 key set. Based on the trust established by the presence of a current 44 anchor, other anchors may be added at the same place in the 45 hierarchy, and, ultimately, supplant the existing anchor(s). 47 This mechanism will require changes to resolver management behavior 48 (but not resolver resolution behavior), and the addition of a single 49 flag bit to the DNSKEY record. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 55 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5 59 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 60 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 61 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 62 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 63 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 64 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8 68 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9 69 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9 70 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 71 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 72 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 73 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 74 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 78 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 79 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 80 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 Intellectual Property and Copyright Statements . . . . . . . . . . 13 84 1. Introduction 86 As part of the reality of fielding DNSSEC (Domain Name System 87 Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has 88 come to the realization that there will not be one signed name space, 89 but rather islands of signed name space each originating from 90 specific points (i.e. 'trust points') in the DNS tree. Each of those 91 islands will be identified by the trust point name, and validated by 92 at least one associated public key. For the purpose of this document 93 we'll call the association of that name and a particular key a 'trust 94 anchor'. A particular trust point can have more than one key 95 designated as a trust anchor. 97 For a DNSSEC-aware resolver to validate information in a DNSSEC 98 protected branch of the hierarchy, it must have knowledge of a trust 99 anchor applicable to that branch. It may also have more than one 100 trust anchor for any given trust point. Under current rules, a chain 101 of trust for DNSSEC-protected data that chains its way back to ANY 102 known trust anchor is considered 'secure'. 104 Because of the probable balkanization of the DNSSEC tree due to 105 signing voids at key locations, a resolver may need to know literally 106 thousands of trust anchors to perform its duties. (e.g., Consider an 107 unsigned ".COM".) Requiring the owner of the resolver to manually 108 manage these many relationships is problematic. It's even more 109 problematic when considering the eventual requirement for key 110 replacement/update for a given trust anchor. The mechanism described 111 herein won't help with the initial configuration of the trust anchors 112 in the resolvers, but should make trust point key replacement/ 113 rollover more viable. 115 As mentioned above, this document describes a mechanism whereby a 116 resolver can update the trust anchors for a given trust point, mainly 117 without human intervention at the resolver. There are some corner 118 cases discussed (e.g., multiple key compromise) that may require 119 manual intervention, but they should be few and far between. This 120 document DOES NOT discuss the general problem of the initial 121 configuration of trust anchors for the resolver. 123 1.1. Compliance Nomenclature 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in BCP 14, [RFC2119]. 129 2. Theory of Operation 131 The general concept of this mechanism is that existing trust anchors 132 can be used to authenticate new trust anchors at the same point in 133 the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a 134 DNSKEY with the Secure Entry Point bit set) (see [RFC4034], section 135 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is 136 validated by an existing trust anchor, then the resolver can add the 137 new key to its set of valid trust anchors for that trust point. 139 There are some issues with this approach which need to be mitigated. 140 For example, a compromise of one of the existing keys could allow an 141 attacker to add their own 'valid' data. This implies a need for a 142 method to revoke an existing key regardless of whether or not that 143 key is compromised. As another example, assuming a single key 144 compromise, we need to prevent an attacker from adding a new key and 145 revoking all the other old keys. 147 2.1. Revocation 149 Assume two trust anchor keys A and B. Assume that B has been 150 compromised. Without a specific revocation bit, B could invalidate A 151 simply by sending out a signed trust point key set which didn't 152 contain A. To fix this, we add a mechanism which requires knowledge 153 of the private key of a DNSKEY to revoke that DNSKEY. 155 A key is considered revoked when the resolver sees the key in a self- 156 signed RRSet and the key has the REVOKE bit (see Section 7 below) set 157 to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this 158 key as a trust anchor or for any other purposes except validating the 159 RRSIG it signed over the DNSKEY RRSet specifically for the purpose of 160 validating the revocation. Unlike the 'Add' operation below, 161 revocation is immediate and permanent upon receipt of a valid 162 revocation at the resolver. 164 A self-signed RRSet is a DNSKEY RRSet which contains the specific 165 DNSKEY and for which there is a corresponding validated RRSIG record. 166 It's not a special DNSKEY RRSet, just a way of describing the 167 validation requirements for that RRSet. 169 N.B. A DNSKEY with the REVOKE bit set has a different fingerprint 170 than one without the bit set. This affects the matching of a DNSKEY 171 to DS records in the parent, or the fingerprint stored at a resolver 172 used to configure a trust point. 174 In the given example, the attacker could revoke B because it has 175 knowledge of B's private key, but could not revoke A. 177 2.2. Add Hold-Down 179 Assume two trust point keys A and B. Assume that B has been 180 compromised. An attacker could generate and add a new trust anchor 181 key - C (by adding C to the DNSKEY RRSet and signing it with B), and 182 then invalidate the compromised key. This would result in both the 183 attacker and owner being able to sign data in the zone and have it 184 accepted as valid by resolvers. 186 To mitigate but not completely solve this problem, we add a hold-down 187 time to the addition of the trust anchor. When the resolver sees a 188 new SEP key in a validated trust point DNSKEY RRSet, the resolver 189 starts an acceptance timer, and remembers all the keys that validated 190 the RRSet. If the resolver ever sees the DNSKEY RRSet without the 191 new key but validly signed, it stops the acceptance process for that 192 key and resets the acceptance timer. If all of the keys which were 193 originally used to validate this key are revoked prior to the timer 194 expiring, the resolver stops the acceptance process and resets the 195 timer. 197 Once the timer expires, the new key will be added as a trust anchor 198 the next time the validated RRSet with the new key is seen at the 199 resolver. The resolver MUST NOT treat the new key as a trust anchor 200 until the hold down time expires AND it has retrieved and validated a 201 DNSKEY RRSet after the hold down time which contains the new key. 203 N.B.: Once the resolver has accepted a key as a trust anchor, the key 204 MUST be considered a valid trust anchor by that resolver until 205 explictly revoked as described above. 207 In the given example, the zone owner can recover from a compromise by 208 revoking B and adding a new key D and signing the DNSKEY RRSet with 209 both A and B. 211 The reason this does not completely solve the problem has to do with 212 the distributed nature of DNS. The resolver only knows what it sees. 213 A determined attacker who holds one compromised key could keep a 214 single resolver from realizing that key had been compromised by 215 intercepting 'real' data from the originating zone and substituting 216 their own (e.g., using the example, signed only by B). This is no 217 worse than the current situation assuming a compromised key. 219 2.3. Active Refresh 221 A resolver which has been configured for automatic update of keys 222 from a particular trust point MUST query that trust point (e.g., do a 223 lookup for the DNSKEY RRSet and related RRSIG records) no less often 224 than the lesser of 15 days or half the original TTL for the DNSKEY 225 RRSet or half the RRSIG expiration interval and no more often than 226 once per hour. The expiration interval is the amount of time from 227 when the RRSIG was last retrieved until the expiration time in the 228 RRSIG. I.e.: queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL, 229 1/2*RRSigExpirationInterval)) 231 If the query fails, the resolver MUST repeat the query until 232 satisfied no more often than once an hour and no less often than the 233 lesser of 1 day or 10% of the original TTL or 10% of the original 234 expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 * 235 origTTL, .1 * expireInterval)). 237 2.4. Resolver Parameters 239 2.4.1. Add Hold-Down Time 241 The add hold-down time is 30 days or the expiration time of the 242 original TTL of the first trust point DNSKEY RRSet which contained 243 the new key, whichever is greater. This ensures that at least two 244 validated DNSKEY RRSets which contain the new key MUST be seen by the 245 resolver prior to the key's acceptance. 247 2.4.2. Remove Hold-Down Time 249 The remove hold-down time is 30 days. This parameter is solely a key 250 management database bookeeping parameter. Failure to remove 251 information about the state of defunct keys from the database will 252 not adversely impact the security of this protocol, but may end up 253 with a database cluttered with obsolete key information. 255 2.4.3. Minimum Trust Anchors per Trust Point 257 A compliant resolver MUST be able to manage at least five SEP keys 258 per trust point. 260 3. Changes to DNSKEY RDATA Wire Format 262 Bit n of the DNSKEY Flags field is designated as the 'REVOKE' flag. 263 If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) 264 signed by the associated key, then the resolver MUST consider this 265 key permanently invalid for all purposes except for validating the 266 revocation. 268 4. State Table 270 The most important thing to understand is the resolver's view of any 271 key at a trust point. The following state table describes that view 272 at various points in the key's lifetime. The table is a normative 273 part of this specification. The initial state of the key is 'Start'. 274 The resolver's view of the state of the key changes as various events 275 occur. 277 This is the state of a trust point key as seen from the resolver. 278 The column on the left indicates the current state. The header at 279 the top shows the next state. The intersection of the two shows the 280 event that will cause the state to transition from the current state 281 to the next. 283 NEXT STATE 284 -------------------------------------------------- 285 FROM |Start |AddPend |Valid |Missing|Revoked|Removed| 286 ---------------------------------------------------------- 287 Start | |NewKey | | | | | 288 ---------------------------------------------------------- 289 AddPend |KeyRem | |AddTime| | | | 290 ---------------------------------------------------------- 291 Valid | | | |KeyRem |Revbit | | 292 ---------------------------------------------------------- 293 Missing | | |KeyPres| |Revbit | | 294 ---------------------------------------------------------- 295 Revoked | | | | | |RemTime| 296 ---------------------------------------------------------- 297 Removed | | | | | | | 298 ---------------------------------------------------------- 300 State Table 302 4.1. Events 303 NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. 304 That key will become a new trust anchor for the named trust point 305 after it's been present in the RRSet for at least 'add time'. 306 KeyPres The key has returned to the valid DNSKEY RRSet. 307 KeyRem The resolver sees a valid DNSKEY RRSet that does not contain 308 this key. 309 AddTime The key has been in every valid DNSKEY RRSet seen for at 310 least the 'add time'. 311 RemTime A revoked key has been missing from the trust point DNSKEY 312 RRSet for sufficient time to be removed from the trust set. 314 RevBit The key has appeared in the trust anchor DNSKEY RRSet with 315 its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet 316 signed by this key. 318 4.2. States 319 Start The key doesn't yet exist as a trust anchor at the resolver. 320 It may or may not exist at the zone server, but either hasn't yet 321 been seen at the resolver or was seen but was absent from the last 322 DNSKEY RRSet (e.g., KeyRem event). 323 AddPend The key has been seen at the resolver, has its 'SEP' bit 324 set, and has been included in a validated DNSKEY RRSet. There is 325 a hold-down time for the key before it can be used as a trust 326 anchor. 327 Valid The key has been seen at the resolver and has been included in 328 all validated DNSKEY RRSets from the time it was first seen up 329 through the hold-down time. It is now valid for verifying RRSets 330 that arrive after the hold down time. Clarification: The DNSKEY 331 RRSet does not need to be continuously present at the resolver 332 (e.g., its TTL might expire). If the RRSet is seen, and is 333 validated (i.e. verifies against an existing trust anchor), this 334 key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. 335 Missing This is an abnormal state. The key remains as a valid trust 336 point key, but was not seen at the resolver in the last validated 337 DNSKEY RRSet. This is an abnormal state because the zone operator 338 should be using the REVOKE bit prior to removal. 339 Revoked This is the state a key moves to once the resolver sees an 340 RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains 341 this key with its REVOKE bit set to '1'. Once in this state, this 342 key MUST permanently be considered invalid as a trust anchor. 343 Removed After a fairly long hold-down time, information about this 344 key may be purged from the resolver. A key in the removed state 345 MUST NOT be considered a valid trust anchor. (Note: this state is 346 more or less equivalent to the "Start" state, except that it's bad 347 practice to re-introduce previously used keys - think of this as 348 the holding state for all the old keys for which the resolver no 349 longer needs to track state.) 351 5. Trust Point Deletion 353 A trust point which has all of its trust anchors revoked is 354 considered deleted and is treated as if the trust point was never 355 configured. If there are no superior configured trust points, data 356 at and below the deleted trust point are considered insecure by the 357 resolver. If there ARE superior configured trust points, data at and 358 below the deleted trust point are evaluated with respect to the 359 superior trust point(s). 361 Alternately, a trust point which is subordinate to another configured 362 trust point MAY be deleted by a resolver after 180 days where such 363 subordinate trust point validly chains to a superior trust point. 364 The decision to delete the subordinate trust anchor is a local 365 configuration decision. Once the subordinate trust point is deleted, 366 validation of the subordinate zone is dependent on validating the 367 chain of trust to the superior trust point. 369 6. Scenarios - Informative 371 The suggested model for operation is to have one active key and one 372 stand-by key at each trust point. The active key will be used to 373 sign the DNSKEY RRSet. The stand-by key will not normally sign this 374 RRSet, but the resolver will accept it as a trust anchor if/when it 375 sees the signature on the trust point DNSKEY RRSet. 377 Since the stand-by key is not in active signing use, the associated 378 private key may (and should) be provided with additional protections 379 not normally available to a key that must be used frequently. E.g., 380 locked in a safe, split among many parties, etc. Notionally, the 381 stand-by key should be less subject to compromise than an active key, 382 but that will be dependent on operational concerns not addressed 383 here. 385 6.1. Adding a Trust Anchor 387 Assume an existing trust anchor key 'A'. 388 1. Generate a new key pair. 389 2. Create a DNSKEY record from the key pair and set the SEP and Zone 390 Key bits. 391 3. Add the DNSKEY to the RRSet. 392 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 393 'A'. 394 5. Wait a while (i.e. for various resolvers' timers to go off and 395 for them to retrieve the new DNSKEY RRSet and signatures). 396 6. The new trust anchor will be populated at the resolvers on the 397 schedule described by the state table and update algorithm - see 398 Section 2 and 4 above. 400 6.2. Deleting a Trust Anchor 402 Assume existing trust anchors 'A' and 'B' and that you want to revoke 403 and delete 'A'. 404 1. Set the revocation bit on key 'A'. 405 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 406 'A' is now revoked. The operator should include the revoked 'A' in 407 the RRSet for at least the remove hold-down time, but then may remove 408 it from the DNSKEY RRSet. 410 6.3. Key Roll-Over 412 Assume existing keys A and B. 'A' is actively in use (i.e. has been 413 signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been 414 in the DNSKEY RRSet and is a valid trust anchor, but wasn't being 415 used to sign the RRSet.) 416 1. Generate a new key pair 'C'. 417 2. Add 'C' to the DNSKEY RRSet. 418 3. Set the revocation bit on key 'A'. 419 4. Sign the RRSet with 'A' and 'B'. 420 'A' is now revoked, 'B' is now the active key, and 'C' will be the 421 stand-by key once the hold-down expires. The operator should include 422 the revoked 'A' in the RRSet for at least the remove hold-down time, 423 but may then remove it from the DNSKEY RRSet. 425 6.4. Active Key Compromised 427 This is the same as the mechanism for Key Roll-Over (Section 6.3) 428 above assuming 'A' is the active key. 430 6.5. Stand-by Key Compromised 432 Using the same assumptions and naming conventions as Key Roll-Over 433 (Section 6.3) above: 434 1. Generate a new key pair 'C'. 435 2. Add 'C' to the DNSKEY RRSet. 436 3. Set the revocation bit on key 'B'. 437 4. Sign the RRSet with 'A' and 'B'. 438 'B' is now revoked, 'A' remains the active key, and 'C' will be the 439 stand-by key once the hold-down expires. 'B' should continue to be 440 included in the RRSet for the remove hold-down time. 442 6.6. Trust Point Deletion 444 To delete a trust point which is subordinate to another configured 445 trust point (e.g. example.com to .com) requires some juggling of the 446 data. The specific process is: 447 1. Generate a new DNSKEY and DS record and provide the DS record to 448 the parent along with DS records for the old keys 449 2. Once the parent has published the DSs, add the new DNSKEY to the 450 RRSet and revoke ALL of the old keys at the same time while 451 signing the DNSKEY RRSet with all of the old and new keys. 452 3. After 30 days stop publishing the old, revoked keys and remove 453 any corresponding DS records in the parent. 454 Revoking the old trust point keys at the same time as adding new keys 455 that chain to a superior trust prevents the resolver from adding the 456 new keys as trust anchors. Adding DS records for the old keys avoids 457 a race condition where either the subordinate zone becomes unsecure 458 (because the trust point was deleted) or becomes bogus (because it 459 didn't chain to the superior zone). 461 7. IANA Considerations 463 The IANA will need to assign a bit in the DNSKEY flags field (see 464 section 7 of [RFC4034]) for the REVOKE bit. There are no other IANA 465 actions required. 467 8. Security Considerations 469 In addition to the following sections, see also Theory of Operation 470 above and especially Section 2.2 for related discussions. 472 8.1. Key Ownership vs Acceptance Policy 474 The reader should note that, while the zone owner is responsible for 475 creating and distributing keys, it's wholly the decision of the 476 resolver owner as to whether to accept such keys for the 477 authentication of the zone information. This implies the decision to 478 update trust anchor keys based on trust for a current trust anchor 479 key is also the resolver owner's decision. 481 The resolver owner (and resolver implementers) MAY choose to permit 482 or prevent key status updates based on this mechanism for specific 483 trust points. If they choose to prevent the automated updates, they 484 will need to establish a mechanism for manual or other out-of-band 485 updates outside the scope of this document. 487 8.2. Multiple Key Compromise 489 This scheme permits recovery as long as at least one valid trust 490 anchor key remains uncompromised. E.g., if there are three keys, you 491 can recover if two of them are compromised. The zone owner should 492 determine their own level of comfort with respect to the number of 493 active valid trust anchors in a zone and should be prepared to 494 implement recovery procedures once they detect a compromise. A 495 manual or other out-of-band update of all resolvers will be required 496 if all trust anchor keys at a trust point are compromised. 498 8.3. Dynamic Updates 500 Allowing a resolver to update its trust anchor set based on in-band 501 key information is potentially less secure than a manual process. 503 However, given the nature of the DNS, the number of resolvers that 504 would require update if a trust anchor key were compromised, and the 505 lack of a standard management framework for DNS, this approach is no 506 worse than the existing situation. 508 9. Normative References 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, March 1997. 513 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 514 Signer (DS)", RFC 3755, May 2004. 516 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 517 Rose, "DNS Security Introduction and Requirements", 518 RFC 4033, March 2005. 520 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 521 Rose, "Resource Records for the DNS Security Extensions", 522 RFC 4034, March 2005. 524 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 525 Rose, "Protocol Modifications for the DNS Security 526 Extensions", RFC 4035, March 2005. 528 Author's Address 530 Michael StJohns 531 Independent 533 Email: mstjohns@comcast.net 535 Full Copyright Statement 537 Copyright (C) The IETF Trust (2007). 539 This document is subject to the rights, licenses and restrictions 540 contained in BCP 78, and except as set forth therein, the authors 541 retain all their rights. 543 This document and the information contained herein are provided on an 544 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 545 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 546 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 547 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 548 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 549 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 551 Intellectual Property 553 The IETF takes no position regarding the validity or scope of any 554 Intellectual Property Rights or other rights that might be claimed to 555 pertain to the implementation or use of the technology described in 556 this document or the extent to which any license under such rights 557 might or might not be available; nor does it represent that it has 558 made any independent effort to identify any such rights. Information 559 on the procedures with respect to rights in RFC documents can be 560 found in BCP 78 and BCP 79. 562 Copies of IPR disclosures made to the IETF Secretariat and any 563 assurances of licenses to be made available, or the result of an 564 attempt made to obtain a general license or permission for the use of 565 such proprietary rights by implementers or users of this 566 specification can be obtained from the IETF on-line IPR repository at 567 http://www.ietf.org/ipr. 569 The IETF invites any interested party to bring to its attention any 570 copyrights, patents or patent applications, or other proprietary 571 rights that may cover technology that may be required to implement 572 this standard. Please address the information to the IETF at 573 ietf-ipr@ietf.org. 575 Acknowledgment 577 Funding for the RFC Editor function is provided by the IETF 578 Administrative Support Activity (IASA).