idnits 2.17.1 draft-ietf-dnsext-trustupdate-threshold-00.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 795. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 811), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 12) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 18, 2004) is 7127 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: '6' is defined on line 700, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3757 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-11) exists of draft-ietf-dnsext-dnssec-records-10 == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-dnssec-intro-12 == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-dnssec-operational-practices-01 -- Obsolete informational reference (is this intentional?): RFC 2459 (ref. '6') (Obsoleted by RFC 3280) Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Ihren 2 Internet-Draft Autonomica AB 3 Expires: April 18, 2005 O. Kolkman 4 RIPE NCC 5 B. Manning 6 EP.net 7 October 18, 2004 9 An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for 10 DNSSEC Trust Anchors. 11 draft-ietf-dnsext-trustupdate-threshold-00 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 18, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 The DNS Security Extensions (DNSSEC) works by validating so called 45 chains of authority. The start of these chains of authority are 46 usually public keys that are anchored in the DNS clients. These keys 47 are known as the so called trust anchors. 49 This memo describes a method how these client trust anchors can be 50 replaced using the DNS validation and querying mechanisms (in-band) 51 when the key pairs used for signing by zone owner are rolled. 53 This memo also describes a method to establish the validity of trust 54 anchors for initial configuration, or priming, using out of band 55 mechanisms. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry 61 Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction and Background . . . . . . . . . . . . . . . . . 5 63 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 64 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 65 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 67 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 68 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 69 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 70 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 71 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 72 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 73 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 74 3.6 Removal of trust anchors for a trust point . . . . . . . . 12 75 3.7 No need for resolver-side overlap of old and new keys . . 13 76 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 77 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.1.1 Bootstrapping trust anchors using a priming key . . . 14 79 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 80 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 6.1 Threshold-based Trust Update Security Considerations . . . 17 83 6.2 Priming Key Security Considerations . . . . . . . . . . . 17 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 87 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 89 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 90 B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23 91 B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23 92 B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23 93 Intellectual Property and Copyright Statements . . . . . . . . 24 95 1. Terminology 97 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 98 and "MAY" in this document are to be interpreted as described in 99 RFC2119 [1]. 101 The term "zone" refers to the unit of administrative control in the 102 Domain Name System. In this document "name server" denotes a DNS 103 name server that is authoritative (i.e. knows all there is to know) 104 for a DNS zone. A "zone owner" is the entity responsible for signing 105 and publishing a zone on a name server. The terms "authentication 106 chain", "bogus", "trust anchors" and "Island of Security" are defined 107 in [4]. Throughout this document we use the term "resolver" to mean 108 "Validating Stub Resolvers" as defined in [4]. 110 We use the term "security apex" as the zone for which a trust anchor 111 has been configured (by validating clients) and which is therefore, 112 by definition, at the root of an island of security. The 113 configuration of trust anchors is a client side issue. Therefore a 114 zone owner may not always know if their zone has become a security 115 apex. 117 A "stale anchor" is a trust anchor (a public key) that relates to a 118 key that is not used for signing. Since trust anchors indicate that 119 a zone is supposed to be secure a validator will mark the all data in 120 an island of security as bogus when all trust anchors become stale. 122 It is assumed that the reader is familiar with public key 123 cryptography concepts [REF: Schneier Applied Cryptography] and is 124 able to distinguish between the private and public parts of a key 125 based on the context in which we use the term "key". If there is a 126 possible ambiguity we will explicitly mention if a private or a 127 public part of a key is used. 129 The term "administrator" is used loosely throughout the text. In 130 some cases an administrator is meant to be a person, in other cases 131 the administrator may be a process that has been delegated certain 132 responsibilities. 134 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points 136 Although the DNSSEC protocol does not make a distinction between 137 different keys the operational practice is that a distinction is made 138 between zone signing keys and key signing keys. A key signing key is 139 used to exclusively sign the DNSKEY Resource Record (RR) set at the 140 apex of a zone and the zone signing keys sign all the data in the 141 zone (including the DNSKEY RRset at the apex). 143 Keys that are intended to be used as the start of the authentication 144 chain for a particular zone, either because they are pointed to by a 145 parental DS RR or because they are configured as a trust anchor, are 146 called Secure Entry Point (SEP) keys. In practice these SEP keys 147 will be key signing keys. 149 In order for the mechanism described herein to work the keys that are 150 intended to be used as secure entry points MUST have the SEP [2] flag 151 set. In the examples it is assumed that keys with the SEP flag set 152 are used as key signing keys and thus exclusively sign the DNSKEY 153 RRset published at the apex of the zone. 155 2. Introduction and Background 157 When DNSSEC signatures are validated the resolver constructs a chain 158 of authority from a pre-configured trust anchor to the DNSKEY 159 Resource Record (RR), which contains the public key that validates 160 the signature stored in an RRSIG RR. DNSSEC is designed so that the 161 administrator of a resolver can validate data in multiple islands of 162 security by configuring multiple trust anchors. 164 It is expected that resolvers will have more than one trust anchor 165 configured. Although there is no deployment experience it is not 166 unreasonable to expect resolvers to be configured with a number of 167 trust anchors that varies between order 1 and order 1000. Because 168 zone owners are expected to roll their keys, trust anchors will have 169 to be maintained (in the resolver end) in order not to become stale. 171 Since there is no global key maintenance policy for zone owners and 172 there are no mechanisms in the DNS to signal the key maintenance 173 policy it may be very hard for resolvers administrators to keep their 174 set of trust anchors up to date. For instance, if there is only one 175 trust anchor configured and the key maintenance policy is clearly 176 published, through some out of band trusted channel, then a resolver 177 administrator can probably keep track of key rollovers and update the 178 trust anchor manually. However, with an increasing number of trust 179 anchors all rolled according to individual policies that are all 180 published through different channels this soon becomes an 181 unmanageable problem. 183 2.1 Dangers of Stale Trust Anchors 185 Whenever a SEP key at a security apex is rolled there exists a danger 186 that "stale anchors" are created. A stale anchor is a trust anchor 187 (i.e. a public key configured in a validating resolver) that relates 188 to a private key that is no longer used for signing. 190 The problem with a stale anchors is that they will (from the 191 validating resolvers point of view) prove data to be false even 192 though it is actually correct. This is because the data is either 193 signed by a new key or is no longer signed and the resolver expects 194 data to be signed by the old (now stale) key. 196 This situation is arguably worse than not having a trusted key 197 configured for the secure entry point, since with a stale key no 198 lookup is typically possible (presuming that the default 199 configuration of a validating recursive nameserver is to not give out 200 data that is signed but failed to verify. 202 The danger of making configured trust anchors become stale anchors 203 may be a reason for zone owners not to roll their keys. If a 204 resolver is configured with many trust anchors that need manual 205 maintenance it may be easy to not notice a key rollover at a security 206 apex, resulting in a stale anchor. 208 In Section 3 this memo sets out a lightweight, in-DNS, mechanism to 209 track key rollovers and modify the configured trust anchors 210 accordingly. The mechanism is stateless and does not need protocol 211 extensions. The proposed design is that this mechanism is 212 implemented as a "trust updating machine" that is run entirely 213 separate from the validating resolver except that the trust updater 214 will have influence over the trust anchors used by the latter. 216 In Section 4 we describe a method [Editors note: for now only the 217 frame work and a set of requirements] to install trust anchors. This 218 method can be used at first configuration or when the trust anchors 219 became stale (typically due to a failure to track several rollover 220 events). 222 The choice for which domains trust anchors are to be configured is a 223 local policy issue. So is the choice which trust anchors has 224 prevalence if there are multiple chains of trust to a given piece of 225 DNS data (e.g. when a parent zone and its child both have trust 226 anchors configured). Both issues are out of the scope of this 227 document. 229 3. Threshold-based Trust Anchor Rollover 231 3.1 The Rollover 233 When a key pair is replaced all signatures (in DNSSEC these are the 234 RRSIG records) created with the old key will be replaced by new 235 signatures created by the new key. Access to the new public key is 236 needed to verify these signatures. 238 Since zone signing keys are in "the middle" of a chain of authority 239 they can be verified using the signature made by a key signing key. 240 Rollover of zone signing keys is therefore transparent to validators 241 and requires no action in the validator end. 243 But if a key signing key is rolled a resolver can determine its 244 authenticity by either following the authorization chain from the 245 parents DS record, an out-of-DNS authentication mechanism or by 246 relying on other trust anchors known for the zone in which the key is 247 rolled. 249 The threshold trust anchor rollover mechanism (or trust update), 250 described below, is based on using existing trust anchors to verify a 251 subset of the available signatures. This is then used as the basis 252 for a decision to accept the new keys as valid trust anchors. 254 Our example pseudo zone below contains a number of key signing keys 255 numbered 1 through Y and two zone signing keys A and B. During a key 256 rollover key 2 is replaced by key Y+1. The zone content changes 257 from: 259 example.com. DNSKEY key1 260 example.com. DNSKEY key2 261 example.com. DNSKEY key3 262 ... 263 example.com. DNSKEY keyY 265 example.com. DNSKEY keyA 266 example.com. DNSKEY keyB 268 example.com. RRSIG DNSKEY ... (key1) 269 example.com. RRSIG DNSKEY ... (key2) 270 example.com. RRSIG DNSKEY ... (key3) 271 ... 272 example.com. RRSIG DNSKEY ... (keyY) 273 example.com. RRSIG DNSKEY ... (keyA) 274 example.com. RRSIG DNSKEY ... (keyB) 276 to: 278 example.com. DNSKEY key1 279 example.com. DNSKEY key3 280 ... 281 example.com. DNSKEY keyY 282 example.com. DNSKEY keyY+1 284 example.com. RRSIG DNSKEY ... (key1) 285 example.com. RRSIG DNSKEY ... (key3) 286 ... 287 example.com. RRSIG DNSKEY ... (keyY) 288 example.com. RRSIG DNSKEY ... (keyY+1) 289 example.com. RRSIG DNSKEY ... (keyA) 290 example.com. RRSIG DNSKEY ... (keyB) 292 When the rollover becomes visible to the verifying stub resolver it 293 will be able to verify the RRSIGs associated with key1, key3 ... 294 keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will 295 not be used for validation, since that key is previously unknown and 296 therefore not trusted. 298 Note that this example is simplified. Because of operational 299 considerations described in [5] having a period during which the two 300 key signing keys are both available is necessary. 302 3.2 Threshold-based Trust Update 304 The threshold-based trust update algorithm applies as follows. If 305 for a particular secure entry point 306 o if the DNSKEY RRset in the zone has been replaced by a more recent 307 one (as determined by comparing the RRSIG inception dates) 308 and 309 o if at least M configured trust anchors directly verify the related 310 RRSIGs over the new DNSKEY RRset 311 and 312 o the number of configured trust anchors that verify the related 313 RRSIGs over the new DNSKEY RRset exceed a locally defined minimum 314 number that should be greater than one 315 then all the trust anchors for the particular secure entry point are 316 replaced by the set of keys from the zones DNSKEY RRset that have the 317 SEP flag set. 319 The choices for the rollover acceptance policy parameter M is left to 320 the administrator of the resolver. To be certain that a rollover is 321 accepted up by resolvers using this mechanism zone owners should roll 322 as few SEP keys at a time as possible (preferably just one). That 323 way they comply to the most strict rollover acceptance policy of 324 M=N-1. 326 The value of M has an upper bound, limited by the number of of SEP 327 keys a zone owner publishes (i.e. N). But there is also a lower 328 bound, since it will not be safe to base the trust in too few 329 signatures. The corner case is M=1 when any validating RRSIG will be 330 sufficient for a complete replacement of the trust anchors for that 331 secure entry point. This is not a recommended configuration, since 332 that will allow an attacker to initiate rollover of the trust anchors 333 himself given access to just one compromised key. Hence M should in 334 be strictly larger than 1 as shown by the third requirement above. 336 If the rollover acceptance policy is M=1 then the result for the 337 rollover in our example above should be that the local database of 338 trust anchors is updated by removing key "key2" from and adding key 339 "keyY+1" to the key store. 341 3.3 Possible Trust Update States 343 We define five states for trust anchor configuration at the client 344 side. 345 PRIMING: There are no trust anchors configured. There may be priming 346 keys available for initial priming of trust anchors. 347 IN-SYNC: The set of trust anchors configured exactly matches the set 348 of SEP keys used by the zone owner to sign the zone. 349 OUT-OF-SYNC: The set of trust anchors is not exactly the same as the 350 set of SEP keys used by the zone owner to sign the zone but there 351 are enough SEP key in use by the zone owner that is also in the 352 trust anchor configuration. 353 UNSYNCABLE: There is not enough overlap between the configured trust 354 anchors and the set of SEP keys used to sign the zone for the new 355 set to be accepted by the validator (i.e. the number of 356 signatures that verify is not sufficient). 357 STALE: There is no overlap between the configured trust anchors and 358 the set of SEP keys used to sign the zone. Here validation of 359 data is no longer possible and hence we are in a situation where 360 the trust anchors are stale. 362 Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of 363 the automatic trust update mechanism. The PRIMING state is where a 364 validator is located before acquiring an up-to-date set of trust 365 anchors. The transition from PRIMING to IN-SYNC is manual (see 366 Section 4 below). 368 Example: assume a secure entry point with four SEP keys and a 369 validator with the policy that it will accept any update to the set 370 of trust anchors as long as no more than two signatures fail to 371 validate (i.e. M >= N-2) and at least two signature does validate 372 (i.e. M >= 2). In this case the rollover of a single key will move 373 the validator from IN-SYNC to OUT-OF-SYNC. When the trust update 374 state machine updates the trust anchors it returns to state IN-SYNC. 376 If if for some reason it fails to update the trust anchors then the 377 next rollover (of a different key) will move the validator from 378 OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys 379 that are configured as trust anchors and that is sufficient to accpt 380 an automatic update of the trust anchors. 382 The UNSYNCABLE state is where a validator is located if it for some 383 reason fails to incorporate enough updates to the trust anchors to be 384 able to accept new updates according to its local policy. In this 385 example (i.e. with the policy specified above) this will either be 386 because M < N-2 or M < 2, which does not suffice to authenticate a 387 successful update of trust anchors. 389 Continuing with the previous example where two of the four SEP keys 390 have already rolled, but the validator has failed to update the set 391 of trust anchors. When the third key rolls over there will only be 392 one trust anchor left that can do successful validation. This is not 393 sufficient to enable automatic update of the trust anchors, hence the 394 new state is UNSYNCABLE. Note, however, that the remaining 395 up-to-date trust anchor is still enough to do successful validation 396 so the validator is still "working" from a DNSSEC point of view. 398 The STALE state, finally, is where a validator ends up when it has 399 zero remaining current trust anchors. This is a dangerous state, 400 since the stale trust anchors will cause all validation to fail. The 401 escape is to remove the stale trust anchors and thereby revert to the 402 PRIMING state. 404 3.4 Implementation notes 406 The DNSSEC protocol specification ordains that a DNSKEY to which a DS 407 record points should be self-signed. Since the keys that serve as 408 trust anchors and the keys that are pointed to by DS records serve 409 the same purpose, they are both secure entry points, we RECOMMEND 410 that zone owners who want to facilitate the automated rollover scheme 411 documented herein self-sign DNSKEYs with the SEP bit set and that 412 implementation check that DNSKEYs with the SEP bit set are 413 self-signed. 415 In order to maintain a uniform way of determining that a keyset in 416 the zone has been replaced by a more recent set the automatic trust 417 update machine SHOULD only accept new DNSKEY RRsets if the 418 accompanying RRSIGs show a more recent inception date than the 419 present set of trust anchors. This is also needed as a safe guard 420 against possible replay attacks where old updates are replayed 421 "backwards" (i.e. one change at a time, but going in the wrong 422 direction, thereby luring the validator into the UNSYNCABLE and 423 finally STALE states). 425 In order to be resilient against failures the implementation should 426 collect the DNSKEY RRsets from (other) authoritative servers if 427 verification of the self signatures fails. 429 The threshold-based trust update mechanism SHOULD only be applied to 430 algorithms, as represented in the algorithm field in the DNSKEY/RRSIG 431 [3], that the resolver is aware of. In other words the SEP keys of 432 unknown algorithms should not be used when counting the number of 433 available signatures (the N constant) and the SEP keys of unknown 434 algorithm should not be entered as trust anchors. 436 When in state UNSYNCABLE or STALE manual intervention will be needed 437 to return to the IN-SYNC state. These states should be flagged. The 438 most appropriate action is human audit possibly followed by 439 re-priming (Section 4) the keyset (i.e. manual transfer to the 440 PRIMING state through removal of the configured trust anchors). 442 An implementation should regularly probe the the authoritative 443 nameservers for new keys. Since there is no mechanism to publish 444 rollover frequencies this document RECOMMENDS zone owners not to roll 445 their key signing keys more often than once per month and resolver 446 administrators to probe for key rollsovers (and apply the threshold 447 criterion for acceptance of trust update) not less often than once 448 per month. If the rollover frequency is higher than the probing 449 frequency then trust anchors may become stale. The exact relation 450 between the frequencies depends on the number of SEP keys rolled by 451 the zone owner and the value M configured by the resolver 452 administrator. 454 In all the cases below a transaction where the threshold criterion is 455 not satisfied should be considered bad (i.e. possibly spoofed or 456 otherwise corrupted data). The most appropriate action is human 457 audit. 459 There is one case where a "bad" state may be escaped from in an 460 automated fashion. This is when entering the STALE state where all 461 DNSSEC validation starts to fail. If this happens it is concievable 462 that it is better to completely discard the stale trust anchors 463 (thereby reverting to the PRIMING state where validation is not 464 possible). A local policy that automates removal of stale trust 465 anchors is therefore suggested. 467 3.5 Possible transactions 468 3.5.1 Single DNSKEY replaced 470 This is probably the most typical transaction on the zone owners 471 part. The result should be that if the threshold criterion is 472 satisfied then the key store is updated by removal of the old trust 473 anchor and addition of the new key as a new trust anchor. Note that 474 if the DNSKEY RRset contains exactly M keys replacement of keys is 475 not possible, i.e. for automatic rollover to work M must be stricly 476 less than N. 478 3.5.2 Addition of a new DNSKEY (no removal) 480 If the threshold criterion is satisfied then the new key is added as 481 a configured trust anchor. Not more than N-M keys can be added at 482 once, since otherwise the algorithm will fail. 484 3.5.3 Removal of old DNSKEY (no addition) 486 If the threshold criterion is satisfied then the old key is removed 487 from being a configured trust anchor. Note that it is not possible 488 to reduce the size of the DNSKEY RRset to a size smaller than the 489 minimum required value for M. 491 3.5.4 Multiple DNSKEYs replaced 493 Arguably it is not a good idea for the zone administrator to replace 494 several keys at the same time, but from the resolver point of view 495 this is exactly what will happen if the validating resolver for some 496 reason failed to notice a previous rollover event. 498 Not more than N-M keys can be replaced at one time or the threshold 499 criterion will not be satisfied. Or, expressed another way: as long 500 as the number of changed keys is less than or equal to N-M the 501 validator is in state OUT-OF-SYNC. When the number of changed keys 502 becomes greater than N-M the state changes to UNSYNCABLE and manual 503 action is needed. 505 3.6 Removal of trust anchors for a trust point 507 If the parent of a secure entry point gets signed and it's trusted 508 keys get configured in the key store of the validating resolver then 509 the configured trust anchors for the child should be removed entirely 510 unless explicitly configured (in the utility configuration) to be an 511 exception. 513 The reason for such a configuration would be that the resolver has a 514 local policy that requires maintenance of trusted keys further down 515 the tree hierarchy than strictly needed from the point of view. 517 The default action when the parent zone changes from unsigned to 518 signed should be to remove the configured trust anchors for the 519 child. This form of "garbage collect" will ensure that the automatic 520 rollover machinery scales as DNSSEC deployment progresses. 522 3.7 No need for resolver-side overlap of old and new keys 524 It is worth pointing out that there is no need for the resolver to 525 keep state about old keys versus new keys, beyond the requirement of 526 tracking signature inception time for the covering RRSIGs as 527 described in Section 3.4. 529 From the resolver point of view there are only trusted and not 530 trusted keys. The reason is that the zone owner needs to do proper 531 maintenance of RRSIGs regardless of the resolver rollover mechanism 532 and hence must ensure that no key rolled out out the DNSKEY set until 533 there cannot be any RRSIGs created by this key still legally cached. 535 Hence the rollover mechanism is entirely stateless with regard to the 536 keys involved: as soon as the resolver (or in this case the rollover 537 tracking utility) detects a change in the DNSKEY RRset (i.e. it is 538 now in the state OUT-OF-SYNC) with a sufficient number of matching 539 RRSIGs the configured trust anchors are immediately updated (and 540 thereby the machine return to state IN-SYNC). I.e. the rollover 541 machine changes states (mostly oscillating between IN-SYNC and 542 OUT-OF-SYNC), but the status of the DNSSEC keys is stateless. 544 4. Bootstrapping automatic rollovers 546 It is expected that with the ability to automatically roll trust 547 anchors at trust points will follow a diminished unwillingness to 548 roll these keys, since the risks associated with stale keys are 549 minimized. 551 The problem of "priming" the trust anchors, or bringing them into 552 sync (which could happen if a resolver is off line for a long period 553 in which a set of SEP keys in a zone 'evolve' away from its trust 554 anchor configuration) remains. 556 For (re)priming we can rely on out of band technology and we propose 557 the following framework. 559 4.1 Priming Keys 561 If all the trust anchors roll somewhat frequently (on the order of 562 months or at most about a year) then it will not be possible to 563 design a device, or a software distribution that includes trust 564 anchors, that after being manufactured is put on a shelf for several 565 key rollover periods before being brought into use (since no trust 566 anchors that were known at the time of manufacture remain active). 568 To alleviate this we propose the concept of "priming keys". Priming 569 keys are ordinary DNSSEC Key Signing Keys with the characteristic 570 that 571 o The private part of a priming key signs the DNSKEY RRset at the 572 security apex, i.e. at least one RRSIG DNSKEY is created by a 573 priming key rather than by an "ordinary" trust anchor 574 o the public parts of priming keys are not included in the DNSKEY 575 RRset. Instead the public parts of priming keys are only 576 available out-of-band. 577 o The public parts of the priming keys have a validity period. 578 Within this period they can be used to obtain trust anchors. 579 o The priming key pairs are long lived (relative to the key rollover 580 period.) 582 4.1.1 Bootstrapping trust anchors using a priming key 584 To install the trust anchors for a particular security apex an 585 administrator of a validating resolver will need to: 586 o query for the DNSKEY RRset of the zone at the security apex; 587 o verify the self signatures of all DNSKEYs in the RRset; 588 o verify the signature of the RRSIG made with a priming key -- 589 verification using one of the public priming keys that is valid at 590 that moment is sufficient; 592 o create the trust anchors by extracting the DNSKEY RRs with the SEP 593 flag set. 594 The SEP keys with algorithms unknown to the validating resolver 595 SHOULD be ignored during the creation of the trust anchors. 597 4.1.2 Distribution of priming keys 599 The public parts of the priming keys SHOULD be distributed 600 exclusively through out-of-DNS mechanisms. The requirements for a 601 distribution mechanism are: 602 o it can carry the "validity" period for the priming keys; 603 o it can carry the self-signature of the priming keys; 604 o and it allows for verification using trust relations outside the 605 DNS. 606 A distribution mechanism would benefit from: 607 o the availability of revocation lists; 608 o the ability of carrying zone owners policy information such as 609 recommended values for "M" and "N" and a rollover frequency; 610 o and the technology on which is based is readily available. 612 5. The Threshold Rollover Mechanism vs Priming 614 There is overlap between the threshold-based trust updater and the 615 Priming method. One could exclusively use the Priming method for 616 maintaining the trust anchors. However the priming method probably 617 relies on "non-DNS' technology and may therefore not be available for 618 all devices that have a resolver. 620 6. Security Considerations 622 6.1 Threshold-based Trust Update Security Considerations 624 A clear issue for resolvers will be how to ensure that they track all 625 rollover events for the zones they have configure trust anchors for. 626 Because of temporary outages validating resolvers may have missed a 627 rollover of a KSK. The parameters that determine the robustness 628 against failures are: the length of the period between rollovers 629 during which the KSK set is stable and validating resolvers can 630 actually notice the change; the number of available KSKs (i.e. N) 631 and the number of signatures that may fail to validate (i.e. N-M). 633 With a large N (i.e. many KSKs) and a small value of M this 634 operation becomes more robust since losing one key, for whatever 635 reason, will not be crucial. Unfortunately the choice for the number 636 of KSKs is a local policy issue for the zone owner while the choice 637 for the parameter M is a local policy issue for the resolver 638 administrator. 640 Higher values of M increase the resilience against attacks somewhat; 641 more signatures need to verify for a rollover to be approved. On the 642 other hand the number of rollover events that may pass unnoticed 643 before the resolver reaches the UNSYNCABLE state goes down. 645 The threshold-based trust update intentionally does not provide a 646 revocation mechanism. In the case that a sufficient number of 647 private keys of a zone owner are simultaneously compromised the the 648 attacker may use these private keys to roll the trust anchors of (a 649 subset of) the resolvers. This is obviously a bad situation but it 650 is not different from most other public keys systems. 652 However, it is important to point out that since any reasonable trust 653 anchor rollover policy (in validating resolvers) will require more 654 than one RRSIG to validate this proposal does provide security 655 concious zone administrators with the option of not storing the 656 individual private keys in the same location and thereby decreasing 657 the likelihood of simultaneous compromise. 659 6.2 Priming Key Security Considerations 661 Since priming keys are not included in the DNSKEY RR set they are 662 less sensitive to packet size constraints and can be chosen 663 relatively large. The private parts are only needed to sign the 664 DNSKEY RR set during the validity period of the particular priming 665 key pair. Note that the private part of the priming key is used each 666 time when a DNSKEY RRset has to be resigned. In practice there is 667 therefore little difference between the usage pattern of the private 668 part of key signing keys and priming keys. 670 7. IANA Considerations 672 NONE. 674 8. References 676 8.1 Normative References 678 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 679 Levels", BCP 14, RFC 2119, March 1997. 681 [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY 682 (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", 683 RFC 3757, May 2004. 685 [3] Arends, R., "Resource Records for the DNS Security Extensions", 686 draft-ietf-dnsext-dnssec-records-10 (work in progress), 687 September 2004. 689 8.2 Informative References 691 [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, 692 "DNS Security Introduction and Requirements", 693 draft-ietf-dnsext-dnssec-intro-12 (work in progress), September 694 2004. 696 [5] Kolkman, O., "DNSSEC Operational Practices", 697 draft-ietf-dnsop-dnssec-operational-practices-01 (work in 698 progress), May 2004. 700 [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 701 Public Key Infrastructure Certificate and CRL Profile", RFC 702 2459, January 1999. 704 Authors' Addresses 706 Johan Ihren 707 Autonomica AB 708 Bellmansgatan 30 709 Stockholm SE-118 47 710 Sweden 712 EMail: johani@autonomica.se 713 Olaf M. Kolkman 714 RIPE NCC 715 Singel 256 716 Amsterdam 1016 AB 717 NL 719 Phone: +31 20 535 4444 720 EMail: olaf@ripe.net 721 URI: http://www.ripe.net/ 723 Bill Manning 724 EP.net 725 Marina del Rey, CA 90295 726 USA 728 Appendix A. Acknowledgments 730 The present design for in-band automatic rollovers of DNSSEC trust 731 anchors is the result of many conversations and it is no longer 732 possible to remember exactly who contributed what. 734 In addition we've also had appreciated help from (in no particular 735 order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt 736 Larson and Mark Kosters. 738 Appendix B. Document History 740 This appendix will be removed if and when the document is submitted 741 to the RFC editor. 743 The version you are reading is tagged as $Revision: 1.3 $. 745 Text between square brackets, other than references, are editorial 746 comments and will be removed. 748 B.1 prior to version 00 750 This draft was initially published as a personal submission under the 751 name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. 753 Kolkman documented the ideas provided by Ihren and Manning. In the 754 process of documenting (and prototyping) Kolkman changed some of the 755 details of the M-N algorithms working. Ihren did not have a chance 756 to review the draft before Kolkman posted; 758 Kolkman takes responsibilities for omissions, fuzzy definitions and 759 mistakes. 761 B.2 version 00 762 o The name of the draft was changed as a result of the draft being 763 adopted as a working group document. 764 o A small section on the concept of stale trust anchors was added. 765 o The different possible states are more clearly defined, including 766 examples of transitions between states. 767 o The terminology is changed throughout the document. The old term 768 "M-N" is replaced by "threshold" (more or less). Also the 769 interpretation of the constants M and N is significantly 770 simplified to bring the usage more in line with "standard" 771 threshold terminlogy. 773 Intellectual Property Statement 775 The IETF takes no position regarding the validity or scope of any 776 Intellectual Property Rights or other rights that might be claimed to 777 pertain to the implementation or use of the technology described in 778 this document or the extent to which any license under such rights 779 might or might not be available; nor does it represent that it has 780 made any independent effort to identify any such rights. Information 781 on the procedures with respect to rights in RFC documents can be 782 found in BCP 78 and BCP 79. 784 Copies of IPR disclosures made to the IETF Secretariat and any 785 assurances of licenses to be made available, or the result of an 786 attempt made to obtain a general license or permission for the use of 787 such proprietary rights by implementers or users of this 788 specification can be obtained from the IETF on-line IPR repository at 789 http://www.ietf.org/ipr. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights that may cover technology that may be required to implement 794 this standard. Please address the information to the IETF at 795 ietf-ipr@ietf.org. 797 Disclaimer of Validity 799 This document and the information contained herein are provided on an 800 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 801 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 802 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 803 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 804 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 805 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 807 Copyright Statement 809 Copyright (C) The Internet Society (2004). This document is subject 810 to the rights, licenses and restrictions contained in BCP 78, and 811 except as set forth therein, the authors retain all their rights. 813 Acknowledgment 815 Funding for the RFC Editor function is currently provided by the 816 Internet Society.