idnits 2.17.1 draft-wkumari-dnsop-trust-management-01.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 (October 5, 2015) is 3098 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4034' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 322, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Intended status: Informational G. Huston 5 Expires: April 7, 2016 APNIC 6 E. Hunt 7 Internet Systems Consortium 8 R. Arends 9 ICANN 10 October 5, 2015 12 Signalling of DNS Security (DNSSEC) Trust Anchors 13 draft-wkumari-dnsop-trust-management-01 15 Abstract 17 [ Editor note: This originally included a mechanism to actually roll 18 the keys (like RFC5011 does), but feedback from the Prague meeting 19 indicated a strong preference for signalling only. ] 21 This document describes a simple method for validating recursive 22 resolvers to signal their configured list of DNSSEC trust anchors. 23 This mechanism allows the trust anchor maintainer to monitor the 24 progress of the migration to a new trust anchor, and so predict the 25 effect before decommissioning the existing trust anchor. 27 It is primarily aimed at the root DNSSEC trust anchor, but should be 28 applicable to trust anchors elsewhere in the DNS as well. 30 [ Ed note - informal summary: One of the big issues with rolling the 31 root key is that it is unclear who all is using RFC5011, who all has 32 successfully fetched and installed the new key, and, most 33 importantly, who all will die when the old key is revoked. By having 34 resolvers query for a special QNAME, comprised of the list of TAs 35 that it knows about, we effectively signal "up stream" to the 36 authoritative server. By querying for this name, the recursive 37 exposes its list of TAs to this authoritative server. This allows 38 the TA maintainer to gather information relating to the state of TAs 39 on resolvers.] 41 [ Ed note: Text inside square brackets ([]) is additional background 42 information, answers to frequently asked questions, general musings, 43 etc. They will be removed before publication.] 45 [ This document is being collaborated on in Github at: 46 https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The 47 most recent version of the document, open issues, etc should all be 48 available here. The authors (gratefully) accept pull requests ] 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at http://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on April 7, 2016. 67 Copyright Notice 69 Copyright (c) 2015 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (http://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 86 2. Trust Anchor Telemetry . . . . . . . . . . . . . . . . . . . 3 87 2.1. TAT Name Format . . . . . . . . . . . . . . . . . . . . . 4 88 3. Sending the Trust Anchor Telemetry Query . . . . . . . . . . 5 89 4. Known issues and limitations . . . . . . . . . . . . . . . . 5 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 92 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 96 9.2. Informative References . . . . . . . . . . . . . . . . . 7 97 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 100 1. Introduction 102 When a DNSSEC-aware resolver performs validation, it requires a trust 103 anchor to validate the DNSSEC chain. An example of a trust anchor is 104 the so called DNSSEC "root key". For a variety of reasons, this 105 trust anchor may need to be replaced or "rolled", to a new key 106 (potentially with a different algorithm, different key length, etc.). 108 [RFC5011] provides a secure mechanism to do this, but operational 109 experience has demonstrated a need for some additional functionality 110 that was not foreseen. 112 During the current efforts to roll the IANA DNSSEC "root key", it has 113 become clear that, in order to predict (and minimize) outages caused 114 by rolling the key, real-time information about the uptake of the new 115 key will be needed. 117 This document defines a mechanism ("trust anchor telemetry") by which 118 validating resolvers can provide information about their configured 119 trust anchors. Readers of this document are expected to be familiar 120 with the contents of [RFC7344] and [RFC5011]. 122 1.1. Requirements notation 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Trust Anchor Telemetry 130 The purpose of the mechanism described in this document is to allow 131 the trust anchor maintainer to determine how widely deployed a given 132 trust anchor is. This information is signaled from the validating 133 resolver to the authoritative servers serving the zone in which the 134 trust anchor lives by sending a periodic query to that zone. The 135 query type of the TAT Query is NULL. The query name is a TAT Name, a 136 format which encodes the list of the trust anchors for that zone that 137 are currently in use by the validating resolver, along with status 138 information about each key. Telemetry information can be retrieved 139 by the trust anchor maintainer by examining logged queries that match 140 the TAT Name format. 142 2.1. TAT Name Format 144 The TAT Name is generated as follows: 146 1. For each trust anchor that the resolver knows and/or is using, 147 generate a string consisting of the key's Algorithm in decimal 148 format, followed by an underscore ('_'), followed by the derived 149 Key Tag in decimal format. [NOTE: If we used hex, this could 150 just be AAKKKK, no need for a punctuation mark, but it would be 151 less human-readable.] 153 2. Follow each string with a character indicating the status of the 154 key from the resolver's point of view: 156 S Static trust anchor, not subject to [RFC5011] 158 A Accepted trust anchor 160 P Pending trust anchor, not yet accepted 162 R Revoked trust anchor 164 3. Sort the list in numerically ascending order of Algorithm and Key 165 Tag. 167 4. Concatenate the list, with each string used as a label in a 168 domain name. 170 5. Append _tat. 172 Assuming no more than two digits for the Algorithm and five for the 173 Key Tag, a TAT Name for the root zone can encode up to 24 trust 174 anchors. [ Someone should probably check my math. QUESTION: Do we 175 need to specify what will happen in the crazy case of a resolver 176 having configured more than 24 trust anchors? -each ] 178 Examples: 180 o If the resolver has a single trust anchor statically configured 181 for the root zone, with an algorithm of RSASHA256 and a Key Tag of 182 19036, it would emit a query for 8_19036S._tat. 184 o If the resolver were configured to use [RFC5011] trust anchor 185 management, it would send 8_19036A._tat. 187 o If a new key with Key Tag 1999 was added to the root zone and had 188 been seen by the resolver, but was too recent to have been 189 accepted as a trust anchor, then the resolver would send a query 190 for 8_1999P.8_19036A._tat. After the hold-down timer ([RFC5011] 191 Section 2.2) had expired, the resolver would send a query for 192 8_1999A.8_19036A._tat. 194 o If there is a separate static trust anchor configured for 195 example.com with an algorithm of RSASHA1 and a Key Tag of 1234, 196 the resolver would send a query for 5_1234S._tat.example.com. 198 NOTE: The format of the TAT Name requires that Key Tags MUST be 199 unique, at least within "recent" history. If (e.g. during a Key 200 Ceremony) a new DNSKEY is generated whose derived Key Tag collides 201 with an exiting one (statistically unlikely, but not impossible) this 202 DNSKEY MUST NOT be used, and a new DNSKEY MUST be generated. [ Ed 203 note: This is to prevent two successive keys having the same keytag 204 (e.g: 123), and then seeing "8_123A." - which 123 key was that?! 205 RFC4034 Appendix B admonition: "Implementations MUST NOT assume that 206 the key tag uniquely identifies a DNSKEY RR", but this appears to be 207 targeted at validating resolver implmentations.] 209 3. Sending the Trust Anchor Telemetry Query 211 When a compliant validating resolver performs the "Active Refresh" 212 query as part of its RFC5011 ([RFC5011] Section 2.3)) processing it 213 will also send a query for the TAT Name. This SHOULD be the default 214 for compliant resolvers. 216 It will receive back either a negative response (e.g. NXDOMAIN), or 217 a (nonsensical) answer. As the entire purpose of this query is to 218 send information from a recursive resolver to the nameservers that 219 serve the zone containing a trust anchor, the response to the query 220 contains no useful information and MUST be ignored. 222 4. Known issues and limitations 224 This solution is designed to provide a rough idea of the rate of 225 uptake of a new key during a key rollover; perfect visibility is not 226 achievable. In particular: 228 1. Only compliant resolvers will send telemetry queries; no 229 information is provided from legacy resolvers, or from those who 230 choose to disable this functionality. 232 2. The trust anchor maintainer has no way to differentiate a query 233 that is emitted by the resolver itself from a query that is 234 forwarded through the resolver. (Note, however, that forwarded 235 queries are likely to be infrequent; responses to TAT queries 236 will in most cases be negatively cached with an NXDOMAIN covering 237 the _TAT subdomain; subsequent client queries would be answered 238 from the cache rather than forwarded to the trust anchor zone.) 240 3. An attacker could forge TAT queries to trick the trust anchor 241 maintainer into a false impression of the adoption rate of a new 242 trust anchor, if there were a perceived advantage to doing so. 244 [ Open Questions: 246 1: In order to disambiguate queries from resolvers versus those 247 forwarded through resolvers (or being recursed because of users 248 behind the resolver) we *could* add craziness like having resolvers 249 include ephemeral UUIDs or something...). Is this worth doing? 250 (Personally I think not...) 252 2: We *could* also specify that compliant resolvers MUST NOT forward 253 queries of type TDS to try limit this. Worth doing? This is some of 254 the reason for having a defined type. 256 3: The authorative server *could* return a record with a long TTL to 257 stop queries (if it knows that it is not doing a rollover in the near 258 future). This seems like a simple option, worth doing? (I think 259 so). (each thinks not.) 261 5. IANA Considerations 263 [ Ed note: This is largely a place holder. The real IANA 264 considerations section will require updating things like the DPS, 265 etc. ] 267 The format of the TAT query requires that Key Tags MUST be unique, at 268 least within an interval. If, during a Key Ceremony, a new DNSKEY is 269 generated whose derived Key Tag collides with an exiting one 270 (statistically unlikely, but not impossible) this DNSKEY MUST NOT be 271 used, and a new DNSKEY MUST be generated. 273 There will need to be some text added to the DNSSEC Ceremony to 274 handle this. 276 6. Security Considerations 278 [ Ed note: a placeholder as well ] 280 This mechanism causes a recursive resolver to disclose the list of 281 trust anchors that it knows about to the authorative servers serving 282 the zone containing the TA (or attackers able to monitor the path 283 between these devices). It is conceviable that an attacker may be 284 able to use this to determine that a resolver trusts an outdated / 285 revoked trust anchor and perform a MitM attack. This would also 286 require the attacker to have factored the private key. This seems 287 farfetched.... 289 7. Contributors 291 A number of people contributed significantly to this document, 292 including Joe Abley, Paul Wouters, Paul Hoffman. Wes Hardaker and 293 David Conrad. 295 8. Acknowledgements 297 9. References 299 9.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 303 RFC2119, March 1997, 304 . 306 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 307 Rose, "Resource Records for the DNS Security Extensions", 308 RFC 4034, DOI 10.17487/RFC4034, March 2005, 309 . 311 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 312 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 313 September 2007, . 315 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 316 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 317 10.17487/RFC7344, September 2014, 318 . 320 9.2. Informative References 322 [I-D.ietf-sidr-iana-objects] 323 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 324 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 325 progress), May 2011. 327 Appendix A. Changes / Author Notes. 329 [RFC Editor: Please remove this section before publication ] 331 From -00 to -01.1: 333 o Ripped all the actual keyroll logic out. 335 o Added Geoff, Evan and Roy as authors. 337 o Added some limitations and known issues. 339 o Renamed to TAT, added tag describing the state of the TA. 341 From -00.1 to -00 (published): 343 o Integrated comments and feedback from DRC and Paul Hoffman. 345 o Use _ as a prefix to make clear it is meta-type (drc) 347 From -00.0 to -00.1 349 o Initial draft, written in an airport lounge. 351 Authors' Addresses 353 Warren Kumari 354 Google 355 1600 Amphitheatre Parkway 356 Mountain View, CA 94043 357 US 359 Email: warren@kumari.net 361 Geoff Huston 362 APNIC 363 6 Cordelia St 364 South Brisbane QLD 4001 365 AUS 367 Email: gih@apnic.net 369 Evan Hunt 370 Internet Systems Consortium 371 950 Charter St 372 Redwood City, CA 94063 373 US 375 Email: each@isc.org 376 Roy Arends 377 ICANN 378 12025 Waterfront Drive, Suite 300 379 Los Angeles, CA 90094-2536 380 US 382 Email: roy.arends@icann.org