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