idnits 2.17.1 draft-ietf-dnsop-dnssec-trust-history-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 22, 2010) is 5170 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: August 26, 2010 February 22, 2010 7 DNSSEC Trust Anchor History Service 8 draft-ietf-dnsop-dnssec-trust-history-00 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 to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on August 26, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 1. Introduction 63 This memo defines a trust history service for DNS validators -- the 64 component in a resolver that performs DNSSEC [RFC4034] validation, 65 validator for short. 67 A validator that has been offline or missed an (emergency) rollover 68 can use this service to reconfigure themselves with the current 69 trust-anchor. Using a newly defined resource record (RR) that links 70 old DNSKEYS together, the TALINK RR, a validator fetches old DNSKEY 71 RRsets and checks they form a chain to the latest key (see 72 Section 2). The lists of old DNSKEYS, linked with the TALINK RRs, do 73 not necessarily need to be published in the zone for which the DNSKEY 74 history is being maintained but can be published in any DNS domain. 75 We will call the entity that offers the trust history the History 76 Provider. The choice of the History Provider is made by the 77 maintainer of the validator, possibly based on a hint provided, using 78 the TALINK, by the zone owner. 80 The algorithm that the validator uses to construct a history and 81 reconfigure a new key is detailed in Section 3. The algorithms for 82 how providers of trust history can fetch the DNSKEY data as published 83 by the zone they track, and publish those in their own domain, are 84 explained in Section 4. 86 2. The TALINK Resource Record 88 The DNS Resource Record type TALINK (decimal TBD) ties the elements 89 of a linked list of DNSKEY RRs together. 91 The rdata consists of two domain names. The first name is the start, 92 or previous name, and the other name the end or next name in the 93 list. The empty label '.' is used at the endpoints of the list. 95 The presentation format is the two domain names. The wire encoding 96 is the two domain names, with no compression so the type can be 97 treated according to [RFC3597]. The list is a double linked list, 98 because this empowers low memory hosts to perform consistency checks. 100 3. Trust History Lookup 102 This is the algorithm that a validator uses to detect and resolve the 103 situation in which a trust-anchor is out of sync with the DNSKEYs 104 published by a zone owner. The algorithm uses the TALINK RR type 105 which is used to link various old DNSKEYs as published by the History 106 Provider, to arive from the outdated configured Trust Anchor to one 107 that matches the current DNSKEY. The TALINK RR type is defined in 108 Section 2. 110 When the algorithm below results in failure the trust history cannot 111 be build and a new trust anchor will need to be re-configured using 112 another mechanism. 114 Step 1: The validator performs a DNSKEY lookup to the target zone, 115 which looks like any other initial DNSKEY lookup that the 116 validator needs to match a trust anchor to the currently used 117 DNSKEY RR set. If the keyset verifies with the trust anchor 118 currently held, the trust-anchor is not out-of sync. Otherwise, 119 store the DNSKEY RR set as result. The algorithm will succesfully 120 build a linked list to this DNSKEY RR or fail. 122 All nameservers (the ones authoritative for the zone or the 123 upstream resolver caches when the validator is not full resolver) 124 SHOULD be checked to make sure the DNSKEY RR sets are the same. 125 The results can differ if a key-rollover is in progress and not 126 all nameservers are in sync yet. This case can be detected by 127 checking that the older keyset signs the newer and take the newer 128 as result keyset. The keysets are distinguished by the average 129 over the middle of the inception and expiration dates of the 130 signatures that are validated by the keyset itself. Otherwise, 131 the lookup fails. If the check fails then the inconsistency may 132 be the result of spoofing, or compromise of (DNS) infrastructure 133 elements. 135 Step 2: Fetch the trust history list end points. Perform a query of 136 QTYPE=TALINK and QNAME being the domain name that is configured to 137 be the History Provider for the particular domain you are trying 138 to update the trust-anchor for. 140 Step 3: Go backwards through the trust history list as provided by 141 the TALINK linked list. Verify that the keyset validly signs the 142 next keyset. This is [RFC4034] validation, but the RRSIG 143 expiration date is ignored. [Editor note: Are we shure that there 144 are no server implementations that will not serve expired RRSIG, 145 are such 'smart' servers allowed by the specs? In other words do 146 we need clarification in the DNSSEC-updates document?] Replace 147 the owner domain name with the target zone name for verification. 148 One of the keys that signs the next keyset MUST have the SEP bit 149 set. The middle of inception and expiration date from the valid 150 signature MUST be older than the signature checked last time. 151 Query type TALINK to get previous and next locations. 153 If all SEP keys have the REVOKE flag set at this step, and the 154 keyset is signed by all SEP keys, then continue but store that the 155 end result is that the trust point is deleted, see Section 5 156 [RFC5011]. 158 If all SEP keys are of an unknown algorithm at this step, continue 159 and at the next step, when you verify if the keyset signs validly: 160 if false, continue with result a failure, if true, continue with 161 the end result that the trust point is deleted. Thus, the keysets 162 with unknown algorithms are stepped over with an end result of 163 failure because the validator cannot determine if unknown 164 algorithm signatures are valid, until the oldest keyset with 165 unknown algorithms is signed by a known algorithm and the result 166 is set to deletion and step 3 continues to a known key. 168 Step 4: When the trust anchor currently held by the validator 169 verifies the keyset, the algorithm is done. The validator SHOULD 170 store the result on stable storage. Use the new trust anchor for 171 validation (if using [RFC5011], put it in state VALID). 173 4. Trust History Tracker 175 External trackers can poll the target zone DNSKEY RRset regularly. 176 Ignore date changes in the RRSIG. Ignore changes to keys with no SEP 177 flag. Copy the newly polled DNSKEY RRset and RRSIGs, change the 178 owner name to a new name at the history location. Publish the new 179 RRset and TALINK records to make it the last element in the list. 180 Update the TALINK in the target zone that advertises the first and 181 last name. 183 Integrated into the rollover, the keys are stored in the history and 184 the TALINK is updated when a new key is used in the rollover process. 185 This gives the TALINK and new historical key time to propagate. 187 The signer can support trust history. Trust history key sets need 188 only contain SEP keys. To use older signers, move historical RRSIGs 189 to another file. Sign the zone, including the TALINK and DNSKEY 190 records. Append the historical RRSIGs to the result. Signing the 191 zone like this obviates the need for changes to signer and server 192 software. 194 5. Example 196 In this example example.com is the History Provider for example.net. 197 The DNSKEY rdata and RRSIG rdata is omitted for brevity, it is a copy 198 and paste of the data from example.net. 200 $ORIGIN example.com. 201 example.com. TALINK h0.example.com. h2.example.com. 203 h0 TALINK . h1.example.com. 204 h0 DNSKEY ... 205 h0 RRSIG ... 207 h1 TALINK h0.example.com. h2.example.com. 208 h1 DNSKEY ... 209 h1 RRSIG ... 211 h2 TALINK h1.example.com. . 212 h2 DNSKEY ... 213 h2 RRSIG ... 215 The example.net zone can advertise the example.com History Provider 216 by providing the TALINK shown here at example.com at the apex of the 217 example.net zone. The TALINK at example.com is then not needed. 219 6. Deployment 221 The trust history is advertised with TALINK RRs at the zone apex. 222 These represent alternative history sources, that can be searched in 223 turn. The TALINK at the zone apex contains the first and last name 224 of the list of historical keys. 226 The History Provider decides the oldest age keys it wants to publish, 227 as operations permit. If validators no longer have trust in the keys 228 then they need no longer be published. The oldest key entries can be 229 omitted from the list to shorten it. 231 The validator decides how long it trusts a key. A recommendation 232 from the zone owner can be configured for keys of that zone, or 233 recommendations per algorithm and key size can be used (e.g. see 234 [NIST800-57]). If a key is older than that, trust history lookup 235 fails with it. 237 The history lookup can be used on its own. Then, the trust history 238 is used whenever the key rolls over and no polling is performed. The 239 time of the last successful key lookup is stored on stable storage. 240 The trust history algorithm is not started unless the last successful 241 key lookup was more than x time ago. This time is suggested to be 242 the same has the Hold-Down timer in RFC 5011 i.e. 30 days, but can be 243 signalled by the zone owner with the TTL of the TALINK RRset at the 244 zone apex. This TTL MUST be validated before it is stored for use 245 later. 247 If a validator is also using [RFC5011] for the target zone, then the 248 trust history algorithm SHOULD only be invoked if the last [RFC5011] 249 successful probe was more than 30 days ago. If a new key has been 250 announced, invoke the history if no 2 probes succeeded during the add 251 hold-down time and there was no successful probe after the add hold- 252 down time passed. Therefore the time of the last successful probe 253 MUST be stored on stable storage. 255 For testing the potentially very infrequently used lookup, the 256 following SHOULD be implemented. For the test the lookup is 257 triggered manually by allowing the system to be given a particular 258 keyset with a last successful lookup date in the past, stored TALINK 259 TTL and a test History Provider. The test History Provider provides 260 access to a generated back-dated test history that signs the current 261 production keyset. 263 7. Security Considerations 265 The History Provider only provides copies of old data. If that 266 historic data is altered or withheld the lookup algorithm fails 267 because of validation errors in Step 3 of the algorithm. If the 268 History provider or a Man in the Middle Adversary (MIMA) has access 269 to the original private keys (through theft, cryptoanalisis, or 270 otherwise), history can be altered without failure of the algorithm. 271 Below we only consider MIMAs and assume the History Provider is a 272 trusted party. 274 Spoofing by a MIMA of data looked up in step 2 or 3, i.e. spoofing of 275 TALINK and DNSKEY data, can present some alternate history. However 276 the DNSKEY RR set trusted that the history should arrive at is 277 already fixed by step 1. If an attempt is made to subvert the 278 algorithm at step 2 or 3, then the result keyset can not be replaced 279 by another keyset unnoticed. 281 To change the keyset trusted as the outcome, the step 1 data has to 282 be spoofed and the key held by the validator (or a newer historic 283 key) has to be compromised. Unless such spoof is targeted to a 284 specific victim, a spoof of the step 1 result has a high visibility. 285 Since most of the validators that receive the spoof have an up-to- 286 date trust anchor most validators that would receive this spoof 287 return validation failure for data from the zone that contains the 288 DNSKEYs. An adversary will therefore have to target the attack to 289 validators that are in the process of an update. Since validators do 290 not announce that they use trust history lookup until step 2 291 adversaries will not be able to select the validators. 293 A spoof of data in steps 2 and 3, together with a compromised (old) 294 key, can result in a downgrade. At steps 2 and 3 a faked trust point 295 deletion or algorithm rollover can be inserted in a fake history. 296 This avoids the high visibility of spoofing the current key (see 297 previous paragraph) and downgrades to insecure. 299 Finally there is the case that one of the keys published by the 300 History Providers has been compromised. Since someone spoofing at 301 step 1 of the lookup algorithm and presenting some fake history to a 302 compromised key, of course does not include key revocations and does 303 extend the history to contain the compromised key, it therefore is 304 not really useful for a History Provider to remove the key from the 305 published history. That only makes lookups fail for those validators 306 who are not under attack. Useful action would be to update 307 validators using some other means. 309 Rollover with [RFC5011] revokes keys after use. If a History 310 Provider is used, then such revoked keys SHOULD be used to perform 311 history tracking and history lookup. 313 The SEP bit is checked to make sure that control over the KSK is 314 necessary to change the keyset for the target zone. 316 8. IANA Considerations 318 Resource record type TALINK has been defined using RFC5395 type 319 expert review, it has RR type number TBD (decimal). 321 9. Acknowledgments 323 Thanks to the people who provided review and suggestions, Edward 324 Lewis, Michael StJohns, Bert Hubert, Mark Andrews, Ted Lemon, Steve 325 Crocker, Bill Manning, Eric Osterweil, Wolfgang Nagele, Alfred 326 Hoenes, Olafur Gudmundsson, Roy Arends and Matthijs Mekking. 328 10. References 330 10.1. Informative References 332 [NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. 333 Smid, "Recommendations for Key Management", NIST 334 SP 800-57, March 2007. 336 [RFC5011] StJohns, M., "Automated Updates of DNS Security 337 (DNSSEC) Trust Anchors", RFC 5011, September 2007. 339 10.2. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource 345 Record (RR) Types", RFC 3597, September 2003. 347 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 348 Rose, "Resource Records for the DNS Security 349 Extensions", RFC 4034, March 2005. 351 Authors' Addresses 353 Wouter Wijngaards 354 NLnet Labs 355 Science Park 140 356 Amsterdam 1098 XG 357 The Netherlands 359 EMail: wouter@nlnetlabs.nl 361 Olaf Kolkman 362 NLnet Labs 363 Science Park 140 364 Amsterdam 1098 XG 365 The Netherlands 367 EMail: olaf@nlnetlabs.nl