idnits 2.17.00 (12 Aug 2021) /tmp/idnits8847/draft-ietf-dnsop-edns-key-tag-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 (March 9, 2016) is 2264 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 171, but not defined == Missing Reference: 'TBA' is mentioned on line 290, but not defined == Unused Reference: 'RFC1034' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 362, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Wessels 3 Internet-Draft Verisign 4 Intended status: Standards Track W. Kumari 5 Expires: September 10, 2016 Google 6 March 9, 2016 8 The EDNS Key Tag Option 9 draft-ietf-dnsop-edns-key-tag-01 11 Abstract 13 The DNS Security Extensions (DNSSEC) were developed to provide origin 14 authentication and integrity protection for DNS data by using digital 15 signatures. These digital signatures can be verified by building a 16 chain-of-trust starting from a trust anchor and proceeding down to a 17 particular node in the DNS. This document specifies a way for 18 validating end-system resolvers to signal to a server which keys are 19 referenced in their chain-of-trust. The extensions allow zone 20 administrators to monitor the progress of rollovers in a DNSSEC- 21 signed zone. 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 September 10, 2016. 40 Copyright Notice 42 Copyright (c) 2016 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 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Use By Queriers . . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . 6 64 5.1.2. Non-validating Stub Resolvers . . . . . . . . . . . . 6 65 5.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . 6 66 5.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 6 67 5.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 7 68 6. Use By Responders . . . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 72 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 75 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 82 [RFC4035] were developed to provide origin authentication and 83 integrity protection for DNS data by using digital signatures. 84 DNSSEC uses Key Tags to efficiently match signatures to the keys from 85 which they are generated. The Key Tag is a 16-bit value computed 86 from the RDATA portion of a DNSKEY RR using a formula not unlike a 87 ones-complement checksum. RRSIG RRs contain a Key Tag field whose 88 value is equal to the Key Tag of the DNSKEY RR that validates the 89 signature. 91 Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 92 whose value is equal to the Key Tag of the DNSKEY RR to which it 93 refers. 95 This draft sets out to specify a way for validating end-system 96 resolvers to tell a server in a DNS query which DNSSEC key(s) they 97 would use to validate the expected response. This is done using the 98 new EDNS option specified below in Section 4 for use in the OPT 99 meta-RR [RFC6891]. This new EDNS option code is OPTIONAL to 100 implement and use. 102 This proposed EDNS option serves to measure the acceptance and use of 103 new trust anchors and key signing keys (KSKs). This signaling option 104 can be used by zone administrators as a gauge to measure the 105 successful deployment of new keys. This is of particular interest 106 for the DNS root zone in the event of key and/or algorithm rollovers 107 that rely on [RFC5011] to automatically update a validating end- 108 system's trust anchor. 110 [ FOR WG DISCUSSION: There is some reluctance within the working 111 group to use EDNS0 to convey the key tags upstream. In particular 112 there is a concern that middleboxes might block messages with unknown 113 option codes. Also since EDNS0 is hop-by-hop, middleboxes and un- 114 upgraded recursives won't necessarily know whether or not the edns- 115 key-tag options should be forwarded. RFC6891 says: "OPTION-CODE 116 values not understood by a responder or requestor MUST be ignored." 117 draft-wkumari-dnsop-trust-management proposed encoding this 118 information in query names, but sufficient issues with this approach 119 were discovered that the authors of the above decided to abandon this 120 work. The authors of draft-ietf-dnsop-edns-key-tag are willing to 121 consider this alternative if so guided by the working group. ] 123 This draft does not seek to introduce another process for rolling 124 keys or updating trust anchors. Rather, this document specifies a 125 means by which a client query can signal the set of keys that a 126 client uses for DNSSEC validation. 128 2. Requirements Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Terminology 136 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 137 A validating security-aware resolver uses this public key or hash 138 as a starting point for building the authentication chain to a 139 signed DNS response. In general, a validating resolver will have 140 to obtain the initial values of its trust anchors via some secure 141 or trusted means outside the DNS protocol. Presence of a trust 142 anchor also implies that the resolver should expect the zone to 143 which the trust anchor points to be signed. (quoted from [RFC4033] 144 Section 2) 146 Key Tag: A 16-bit integer that identifies and enables efficient 147 selection of DNSSEC public keys. A Key Tag value can be computed 148 over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and 149 DS records can be used to help select the corresponding DNSKEY RR 150 efficiently when more than one candidate DNSKEY RR is available. 151 For most algorithms the Key Tag is a simple 16-bit modular sum of 152 the DNSKEY RDATA. See [RFC4034] Appendix B. 154 4. Option Format 156 The edns-key-tag option is encoded as follows: 158 0 8 16 159 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 160 | OPTION-CODE | 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 | OPTION-LENGTH | 163 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 164 | KEY-TAG | 165 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 166 | ... / 167 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 169 where: 171 OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD]. 173 OPTION-LENGTH: The value 2 x number of key-tag values present. 175 KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B). 177 5. Use By Queriers 179 A validating end-system resolver sets the edns-key-tag option in the 180 OPT meta-RR when sending a DNSKEY query. The validating end-system 181 resolver SHOULD also set the DNSSEC OK bit [RFC4034] to indicate that 182 it wishes to receive DNSSEC RRs in the response. 184 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY 185 queries. 187 The KEY-TAG value(s) included in the edns-key-tag option represent 188 the Key Tag of the Trust Anchor or DNSKEY RR that will be used to 189 validate the expected response. When the client sends a DNSKEY 190 query, the edns-key-tag option represents the Key Tag(s) of the 191 KSK(s) of the zone for which the server is authoritative. A 192 validating end-system resolver learns the Key Tag(s) of the KSK(s) 193 from the zone's DS record(s) (found in the parent), or from a 194 configured trust anchor. 196 A DNS client SHOULD include the edns-key-tag option when issuing a 197 DNSKEY query for a zone corresponding to a configured Trust Anchor. 199 A DNS client MAY include the edns-key-tag option when issuing a 200 DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags learned via 201 DS records). Since some DNSSEC validators implement bottom-up 202 validation, non-Trust Anchor Key Tags zone might not be known at the 203 time of the query. Such a validator can include the edns-key-tag 204 option based on previously cached data. 206 A DNS client MUST NOT include Key Tag(s) for keys which are not 207 learned via either configured Trust Anchor or DS records. 209 Since the edns-key-tag option is only set in the query, if a client 210 sees these options in the response, no action needs to be taken and 211 the client MUST ignore the option values. 213 5.1. Stub Resolvers 215 Typically, stub resolvers rely on an upstream recursive server (or 216 cache) to provide a response. Optimal setting of the edns-key-tag 217 option depends on whether the stub resolver elects to perform its own 218 validation. 220 5.1.1. Validating Stub Resolvers 222 A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to 223 indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG 224 RRs) in the response. Such validating resolvers SHOULD include the 225 edns-key-tag option in the OPT RR when sending a DNSKEY query. 227 5.1.2. Non-validating Stub Resolvers 229 The edns-key-tag option MUST NOT be included by non-validating stub 230 resolvers. 232 5.2. Recursive Resolvers 234 5.2.1. Validating Recursive Resolvers 236 A validating recursive resolver is, by definition, configured with at 237 least one trust anchor. Thus, a recursive resolver SHOULD include 238 the edns-key-tag option in its DNSKEY queries as described above. 240 In addition, the clients of a validating recursive resolver might be 241 configured to do their own validation, with their own trust 242 anchor(s). When a validating recursive resolver receives a query 243 that includes the edns-key-tag option with a Key Tag list that 244 differs from its own, it SHOULD forward both the client's Key Tag 245 list as well as its own. When doing so, the recursive resolver 246 SHOULD transmit the two Key Tag lists using separate instances of the 247 edns-key-tag option code in the OPT meta-RR. For example, if the 248 recursive resolver's Key Tag list is (19036, 12345) and the stub/ 249 client's list is (19036, 34567), the recursive would include the 250 edns-key-tag option twice: Once with values (19036, 12345) and once 251 with values (19036, 34567). 253 A validating recursive resolver MAY combine stub/client Key Tag 254 values from multiple incoming queries into a single outgoing query. 255 It is RECOMMENDED that implementations place reasonable limits on the 256 number of Key Tags to include in the outgoing edns-key-tag option. 258 If the client included the DO and Checking Disabled (CD) bits, but 259 did not include the edns-key-tag option in the query, the validating 260 recursive resolver MAY include the option with its own Key Tag values 261 in full. 263 Validating recursive resolvers MUST NOT set the edns-key-tag option 264 in the final response to the stub client. 266 5.2.2. Non-validating Recursive Resolvers 268 Recursive resolvers that do not validate responses SHOULD copy the 269 edns-key-tag option seen in received queries, as they represent the 270 wishes of the validating downstream resolver that issued the original 271 query. 273 6. Use By Responders 275 An authoritative name server receiving queries with the edns-key-tag 276 option MAY log or otherwise collect the Key Tag values to provide 277 information to the zone operator. 279 A responder MUST NOT include the edns-key-tag option in any DNS 280 response. 282 7. IANA Considerations 284 The IANA is directed to assign an EDNS0 option code for the edns-key- 285 tag option from the DNS EDNS0 Option Codes (OPT) registry as follows: 287 +-------+--------------+----------+-----------------+ 288 | Value | Name | Status | Reference | 289 +-------+--------------+----------+-----------------+ 290 | [TBA] | edns-key-tag | Optional | [This document] | 291 +-------+--------------+----------+-----------------+ 293 8. Security Considerations 295 This document specifies a way for a client to signal its trust anchor 296 knowledge to a cache or server. The signals are optional codes 297 contained in the OPT meta-RR used with EDNS. The goal of these 298 options is to signal new trust anchor uptake in clients to allow zone 299 administrators to know when it is possible to complete a key rollover 300 in a DNSSEC-signed zone. 302 There is a possibility that an eavesdropper or server could infer the 303 validator in use by a client by the Key Tag list seen in queries. 304 This may allow an attacker to find validators using old, possibly 305 broken, keys. It could also be used to identify the validator or 306 narrow down the possible validator implementations in use by a 307 client, which could have a known vulnerability that could be 308 exploited by the attacker. 310 Consumers of data collected from the edns-key-tag option are advised 311 that provided Key Tag values might be "made up" by some DNS clients 312 with malicious or at least mischievous intentions. For example, an 313 attacker with sufficient resources might try to generate large 314 numbers of queries including only old Key Tag values, with the 315 intention of delaying the completion of a key rollover. 317 DNSSEC does not require keys in a zone to have unique Key Tags. 318 During a rollover there is a small possibility that an old key and a 319 new key will have identical Key Tag values. Zone operators relying 320 on the edns-key-tag mechanism SHOULD take care to ensure that new 321 keys have unique Key Tag values. 323 9. Privacy Considerations 325 This proposal adds additional, optional "signaling" to DNS queries in 326 the form of Key Tag values. While Key Tag values themselves are not 327 considered private information, it may be possible for an 328 eavesdropper to use Key Tag values as a fingerprinting technique to 329 identify particular DNS validating clients. This may be especially 330 true if the validator is configured with trust anchor for zones in 331 addition to the root zone. 333 A validating end-system resolver need not transmit the edns-key-tag 334 option in every applicable query. Due to privacy concerns, such a 335 resolver MAY choose to transmit the edns-key-tag option for a subset 336 of queries (e.g., every 25th time), or by random chance with a 337 certain probability (e.g., 5%). 339 Implementations of this specification MAY be administratively 340 configured to only transmit the edns-key-tag option for certain 341 zones. For example, the software's configuration file may specify a 342 list of zones for which use of the option is allowed or denied. 343 Since the primary motivation for this specification is to provide 344 operational measurement data for root zone key rollovers, it is 345 RECOMMENDED that implementations at least include the edns-key-tag 346 option for root zone DNSKEY queries. 348 10. Acknowledgments 350 This document was inspired by and borrows heavily from [RFC6975] by 351 Scott Rose and Steve Crocker. The authors would like to thank Casey 352 Deccio, Burt Kalisky, Bob Harold, Tim Wicinski, Suzanne Woolf, and 353 other members of the dnsop working group for their input. 355 11. References 356 11.1. Normative References 358 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 359 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 360 . 362 [RFC1035] Mockapetris, P., "Domain names - implementation and 363 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 364 November 1987, . 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 368 RFC2119, March 1997, 369 . 371 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 372 Rose, "DNS Security Introduction and Requirements", 373 RFC 4033, DOI 10.17487/RFC4033, March 2005, 374 . 376 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 377 Rose, "Resource Records for the DNS Security Extensions", 378 RFC 4034, DOI 10.17487/RFC4034, March 2005, 379 . 381 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 382 Rose, "Protocol Modifications for the DNS Security 383 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 384 . 386 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 387 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 388 RFC6891, April 2013, 389 . 391 11.2. Informative References 393 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 394 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 395 September 2007, . 397 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 398 Algorithm Understanding in DNS Security Extensions 399 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 400 . 402 Appendix A. Changes / Author Notes. 404 [RFC Editor: Please remove this section before publication] 406 From -00 to -01: 408 o Changed how a recursive should combine a stub's key tag values 409 with its own. Previously it was to be a union of key tag values. 410 Now it is a separate instance of the option code for recursive and 411 stub. 413 o Added Warren as coauthor. 415 Authors' Addresses 417 Duane Wessels 418 Verisign 419 12061 Bluemont Way 420 Reston, VA 20190 421 United States 423 Phone: +1 703 948-3200 424 Email: dwessels@verisign.com 425 URI: http://verisigninc.com 427 Warren Kumari 428 Google 429 1600 Amphitheatre Parkway 430 Mountain View, CA 94043 431 United States 433 Email: warren@kumari.net