1*00b67f09SDavid van Moolenbroek 2*00b67f09SDavid van Moolenbroek 3*00b67f09SDavid van Moolenbroek 4*00b67f09SDavid van Moolenbroek 5*00b67f09SDavid van Moolenbroek 6*00b67f09SDavid van Moolenbroek 7*00b67f09SDavid van MoolenbroekNetwork Working Group M. StJohns 8*00b67f09SDavid van MoolenbroekRequest for Comments: 5011 Independent 9*00b67f09SDavid van MoolenbroekCategory: Standards Track September 2007 10*00b67f09SDavid van Moolenbroek 11*00b67f09SDavid van Moolenbroek 12*00b67f09SDavid van Moolenbroek Automated Updates of DNS Security (DNSSEC) Trust Anchors 13*00b67f09SDavid van Moolenbroek 14*00b67f09SDavid van MoolenbroekStatus of This Memo 15*00b67f09SDavid van Moolenbroek 16*00b67f09SDavid van Moolenbroek This document specifies an Internet standards track protocol for the 17*00b67f09SDavid van Moolenbroek Internet community, and requests discussion and suggestions for 18*00b67f09SDavid van Moolenbroek improvements. Please refer to the current edition of the "Internet 19*00b67f09SDavid van Moolenbroek Official Protocol Standards" (STD 1) for the standardization state 20*00b67f09SDavid van Moolenbroek and status of this protocol. Distribution of this memo is unlimited. 21*00b67f09SDavid van Moolenbroek 22*00b67f09SDavid van MoolenbroekAbstract 23*00b67f09SDavid van Moolenbroek 24*00b67f09SDavid van Moolenbroek This document describes a means for automated, authenticated, and 25*00b67f09SDavid van Moolenbroek authorized updating of DNSSEC "trust anchors". The method provides 26*00b67f09SDavid van Moolenbroek protection against N-1 key compromises of N keys in the trust point 27*00b67f09SDavid van Moolenbroek key set. Based on the trust established by the presence of a current 28*00b67f09SDavid van Moolenbroek anchor, other anchors may be added at the same place in the 29*00b67f09SDavid van Moolenbroek hierarchy, and, ultimately, supplant the existing anchor(s). 30*00b67f09SDavid van Moolenbroek 31*00b67f09SDavid van Moolenbroek This mechanism will require changes to resolver management behavior 32*00b67f09SDavid van Moolenbroek (but not resolver resolution behavior), and the addition of a single 33*00b67f09SDavid van Moolenbroek flag bit to the DNSKEY record. 34*00b67f09SDavid van Moolenbroek 35*00b67f09SDavid van Moolenbroek 36*00b67f09SDavid van Moolenbroek 37*00b67f09SDavid van Moolenbroek 38*00b67f09SDavid van Moolenbroek 39*00b67f09SDavid van Moolenbroek 40*00b67f09SDavid van Moolenbroek 41*00b67f09SDavid van Moolenbroek 42*00b67f09SDavid van Moolenbroek 43*00b67f09SDavid van Moolenbroek 44*00b67f09SDavid van Moolenbroek 45*00b67f09SDavid van Moolenbroek 46*00b67f09SDavid van Moolenbroek 47*00b67f09SDavid van Moolenbroek 48*00b67f09SDavid van Moolenbroek 49*00b67f09SDavid van Moolenbroek 50*00b67f09SDavid van Moolenbroek 51*00b67f09SDavid van Moolenbroek 52*00b67f09SDavid van Moolenbroek 53*00b67f09SDavid van Moolenbroek 54*00b67f09SDavid van Moolenbroek 55*00b67f09SDavid van Moolenbroek 56*00b67f09SDavid van Moolenbroek 57*00b67f09SDavid van Moolenbroek 58*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 1] 59*00b67f09SDavid van Moolenbroek 60*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 61*00b67f09SDavid van Moolenbroek 62*00b67f09SDavid van Moolenbroek 63*00b67f09SDavid van MoolenbroekTable of Contents 64*00b67f09SDavid van Moolenbroek 65*00b67f09SDavid van Moolenbroek 1. Introduction ....................................................2 66*00b67f09SDavid van Moolenbroek 1.1. Compliance Nomenclature ....................................3 67*00b67f09SDavid van Moolenbroek 2. Theory of Operation .............................................3 68*00b67f09SDavid van Moolenbroek 2.1. Revocation .................................................4 69*00b67f09SDavid van Moolenbroek 2.2. Add Hold-Down ..............................................4 70*00b67f09SDavid van Moolenbroek 2.3. Active Refresh .............................................5 71*00b67f09SDavid van Moolenbroek 2.4. Resolver Parameters ........................................6 72*00b67f09SDavid van Moolenbroek 2.4.1. Add Hold-Down Time ..................................6 73*00b67f09SDavid van Moolenbroek 2.4.2. Remove Hold-Down Time ...............................6 74*00b67f09SDavid van Moolenbroek 2.4.3. Minimum Trust Anchors per Trust Point ...............6 75*00b67f09SDavid van Moolenbroek 3. Changes to DNSKEY RDATA Wire Format .............................6 76*00b67f09SDavid van Moolenbroek 4. State Table .....................................................6 77*00b67f09SDavid van Moolenbroek 4.1. Events .....................................................7 78*00b67f09SDavid van Moolenbroek 4.2. States .....................................................7 79*00b67f09SDavid van Moolenbroek 5. Trust Point Deletion ............................................8 80*00b67f09SDavid van Moolenbroek 6. Scenarios - Informative .........................................9 81*00b67f09SDavid van Moolenbroek 6.1. Adding a Trust Anchor ......................................9 82*00b67f09SDavid van Moolenbroek 6.2. Deleting a Trust Anchor ....................................9 83*00b67f09SDavid van Moolenbroek 6.3. Key Roll-Over .............................................10 84*00b67f09SDavid van Moolenbroek 6.4. Active Key Compromised ....................................10 85*00b67f09SDavid van Moolenbroek 6.5. Stand-by Key Compromised ..................................10 86*00b67f09SDavid van Moolenbroek 6.6. Trust Point Deletion ......................................10 87*00b67f09SDavid van Moolenbroek 7. IANA Considerations ............................................11 88*00b67f09SDavid van Moolenbroek 8. Security Considerations ........................................11 89*00b67f09SDavid van Moolenbroek 8.1. Key Ownership vs. Acceptance Policy .......................11 90*00b67f09SDavid van Moolenbroek 8.2. Multiple Key Compromise ...................................12 91*00b67f09SDavid van Moolenbroek 8.3. Dynamic Updates ...........................................12 92*00b67f09SDavid van Moolenbroek 9. Normative References ...........................................12 93*00b67f09SDavid van Moolenbroek 10. Informative References ........................................12 94*00b67f09SDavid van Moolenbroek 95*00b67f09SDavid van Moolenbroek1. Introduction 96*00b67f09SDavid van Moolenbroek 97*00b67f09SDavid van Moolenbroek As part of the reality of fielding DNSSEC (Domain Name System 98*00b67f09SDavid van Moolenbroek Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has 99*00b67f09SDavid van Moolenbroek come to the realization that there will not be one signed name space, 100*00b67f09SDavid van Moolenbroek but rather islands of signed name spaces each originating from 101*00b67f09SDavid van Moolenbroek specific points (i.e., 'trust points') in the DNS tree. Each of 102*00b67f09SDavid van Moolenbroek those islands will be identified by the trust point name, and 103*00b67f09SDavid van Moolenbroek validated by at least one associated public key. For the purpose of 104*00b67f09SDavid van Moolenbroek this document, we'll call the association of that name and a 105*00b67f09SDavid van Moolenbroek particular key a 'trust anchor'. A particular trust point can have 106*00b67f09SDavid van Moolenbroek more than one key designated as a trust anchor. 107*00b67f09SDavid van Moolenbroek 108*00b67f09SDavid van Moolenbroek For a DNSSEC-aware resolver to validate information in a DNSSEC 109*00b67f09SDavid van Moolenbroek protected branch of the hierarchy, it must have knowledge of a trust 110*00b67f09SDavid van Moolenbroek anchor applicable to that branch. It may also have more than one 111*00b67f09SDavid van Moolenbroek 112*00b67f09SDavid van Moolenbroek 113*00b67f09SDavid van Moolenbroek 114*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 2] 115*00b67f09SDavid van Moolenbroek 116*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 117*00b67f09SDavid van Moolenbroek 118*00b67f09SDavid van Moolenbroek 119*00b67f09SDavid van Moolenbroek trust anchor for any given trust point. Under current rules, a chain 120*00b67f09SDavid van Moolenbroek of trust for DNSSEC-protected data that chains its way back to ANY 121*00b67f09SDavid van Moolenbroek known trust anchor is considered 'secure'. 122*00b67f09SDavid van Moolenbroek 123*00b67f09SDavid van Moolenbroek Because of the probable balkanization of the DNSSEC tree due to 124*00b67f09SDavid van Moolenbroek signing voids at key locations, a resolver may need to know literally 125*00b67f09SDavid van Moolenbroek thousands of trust anchors to perform its duties (e.g., consider an 126*00b67f09SDavid van Moolenbroek unsigned ".COM"). Requiring the owner of the resolver to manually 127*00b67f09SDavid van Moolenbroek manage these many relationships is problematic. It's even more 128*00b67f09SDavid van Moolenbroek problematic when considering the eventual requirement for key 129*00b67f09SDavid van Moolenbroek replacement/update for a given trust anchor. The mechanism described 130*00b67f09SDavid van Moolenbroek herein won't help with the initial configuration of the trust anchors 131*00b67f09SDavid van Moolenbroek in the resolvers, but should make trust point key 132*00b67f09SDavid van Moolenbroek replacement/rollover more viable. 133*00b67f09SDavid van Moolenbroek 134*00b67f09SDavid van Moolenbroek As mentioned above, this document describes a mechanism whereby a 135*00b67f09SDavid van Moolenbroek resolver can update the trust anchors for a given trust point, mainly 136*00b67f09SDavid van Moolenbroek without human intervention at the resolver. There are some corner 137*00b67f09SDavid van Moolenbroek cases discussed (e.g., multiple key compromise) that may require 138*00b67f09SDavid van Moolenbroek manual intervention, but they should be few and far between. This 139*00b67f09SDavid van Moolenbroek document DOES NOT discuss the general problem of the initial 140*00b67f09SDavid van Moolenbroek configuration of trust anchors for the resolver. 141*00b67f09SDavid van Moolenbroek 142*00b67f09SDavid van Moolenbroek1.1. Compliance Nomenclature 143*00b67f09SDavid van Moolenbroek 144*00b67f09SDavid van Moolenbroek The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145*00b67f09SDavid van Moolenbroek "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146*00b67f09SDavid van Moolenbroek document are to be interpreted as described in BCP 14, [RFC2119]. 147*00b67f09SDavid van Moolenbroek 148*00b67f09SDavid van Moolenbroek2. Theory of Operation 149*00b67f09SDavid van Moolenbroek 150*00b67f09SDavid van Moolenbroek The general concept of this mechanism is that existing trust anchors 151*00b67f09SDavid van Moolenbroek can be used to authenticate new trust anchors at the same point in 152*00b67f09SDavid van Moolenbroek the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a 153*00b67f09SDavid van Moolenbroek DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section 154*00b67f09SDavid van Moolenbroek 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is 155*00b67f09SDavid van Moolenbroek validated by an existing trust anchor, then the resolver can add the 156*00b67f09SDavid van Moolenbroek new key to its set of valid trust anchors for that trust point. 157*00b67f09SDavid van Moolenbroek 158*00b67f09SDavid van Moolenbroek There are some issues with this approach that need to be mitigated. 159*00b67f09SDavid van Moolenbroek For example, a compromise of one of the existing keys could allow an 160*00b67f09SDavid van Moolenbroek attacker to add their own 'valid' data. This implies a need for a 161*00b67f09SDavid van Moolenbroek method to revoke an existing key regardless of whether or not that 162*00b67f09SDavid van Moolenbroek key is compromised. As another example, assuming a single key 163*00b67f09SDavid van Moolenbroek compromise, we need to prevent an attacker from adding a new key and 164*00b67f09SDavid van Moolenbroek revoking all the other old keys. 165*00b67f09SDavid van Moolenbroek 166*00b67f09SDavid van Moolenbroek 167*00b67f09SDavid van Moolenbroek 168*00b67f09SDavid van Moolenbroek 169*00b67f09SDavid van Moolenbroek 170*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 3] 171*00b67f09SDavid van Moolenbroek 172*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 173*00b67f09SDavid van Moolenbroek 174*00b67f09SDavid van Moolenbroek 175*00b67f09SDavid van Moolenbroek2.1. Revocation 176*00b67f09SDavid van Moolenbroek 177*00b67f09SDavid van Moolenbroek Assume two trust anchor keys A and B. Assume that B has been 178*00b67f09SDavid van Moolenbroek compromised. Without a specific revocation bit, B could invalidate A 179*00b67f09SDavid van Moolenbroek simply by sending out a signed trust point key set that didn't 180*00b67f09SDavid van Moolenbroek contain A. To fix this, we add a mechanism that requires knowledge 181*00b67f09SDavid van Moolenbroek of the private key of a DNSKEY to revoke that DNSKEY. 182*00b67f09SDavid van Moolenbroek 183*00b67f09SDavid van Moolenbroek A key is considered revoked when the resolver sees the key in a 184*00b67f09SDavid van Moolenbroek self-signed RRSet and the key has the REVOKE bit (see Section 7 185*00b67f09SDavid van Moolenbroek below) set to '1'. Once the resolver sees the REVOKE bit, it MUST 186*00b67f09SDavid van Moolenbroek NOT use this key as a trust anchor or for any other purpose except to 187*00b67f09SDavid van Moolenbroek validate the RRSIG it signed over the DNSKEY RRSet specifically for 188*00b67f09SDavid van Moolenbroek the purpose of validating the revocation. Unlike the 'Add' operation 189*00b67f09SDavid van Moolenbroek below, revocation is immediate and permanent upon receipt of a valid 190*00b67f09SDavid van Moolenbroek revocation at the resolver. 191*00b67f09SDavid van Moolenbroek 192*00b67f09SDavid van Moolenbroek A self-signed RRSet is a DNSKEY RRSet that contains the specific 193*00b67f09SDavid van Moolenbroek DNSKEY and for which there is a corresponding validated RRSIG record. 194*00b67f09SDavid van Moolenbroek It's not a special DNSKEY RRSet, just a way of describing the 195*00b67f09SDavid van Moolenbroek validation requirements for that RRSet. 196*00b67f09SDavid van Moolenbroek 197*00b67f09SDavid van Moolenbroek N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint 198*00b67f09SDavid van Moolenbroek than one without the bit set. This affects the matching of a DNSKEY 199*00b67f09SDavid van Moolenbroek to DS records in the parent [RFC3755], or the fingerprint stored at a 200*00b67f09SDavid van Moolenbroek resolver used to configure a trust point. 201*00b67f09SDavid van Moolenbroek 202*00b67f09SDavid van Moolenbroek In the given example, the attacker could revoke B because it has 203*00b67f09SDavid van Moolenbroek knowledge of B's private key, but could not revoke A. 204*00b67f09SDavid van Moolenbroek 205*00b67f09SDavid van Moolenbroek2.2. Add Hold-Down 206*00b67f09SDavid van Moolenbroek 207*00b67f09SDavid van Moolenbroek Assume two trust point keys A and B. Assume that B has been 208*00b67f09SDavid van Moolenbroek compromised. An attacker could generate and add a new trust anchor 209*00b67f09SDavid van Moolenbroek key C (by adding C to the DNSKEY RRSet and signing it with B), and 210*00b67f09SDavid van Moolenbroek then invalidate the compromised key. This would result in both the 211*00b67f09SDavid van Moolenbroek attacker and owner being able to sign data in the zone and have it 212*00b67f09SDavid van Moolenbroek accepted as valid by resolvers. 213*00b67f09SDavid van Moolenbroek 214*00b67f09SDavid van Moolenbroek To mitigate but not completely solve this problem, we add a hold-down 215*00b67f09SDavid van Moolenbroek time to the addition of the trust anchor. When the resolver sees a 216*00b67f09SDavid van Moolenbroek new SEP key in a validated trust point DNSKEY RRSet, the resolver 217*00b67f09SDavid van Moolenbroek starts an acceptance timer, and remembers all the keys that validated 218*00b67f09SDavid van Moolenbroek the RRSet. If the resolver ever sees the DNSKEY RRSet without the 219*00b67f09SDavid van Moolenbroek new key but validly signed, it stops the acceptance process for that 220*00b67f09SDavid van Moolenbroek key and resets the acceptance timer. If all of the keys that were 221*00b67f09SDavid van Moolenbroek 222*00b67f09SDavid van Moolenbroek 223*00b67f09SDavid van Moolenbroek 224*00b67f09SDavid van Moolenbroek 225*00b67f09SDavid van Moolenbroek 226*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 4] 227*00b67f09SDavid van Moolenbroek 228*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 229*00b67f09SDavid van Moolenbroek 230*00b67f09SDavid van Moolenbroek 231*00b67f09SDavid van Moolenbroek originally used to validate this key are revoked prior to the timer 232*00b67f09SDavid van Moolenbroek expiring, the resolver stops the acceptance process and resets the 233*00b67f09SDavid van Moolenbroek timer. 234*00b67f09SDavid van Moolenbroek 235*00b67f09SDavid van Moolenbroek Once the timer expires, the new key will be added as a trust anchor 236*00b67f09SDavid van Moolenbroek the next time the validated RRSet with the new key is seen at the 237*00b67f09SDavid van Moolenbroek resolver. The resolver MUST NOT treat the new key as a trust anchor 238*00b67f09SDavid van Moolenbroek until the hold-down time expires AND it has retrieved and validated a 239*00b67f09SDavid van Moolenbroek DNSKEY RRSet after the hold-down time that contains the new key. 240*00b67f09SDavid van Moolenbroek 241*00b67f09SDavid van Moolenbroek N.B.: Once the resolver has accepted a key as a trust anchor, the key 242*00b67f09SDavid van Moolenbroek MUST be considered a valid trust anchor by that resolver until 243*00b67f09SDavid van Moolenbroek explicitly revoked as described above. 244*00b67f09SDavid van Moolenbroek 245*00b67f09SDavid van Moolenbroek In the given example, the zone owner can recover from a compromise by 246*00b67f09SDavid van Moolenbroek revoking B and adding a new key D and signing the DNSKEY RRSet with 247*00b67f09SDavid van Moolenbroek both A and B. 248*00b67f09SDavid van Moolenbroek 249*00b67f09SDavid van Moolenbroek The reason this does not completely solve the problem has to do with 250*00b67f09SDavid van Moolenbroek the distributed nature of DNS. The resolver only knows what it sees. 251*00b67f09SDavid van Moolenbroek A determined attacker who holds one compromised key could keep a 252*00b67f09SDavid van Moolenbroek single resolver from realizing that the key had been compromised by 253*00b67f09SDavid van Moolenbroek intercepting 'real' data from the originating zone and substituting 254*00b67f09SDavid van Moolenbroek their own (e.g., using the example, signed only by B). This is no 255*00b67f09SDavid van Moolenbroek worse than the current situation assuming a compromised key. 256*00b67f09SDavid van Moolenbroek 257*00b67f09SDavid van Moolenbroek2.3. Active Refresh 258*00b67f09SDavid van Moolenbroek 259*00b67f09SDavid van Moolenbroek A resolver that has been configured for an automatic update of keys 260*00b67f09SDavid van Moolenbroek from a particular trust point MUST query that trust point (e.g., do a 261*00b67f09SDavid van Moolenbroek lookup for the DNSKEY RRSet and related RRSIG records) no less often 262*00b67f09SDavid van Moolenbroek than the lesser of 15 days, half the original TTL for the DNSKEY 263*00b67f09SDavid van Moolenbroek RRSet, or half the RRSIG expiration interval and no more often than 264*00b67f09SDavid van Moolenbroek once per hour. The expiration interval is the amount of time from 265*00b67f09SDavid van Moolenbroek when the RRSIG was last retrieved until the expiration time in the 266*00b67f09SDavid van Moolenbroek RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL, 267*00b67f09SDavid van Moolenbroek 1/2*RRSigExpirationInterval)) 268*00b67f09SDavid van Moolenbroek 269*00b67f09SDavid van Moolenbroek If the query fails, the resolver MUST repeat the query until 270*00b67f09SDavid van Moolenbroek satisfied no more often than once an hour and no less often than the 271*00b67f09SDavid van Moolenbroek lesser of 1 day, 10% of the original TTL, or 10% of the original 272*00b67f09SDavid van Moolenbroek expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day, 273*00b67f09SDavid van Moolenbroek .1 * origTTL, .1 * expireInterval)). 274*00b67f09SDavid van Moolenbroek 275*00b67f09SDavid van Moolenbroek 276*00b67f09SDavid van Moolenbroek 277*00b67f09SDavid van Moolenbroek 278*00b67f09SDavid van Moolenbroek 279*00b67f09SDavid van Moolenbroek 280*00b67f09SDavid van Moolenbroek 281*00b67f09SDavid van Moolenbroek 282*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 5] 283*00b67f09SDavid van Moolenbroek 284*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 285*00b67f09SDavid van Moolenbroek 286*00b67f09SDavid van Moolenbroek 287*00b67f09SDavid van Moolenbroek2.4. Resolver Parameters 288*00b67f09SDavid van Moolenbroek 289*00b67f09SDavid van Moolenbroek2.4.1. Add Hold-Down Time 290*00b67f09SDavid van Moolenbroek 291*00b67f09SDavid van Moolenbroek The add hold-down time is 30 days or the expiration time of the 292*00b67f09SDavid van Moolenbroek original TTL of the first trust point DNSKEY RRSet that contained the 293*00b67f09SDavid van Moolenbroek new key, whichever is greater. This ensures that at least two 294*00b67f09SDavid van Moolenbroek validated DNSKEY RRSets that contain the new key MUST be seen by the 295*00b67f09SDavid van Moolenbroek resolver prior to the key's acceptance. 296*00b67f09SDavid van Moolenbroek 297*00b67f09SDavid van Moolenbroek2.4.2. Remove Hold-Down Time 298*00b67f09SDavid van Moolenbroek 299*00b67f09SDavid van Moolenbroek The remove hold-down time is 30 days. This parameter is solely a key 300*00b67f09SDavid van Moolenbroek management database bookeeping parameter. Failure to remove 301*00b67f09SDavid van Moolenbroek information about the state of defunct keys from the database will 302*00b67f09SDavid van Moolenbroek not adversely impact the security of this protocol, but may end up 303*00b67f09SDavid van Moolenbroek with a database cluttered with obsolete key information. 304*00b67f09SDavid van Moolenbroek 305*00b67f09SDavid van Moolenbroek2.4.3. Minimum Trust Anchors per Trust Point 306*00b67f09SDavid van Moolenbroek 307*00b67f09SDavid van Moolenbroek A compliant resolver MUST be able to manage at least five SEP keys 308*00b67f09SDavid van Moolenbroek per trust point. 309*00b67f09SDavid van Moolenbroek 310*00b67f09SDavid van Moolenbroek3. Changes to DNSKEY RDATA Wire Format 311*00b67f09SDavid van Moolenbroek 312*00b67f09SDavid van Moolenbroek Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag. 313*00b67f09SDavid van Moolenbroek If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) 314*00b67f09SDavid van Moolenbroek signed by the associated key, then the resolver MUST consider this 315*00b67f09SDavid van Moolenbroek key permanently invalid for all purposes except for validating the 316*00b67f09SDavid van Moolenbroek revocation. 317*00b67f09SDavid van Moolenbroek 318*00b67f09SDavid van Moolenbroek4. State Table 319*00b67f09SDavid van Moolenbroek 320*00b67f09SDavid van Moolenbroek The most important thing to understand is the resolver's view of any 321*00b67f09SDavid van Moolenbroek key at a trust point. The following state table describes this view 322*00b67f09SDavid van Moolenbroek at various points in the key's lifetime. The table is a normative 323*00b67f09SDavid van Moolenbroek part of this specification. The initial state of the key is 'Start'. 324*00b67f09SDavid van Moolenbroek The resolver's view of the state of the key changes as various events 325*00b67f09SDavid van Moolenbroek occur. 326*00b67f09SDavid van Moolenbroek 327*00b67f09SDavid van Moolenbroek This is the state of a trust-point key as seen from the resolver. 328*00b67f09SDavid van Moolenbroek The column on the left indicates the current state. The header at 329*00b67f09SDavid van Moolenbroek the top shows the next state. The intersection of the two shows the 330*00b67f09SDavid van Moolenbroek event that will cause the state to transition from the current state 331*00b67f09SDavid van Moolenbroek to the next. 332*00b67f09SDavid van Moolenbroek 333*00b67f09SDavid van Moolenbroek 334*00b67f09SDavid van Moolenbroek 335*00b67f09SDavid van Moolenbroek 336*00b67f09SDavid van Moolenbroek 337*00b67f09SDavid van Moolenbroek 338*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 6] 339*00b67f09SDavid van Moolenbroek 340*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 341*00b67f09SDavid van Moolenbroek 342*00b67f09SDavid van Moolenbroek 343*00b67f09SDavid van Moolenbroek NEXT STATE 344*00b67f09SDavid van Moolenbroek -------------------------------------------------- 345*00b67f09SDavid van Moolenbroek FROM |Start |AddPend |Valid |Missing|Revoked|Removed| 346*00b67f09SDavid van Moolenbroek ---------------------------------------------------------- 347*00b67f09SDavid van Moolenbroek Start | |NewKey | | | | | 348*00b67f09SDavid van Moolenbroek ---------------------------------------------------------- 349*00b67f09SDavid van Moolenbroek AddPend |KeyRem | |AddTime| | | | 350*00b67f09SDavid van Moolenbroek ---------------------------------------------------------- 351*00b67f09SDavid van Moolenbroek Valid | | | |KeyRem |Revbit | | 352*00b67f09SDavid van Moolenbroek ---------------------------------------------------------- 353*00b67f09SDavid van Moolenbroek Missing | | |KeyPres| |Revbit | | 354*00b67f09SDavid van Moolenbroek ---------------------------------------------------------- 355*00b67f09SDavid van Moolenbroek Revoked | | | | | |RemTime| 356*00b67f09SDavid van Moolenbroek ---------------------------------------------------------- 357*00b67f09SDavid van Moolenbroek Removed | | | | | | | 358*00b67f09SDavid van Moolenbroek ---------------------------------------------------------- 359*00b67f09SDavid van Moolenbroek 360*00b67f09SDavid van Moolenbroek State Table 361*00b67f09SDavid van Moolenbroek 362*00b67f09SDavid van Moolenbroek4.1. Events 363*00b67f09SDavid van Moolenbroek 364*00b67f09SDavid van Moolenbroek NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. 365*00b67f09SDavid van Moolenbroek That key will become a new trust anchor for the named trust 366*00b67f09SDavid van Moolenbroek point after it's been present in the RRSet for at least 'add 367*00b67f09SDavid van Moolenbroek time'. 368*00b67f09SDavid van Moolenbroek 369*00b67f09SDavid van Moolenbroek KeyPres The key has returned to the valid DNSKEY RRSet. 370*00b67f09SDavid van Moolenbroek 371*00b67f09SDavid van Moolenbroek KeyRem The resolver sees a valid DNSKEY RRSet that does not contain 372*00b67f09SDavid van Moolenbroek this key. 373*00b67f09SDavid van Moolenbroek 374*00b67f09SDavid van Moolenbroek AddTime The key has been in every valid DNSKEY RRSet seen for at 375*00b67f09SDavid van Moolenbroek least the 'add time'. 376*00b67f09SDavid van Moolenbroek 377*00b67f09SDavid van Moolenbroek RemTime A revoked key has been missing from the trust-point DNSKEY 378*00b67f09SDavid van Moolenbroek RRSet for sufficient time to be removed from the trust set. 379*00b67f09SDavid van Moolenbroek 380*00b67f09SDavid van Moolenbroek RevBit The key has appeared in the trust anchor DNSKEY RRSet with 381*00b67f09SDavid van Moolenbroek its "REVOKED" bit set, and there is an RRSig over the DNSKEY 382*00b67f09SDavid van Moolenbroek RRSet signed by this key. 383*00b67f09SDavid van Moolenbroek 384*00b67f09SDavid van Moolenbroek4.2. States 385*00b67f09SDavid van Moolenbroek 386*00b67f09SDavid van Moolenbroek Start The key doesn't yet exist as a trust anchor at the resolver. 387*00b67f09SDavid van Moolenbroek It may or may not exist at the zone server, but either 388*00b67f09SDavid van Moolenbroek hasn't yet been seen at the resolver or was seen but was 389*00b67f09SDavid van Moolenbroek absent from the last DNSKEY RRSet (e.g., KeyRem event). 390*00b67f09SDavid van Moolenbroek 391*00b67f09SDavid van Moolenbroek 392*00b67f09SDavid van Moolenbroek 393*00b67f09SDavid van Moolenbroek 394*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 7] 395*00b67f09SDavid van Moolenbroek 396*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 397*00b67f09SDavid van Moolenbroek 398*00b67f09SDavid van Moolenbroek 399*00b67f09SDavid van Moolenbroek AddPend The key has been seen at the resolver, has its 'SEP' bit 400*00b67f09SDavid van Moolenbroek set, and has been included in a validated DNSKEY RRSet. 401*00b67f09SDavid van Moolenbroek There is a hold-down time for the key before it can be used 402*00b67f09SDavid van Moolenbroek as a trust anchor. 403*00b67f09SDavid van Moolenbroek 404*00b67f09SDavid van Moolenbroek Valid The key has been seen at the resolver and has been included 405*00b67f09SDavid van Moolenbroek in all validated DNSKEY RRSets from the time it was first 406*00b67f09SDavid van Moolenbroek seen through the hold-down time. It is now valid for 407*00b67f09SDavid van Moolenbroek verifying RRSets that arrive after the hold-down time. 408*00b67f09SDavid van Moolenbroek Clarification: The DNSKEY RRSet does not need to be 409*00b67f09SDavid van Moolenbroek continuously present at the resolver (e.g., its TTL might 410*00b67f09SDavid van Moolenbroek expire). If the RRSet is seen and is validated (i.e., 411*00b67f09SDavid van Moolenbroek verifies against an existing trust anchor), this key MUST be 412*00b67f09SDavid van Moolenbroek in the RRSet, otherwise a 'KeyRem' event is triggered. 413*00b67f09SDavid van Moolenbroek 414*00b67f09SDavid van Moolenbroek Missing This is an abnormal state. The key remains a valid trust- 415*00b67f09SDavid van Moolenbroek point key, but was not seen at the resolver in the last 416*00b67f09SDavid van Moolenbroek validated DNSKEY RRSet. This is an abnormal state because 417*00b67f09SDavid van Moolenbroek the zone operator should be using the REVOKE bit prior to 418*00b67f09SDavid van Moolenbroek removal. 419*00b67f09SDavid van Moolenbroek 420*00b67f09SDavid van Moolenbroek Revoked This is the state a key moves to once the resolver sees an 421*00b67f09SDavid van Moolenbroek RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet 422*00b67f09SDavid van Moolenbroek contains this key with its REVOKE bit set to '1'. Once in 423*00b67f09SDavid van Moolenbroek this state, this key MUST permanently be considered invalid 424*00b67f09SDavid van Moolenbroek as a trust anchor. 425*00b67f09SDavid van Moolenbroek 426*00b67f09SDavid van Moolenbroek Removed After a fairly long hold-down time, information about this 427*00b67f09SDavid van Moolenbroek key may be purged from the resolver. A key in the removed 428*00b67f09SDavid van Moolenbroek state MUST NOT be considered a valid trust anchor. (Note: 429*00b67f09SDavid van Moolenbroek this state is more or less equivalent to the "Start" state, 430*00b67f09SDavid van Moolenbroek except that it's bad practice to re-introduce previously 431*00b67f09SDavid van Moolenbroek used keys -- think of this as the holding state for all the 432*00b67f09SDavid van Moolenbroek old keys for which the resolver no longer needs to track 433*00b67f09SDavid van Moolenbroek state.) 434*00b67f09SDavid van Moolenbroek 435*00b67f09SDavid van Moolenbroek5. Trust Point Deletion 436*00b67f09SDavid van Moolenbroek 437*00b67f09SDavid van Moolenbroek A trust point that has all of its trust anchors revoked is considered 438*00b67f09SDavid van Moolenbroek deleted and is treated as if the trust point was never configured. 439*00b67f09SDavid van Moolenbroek If there are no superior configured trust points, data at and below 440*00b67f09SDavid van Moolenbroek the deleted trust point are considered insecure by the resolver. If 441*00b67f09SDavid van Moolenbroek there ARE superior configured trust points, data at and below the 442*00b67f09SDavid van Moolenbroek deleted trust point are evaluated with respect to the superior trust 443*00b67f09SDavid van Moolenbroek point(s). 444*00b67f09SDavid van Moolenbroek 445*00b67f09SDavid van Moolenbroek Alternately, a trust point that is subordinate to another configured 446*00b67f09SDavid van Moolenbroek trust point MAY be deleted by a resolver after 180 days, where such a 447*00b67f09SDavid van Moolenbroek 448*00b67f09SDavid van Moolenbroek 449*00b67f09SDavid van Moolenbroek 450*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 8] 451*00b67f09SDavid van Moolenbroek 452*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 453*00b67f09SDavid van Moolenbroek 454*00b67f09SDavid van Moolenbroek 455*00b67f09SDavid van Moolenbroek subordinate trust point validly chains to a superior trust point. 456*00b67f09SDavid van Moolenbroek The decision to delete the subordinate trust anchor is a local 457*00b67f09SDavid van Moolenbroek configuration decision. Once the subordinate trust point is deleted, 458*00b67f09SDavid van Moolenbroek validation of the subordinate zone is dependent on validating the 459*00b67f09SDavid van Moolenbroek chain of trust to the superior trust point. 460*00b67f09SDavid van Moolenbroek 461*00b67f09SDavid van Moolenbroek6. Scenarios - Informative 462*00b67f09SDavid van Moolenbroek 463*00b67f09SDavid van Moolenbroek The suggested model for operation is to have one active key and one 464*00b67f09SDavid van Moolenbroek stand-by key at each trust point. The active key will be used to 465*00b67f09SDavid van Moolenbroek sign the DNSKEY RRSet. The stand-by key will not normally sign this 466*00b67f09SDavid van Moolenbroek RRSet, but the resolver will accept it as a trust anchor if/when it 467*00b67f09SDavid van Moolenbroek sees the signature on the trust point DNSKEY RRSet. 468*00b67f09SDavid van Moolenbroek 469*00b67f09SDavid van Moolenbroek Since the stand-by key is not in active signing use, the associated 470*00b67f09SDavid van Moolenbroek private key may (and should) be provided with additional protections 471*00b67f09SDavid van Moolenbroek not normally available to a key that must be used frequently (e.g., 472*00b67f09SDavid van Moolenbroek locked in a safe, split among many parties, etc). Notionally, the 473*00b67f09SDavid van Moolenbroek stand-by key should be less subject to compromise than an active key, 474*00b67f09SDavid van Moolenbroek but that will be dependent on operational concerns not addressed 475*00b67f09SDavid van Moolenbroek here. 476*00b67f09SDavid van Moolenbroek 477*00b67f09SDavid van Moolenbroek6.1. Adding a Trust Anchor 478*00b67f09SDavid van Moolenbroek 479*00b67f09SDavid van Moolenbroek Assume an existing trust anchor key 'A'. 480*00b67f09SDavid van Moolenbroek 481*00b67f09SDavid van Moolenbroek 1. Generate a new key pair. 482*00b67f09SDavid van Moolenbroek 483*00b67f09SDavid van Moolenbroek 2. Create a DNSKEY record from the key pair and set the SEP and Zone 484*00b67f09SDavid van Moolenbroek Key bits. 485*00b67f09SDavid van Moolenbroek 486*00b67f09SDavid van Moolenbroek 3. Add the DNSKEY to the RRSet. 487*00b67f09SDavid van Moolenbroek 488*00b67f09SDavid van Moolenbroek 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - 489*00b67f09SDavid van Moolenbroek 'A'. 490*00b67f09SDavid van Moolenbroek 491*00b67f09SDavid van Moolenbroek 5. Wait for various resolvers' timers to go off and for them to 492*00b67f09SDavid van Moolenbroek retrieve the new DNSKEY RRSet and signatures. 493*00b67f09SDavid van Moolenbroek 494*00b67f09SDavid van Moolenbroek 6. The new trust anchor will be populated at the resolvers on the 495*00b67f09SDavid van Moolenbroek schedule described by the state table and update algorithm -- see 496*00b67f09SDavid van Moolenbroek Sections 2 and 4 above. 497*00b67f09SDavid van Moolenbroek 498*00b67f09SDavid van Moolenbroek6.2. Deleting a Trust Anchor 499*00b67f09SDavid van Moolenbroek 500*00b67f09SDavid van Moolenbroek Assume existing trust anchors 'A' and 'B' and that you want to revoke 501*00b67f09SDavid van Moolenbroek and delete 'A'. 502*00b67f09SDavid van Moolenbroek 503*00b67f09SDavid van Moolenbroek 504*00b67f09SDavid van Moolenbroek 505*00b67f09SDavid van Moolenbroek 506*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 9] 507*00b67f09SDavid van Moolenbroek 508*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 509*00b67f09SDavid van Moolenbroek 510*00b67f09SDavid van Moolenbroek 511*00b67f09SDavid van Moolenbroek 1. Set the revocation bit on key 'A'. 512*00b67f09SDavid van Moolenbroek 513*00b67f09SDavid van Moolenbroek 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked. 514*00b67f09SDavid van Moolenbroek The operator should include the revoked 'A' in the RRSet for at 515*00b67f09SDavid van Moolenbroek least the remove hold-down time, but then may remove it from the 516*00b67f09SDavid van Moolenbroek DNSKEY RRSet. 517*00b67f09SDavid van Moolenbroek 518*00b67f09SDavid van Moolenbroek6.3. Key Roll-Over 519*00b67f09SDavid van Moolenbroek 520*00b67f09SDavid van Moolenbroek Assume existing keys A and B. 'A' is actively in use (i.e. has been 521*00b67f09SDavid van Moolenbroek signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been 522*00b67f09SDavid van Moolenbroek in the DNSKEY RRSet and is a valid trust anchor, but wasn't being 523*00b67f09SDavid van Moolenbroek used to sign the RRSet). 524*00b67f09SDavid van Moolenbroek 525*00b67f09SDavid van Moolenbroek 1. Generate a new key pair 'C'. 526*00b67f09SDavid van Moolenbroek 2. Add 'C' to the DNSKEY RRSet. 527*00b67f09SDavid van Moolenbroek 3. Set the revocation bit on key 'A'. 528*00b67f09SDavid van Moolenbroek 4. Sign the RRSet with 'A' and 'B'. 529*00b67f09SDavid van Moolenbroek 530*00b67f09SDavid van Moolenbroek 'A' is now revoked, 'B' is now the active key, and 'C' will be the 531*00b67f09SDavid van Moolenbroek stand-by key once the hold-down expires. The operator should include 532*00b67f09SDavid van Moolenbroek the revoked 'A' in the RRSet for at least the remove hold-down time, 533*00b67f09SDavid van Moolenbroek but may then remove it from the DNSKEY RRSet. 534*00b67f09SDavid van Moolenbroek 535*00b67f09SDavid van Moolenbroek6.4. Active Key Compromised 536*00b67f09SDavid van Moolenbroek 537*00b67f09SDavid van Moolenbroek This is the same as the mechanism for Key Roll-Over (Section 6.3) 538*00b67f09SDavid van Moolenbroek above, assuming 'A' is the active key. 539*00b67f09SDavid van Moolenbroek 540*00b67f09SDavid van Moolenbroek6.5. Stand-by Key Compromised 541*00b67f09SDavid van Moolenbroek 542*00b67f09SDavid van Moolenbroek Using the same assumptions and naming conventions as Key Roll-Over 543*00b67f09SDavid van Moolenbroek (Section 6.3) above: 544*00b67f09SDavid van Moolenbroek 545*00b67f09SDavid van Moolenbroek 1. Generate a new key pair 'C'. 546*00b67f09SDavid van Moolenbroek 2. Add 'C' to the DNSKEY RRSet. 547*00b67f09SDavid van Moolenbroek 3. Set the revocation bit on key 'B'. 548*00b67f09SDavid van Moolenbroek 4. Sign the RRSet with 'A' and 'B'. 549*00b67f09SDavid van Moolenbroek 550*00b67f09SDavid van Moolenbroek 'B' is now revoked, 'A' remains the active key, and 'C' will be the 551*00b67f09SDavid van Moolenbroek stand-by key once the hold-down expires. 'B' should continue to be 552*00b67f09SDavid van Moolenbroek included in the RRSet for the remove hold-down time. 553*00b67f09SDavid van Moolenbroek 554*00b67f09SDavid van Moolenbroek6.6. Trust Point Deletion 555*00b67f09SDavid van Moolenbroek 556*00b67f09SDavid van Moolenbroek To delete a trust point that is subordinate to another configured 557*00b67f09SDavid van Moolenbroek trust point (e.g., example.com to .com) requires some juggling of the 558*00b67f09SDavid van Moolenbroek data. The specific process is: 559*00b67f09SDavid van Moolenbroek 560*00b67f09SDavid van Moolenbroek 561*00b67f09SDavid van Moolenbroek 562*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 10] 563*00b67f09SDavid van Moolenbroek 564*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 565*00b67f09SDavid van Moolenbroek 566*00b67f09SDavid van Moolenbroek 567*00b67f09SDavid van Moolenbroek 1. Generate a new DNSKEY and DS record and provide the DS record to 568*00b67f09SDavid van Moolenbroek the parent along with DS records for the old keys. 569*00b67f09SDavid van Moolenbroek 570*00b67f09SDavid van Moolenbroek 2. Once the parent has published the DSs, add the new DNSKEY to the 571*00b67f09SDavid van Moolenbroek RRSet and revoke ALL of the old keys at the same time, while 572*00b67f09SDavid van Moolenbroek signing the DNSKEY RRSet with all of the old and new keys. 573*00b67f09SDavid van Moolenbroek 574*00b67f09SDavid van Moolenbroek 3. After 30 days, stop publishing the old, revoked keys and remove 575*00b67f09SDavid van Moolenbroek any corresponding DS records in the parent. 576*00b67f09SDavid van Moolenbroek 577*00b67f09SDavid van Moolenbroek Revoking the old trust-point keys at the same time as adding new keys 578*00b67f09SDavid van Moolenbroek that chain to a superior trust prevents the resolver from adding the 579*00b67f09SDavid van Moolenbroek new keys as trust anchors. Adding DS records for the old keys avoids 580*00b67f09SDavid van Moolenbroek a race condition where either the subordinate zone becomes unsecure 581*00b67f09SDavid van Moolenbroek (because the trust point was deleted) or becomes bogus (because it 582*00b67f09SDavid van Moolenbroek didn't chain to the superior zone). 583*00b67f09SDavid van Moolenbroek 584*00b67f09SDavid van Moolenbroek7. IANA Considerations 585*00b67f09SDavid van Moolenbroek 586*00b67f09SDavid van Moolenbroek The IANA has assigned a bit in the DNSKEY flags field (see Section 7 587*00b67f09SDavid van Moolenbroek of [RFC4034]) for the REVOKE bit (8). 588*00b67f09SDavid van Moolenbroek 589*00b67f09SDavid van Moolenbroek8. Security Considerations 590*00b67f09SDavid van Moolenbroek 591*00b67f09SDavid van Moolenbroek In addition to the following sections, see also Theory of Operation 592*00b67f09SDavid van Moolenbroek above (Section 2) and especially Section 2.2 for related discussions. 593*00b67f09SDavid van Moolenbroek 594*00b67f09SDavid van Moolenbroek Security considerations for trust anchor rollover not specific to 595*00b67f09SDavid van Moolenbroek this protocol are discussed in [RFC4986]. 596*00b67f09SDavid van Moolenbroek 597*00b67f09SDavid van Moolenbroek8.1. Key Ownership vs. Acceptance Policy 598*00b67f09SDavid van Moolenbroek 599*00b67f09SDavid van Moolenbroek The reader should note that, while the zone owner is responsible for 600*00b67f09SDavid van Moolenbroek creating and distributing keys, it's wholly the decision of the 601*00b67f09SDavid van Moolenbroek resolver owner as to whether to accept such keys for the 602*00b67f09SDavid van Moolenbroek authentication of the zone information. This implies the decision to 603*00b67f09SDavid van Moolenbroek update trust-anchor keys based on trusting a current trust-anchor key 604*00b67f09SDavid van Moolenbroek is also the resolver owner's decision. 605*00b67f09SDavid van Moolenbroek 606*00b67f09SDavid van Moolenbroek The resolver owner (and resolver implementers) MAY choose to permit 607*00b67f09SDavid van Moolenbroek or prevent key status updates based on this mechanism for specific 608*00b67f09SDavid van Moolenbroek trust points. If they choose to prevent the automated updates, they 609*00b67f09SDavid van Moolenbroek will need to establish a mechanism for manual or other out-of-band 610*00b67f09SDavid van Moolenbroek updates, which are outside the scope of this document. 611*00b67f09SDavid van Moolenbroek 612*00b67f09SDavid van Moolenbroek 613*00b67f09SDavid van Moolenbroek 614*00b67f09SDavid van Moolenbroek 615*00b67f09SDavid van Moolenbroek 616*00b67f09SDavid van Moolenbroek 617*00b67f09SDavid van Moolenbroek 618*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 11] 619*00b67f09SDavid van Moolenbroek 620*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 621*00b67f09SDavid van Moolenbroek 622*00b67f09SDavid van Moolenbroek 623*00b67f09SDavid van Moolenbroek8.2. Multiple Key Compromise 624*00b67f09SDavid van Moolenbroek 625*00b67f09SDavid van Moolenbroek This scheme permits recovery as long as at least one valid trust- 626*00b67f09SDavid van Moolenbroek anchor key remains uncompromised, e.g., if there are three keys, you 627*00b67f09SDavid van Moolenbroek can recover if two of them are compromised. The zone owner should 628*00b67f09SDavid van Moolenbroek determine their own level of comfort with respect to the number of 629*00b67f09SDavid van Moolenbroek active, valid trust anchors in a zone and should be prepared to 630*00b67f09SDavid van Moolenbroek implement recovery procedures once they detect a compromise. A 631*00b67f09SDavid van Moolenbroek manual or other out-of-band update of all resolvers will be required 632*00b67f09SDavid van Moolenbroek if all trust-anchor keys at a trust point are compromised. 633*00b67f09SDavid van Moolenbroek 634*00b67f09SDavid van Moolenbroek8.3. Dynamic Updates 635*00b67f09SDavid van Moolenbroek 636*00b67f09SDavid van Moolenbroek Allowing a resolver to update its trust anchor set based on in-band 637*00b67f09SDavid van Moolenbroek key information is potentially less secure than a manual process. 638*00b67f09SDavid van Moolenbroek However, given the nature of the DNS, the number of resolvers that 639*00b67f09SDavid van Moolenbroek would require update if a trust anchor key were compromised, and the 640*00b67f09SDavid van Moolenbroek lack of a standard management framework for DNS, this approach is no 641*00b67f09SDavid van Moolenbroek worse than the existing situation. 642*00b67f09SDavid van Moolenbroek 643*00b67f09SDavid van Moolenbroek9. Normative References 644*00b67f09SDavid van Moolenbroek 645*00b67f09SDavid van Moolenbroek [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646*00b67f09SDavid van Moolenbroek Requirement Levels", BCP 14, RFC 2119, March 1997. 647*00b67f09SDavid van Moolenbroek 648*00b67f09SDavid van Moolenbroek [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 649*00b67f09SDavid van Moolenbroek Signer (DS)", RFC 3755, May 2004. 650*00b67f09SDavid van Moolenbroek 651*00b67f09SDavid van Moolenbroek [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 652*00b67f09SDavid van Moolenbroek Rose, "DNS Security Introduction and Requirements", RFC 653*00b67f09SDavid van Moolenbroek 4033, March 2005. 654*00b67f09SDavid van Moolenbroek 655*00b67f09SDavid van Moolenbroek [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 656*00b67f09SDavid van Moolenbroek Rose, "Resource Records for the DNS Security Extensions", 657*00b67f09SDavid van Moolenbroek RFC 4034, March 2005. 658*00b67f09SDavid van Moolenbroek 659*00b67f09SDavid van Moolenbroek [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 660*00b67f09SDavid van Moolenbroek Rose, "Protocol Modifications for the DNS Security 661*00b67f09SDavid van Moolenbroek Extensions", RFC 4035, March 2005. 662*00b67f09SDavid van Moolenbroek 663*00b67f09SDavid van Moolenbroek10. Informative References 664*00b67f09SDavid van Moolenbroek 665*00b67f09SDavid van Moolenbroek [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, 666*00b67f09SDavid van Moolenbroek "Requirements Related to DNS Security (DNSSEC) Trust 667*00b67f09SDavid van Moolenbroek Anchor Rollover", RFC 4986, August 2007. 668*00b67f09SDavid van Moolenbroek 669*00b67f09SDavid van Moolenbroek 670*00b67f09SDavid van Moolenbroek 671*00b67f09SDavid van Moolenbroek 672*00b67f09SDavid van Moolenbroek 673*00b67f09SDavid van Moolenbroek 674*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 12] 675*00b67f09SDavid van Moolenbroek 676*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 677*00b67f09SDavid van Moolenbroek 678*00b67f09SDavid van Moolenbroek 679*00b67f09SDavid van MoolenbroekAuthor's Address 680*00b67f09SDavid van Moolenbroek 681*00b67f09SDavid van Moolenbroek Michael StJohns 682*00b67f09SDavid van Moolenbroek Independent 683*00b67f09SDavid van Moolenbroek 684*00b67f09SDavid van Moolenbroek EMail: mstjohns@comcast.net 685*00b67f09SDavid van Moolenbroek 686*00b67f09SDavid van Moolenbroek 687*00b67f09SDavid van Moolenbroek 688*00b67f09SDavid van Moolenbroek 689*00b67f09SDavid van Moolenbroek 690*00b67f09SDavid van Moolenbroek 691*00b67f09SDavid van Moolenbroek 692*00b67f09SDavid van Moolenbroek 693*00b67f09SDavid van Moolenbroek 694*00b67f09SDavid van Moolenbroek 695*00b67f09SDavid van Moolenbroek 696*00b67f09SDavid van Moolenbroek 697*00b67f09SDavid van Moolenbroek 698*00b67f09SDavid van Moolenbroek 699*00b67f09SDavid van Moolenbroek 700*00b67f09SDavid van Moolenbroek 701*00b67f09SDavid van Moolenbroek 702*00b67f09SDavid van Moolenbroek 703*00b67f09SDavid van Moolenbroek 704*00b67f09SDavid van Moolenbroek 705*00b67f09SDavid van Moolenbroek 706*00b67f09SDavid van Moolenbroek 707*00b67f09SDavid van Moolenbroek 708*00b67f09SDavid van Moolenbroek 709*00b67f09SDavid van Moolenbroek 710*00b67f09SDavid van Moolenbroek 711*00b67f09SDavid van Moolenbroek 712*00b67f09SDavid van Moolenbroek 713*00b67f09SDavid van Moolenbroek 714*00b67f09SDavid van Moolenbroek 715*00b67f09SDavid van Moolenbroek 716*00b67f09SDavid van Moolenbroek 717*00b67f09SDavid van Moolenbroek 718*00b67f09SDavid van Moolenbroek 719*00b67f09SDavid van Moolenbroek 720*00b67f09SDavid van Moolenbroek 721*00b67f09SDavid van Moolenbroek 722*00b67f09SDavid van Moolenbroek 723*00b67f09SDavid van Moolenbroek 724*00b67f09SDavid van Moolenbroek 725*00b67f09SDavid van Moolenbroek 726*00b67f09SDavid van Moolenbroek 727*00b67f09SDavid van Moolenbroek 728*00b67f09SDavid van Moolenbroek 729*00b67f09SDavid van Moolenbroek 730*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 13] 731*00b67f09SDavid van Moolenbroek 732*00b67f09SDavid van MoolenbroekRFC 5011 Trust Anchor Update September 2007 733*00b67f09SDavid van Moolenbroek 734*00b67f09SDavid van Moolenbroek 735*00b67f09SDavid van MoolenbroekFull Copyright Statement 736*00b67f09SDavid van Moolenbroek 737*00b67f09SDavid van Moolenbroek Copyright (C) The IETF Trust (2007). 738*00b67f09SDavid van Moolenbroek 739*00b67f09SDavid van Moolenbroek This document is subject to the rights, licenses and restrictions 740*00b67f09SDavid van Moolenbroek contained in BCP 78, and except as set forth therein, the authors 741*00b67f09SDavid van Moolenbroek retain all their rights. 742*00b67f09SDavid van Moolenbroek 743*00b67f09SDavid van Moolenbroek This document and the information contained herein are provided on an 744*00b67f09SDavid van Moolenbroek "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 745*00b67f09SDavid van Moolenbroek OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 746*00b67f09SDavid van Moolenbroek THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 747*00b67f09SDavid van Moolenbroek OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 748*00b67f09SDavid van Moolenbroek THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 749*00b67f09SDavid van Moolenbroek WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 750*00b67f09SDavid van Moolenbroek 751*00b67f09SDavid van MoolenbroekIntellectual Property 752*00b67f09SDavid van Moolenbroek 753*00b67f09SDavid van Moolenbroek The IETF takes no position regarding the validity or scope of any 754*00b67f09SDavid van Moolenbroek Intellectual Property Rights or other rights that might be claimed to 755*00b67f09SDavid van Moolenbroek pertain to the implementation or use of the technology described in 756*00b67f09SDavid van Moolenbroek this document or the extent to which any license under such rights 757*00b67f09SDavid van Moolenbroek might or might not be available; nor does it represent that it has 758*00b67f09SDavid van Moolenbroek made any independent effort to identify any such rights. Information 759*00b67f09SDavid van Moolenbroek on the procedures with respect to rights in RFC documents can be 760*00b67f09SDavid van Moolenbroek found in BCP 78 and BCP 79. 761*00b67f09SDavid van Moolenbroek 762*00b67f09SDavid van Moolenbroek Copies of IPR disclosures made to the IETF Secretariat and any 763*00b67f09SDavid van Moolenbroek assurances of licenses to be made available, or the result of an 764*00b67f09SDavid van Moolenbroek attempt made to obtain a general license or permission for the use of 765*00b67f09SDavid van Moolenbroek such proprietary rights by implementers or users of this 766*00b67f09SDavid van Moolenbroek specification can be obtained from the IETF on-line IPR repository at 767*00b67f09SDavid van Moolenbroek http://www.ietf.org/ipr. 768*00b67f09SDavid van Moolenbroek 769*00b67f09SDavid van Moolenbroek The IETF invites any interested party to bring to its attention any 770*00b67f09SDavid van Moolenbroek copyrights, patents or patent applications, or other proprietary 771*00b67f09SDavid van Moolenbroek rights that may cover technology that may be required to implement 772*00b67f09SDavid van Moolenbroek this standard. Please address the information to the IETF at 773*00b67f09SDavid van Moolenbroek ietf-ipr@ietf.org. 774*00b67f09SDavid van Moolenbroek 775*00b67f09SDavid van Moolenbroek 776*00b67f09SDavid van Moolenbroek 777*00b67f09SDavid van Moolenbroek 778*00b67f09SDavid van Moolenbroek 779*00b67f09SDavid van Moolenbroek 780*00b67f09SDavid van Moolenbroek 781*00b67f09SDavid van Moolenbroek 782*00b67f09SDavid van Moolenbroek 783*00b67f09SDavid van Moolenbroek 784*00b67f09SDavid van Moolenbroek 785*00b67f09SDavid van Moolenbroek 786*00b67f09SDavid van MoolenbroekStJohns Standards Track [Page 14] 787*00b67f09SDavid van Moolenbroek 788