idnits 2.17.00 (12 Aug 2021) /tmp/idnits11588/draft-ietf-dnsop-edns-key-tag-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 (December 9, 2015) is 2355 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 155, but not defined == Missing Reference: 'TBA' is mentioned on line 268, but not defined == Unused Reference: 'RFC1034' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 340, 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 Labs 4 Intended status: Standards Track December 9, 2015 5 Expires: June 11, 2016 7 The EDNS Key Tag Option 8 draft-ietf-dnsop-edns-key-tag-00 10 Abstract 12 The DNS Security Extensions (DNSSEC) were developed to provide origin 13 authentication and integrity protection for DNS data by using digital 14 signatures. These digital signatures can be verified by building a 15 chain-of-trust starting from a trust anchor and proceeding down to a 16 particular node in the DNS. This document specifies a way for 17 validating end-system resolvers to signal to a server which keys are 18 referenced in their chain-of-trust. The extensions allow zone 19 administrators to monitor the progress of rollovers in a DNSSEC- 20 signed zone. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on June 11, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Use By Queriers . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . . 5 62 5.1.1. Validating Stub Resolvers . . . . . . . . . . . . . . . 5 63 5.1.2. Non-validating Stub Resolvers . . . . . . . . . . . . . 6 64 5.2. Recursive Resolvers . . . . . . . . . . . . . . . . . . . . 6 65 5.2.1. Validating Recursive Resolvers . . . . . . . . . . . . 6 66 5.2.2. Non-validating Recursive Resolvers . . . . . . . . . . 6 67 6. Use By Responders . . . . . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 80 [RFC4035] were developed to provide origin authentication and 81 integrity protection for DNS data by using digital signatures. 82 DNSSEC uses Key Tags to efficiently match signatures to the keys from 83 which they are generated. The Key Tag is a 16-bit value computed 84 from the RDATA portion of a DNSKEY RR using a formula not unlike a 85 ones-complement checksum. RRSIG RRs contain a Key Tag field whose 86 value is equal to the Key Tag of the DNSKEY RR that validates the 87 signature. 89 Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 90 whose value is equal to the Key Tag of the DNSKEY RR to which it 91 refers. 93 This draft sets out to specify a way for validating end-system 94 resolvers to tell a server in a DNS query which DNSSEC key(s) they 95 would use to validate the expected response. This is done using the 96 new EDNS option specified below in Section 4 for use in the OPT 97 meta-RR [RFC6891]. This new EDNS option code is OPTIONAL to 98 implement and use. 100 This proposed EDNS option serves to measure the acceptance and use of 101 new trust anchors and key signing keys (KSKs). This signaling option 102 can be used by zone administrators as a gauge to measure the 103 successful deployment of new keys. This is of particular interest 104 for the DNS root zone in the event of key and/or algorithm rollovers 105 which relies on [RFC5011] to automatically update a validating end- 106 system's trust anchor. 108 This draft does not seek to introduce another process for rolling 109 keys or updating trust anchors. Rather, this document specifies a 110 means by which a client query can signal the set of keys that a 111 client uses for DNSSEC validation. 113 2. Requirements Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Terminology 120 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 121 A validating security-aware resolver uses this public key or hash 122 as a starting point for building the authentication chain to a 123 signed DNS response. In general, a validating resolver will have 124 to obtain the initial values of its trust anchors via some secure 125 or trusted means outside the DNS protocol. Presence of a trust 126 anchor also implies that the resolver should expect the zone to 127 which the trust anchor points to be signed. (quoted from [RFC4033] 128 Section 2) 130 Key Tag: A 16-bit integer that identifies and enables efficient 131 selection of DNSSEC public keys. A Key Tag value can be computed 132 over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and 133 DS records can be used to help select the corresponding DNSKEY RR 134 efficiently when more than one candidate DNSKEY RR is available. 135 For most algorithms the Key Tag is a simple 16-bit modular sum of 136 the DNSKEY RDATA. See [RFC4034] Appendix B. 138 4. Option Format 140 The edns-key-tag option is encoded as follows: 142 0 8 16 143 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 144 | OPTION-CODE | 145 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 146 | OPTION-LENGTH | 147 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 148 | KEY-TAG | 149 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 150 | ... / 151 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 153 where: 155 OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD]. 157 OPTION-LENGTH: The value 2 x number of key-tag values present. 159 KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B). 161 5. Use By Queriers 163 A validating end-system resolver sets the edns-key-tag option in the 164 OPT meta-RR when sending a DNSKEY query. The validating end-system 165 resolver SHOULD also set the DNSSEC OK bit [RFC4034] to indicate that 166 it wishes to receive DNSSEC RRs in the response. 168 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY 169 queries. 171 The KEY-TAG value(s) included in the edns-key-tag option represent 172 the Key Tag of the Trust Anchor or DNSKEY RR that will be used to 173 validate the expected response. When the client sends a DNSKEY 174 query, the edns-key-tag option represents the Key Tag(s) of the 175 KSK(s) of the zone for which the server is authoritative. A 176 validating end-system resolver learns the Key Tag(s) of the KSK(s) 177 from the zone's DS record(s) (found in the parent), or from a 178 configured trust anchor. 180 A DNS client SHOULD include the edns-key-tag option when issuing a 181 DNSKEY query for a zone corresponding to a configured Trust Anchor. 183 A DNS client MAY include the edns-key-tag option when issuing a 184 DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags learned via 185 DS records). Since some DNSSEC validators implement bottom-up 186 validation, non-Trust Anchor Key Tags zone might not be known at the 187 time of the query. Such a validator can include the edns-key-tag 188 option based on previously cached data. 190 A DNS client MUST NOT include Key Tag(s) for keys which are not 191 learned via either configured Trust Anchor or DS records. 193 Since the edns-key-tag option is only set in the query, if a client 194 sees these options in the response, no action needs to be taken and 195 the client MUST ignore the option values. 197 5.1. Stub Resolvers 199 Typically, stub resolvers rely on an upstream recursive server (or 200 cache) to provide a response. Optimal setting of the edns-key-tag 201 option depends on whether the stub resolver elects to perform its own 202 validation. 204 5.1.1. Validating Stub Resolvers 206 A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to 207 indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG 208 RRs) in the response. Such validating resolvers SHOULD include the 209 edns-key-tag option in the OPT RR when sending a DNSKEY query. 211 5.1.2. Non-validating Stub Resolvers 213 The edns-key-tag option MUST NOT be included by non-validating stub 214 resolvers. 216 5.2. Recursive Resolvers 218 5.2.1. Validating Recursive Resolvers 220 A validating recursive resolver sets the edns-key-tag option when 221 performing recursion based on relevant keys it knows and any edns- 222 key-tag values in the stub client query. When the recursive server 223 receives a query with the option set, the recursive server SHOULD set 224 the edns-key-tag list for any outgoing iterative queries for that 225 resolution chain to a union of the stub client's Key Tag(s) and the 226 validating recursive resolver's Key Tag(s). For example, if the 227 recursive resolver's Key Tag list is (19036, 12345) and the stub's 228 list is (19036, 34567), the final edns-key-tag list would be (19036, 229 12345, 34567). 231 A validating recursive resolver MAY combine stub client Key Tag 232 values from multiple incoming queries into a single outgoing query. 233 It is RECOMMENDED that implementations place reasonable limits on the 234 number of Key Tags to include in the outgoing edns-key-tag option. 236 If the client included the DO and Checking Disabled (CD) bits, but 237 did not include the edns-key-tag option in the query, the validating 238 recursive resolver MAY include the option with its own Key Tag values 239 in full. 241 Validating recursive resolvers MUST NOT set the edns-key-tag option 242 in the final response to the stub client. 244 5.2.2. Non-validating Recursive Resolvers 246 Recursive resolvers that do not validate responses SHOULD copy the 247 edns-key-tag option seen in received queries, as they represent the 248 wishes of the validating downstream resolver that issued the original 249 query. 251 6. Use By Responders 253 An authoritative name server receiving queries with the edns-key-tag 254 option MAY log or otherwise collect the Key Tag values to provide 255 information to the zone operator. 257 A responder MUST NOT include the edns-key-tag option in any DNS 258 response. 260 7. IANA Considerations 262 The IANA is directed to assign an EDNS0 option code for the edns-key- 263 tag option from the DNS EDNS0 Option Codes (OPT) registry as follows: 265 +-------+--------------+----------+-----------------+ 266 | Value | Name | Status | Reference | 267 +-------+--------------+----------+-----------------+ 268 | [TBA] | edns-key-tag | Optional | [This document] | 269 +-------+--------------+----------+-----------------+ 271 8. Security Considerations 273 This document specifies a way for a client to signal its trust anchor 274 knowledge to a cache or server. The signals are optional codes 275 contained in the OPT meta-RR used with EDNS. The goal of these 276 options is to signal new trust anchor uptake in clients to allow zone 277 administrators to know when it is possible to complete a key rollover 278 in a DNSSEC-signed zone. 280 There is a possibility that an eavesdropper or server could infer the 281 validator in use by a client by the Key Tag list seen in queries. 282 This may allow an attacker to find validators using old, possibly 283 broken, keys. It could also be used to identify the validator or 284 narrow down the possible validator implementations in use by a 285 client, which could have a known vulnerability that could be 286 exploited by the attacker. 288 Consumers of data collected from the edns-key-tag option are advised 289 that provided Key Tag values might be "made up" by some DNS clients 290 with malicious or at least mischievous intentions. For example, an 291 attacker with sufficient resources might try to generate large 292 numbers of queries including only old Key Tag values, with the 293 intention of delaying the completion of a key rollover. 295 DNSSEC does not require keys in a zone to have unique Key Tags. 296 During a rollover there is a small possibility that an old key and a 297 new key will have identical Key Tag values. Zone operators relying 298 on the edns-key-tag mechanism SHOULD take care to ensure that new 299 keys have unique Key Tag values. 301 9. Privacy Considerations 303 This proposal adds additional "signaling" to DNS queries in the form 304 of Key Tag values. While Key Tag values themselves are not 305 considered private information, it may be possible for an 306 eavesdropper to use Key Tag values as a fingerprinting technique to 307 identify particular DNS validating clients. This may be especially 308 true if the validator is configured with trust anchor for zones in 309 addition to the root zone. 311 A validating end-system resolver need not transmit the edns-key-tag 312 option in every applicable query. Due to privacy concerns, such a 313 resolver MAY choose to transmit the edns-key-tag option for a subset 314 of queries (e.g., every 25th time), or by random chance with a 315 certain probability (e.g., 5%). 317 Implementations of this specification MAY be administratively 318 configured to only transmit the edns-key-tag option for certain 319 zones. For example, the software's configuration file may specify a 320 list of zones for which use of the option is allowed or denied. 321 Since the primary motivation for this specification is to provide 322 operational measurement data for root zone key rollovers, it is 323 RECOMMENDED that implementations at least include the edns-key-tag 324 option for root zone DNSKEY queries. 326 10. Acknowledgments 328 This document was inspired by and borrows heavily from [RFC6975] by 329 Scott Rose and Steve Crocker. The author would like to thank to 330 Casey Deccio and Burt Kalisky for early feedback. 332 11. References 334 11.1. Normative References 336 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 337 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 338 . 340 [RFC1035] Mockapetris, P., "Domain names - implementation and 341 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 342 November 1987, . 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 346 RFC2119, March 1997, 347 . 349 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 350 Rose, "DNS Security Introduction and Requirements", 351 RFC 4033, DOI 10.17487/RFC4033, March 2005, 352 . 354 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 355 Rose, "Resource Records for the DNS Security Extensions", 356 RFC 4034, DOI 10.17487/RFC4034, March 2005, 357 . 359 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 360 Rose, "Protocol Modifications for the DNS Security 361 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 362 . 364 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 365 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 366 RFC6891, April 2013, 367 . 369 11.2. Informative References 371 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 372 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 373 September 2007, . 375 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 376 Algorithm Understanding in DNS Security Extensions 377 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 378 . 380 Author's Address 382 Duane Wessels 383 Verisign Labs 384 12061 Bluemont Way 385 Reston, VA 20190 387 Phone: +1 703 948-3200 388 Email: dwessels@verisign.com 389 URI: http://verisigninc.com