idnits 2.17.1 draft-ietf-dnsop-dnssec-trust-history-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2010) is 5048 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) -- Obsolete informational reference (is this intentional?): RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations W. Wijngaards 3 Internet-Draft O. Kolkman 4 Intended status: Standards Track NLnet Labs 5 Expires: December 31, 2010 June 29, 2010 7 DNSSEC Trust Anchor History Service 8 draft-ietf-dnsop-dnssec-trust-history-02 10 Abstract 12 When DNS validators have trusted keys, but have been offline for a 13 longer period, key rollover will fail and they are stuck with stale 14 trust anchors. History service allows validators to query for older 15 DNSKEY RRsets and pick up the rollover trail where they left off. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 31, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 This memo defines a trust history service for DNS validators -- the 58 component in a resolver that performs DNSSEC [RFC4034] validation, 59 validator for short. 61 A validator that has been offline or missed an (emergency) rollover 62 can use this service to reconfigure themselves with the current 63 trust-anchor. Using a newly defined resource record (RR) that links 64 old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY 65 RRsets and checks they form a chain to the latest key (see 66 Section 3). The lists of old DNSKEYS, linked with the TALINK RRs, do 67 not necessarily need to be published in the zone for which the DNSKEY 68 history is being maintained but can be published in any DNS domain. 69 We will call the entity that offers the trust history the History 70 Provider. The choice of the History Provider is made by the 71 maintainer of the validator, possibly based on a hint provided, using 72 the TALINK, by the zone owner. 74 Section 2 provides background on the mechanism and usage. It looks 75 at the viewpoints of publishers and consumers of trust anchors, the 76 use of keys with revocation flags, and SEP flags. 78 The algorithm that the validator uses to construct a history and 79 reconfigure a new key is detailed in Section 4, it uses the TALINK RR 80 type defined in Section 3. The algorithms for how providers of trust 81 history can fetch the DNSKEY data as published by the zone they track 82 and publish that are explained in Section 5. 84 2. Motivation and Description 86 Validators provide a service in DNSSEC that can be seen from two 87 ways. Seen from the publisher's point of view, they provide 88 assurance that the data as received is as it was when it left the 89 publisher's hands. In this way of looking at things, validators 90 provide a publication integrity service. The publisher can be 91 confident that nobody can alter the published data (if it is 92 validated), because any alteration will be detected. So it protects 93 a publisher from being seen to send someone to the wrong place. 95 From the consumer's point of view, validators provide a reason to 96 trust the data from the network. In this view, the validator is 97 making a claim about whether the data ought to be accepted or not. 98 This is subtly different from the publisher's point of view, because 99 the question for the consumer is not whether the data is safe while 100 the consumer is not looking, but whether the data is safe for the 101 consumer at the moment of consumption. Validation protects a 102 consumer from going to the wrong place. 104 These two slightly different ways of looking at the situation result 105 in slightly different operational goals. Whereas publishers want to 106 make assertions about their data, by controlling the roll over of 107 keys, consumers want to get the best assurance that they can get that 108 the data they are consuming is correct. 110 If a validator has been offline during a key rollover event for one 111 of its trust anchors, then the validator will be unable to validate 112 answers that need that trust anchor. For the publisher, this state 113 of affairs is acceptable: the publisher is confident that no 114 validator ever consumes the wrong data. For the consumer, however, 115 this state of affairs represents an outage. 117 Since publishers of trust anchors already use a chained series of 118 keys to perform rollovers under some circumstances (see [RFC5011]), 119 it is possible to use the history of that chain to allow a validator 120 to resume service for the consumer without needing to use an out-of- 121 band mechanism to obtain a new trust anchor. This improves the 122 experience for consumers of validated data, and increases the chances 123 that DNSSEC is useful for consumers of DNS data. 125 The mechanism to do this is a double-linked list that recounts a 126 portion of the history of DNSKEY Resource Records. The list is used 127 by a validator to catch up with the changes that the validator 128 somehow missed. This approach may be thought of as replaying the 129 [RFC5011] rollover history, only at a later time. 131 2.1. Considerations for Using a Revoked Key 133 The keys that the publisher rolled are marked REVOKED by the RFC5011 134 protocol. At this point the publisher considers the keys revoked, 135 but the validators have not yet seen this or marked the keys as 136 revoked. In the RFC5011 protocol, the validators probe regularly and 137 can then see if keys are revoked. If unable to probe, they will be 138 unable to see if keys are revoked. Hence when using a history to 139 recount rollovers, the consumer's validator has also missed a number 140 of revocations. The goal is to pick up the right keys and also the 141 new revocations along the way. 143 Although the keys have been marked by the publisher as REVOKED a long 144 time ago, for the consumer these REVOKED keys are new information. 146 Their storage in the history list makes it possible for consumers to 147 pick up key revocations if they missed the revocation announcement 148 because they could not probe. 150 This is the allowed usage of REVOKED keys. The publisher is 151 announcing their presence. And the validators mark them as REVOKED 152 after verification. The initial part of this verification is the 153 reverse walk through the history list, which is to avoid exposing 154 which key is trusted. This means that older signatures with keys 155 that have in the meantime been revoked are used to construct and 156 verify the history list by the validator. 158 A consequence is that once a publisher marks keys as REVOKED, there 159 will still be consumers who are using such keys, because they have 160 not seen the revocation. From the publishers point of view they are 161 revoked and the revocation is filed in the historical key list. From 162 the consumers point of view, it has not seen a revocation yet, and a 163 historical key list lookup algorithm is a state change where a new 164 trusted key is obtained while the old key is observed to be revoked. 166 2.2. Motivation for Requiring the SEP Bit 168 The SEP bit is used to differentiate Key Signing Keys from other 169 keys. It is defined in [RFC3757], it is used to designate trust 170 anchors in [RFC5011]. The protocol herein specified requires that 171 DNSKEYs that are subject to use for the trust history service have 172 the SEP bit set. The reason for this is to keep the set of keys that 173 need to be stored in history small. 175 3. The TALINK Resource Record 177 The DNS Resource Record type TALINK (decimal 58) ties the elements of 178 a linked list of DNSKEY RRs together. 180 The rdata consists of two domain names. The first name is the start, 181 or previous name, and the other name the end or next name in the 182 list. The empty label '.' is used at the endpoints of the list. 184 The presentation format is the two domain names. The wire encoding 185 is the two domain names, with no compression so the type can be 186 treated according to [RFC3597]. The list is a double linked list, 187 because this empowers low memory hosts to perform consistency checks. 189 The TALINK used at the zone apex holds the endpoints of the list. 190 The TALINKs that form the lists hold previous and next entries. 191 These TALINKs are distinguished by their usage (entrypoint or list 192 connection). The double linked list is not circular, because lookups 193 must stop when they reach the oldest entry. 195 4. Trust History Lookup 197 This is the algorithm that a validator uses to detect and resolve the 198 situation in which a trust-anchor is out of sync with the DNSKEYs 199 published by a zone owner. The algorithm uses the TALINK RR type 200 which is used to link various old DNSKEYs as published by the History 201 Provider, to arrive from the outdated configured Trust Anchor to one 202 that matches the current DNSKEY. The TALINK RR type is defined in 203 Section 3. 205 When the algorithm below results in failure the trust history cannot 206 be built and a new trust anchor will need to be re-configured using 207 another mechanism. 209 Step 1: The validator performs a DNSKEY lookup to the target zone, 210 which looks like any other initial DNSKEY lookup that the 211 validator needs to match a trust anchor to the currently used 212 DNSKEY RR set. If the keyset verifies with the trust anchor 213 currently held, the trust-anchor is not out of sync. Otherwise, 214 store the DNSKEY RR set as result. The algorithm will 215 successfully build a linked list to this DNSKEY RR, or delete the 216 trust point, or fail. 218 All nameservers (the ones authoritative for the zone or the 219 upstream resolver caches when the validator is not full resolver) 220 SHOULD be checked to make sure the DNSKEY RR sets are the same. 221 The results can differ if a key-rollover is in progress and not 222 all nameservers are in sync yet. This case can be detected by 223 checking that the older keyset signs the newer and take the newer 224 as result keyset. If both of the keysets sign each other, the 225 result keyset has the newest rrsig that validates it using the 226 other keyset. Use the the average over the middle of the 227 inception and expiration dates of the signatures that are 228 validated (and for serial arithmetic assume all dates on these 229 signatures lie within 2^(SERIAL_BITS-1) distance). If the keysets 230 do not sign each other then this is not a secure change in the 231 keyset and the history lookup fails. 233 Step 2: Fetch the trust history list end points. Perform a query of 234 QTYPE TALINK and QNAME the domain name that is configured to be 235 the History Provider for the particular domain you are trying to 236 update the trust-anchor for. 238 Step 3: Go backwards through the trust history list as provided by 239 the TALINK linked list. Verify that the keyset validly signs the 240 next keyset. This is [RFC4034] validation, but the RRSIG 241 expiration date is ignored. Replace the owner domain name with 242 the target zone name for verification. One of the keys that signs 243 the next keyset MUST have the SEP bit set. The middle of 244 inception and expiration date from the valid signature MUST be 245 older than that of the signature that validates the next keys in 246 the list. Take the average if multiple signatures validate (and 247 for serial arithmetic assume all dates on these signatures lie 248 within 2^(SERIAL_BITS-1) distance). Query type TALINK to get 249 previous and next locations. 251 If all SEP keys have the REVOKE flag set at this step, and the 252 keyset is signed by all SEP keys, then continue but store that the 253 end result is that the trust point is deleted, see Section 5 254 [RFC5011]. 256 If all SEP keys are of an unknown algorithm at this step, continue 257 and at the next step, when you verify if the keyset signs validly: 258 if false, continue with result a failure, if true, continue with 259 the end result that the trust point is deleted. Thus, the keysets 260 with unknown algorithms are stepped over with an end result of 261 failure because the validator cannot determine if unknown 262 algorithm signatures are valid, until the oldest keyset with 263 unknown algorithms is signed by a known algorithm and the result 264 is set to deletion and step 3 continues to a known key. 266 Step 4: When the trust anchor currently held by the validator 267 verifies the keyset, the algorithm is done. The validator SHOULD 268 store the result on stable storage. Use the new trust anchor for 269 validation (if using [RFC5011], put it in state VALID). 271 5. Trust History Tracker 273 External trackers can poll the target zone DNSKEY RRset regularly. 274 Ignore date changes in the RRSIG. Ignore changes to keys with no SEP 275 flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the 276 owner name to a new name at the history location. Publish the new 277 RRset and TALINK records to make it the last element in the list. 278 Update the TALINK that advertises the first and last name. 280 Integrated into the rollover, the keys are stored in the history and 281 the TALINK is updated when a new key is used in the rollover process. 282 This gives the TALINK and new historical key time to propagate. 284 The signer can support trust history. Trust history key sets need 285 only contain SEP keys. To use older signers, move historical RRSIGs 286 to another file. Sign the zone, including the TALINK and DNSKEY 287 records. Append the historical RRSIGs to the result. Signing the 288 zone like this obviates the need for changes to signer and server 289 software. 291 6. Example 293 In this example the trust history for the 'example.net' zone is 294 published in the 'example.com' namespace. The DNSKEY rdata and RRSIG 295 rdata is omitted for brevity, it is a copy and paste of the data from 296 example.net. 298 $ORIGIN example.com. 299 example.com. TALINK h0.example.com. h2.example.com. 301 h0 TALINK . h1.example.com. 302 h0 DNSKEY ... 303 h0 RRSIG ... 305 h1 TALINK h0.example.com. h2.example.com. 306 h1 DNSKEY ... 307 h1 RRSIG ... 309 h2 TALINK h1.example.com. . 310 h2 DNSKEY ... 311 h2 RRSIG ... 313 The example.net zone can advertise the example.com History Provider 314 by providing the TALINK shown here at example.com at the apex of the 315 example.net zone. The TALINK at example.com is then not needed. 317 7. Deployment 319 The trust history is advertised with TALINK RRs at the zone apex. 320 These represent alternative history sources, that can be searched in 321 turn. The TALINK at the zone apex contains the first and last name 322 of the list of historical keys. 324 The historical list of keys grows perpetually. Since most validators 325 have recent keys, their processing time remains similar as the list 326 grows. If validators no longer have trust in the keys then they need 327 no longer be published. The oldest key entries can be omitted from 328 the list to shorten it. 330 The validator decides how long it trusts a key. A recommendation 331 from the zone owner can be configured for keys of that zone, or 332 recommendations per algorithm and key size can be used (e.g. see 333 [NIST800-57]). If a key is older than that, trust history lookup 334 fails with it and the trust point can be considered deleted. This 335 assumes the validator has decided on a security policy and also can 336 take actions when the update of the trust anchor fails. Without such 337 policy, or if the alternative is no DNSSEC, the approach below can be 338 used. 340 In general, the decision can be that any key - no matter how old or 341 how small - is better than no security. The validator then never 342 considers a key too old, and the lookup algorithm becomes an 343 unsecured update mechanism at the time where the key can be trivially 344 broken. The history provider SHOULD provide these broken keys to 345 facilitate clients performing the unsecured update. If a key can not 346 be trivially broken then it provides a non-trivial amount of security 347 that the history lookup algorithm uses to get the current keys. 348 Conceivably after the update the result is stored on stable storage 349 and the client is thereafter safe - it performs a leap of faith. The 350 validator operator can opt for this set up after considering the 351 trade-off between loss of DNSSEC, loss of connectivity, and the 352 argument that perceived security is worse than no security. 354 The history lookup can be used on its own. Then, the trust history 355 is used whenever the key rolls over and no polling is performed. The 356 results of trust history lookup SHOULD be stored on stable storage, 357 so that the trust history lookup does not need to be performed if the 358 last results are okay and for use as trusted anchor in the next 359 history lookup. 361 If a validator is also using [RFC5011] for the target zone, then the 362 trust history algorithm SHOULD only be invoked if the [RFC5011] 363 algorithm failed due to the inability to perform probes. This is the 364 case when the last [RFC5011] successful probe was more than 30 days 365 ago. If a new key has been announced, invoke the history if no 2 366 probes succeeded during the add hold-down time and there was no 367 successful probe after the add hold-down time passed. Therefore the 368 time of the last successful probe MUST be stored on stable storage. 370 For testing the potentially very infrequently used lookup, the 371 following SHOULD be implemented. For the test the lookup is 372 triggered manually by allowing the system to be given a particular 373 keyset with a last successful lookup date in the past and a test 374 History Provider. The test History Provider provides access to a 375 generated back-dated test history. 377 8. Security Considerations 379 The History Provider only provides copies of old data. If that 380 historic data is altered or withheld the lookup algorithm fails 381 because of validation errors in Step 3 of the algorithm. If the 382 History provider or a Man in the Middle Adversary (MIMA) has access 383 to the original private keys (through theft, cryptanalisis, or 384 otherwise), history can be altered without failure of the algorithm. 385 Below we only consider MIMAs and assume the History Provider is a 386 trusted party. 388 Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of 389 TALINK and DNSKEY data, can present some alternate history. However 390 the DNSKEY RR set trusted that the history should arrive at is 391 already fixed by step 1. If an attempt is made to subvert the 392 algorithm at step 2 or 3, then the result keyset can not be replaced 393 by another keyset unnoticed. 395 To change the keyset trusted as the outcome, the step 1 data has to 396 be spoofed and the key held by the validator (or a newer historic 397 key) has to be compromised. Unless such spoof is targeted to a 398 specific victim, a spoof of the step 1 result has a high visibility. 399 Since most of the validators that receive the spoof have an up-to- 400 date trust anchor most validators that would receive this spoof 401 return validation failure for data from the zone that contains the 402 DNSKEYs. An adversary will therefore have to target the attack to 403 validators that are in the process of an update. Since validators do 404 not announce that they use trust history lookup until step 2 405 adversaries will not be able to select the validators. 407 A spoof of data in steps 2 and 3, together with a compromised (old) 408 key, can result in a downgrade. At steps 2 and 3 a faked trust point 409 deletion or algorithm rollover can be inserted in a fake history. 410 This avoids the high visibility of spoofing the current key (see 411 previous paragraph) and downgrades to insecure. 413 Finally there is the case that one of the keys published by the 414 History Providers has been compromised. Since someone spoofing at 415 step 1 of the lookup algorithm and presenting some fake history to a 416 compromised key, of course does not include key revocations and does 417 extend the history to contain the compromised key, it therefore is 418 not really useful for a History Provider to remove the key from the 419 published history. That only makes lookups fail for those validators 420 who are not under attack. Useful action could be to update 421 validators using some other means. 423 Rollover with [RFC5011] revokes keys after use. If a History 424 Provider is used, then such revoked keys SHOULD be used to perform 425 history tracking and history lookup. The trust anchor keys that the 426 validator has in its own storage and final current keys that it 427 stores MUST NOT be trusted if they are revoked. 429 If the validator operator chooses to operate trust history without 430 also using [RFC5011] the trust anchor does not get hold-down timer 431 protection. This has associated risks, in that the immediate 432 rollover without timeout that it provides could be abused (if private 433 keys are compromised). Such abuse could result in the stored lookup 434 results to become compromised. The key changes can be logged, to 435 inform operators and keep an audit trail. 437 The SEP bit is checked to make sure that control over the KSK is 438 necessary to change the keyset for the target zone. 440 The algorithm can be used to get the inception and expiration times 441 of signatures on the current keyset, a clock. A MIMA can attempt to 442 shorten history and put back that clock, but the algorithm attempts 443 to make this difficult to target and highly visible to others. 445 If the clock of the validator can be influenced, then setting it 446 forward is unlikely to give advantage, but setting it backward 447 enables a replay attack of old DNSSEC data and signatures. This 448 vulnerability exists also in plain DNSSEC. 450 9. IANA Considerations 452 Resource record type TALINK has been defined using RFC5395 expert 453 review, it has RR type number 58 (decimal). 455 10. Acknowledgments 457 Thanks to the people who provided review and suggestions, Peter Koch, 458 Andrew Sullivan, Joe Abley, George Barwood, Edward Lewis, Michael 459 StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve Crocker, Bill 460 Manning, Eric Osterweil, Wolfgang Nagele, Alfred Hoenes, Olafur 461 Gudmundsson, Roy Arends and Matthijs Mekking. 463 11. References 465 11.1. Informative References 467 [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. 468 Smid, "Recommendations for Key Management", NIST 469 SP 800-57, March 2007. 471 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name 472 System KEY (DNSKEY) Resource Record (RR) Secure Entry 473 Point (SEP) Flag", RFC 3757, April 2004. 475 [RFC5011] StJohns, M., "Automated Updates of DNS Security 476 (DNSSEC) Trust Anchors", RFC 5011, September 2007. 478 11.2. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, March 1997. 483 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource 484 Record (RR) Types", RFC 3597, September 2003. 486 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 487 Rose, "Resource Records for the DNS Security 488 Extensions", RFC 4034, March 2005. 490 Authors' Addresses 492 Wouter Wijngaards 493 NLnet Labs 494 Science Park 140 495 Amsterdam 1098 XG 496 The Netherlands 498 EMail: wouter@nlnetlabs.nl 500 Olaf Kolkman 501 NLnet Labs 502 Science Park 140 503 Amsterdam 1098 XG 504 The Netherlands 506 EMail: olaf@nlnetlabs.nl