idnits 2.17.1 draft-fanf-dnsop-trust-anchor-witnesses-00.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 (February 13, 2014) is 3722 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) == Missing Reference: 'TBD' is mentioned on line 162, but not defined ** Obsolete normative reference: RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Downref: Normative reference to an Informational RFC: RFC 6781 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations (dnsop) T. Finch 3 Internet-Draft University of Cambridge 4 Intended status: Standards Track February 13, 2014 5 Expires: August 17, 2014 7 The WS resource record: dispersing trust in the DNSSEC root keys 8 draft-fanf-dnsop-trust-anchor-witnesses-00 10 Abstract 12 At the moment the root DNSSEC key is a single point of trust and a 13 single point of failure for the whole system. This memo describes a 14 mechanism for dispersing trust in the root key. Witnesses vouch for 15 the root trust anchor by publishing WS records in the DNS. 16 Validators only update their root trust anchors if multiple witnesses 17 agree. The root-witnesses.arpa zone enables a validator to bootstrap 18 trust when it has no working trust anchors other than its witnesses. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 17, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. The WS resource record . . . . . . . . . . . . . . . . . . . . 4 57 3. How validators use WS records . . . . . . . . . . . . . . . . 5 58 3.1. Trust anchor configuration . . . . . . . . . . . . . . . . 5 59 3.2. When to try a trust anchor update . . . . . . . . . . . . 5 60 3.3. Trust anchor update process . . . . . . . . . . . . . . . 6 61 4. How witnesses publish WS records . . . . . . . . . . . . . . . 7 62 4.1. Contents of a witness zone . . . . . . . . . . . . . . . . 7 63 4.2. Lifecycle of witness zones . . . . . . . . . . . . . . . . 8 64 5. The root trust anchor . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Locating root trust anchor witness zones . . . . . . . . . 8 66 5.2. Root trust anchor witness organizations . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Normative references . . . . . . . . . . . . . . . . . . . . . 10 70 Appendix A. Questions . . . . . . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 At the moment the root DNSSEC key is a single point of trust and a 76 single point of failure for the whole system. It has a number of 77 problems: 79 o Root trust anchor rollovers using [RFC5011] require validators to 80 be online while the rollover happens. With the current root key 81 management plan, rollovers take a few weeks. This is 82 uncomfortably long for emergency rollovers. 84 o Systems that are offline during a rollover have to use an out-of- 85 band mechanism to update their trust anchors, relying on non-DNS 86 sources of trust. There is no clear specification or security 87 analysis for this process. 89 o The root key is a single point of failure with no standby, though 90 its storage and management is extremely resilient and trustworthy 91 (in stark contrast to the out-of-band trust anchor update keys). 93 o The concentration of trust in the root is politically 94 uncomfortable. 96 This memo describes a mechanism for dispersing trust in the root key. 97 Witnesses vouch for the root trust anchor by publishing WS records in 98 the DNS. Validators only update their root trust anchors if multiple 99 witnesses agree. 101 This mechanism has the following advantages: 103 o There is no single point of failure since there are many witnesses 104 not one of which is completely trusted. 106 o There are no special timing constraints as in [RFC5011]. 107 Witnessed trust anchor updates are like normal KSK rollovers. 109 o The mechanism is in-band, using only DNS, even for bootstrapping. 111 o The same procedure works for online and offline key rollovers. 113 o Rollovers can become routine. 115 There are some potential advantages: 117 o It can allow for a crash rollover of the root key, in the event 118 that it is lost or compromised, with validators recovering 119 automatically rather than having to be manually forced to fetch 120 and authenticate the replacement trust anchor. 122 o It could allow a smaller root DNSKEY RRset by allowing the 123 witnesses to vouch for the root ZSK directly instead of via a KSK. 124 This saves the cost of high-assurance storage for the root KSK, 125 but requires more frequent communication between the root DNSSEC 126 key managers and the witnesses. 128 There are some limitations and disadvantages: 130 o It does not disperse trust in the root zone signing key or root 131 zone maintenance. 133 o A lot more co-ordination between organizations is necessary, for 134 the witnesses to get out-of-band authentication of new trust 135 anchors. 137 This mechanism can be used to automatically update any trust anchor, 138 though it is designed for and includes some special considerations 139 for the root trust anchor. The root-witnesses.arpa zone is set up to 140 enable a validator to bootstrap trust when it has no working trust 141 anchors other than its witnesses. 143 1.1. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2. The WS resource record 151 The WS (witness signer) resource record contains a cryptographic 152 digest of a DNSKEY record at a DNSSEC trust anchor. WS records are 153 published separately from the trust anchor by trust anchor witnesses 154 to show that the witnesses vouch for the trust anchor DNSKEY(s). WS 155 records are used by validators to update their trust anchors. 157 The WS resource record RDATA has exactly the same wire format and 158 presentation format as the DS RR, as described in [RFC4034] section 159 5. Although WS has the same syntax as DS, its semantics differ as 160 described below. 162 The WS resource record type number is [TBD] 164 The WS RR is treated as a normal RR for signing, serving, resolving, 165 and validating. None of the special behaviour for DS records 166 described in [RFC4035] sections 2.4, 2.6, 3.1 applies to WS records. 168 Unlike DS records (where the DS record on the parent side of a zone 169 cut refers to a DNSKEY record on the child side of the zone cut at 170 the same name), WS records do not explicitly indicate the name of the 171 trust anchor DNSKEY records that they refer to. This information is 172 part of the valiator configuration (see Section 3.1). 174 WS records SHOULD be placed at the apex of a witness zone. They 175 SHOULD refer to DNSKEY records with the SEP (secure entry point) flag 176 set [RFC3757]. 178 3. How validators use WS records 180 3.1. Trust anchor configuration 182 A validator's configuration for a trust anchor consists of the the 183 trust anchor owner name, and either a set of public keys or a set of 184 DS records, as described in [RFC4035] section 4.4. 186 A trust anchor that is automatically updated is associated with the 187 witnesses that vouch for it. It has a quorum value stating how many 188 witnesses must agree before the trust anchor is updated. 190 Each witness is a normal statically-configured trust anchor. That 191 is, witnesses are not updated automatically except by out-of-band 192 configuration updates or software updates. Each witness is 193 associated with one automatically updated trust anchor for which it 194 vouches. 196 3.2. When to try a trust anchor update 198 The validator SHALL keep track of the DNSKEY records from the DNS at 199 the trust anchor name. It only tracks the set of all records with 200 the SEP flag set, or the subset of SEP keys with algorithms supported 201 by the validator. (This is so that ZSK rollovers do not trigger 202 trust anchor updates.) 204 When the validator notices that this set has changed it SHOULD 205 attempt to update the trust anchor as described below. During the 206 update process it SHOULD continue to serve clients and use the 207 existing trust anchor to validate responses. 209 The validator MAY track the DNSKEY records persistently in order to 210 make restarts faster. If so, it SHOULD discard any saved DNSKEY 211 records after their RRSIG expiry time. If it does not, it SHOULD 212 perform an update attempt at restart. 214 When starting, a validator can find that its existing trust anchor 215 does not work, perhaps because a key rollover happened while it was 216 offline. In this situation it cannot serve clients until the update 217 process completes successfully. 219 A broken trust anchor is not expected to happen during normal 220 operations, since validation ought to work at every point in a key 221 rollover. However, if some disaster occurs and the trust anchor 222 private key is lost or compromised, there might be a disruptive crash 223 key rollover. 225 When it sees a crash rollover, a validator will not be able to 226 validate the new DNSKEY RRset, so will discard it and retry the query 227 in an attempt to obtain a working version. If this problem persists 228 the validator MAY attempt to update the trust anchor using an invalid 229 DNSKEY response. 231 3.3. Trust anchor update process 233 Trust anchor updates are performed with respect to a DNSKEY RRset 234 from the trust anchor owner name. This allows the validator to 235 ensure that a successful update will lead to a working configuration. 237 The validator queries for the WS RRset at each of the trust anchor's 238 witnesses. The witnesses SHOULD be queried in a random order, so 239 that the validator avoids relying too much on a subset of the 240 witnesses. The query process SHOULD stop when a quorum has been 241 achieved for one or more WS RRs. The queries MAY be performed 242 concurrently to improve performance (though it doesn't make sense to 243 use a level of concurrency greater than the quorum size). 245 The witness queries follow normal DNS resolution and DNSSEC 246 validation rules. The response from a witness MUST validate as 247 secure using that witness's trust anchor. (The special arrangements 248 for the root trust anchor witnesses described in Section 5.1 ensure 249 that the requirements in this paragraph can be satisfied even when 250 the root trust anchor is broken.) 252 The validator MUST ensure there are no duplicate WS RRs in the 253 response from a witness. Duplicate RRs are not allowed (see 254 [RFC2181] section 5), but it is particularly important to prevent 255 duplicate WS RRs so that a witness cannot count more than once 256 towards a quorum. 258 The validator SHOULD ignore a WS RR if it does not contain a valid 259 digest of a DNSKEY record with the SEP flag set. This ensures that 260 the validator does not count a quorum of useless WS RRs. 262 For each usable WS RR that the validator receives from a witness, it 263 keeps a count of the number of responses that contained that WS RR. 265 A WS RR can be trusted when this count reaches the required quorum. 267 If the trust anchor that is being updated is configured with DS RRs, 268 then the validator converts the trusted WS RRs into DS RRs by 269 changing their RR TYPE fields and uses those for the new 270 configuration. If the trust anchor is configured with public keys, 271 then the new keys are taken from the DNSKEY RRs that are 272 authenticated by the trusted WS RRs. 274 4. How witnesses publish WS records 276 The administrative arrangements for publishing WS records in a 277 witness zone are analogous to publishing DS records in a parent zone. 279 There MUST be an out-of-band (non-DNS) communications channel between 280 the witnesses and the owner of the zone for which they vouch. This 281 is used to authenticate WS RRset changes. 283 The timing of trust anchor rollovers is the same as for KSK rollovers 284 [RFC6781], except that instead of updating parental DS records, 285 withess WS records must be updated. 287 4.1. Contents of a witness zone 289 o A SOA record. 291 o NS records and name server address records. The name server names 292 SHOULD be in the witness zone. (Section 5.1 below explains this 293 requirement.) 295 o A DNSKEY RRset. This SHALL contain exactly one record with the 296 SEP flag set, corresponding to the witness trust anchor. The 297 DNSKEY RRset SHALL be signed by this key. As usual, the DNSKEY 298 RRset SHOULD contain other keys which are used as zone-signing 299 keys. 301 o A WS RRset. There MAY be multiple WS records to allow for 302 multiple digest types and/or multiple trust anchor keys. 304 o Other DNSSEC RRs necessary for a signed zone. 306 o There MAY be other records to provide information about this 307 witness zone. There SHOULD NOT be any records unrelated to 308 witness operations, such as delegations. 310 4.2. Lifecycle of witness zones 312 A trust anchor SHOULD have many witness zones, in order to provide 313 resilience as well as dispersal of trust. 315 Each witness zone is tied to a fixed witness trust anchor. The zone 316 lasts as long as its trust anchor. This SHOULD be at least 10 years, 317 since old software and configurations cannot function after too many 318 of their witnesses have been retired. 320 Witnesses are continually retired. It is expected that some 321 witnesses will have to retire early, for instance, if their keys are 322 lost or compromised, or if their host organization is no longer able 323 to maintain them. This is OK since there are plenty of other 324 witnesses. 326 New witnesses are continually introduced. Validators configured with 327 an up-to-date set of witnesses will have a decent lifetime. Given an 328 average witness lifetime of W years, a pool of P witnesses, and a 329 quorum size of Q, we expect P/W witness retirements per year. A 330 validator configuration will last until there are Q witnesses left, 331 that is, until there have been P-Q retirements, which takes V=(P- 332 Q)*(W/P) years. For example, if P=30, W=10, and Q=6, then V=8. 334 A witness organization may run multiple witness zones on a rolling 335 replacement schedule in order to avoid a hiatus when a zone is 336 retired. Validators SHOULD be configured to use only one witness 337 zone from each witness organization, to avoid trusting one 338 organization too much. 340 5. The root trust anchor 342 5.1. Locating root trust anchor witness zones 344 There is a bootstrapping problem when a validator has an out-of-date 345 root trust anchor: it needs to find the name servers for the witness 346 zones in order to be able to get the WS records that vouch for the 347 new root trust anchor; however it is unable to validate the responses 348 it gets while resolving the name server addresses. This section 349 describes how to minimize this bootstrapping problem. 351 All root witness zones SHALL be delegated from a single parent zone, 352 called root-witnesses.arpa. This zone is to be maintained by IANA. 353 A delegation in this zone indicates that there are out-of-band 354 arrangements between the root DNSSEC key managers (XXX do they have a 355 better name?) and the witness organization allowing the witness 356 organization to meaningfully vouch for changes to the root DNSSEC 357 trust anchor. 359 The root-witnesses.arpa zone SHOULD NOT be signed. Leaving the zone 360 unsigned prevents the risk that validators will use some higher-level 361 trust anchor to validate responses from a witness zone rather than 362 the witness trust anchor itself. In particular we want to avoid a 363 compromised root key being used to vouch for itself. The purpose of 364 the root-witnesses.arpa zone is to contain delegation NS RRs and glue 365 address records for the witness zones, and these records are never 366 signed. The signed parts of delegations are the DS RRsets; omitting 367 those prevents unsafe witness validation, but also leaves almost 368 nothing in the root-witnesses.arpa zone to sign. 370 Each witness zone's name servers have names inside that witness zone 371 so that they can be validated by the witness trust anchor without 372 depending on any other part of the DNS. 374 The root-witnesses.arpa zone SHALL be served by the root name 375 servers. This is so that a bootstrapping validating resolver can 376 find its witnesses using just its root hints, and get a direct 377 referral to the right witness zone name servers, again without 378 depending on any other part of the DNS. 380 Since the referral from root-witnesses.arpa is to a zone for which 381 the validating resolver has a trust anchor, it does not need to 382 validate the delegation chain through the witness zone's parents. 383 Depending on its validation strategy, a bootstrapping validator might 384 need special logic to avoid validaing this delegation chain or to 385 ignore validation failures in it, in particular when its root trust 386 anchor is stale. 388 5.2. Root trust anchor witness organizations 390 In order to populate the root-witnesses.arpa zone, IANA has to select 391 a number of root witness organizations who will receive delegations 392 from this zone. 394 These might be selected from TLD operators, root server operators, 395 registry service providers, accredited registrars, and others who 396 have an interest in the security and robustness of the DNS. 398 6. Security Considerations 400 This memo aims to improve the security and robustness of the DNS. 401 There are security-related requirements and recommendations 402 throughout. 404 7. IANA Considerations 406 A DNS RR type number is required for the WS RR. 408 This memo directs IANA to set up the root-witnesses.arpa zone and 409 manage ongoing liaison with the root trust anchor witnesses. 411 8. Normative references 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 417 Specification", RFC 2181, July 1997. 419 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name 420 System KEY (DNSKEY) Resource Record (RR) Secure Entry 421 Point (SEP) Flag", RFC 3757, April 2004. 423 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 424 Rose, "Resource Records for the DNS Security Extensions", 425 RFC 4034, March 2005. 427 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 428 Rose, "Protocol Modifications for the DNS Security 429 Extensions", RFC 4035, March 2005. 431 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 432 Trust Anchors", STD 74, RFC 5011, September 2007. 434 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 435 Operational Practices, Version 2", RFC 6781, 436 December 2012. 438 Appendix A. Questions 440 Should this this scheme be extended to be more like DLV? That is, 441 witness zones could vouch for any trust anchors. Validators would 442 look up WS records by concatenating the name of the automatically 443 updated trust anchor name and the witness zone name. There would be 444 an implicit many-to-many relationship between witnesses and 445 automatically updated trust anchors, instead of an explicit many-to- 446 one relationship. 448 Author's Address 450 Tony Finch 451 University of Cambridge Computing Service 452 Roger Needham Building 453 7 JJ Thomson Avenue 454 Cambridge CB3 0RB 455 ENGLAND 457 Phone: +44 797 040 1426 458 Email: dot@dotat.at 459 URI: http://dotat.at/