idnits 2.17.00 (12 Aug 2021) /tmp/idnits59864/draft-wkumari-dnsop-trust-management-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 (June 29, 2015) is 2518 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DNS-TRANSPORT' is mentioned on line 129, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 264, but no explicit reference was found in the text == Outdated reference: draft-ietf-sidr-iana-objects has been published as RFC 6491 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 template W. Kumari 3 Internet-Draft Google 4 Intended status: Informational June 29, 2015 5 Expires: December 31, 2015 7 Simplified Updates of DNS Security (DNSSEC) Trust Anchors 8 draft-wkumari-dnsop-trust-management-00 10 Abstract 12 This document describes a simple means for automated updating of 13 DNSSEC trust anchors. This mechanism allows the trust anchor 14 maintainer to monitor the progress of the migration to the new trust 15 anchor, and so predict the effect before decommissioning the existing 16 trust anchor. 18 It is primarily aimed at the root DNSSEC trust anchor, but should be 19 applicable to trust anchors elsewhere in the DNS as well. 21 [ Ed note - informal summary: One of the big issues with rolling the 22 root key is that it is unclear who all is using RFC5011, who all has 23 successfully fetched and installed the new key, and, most 24 importantly, who all will die when the old key is revoked. A 25 secondary problem is that the response sizes suddenly increase, 26 potentially blowing the MTU limit. This document describes a method 27 that is basically CDS, but for the root key (or any other trust 28 anchor). Unlike the CDS record though, this record lives at a 29 special name - by querying for this name, the recursive exposes its 30 list of TAs to the auth server (signalling upstream) . This allows 31 the TA maintainer to predict how many, and who all will break. It 32 also allows the pre-publication of a key before using it, and so 33 avoids the need to double response sizes...] 35 [ Ed note: Text inside square brackets ([]) is additional background 36 information, answers to frequently asked questions, general musings, 37 etc. They will be removed before publication.] 39 [ This document is being collaborated on in Github at: 40 https://github.com/wkumari/draft-wkumari-dnsop-trust-management. The 41 most recent version of the document, open issues, etc should all be 42 available here. The authors (gratefully) accept pull requests ] 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on December 31, 2015. 61 Copyright Notice 63 Copyright (c) 2015 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 80 2. TDS Record Format . . . . . . . . . . . . . . . . . . . . . . 3 81 2.1. TDS Owner Name . . . . . . . . . . . . . . . . . . . . . 3 82 3. TDS Record Processing . . . . . . . . . . . . . . . . . . . . 4 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 85 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 89 8.2. Informative References . . . . . . . . . . . . . . . . . 6 90 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 6 91 Appendix B. Worked example . . . . . . . . . . . . . . . . . . . 7 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 94 1. Introduction 96 When a DNSSEC aware resolver performs validation, it requires a trust 97 anchor to validate the DNSSEC chain. An example of a trust anchor is 98 the so called DNSSEC "root key". For a variety of reasons this trust 99 anchor may need to be replaced or "rolled", to a new key (potentially 100 with a different algorithm, different key length, etc.). 102 [RFC5011] provides a secure mechanism to do this, but operational 103 experience has demonstrated a need for some additional functionality 104 that was not foreseen. 106 During the recent effort to roll the IANA DNSSEC "root key", it has 107 become clear that, in order to predict (and minimize) outages caused 108 by rolling the key, one needs to know who does not have the new key. 109 In addition, RFC5011 style key rolls require "double signing", which 110 significantly increases the size of the responses. 112 This document defines a new record type, Trust DS (TDS), which 113 provides a mechanism very similar to the Child DS (CDS) [RFC7344] 114 record, and some practices for using it. Readers of this document 115 are expected to be familiar with the contents of [RFC7344]. 117 1.1. Requirements notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. TDS Record Format 125 The wire and presentation format of the Trust DS (TDS) resource 126 record is identical to the DS record [RFC4034]. 128 IANA has allocated RR code TBD for the TDS resource record via Expert 129 Review [DNS-TRANSPORT]. The TDS RR uses the same registries as DS 130 for its fields. No special processing is performed by authoritative 131 servers or by resolvers, when serving or resolving. 133 For all practical purposes, TDS is a regular RR type. 135 2.1. TDS Owner Name 137 Much of the purpose of the mechanism described in this document is to 138 provide a mechanism to allow the trust anchor maintainer to determine 139 how widely deployed the trust anchor is, and who is using an outdated 140 trust anchor. This information is signalled from the validating 141 resolver to the authoritative server serving the zone in which the 142 Trust Anchor lives. 144 This information is available from looking at queries to DNS servers 145 serving the DNSKEY for the zone; each resolver using this mechanism 146 will periodically query the zone for a name encoding the list of 147 trust anchors it is using for that zone. 149 This name is computed as follows: 151 1. Take the Key Tags of all of the DS records corresponding to the 152 TA(s) that the resolver knows / is using. 154 2. Sort this list in numerically ascending order 156 3. Concatenate the list, separating each Key Tag with a hyphen 157 ('-'), then append this to an underscore ('_') 159 As an example, if the resolver has a single Trust Anchor with a Key 160 Tag of 4217, it would generate an owner name of _4217. If it has two 161 Trust Anchors, with Key Tags 1985 and 1776 it would generate an owner 162 name of _1776-1985. 164 NOTE: The generation of the TDS Name means that Key Tags MUST be 165 unique, at least within "recent" history. If (e.g during a Key 166 Ceremony) a new DNSKEY is generated whose derived Key Tag collides 167 with an exiting one (statistically unlikely, but not impossible) this 168 DNSKEY MUST NOT be used, and a new DNSKEY MUST be generated. [ Ed 169 note: This is to prevent two successive keys having the same keytag 170 (e.g: 123), and then seeing "_123." - which 123 key was that?! 171 RFC4034 Appendix B admonition: "Implementations MUST NOT assume that 172 the key tag uniquely identifies a DNSKEY RR" - I think that is for 173 validators though.] 175 3. TDS Record Processing 177 A compliant recursive resolver will periodically (every 'Active 178 Refresh' interval ([RFC5011] Section 2.3)) query the trust point 179 domain for the TDS Owner Name. It will receive back either an error 180 (e.g NoError / NoData), or a TDS RRSet. It will validate the TDS 181 record, using standard DNSSEC logic. 183 Assuming a TDS RRSet is received and validates, the resolver will 184 parse the RRSet. The RRSet will contain one or more TDS records, 185 listing the DS records that correspond to DNSKEYs that may sign the 186 zone. The resolver SHOULD store this list to its configuration / 187 persistent storage. 189 [Ed note: See Appendix B for a worked example of performing a keyroll 190 using this mechanism. It's much less complex than this all makes it 191 sound...] 193 [Ed note - Corner cases. I didn't want to spend too long writing out 194 all of the handling for these until I've gotten some feedback on the 195 concept:] 197 1. The TDS doesn't validate. This is the same as in a non-TDS / 198 RFC5011 world. You entered the TA incorrectly, you are under 199 attack, or similar. 201 2. There is no TDS record (you get NoError / NoData). You have 202 somehow become out of sync with the system, or someone has 203 bungled the keyroll in an odd way. Panicking is a good option 204 here. 206 4. IANA Considerations 208 [ Ed note: This is largely a place holder. The real IANA 209 considerations section will require updating things like the DPS, 210 etc. ] 212 The generation of the TDS Name means that Key Tags MUST be unique, at 213 least within an interval. If, during a Key Ceremony, a new DNSKEY is 214 generated whose derived Key Tag collides with an exiting one 215 (statistically unlikely, but not impossible) this DNSKEY MUST NOT be 216 used, and a new DNSKEY MUST be generated. 218 There will need to be some text added to the DNSSEC Ceremony to 219 handle this. 221 In addition, the IANA is instructed to publish a TDS record 222 containing all trust anchors that are to be considered "trusted" for 223 the root key, with owner names as described above. 225 5. Security Considerations 227 [ Ed note: a placeholder as well ] 229 This mechanism can be used to roll from one trusted (whatever that 230 means) to a new key. It cannot, and should not be used to recover 231 from a (suspected) compromised key (this is true for RFC5011 as 232 well). 234 This relies upon the strength of the hashing algorithm in the DS. 236 6. Contributors 238 A number of people contributed significantly to this document, 239 including Joe Abley, Paul Wouters, Paul Hoffman. Wes Hardaker and 240 David Conrad. 242 7. Acknowledgements 244 8. References 246 8.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, March 1997. 251 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 252 Rose, "Resource Records for the DNS Security Extensions", 253 RFC 4034, March 2005. 255 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 256 Trust Anchors", STD 74, RFC 5011, September 2007. 258 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 259 DNSSEC Delegation Trust Maintenance", RFC 7344, September 260 2014. 262 8.2. Informative References 264 [I-D.ietf-sidr-iana-objects] 265 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 266 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 267 progress), May 2011. 269 Appendix A. Changes / Author Notes. 271 [RFC Editor: Please remove this section before publication ] 273 From -00.1 to -00 (published): 275 Integrated comments and feedback from DRC and Paul Hoffman. 277 Use _ as a prefix to make clear it is meta-type (drc) 279 From -00.0 to -00.1 281 o Initial draft, written in an airport lounge. 283 Appendix B. Worked example 285 This section provides an example of rolling the root trust anchor 286 from a DNSKEY with Key Tag 17 to one with Key Tag 42. It is written 287 informally, and will be tidied up / made more formal before 288 publication. To keep this readable, I've made key tags and hashes 289 and such be short. 291 The root trust anchor is RSA/SHA-1, generating a DS with SHA-1 the DS 292 works out to 17 5 1 111222 #(Tag RSA/SHA1 SHA1 Key). This DS is 293 installed into a root zone in a TDS record: 295 _17 IN TDS 17 5 1 111222 297 Compliant resolvers are configured with this information, by manually 298 placing this in thier config files (in the same way resolvers are 299 currently manually configred with the DNSKEY). The resolver will 300 periodically query the root for qname 17, type TDS. It will receive 301 (and validate!) this TDS record, will see that is has this key, and 302 will go back to sleep. The root TA maintainer can see that everyone 303 is using the key with ID 17. 305 Eventually the trust anchor maintainer withes to roll to a new RSA/ 306 SHA-256 key, so they generate the new key. They compute the DS 307 (using SHA-256) and the computed DS is 42 (Tag) 8 (RSA/SHA-256) 2 308 (SHA-256) 333444. They now publish TDS records as follows: 310 _17 IN TDS 17 5 1 111222 311 IN TDS 42 8 2 333444 313 _17-42 IN TDS 17 5 1 111222 314 IN TDS 42 8 2 333444 316 A resolver who only knows about Key 17 queries for 17 and will now 317 start getting 2 TDS records and will see that this does not match 318 what is has configured, and so will add the 42 DS record to its 319 configured list of acceptable keys (now it has 17 and 42). 321 On its next scheduled check it will lookup _17-42 and see that it is 322 "in sync" and will go back to sleep. The trust anchor maintainer 323 will observe resolvers change from quering for 17 to querying for 324 _17-42. Hopefully everyone will end up querying for _17-42, but the 325 maintainer can observe who is still asking for 17 and trobleshoot 326 with them to see why they have not updated yet. At some point 327 (99.9%?), the maintainer will decide enough people have moved and can 328 now start using the new key, by adding it to the DNSKEY set (if they 329 are really brave / concerned about MTU they could just start using it 330 instead of the old key). 332 The maintainer would now like to stop using the old key. They now 333 publish: 335 _17-42 IN TDS 42 8 2 333444 336 _42 IN TDS 42 8 2 333444 338 Resolvers will query for _17-42 and only receive the Key 42 record. 339 They will then remove the Key 17 record from thier config, leaving 340 only Key 42. They will then start querying just for 42, and see that 341 they are now in sync. 343 Remember: The DS records in the TDS RRSet define the entire set that 344 the trust anchor maintainer would like resolver operator to use for 345 that trust point. 347 Author's Address 349 Warren Kumari 350 Google 351 1600 Amphitheatre Parkway 352 Mountain View, CA 94043 353 US 355 Email: warren@kumari.net