idnits 2.17.1 draft-ietf-dnsop-edns-key-tag-05.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 16, 2017) is 2619 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 217, but not defined == Missing Reference: 'TBA' is mentioned on line 414, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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: August 20, 2017 Google 6 P. Hoffman 7 ICANN 8 February 16, 2017 10 Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) 11 draft-ietf-dnsop-edns-key-tag-05 13 Abstract 15 The DNS Security Extensions (DNSSEC) were developed to provide origin 16 authentication and integrity protection for DNS data by using digital 17 signatures. These digital signatures can be verified by building a 18 chain-of-trust starting from a trust anchor and proceeding down to a 19 particular node in the DNS. This document specifies two different 20 ways for validating resolvers to signal to a server which keys are 21 referenced in their chain-of-trust. The data from such signaling 22 allow zone administrators to monitor the progress of rollovers in a 23 DNSSEC-signed zone. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 20, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Design Evolution . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 4 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Using the edns-key-tag Option . . . . . . . . . . . . . . . . 5 64 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 5 66 4.2.1. Stub Resolvers . . . . . . . . . . . . . . . . . . . 6 67 4.2.1.1. Validating Stub Resolvers . . . . . . . . . . . . 6 68 4.2.1.2. Non-validating Stub Resolvers . . . . . . . . . . 6 69 4.2.2. Recursive Resolvers . . . . . . . . . . . . . . . . . 6 70 4.2.2.1. Validating Recursive Resolvers . . . . . . . . . 6 71 4.2.2.2. Non-validating Recursive Resolvers . . . . . . . 7 72 4.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 7 73 5. Using the Key Tag Query . . . . . . . . . . . . . . . . . . . 7 74 5.1. Query Format . . . . . . . . . . . . . . . . . . . . . . 8 75 5.2. Use By Queriers . . . . . . . . . . . . . . . . . . . . . 8 76 5.3. Use By Responders . . . . . . . . . . . . . . . . . . . . 8 77 5.3.1. Interaction With Aggressive Negative Caching . . . . 9 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 10.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034] and 90 [RFC4035] were developed to provide origin authentication and 91 integrity protection for DNS data by using digital signatures. 92 DNSSEC uses Key Tags to efficiently match signatures to the keys from 93 which they are generated. The Key Tag is a 16-bit value computed 94 from the RDATA portion of a DNSKEY RR using a formula not unlike a 95 ones-complement checksum. RRSIG RRs contain a Key Tag field whose 96 value is equal to the Key Tag of the DNSKEY RR that validates the 97 signature. 99 Likewise, Delegation Signer (DS) RRs also contain a Key Tag field 100 whose value is equal to the Key Tag of the DNSKEY RR to which it 101 refers. 103 This document specifies how validating resolvers can tell a server, 104 in a DNS query, which DNSSEC key(s) they would use to validate the 105 server's responses. It describes two independent methods for 106 conveying Key Tag information bewteen clients and servers: placing an 107 EDNS option in the OPT meta-RR [RFC6891] that contains the key tags 108 (described in Section 4), and by periodically sending special "key 109 tag queries" to a server authoritative for the zone (described in 110 Section 5). 112 Each of these new signaling mechanisms is OPTIONAL to implement and 113 use. These mechanisms serve to measure the acceptance and use of new 114 DNSSEC trust anchors and key signing keys (KSKs). This signaling 115 data can be used by zone administrators as a gauge to measure the 116 successful deployment of new keys. This is of particular interest 117 for the DNS root zone in the event of key and/or algorithm rollovers 118 that rely on [RFC5011] to automatically update a validating DNS 119 resolver's trust anchor. 121 This document does not introduce new processes for rolling keys or 122 updating trust anchors. Rather, it specifies a means by which a DNS 123 query can signal the set of keys that a client uses for DNSSEC 124 validation. 126 1.1. Design Evolution 128 Initially, when the work on this document started, it proposed 129 including Key Tag values in a new EDNS(0) option code. It was 130 modeled after [RFC6975], which provides DNSSEC algorithm signaling. 132 The authors received feedback from dnsop Working Group participants 133 that it might be better to convey Key Tags in QNAME of a separate DNS 134 query, rather than as an EDNS(0) option. Mostly this is because 135 forwarding (e.g. from stub to recursive to authoritative) could be 136 problematic. Reasons include: 138 1. EDNS(0) is a hop-by-hop protocol. Unknown option codes would not 139 be forwarded by default, as per [RFC6891]. 141 2. Middleboxes might block entire queries containing unknown EDNS(0) 142 option codes. 144 3. A recursive might need to remember Key Tag values (i.e., keep 145 state) received from its stub clients and then forward them at a 146 later opportunity. 148 One advantage of the EDNS(0) option code is that it is possible to 149 see that a stub client has a different Key Tag list than its 150 forwarder. In the QNAME-based approach, this is not possible because 151 queries originated by a stub and a forwarder are indistinguishable. 152 The authors feel this advantage is not sufficient to justify the 153 EDNS(0) approach. 155 One downside to the QNAME approach is that it uses a separate query, 156 whereas with EDNS(0) the Key Tag values are "piggy-backed" on to an 157 existing DNSKEY query. For this reason, this document recommends 158 only sending QNAME-based key tag queries for configured trust 159 anchors, although EDNS-based key tags can be sent with any DNSKEY 160 query. 162 Another downside to the QNAME-based approach is that since the trust 163 anchor zone might not contain labels matching the QNAME, these 164 queries could be subject to aggressive negative caching features now 165 in development by the Working Group. This could affect the amount of 166 signaling sent by some clients compared to others. 168 A probably minor downside to the QNAME-based approach is that it 169 cannot be used with extremely long query names if the addition of the 170 prefix would cause the name to be longer than 255 octets. 172 2. Requirements Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [RFC2119]. 178 3. Terminology 180 Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. 181 A validating security-aware resolver uses this public key or hash 182 as a starting point for building the authentication chain to a 183 signed DNS response. In general, a validating resolver will have 184 to obtain the initial values of its trust anchors via some secure 185 or trusted means outside the DNS protocol. Presence of a trust 186 anchor also implies that the resolver should expect the zone to 187 which the trust anchor points to be signed. (quoted from [RFC4033] 188 Section 2) 190 Key Tag: A 16-bit integer that identifies and enables efficient 191 selection of DNSSEC public keys. A Key Tag value can be computed 192 over the RDATA of a DNSKEY RR. The Key Tag field in the RRSIG and 193 DS records can be used to help select the corresponding DNSKEY RR 194 efficiently when more than one candidate DNSKEY RR is available. 195 For most algorithms the Key Tag is a simple 16-bit modular sum of 196 the DNSKEY RDATA. See [RFC4034] Appendix B. 198 4. Using the edns-key-tag Option 200 4.1. Option Format 202 The edns-key-tag option is encoded as follows: 204 0 8 16 205 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 206 | OPTION-CODE | 207 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 208 | OPTION-LENGTH | 209 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 210 | KEY-TAG | 211 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 212 | ... / 213 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 215 where: 217 OPTION-CODE: The EDNS0 option code assigned to edns-key-tag, [TBD]. 219 OPTION-LENGTH: The value 2 x number of key-tag values present. 221 KEY-TAG: One or more 16-bit Key Tag values ([RFC4034], Appendix B). 223 4.2. Use By Queriers 225 A validating resolver sets the edns-key-tag option in the OPT meta-RR 226 when sending a DNSKEY query. The validating resolver SHOULD also set 227 the DNSSEC OK bit [RFC4034] to indicate that it wishes to receive 228 DNSSEC RRs in the response. 230 A DNS client MUST NOT include the edns-key-tag option for non-DNSKEY 231 queries. 233 The KEY-TAG value(s) included in the edns-key-tag option represent 234 the Key Tag of the Trust Anchor or DNSKEY RR that will be used to 235 validate the expected response. When the client sends a DNSKEY 236 query, the edns-key-tag option represents the Key Tag(s) of the 237 KSK(s) of the zone for which the server is authoritative. A 238 validating resolver learns the Key Tag(s) of the KSK(s) from the 239 zone's DS record(s) (found in the parent), or from a configured trust 240 anchor. 242 A DNS client SHOULD include the edns-key-tag option when issuing a 243 DNSKEY query for a zone corresponding to a configured Trust Anchor. 245 A DNS client MAY include the edns-key-tag option when issuing a 246 DNSKEY query for a non-Trust Anchor zone (i.e., Key Tags learned via 247 DS records). Since some DNSSEC validators implement bottom-up 248 validation, non-Trust Anchor Key Tags zone might not be known at the 249 time of the query. Such a validator can include the edns-key-tag 250 option based on previously cached data. 252 A DNS client MUST NOT include Key Tag(s) for keys which are not 253 learned via either configured Trust Anchor or DS records. 255 Since the edns-key-tag option is only set in the query, if a client 256 sees these options in the response, no action needs to be taken and 257 the client MUST ignore the option values. 259 4.2.1. Stub Resolvers 261 Typically, stub resolvers rely on an upstream recursive server (or 262 cache) to provide a response. Optimal setting of the edns-key-tag 263 option depends on whether the stub resolver elects to perform its own 264 validation. 266 4.2.1.1. Validating Stub Resolvers 268 A validating stub resolver sets the DNSSEC OK (DO) bit [RFC4034] to 269 indicate that it wishes to receive additional DNSSEC RRs (i.e., RRSIG 270 RRs) in the response. Such validating resolvers SHOULD include the 271 edns-key-tag option in the OPT RR when sending a DNSKEY query. 273 4.2.1.2. Non-validating Stub Resolvers 275 The edns-key-tag option MUST NOT be included by non-validating stub 276 resolvers. 278 4.2.2. Recursive Resolvers 280 4.2.2.1. Validating Recursive Resolvers 282 A validating recursive resolver is, by definition, configured with at 283 least one trust anchor. Thus, a recursive resolver SHOULD include 284 the edns-key-tag option in its DNSKEY queries as described above. 286 In addition, the clients of a validating recursive resolver might be 287 configured to do their own validation, with their own trust 288 anchor(s). When a validating recursive resolver receives a query 289 that includes the edns-key-tag option with a Key Tag list that 290 differs from its own, it SHOULD forward both the client's Key Tag 291 list as well as its own. When doing so, the recursive resolver 292 SHOULD transmit the two Key Tag lists using separate instances of the 293 edns-key-tag option code in the OPT meta-RR. For example, if the 294 recursive resolver's Key Tag list is (19036, 12345) and the stub/ 295 client's list is (19036, 34567), the recursive would include the 296 edns-key-tag option twice: Once with values (19036, 12345) and once 297 with values (19036, 34567). 299 A validating recursive resolver MAY combine stub/client Key Tag 300 values from multiple incoming queries into a single outgoing query. 301 It is RECOMMENDED that implementations place reasonable limits on the 302 number of Key Tags to include in the outgoing edns-key-tag option. 304 If the client included the DO and Checking Disabled (CD) bits, but 305 did not include the edns-key-tag option in the query, the validating 306 recursive resolver MAY include the option with its own Key Tag values 307 in full. 309 Validating recursive resolvers MUST NOT set the edns-key-tag option 310 in the final response to the stub client. 312 4.2.2.2. Non-validating Recursive Resolvers 314 Recursive resolvers that do not validate responses SHOULD copy the 315 edns-key-tag option seen in received queries, as they represent the 316 wishes of the validating downstream resolver that issued the original 317 query. 319 4.3. Use By Responders 321 An authoritative name server receiving queries with the edns-key-tag 322 option MAY log or otherwise collect the Key Tag values to provide 323 information to the zone operator. 325 A responder MUST NOT include the edns-key-tag option in any DNS 326 response. 328 5. Using the Key Tag Query 329 5.1. Query Format 331 A key tag query consists of a standard DNS query of type NULL and of 332 class IN [RFC1035]. 334 The first component of the query name is the string "_ta-" followed 335 by a sorted, hyphen-separated list of hexadecimal-encoded Key Tag 336 values. The zone name corresponding to the trust anchor is appended 337 to this first component. 339 For example, a validating DNS resolver that has a single root zone 340 trust anchor with key tag 17476 (decimal) would originate a query of 341 the form QTYPE=NULL, QCLASS=IN, QNAME=_ta-4444. 343 Hexadecimal values MUST be zero-padded. For example, if the key tag 344 is 999 (decimal), it is represented in hexadecimal as 03e7. 346 When representing multiple key tag values, they MUST be sorted in 347 order from smallest to largest. For example, A validating DNS 348 resolver that has a three trust anchors for the example.com zone with 349 key tags 1589, 43547, 31406 (decimal) would originate a query of the 350 form QTYPE=NULL, QCLASS=IN, QNAME=_ta-0635-7aae-aa1b.example.com. 352 5.2. Use By Queriers 354 A validating DNS resolver (stub or recursive) SHOULD originate a key 355 tag query whenever it also originates a DNSKEY query for a configured 356 Trust Anchor zone. In other words, the need to issue a DNSKEY query 357 is also the trigger to issue a key tag query. 359 The value(s) included in the key tag query represent the Key Tag(s) 360 of the Trust Anchor that will be used to validate the expected DNSKEY 361 response. 363 A DNS validating resolver SHOULD NOT originate key tag queries when 364 also originating DNSKEY queries for non-Trust Anchor zones. 366 A non-validating DNS resolver MUST NOT originate key tag queries. 368 DNS resolvers with caches SHOULD cache and reuse the response to a 369 key tag query just as it would any other response. 371 5.3. Use By Responders 373 An authoritative name server receiving key tag queries MAY log or 374 otherwise collect the Key Tag values to provide information to the 375 zone operator. 377 An authoritative name server MUST generate an appropriate response to 378 the key tag query. A server does not need to have built-in logic 379 that determines the response to key tag queries: the response code is 380 determined by whether the data is in the zone file or covered by 381 wildcard. The zone operator might want to add specific key tag 382 records to its zone, perhaps with specific TTLs, to affect the 383 frequency of key tag queries from clients. 385 5.3.1. Interaction With Aggressive Negative Caching 387 Aggressive NSEC/NSEC3 negative caching 388 [draft-ietf-dnsop-nsec-aggressiveuse] may also affect the quality of 389 key tag signaling. When the response code for a key tag query is 390 NXDOMAIN, DNS resolvers that implement aggressive negative caching 391 will send fewer key tag queries than resolvers that do not implement 392 it. 394 For this reason, zone operators might choose to create records 395 corresponding to expected key tag queries. During a rollover from 396 key tag 1111 (hex) to key tag 2222 (hex), the zone could include the 397 following records: 399 _ta-1111 IN NULL \# 0 400 _ta-2222 IN NULL \# 0 401 _ta-1111-2222 IN NULL \# 0 403 Recall that when multiple key tags are present, the originating 404 client MUST sort them from smallest to largest in the query name. 406 6. IANA Considerations 408 The IANA is directed to assign an EDNS0 option code for the edns-key- 409 tag option from the DNS EDNS0 Option Codes (OPT) registry as follows: 411 +-------+--------------+----------+-----------------+ 412 | Value | Name | Status | Reference | 413 +-------+--------------+----------+-----------------+ 414 | [TBA] | edns-key-tag | Optional | [This document] | 415 +-------+--------------+----------+-----------------+ 417 7. Security Considerations 419 This document specifies a way for a client to signal its trust anchor 420 knowledge to a cache or server. The goal of these optional 421 mechanisms is to signal new trust anchor uptake in clients to allow 422 zone administrators to know when it is possible to complete a key 423 rollover in a DNSSEC-signed zone. 425 There is a possibility that an eavesdropper or server could infer the 426 validator in use by a client by the Key Tag list seen. This may 427 allow an attacker to find validators using old, possibly broken, 428 keys. It could also be used to identify the validator or narrow down 429 the possible validator implementations in use by a client, which 430 could have a known vulnerability that could be exploited by the 431 attacker. 433 Consumers of data collected from the mechanisms are advised that 434 provided Key Tag values might be "made up" by some DNS clients with 435 malicious or at least mischievous intentions. For example, an 436 attacker with sufficient resources might try to generate large 437 numbers of queries including only old Key Tag values, with the 438 intention of delaying the completion of a key rollover. 440 DNSSEC does not require keys in a zone to have unique Key Tags. 441 During a rollover there is a small possibility that an old key and a 442 new key will have identical Key Tag values. Zone operators relying 443 on the edns-key-tag mechanism SHOULD take care to ensure that new 444 keys have unique Key Tag values. 446 8. Privacy Considerations 448 This proposal adds additional, optional "signaling" to DNS queries in 449 the form of Key Tag values. While Key Tag values themselves are not 450 considered private information, it may be possible for an 451 eavesdropper to use Key Tag values as a fingerprinting technique to 452 identify particular DNS validating clients. This may be especially 453 true if the validator is configured with trust anchor for zones in 454 addition to the root zone. 456 A validating resolver need not transmit the key tags in every 457 applicable query. Due to privacy concerns, such a resolver MAY 458 choose to transmit the key tags for a subset of queries (e.g., every 459 25th time), or by random chance with a certain probability (e.g., 460 5%). 462 Implementations of this specification MAY be administratively 463 configured to only transmit the key tags for certain zones. For 464 example, the software's configuration file may specify a list of 465 zones for which use of the mechanisms described here is allowed or 466 denied. Since the primary motivation for this specification is to 467 provide operational measurement data for root zone key rollovers, it 468 is RECOMMENDED that implementations at least include the edns-key-tag 469 option for root zone DNSKEY queries. 471 9. Acknowledgments 473 This document was inspired by and borrows heavily from [RFC6975] by 474 Scott Rose and Steve Crocker. The authors would like to thank Mark 475 Andrews, Casey Deccio, Burt Kalisky, Bob Harold, Edward Lewis, Tim 476 Wicinski, Suzanne Woolf, and other members of the dnsop working group 477 for their input. 479 10. References 481 10.1. Normative References 483 [RFC1035] Mockapetris, P., "Domain names - implementation and 484 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 485 November 1987, . 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 493 Rose, "DNS Security Introduction and Requirements", 494 RFC 4033, DOI 10.17487/RFC4033, March 2005, 495 . 497 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 498 Rose, "Resource Records for the DNS Security Extensions", 499 RFC 4034, DOI 10.17487/RFC4034, March 2005, 500 . 502 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 503 Rose, "Protocol Modifications for the DNS Security 504 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 505 . 507 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 508 for DNS (EDNS(0))", STD 75, RFC 6891, 509 DOI 10.17487/RFC6891, April 2013, 510 . 512 10.2. Informative References 514 [draft-ietf-dnsop-nsec-aggressiveuse] 515 Fujiwara, K., "Aggressive use of NSEC/NSEC3", 2016. 517 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 518 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 519 September 2007, . 521 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 522 Algorithm Understanding in DNS Security Extensions 523 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 524 . 526 Authors' Addresses 528 Duane Wessels 529 Verisign 530 12061 Bluemont Way 531 Reston, VA 20190 532 United States 534 Phone: +1 703 948-3200 535 Email: dwessels@verisign.com 536 URI: http://verisigninc.com 538 Warren Kumari 539 Google 540 1600 Amphitheatre Parkway 541 Mountain View, CA 94043 542 United States 544 Email: warren@kumari.net 546 Paul Hoffman 547 ICANN 549 Email: paul.hoffman@icann.org