idnits 2.17.1 draft-huque-dnssec-alg-nego-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 206: '...t in the EDNS Flags field MUST also be...' RFC 2119 keyword, line 219: '...option, an Authoritative Server SHOULD...' RFC 2119 keyword, line 226: '...he incoming query, it MUST send back a...' RFC 2119 keyword, line 227: '...de 2). This response MUST contain the...' RFC 2119 keyword, line 245: '...ng the query domain name, then it MUST...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2018) is 2077 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) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Huque 3 Internet-Draft Salesforce 4 Intended status: Standards Track H. Shulman 5 Expires: January 23, 2019 Fraunhofer Institute 6 S. Kerr 7 Oracle Dyn 8 July 22, 2018 10 Algorithm Negotiation in DNSSEC 11 draft-huque-dnssec-alg-nego-03 13 Abstract 15 This document specifies a DNS extension that allows a DNS client to 16 specify a list of DNSSEC algorithms, in preference order, that the 17 client desires to use. A DNS server upon receipt of this extension 18 can choose to selectively respond with DNSSEC signatures using the 19 most preferred algorithm they support. This mechanism may make it 20 easier for DNS zone operators to support signing zone data 21 simultaneously with multiple DNSSEC algorithms, without significantly 22 increasing the size of DNS responses. It will also allow an easier 23 way to transition to new algorithms while still retaining support for 24 older DNS validators that do not yet support the new algorithms. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 23, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. DNSSEC Preferred Algorithms Option . . . . . . . . . . . . . 4 62 3. Why not use RFC 6975 for Algorithm Signaling? . . . . . . . . 4 63 4. Changes to Clients . . . . . . . . . . . . . . . . . . . . . 5 64 5. Changes to Servers . . . . . . . . . . . . . . . . . . . . . 5 65 6. Cache Considerations . . . . . . . . . . . . . . . . . . . . 6 66 7. Preventing Downgrade Attacks . . . . . . . . . . . . . . . . 6 67 8. Dealing with Proxies and Middleboxes . . . . . . . . . . . . 6 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 12.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The DNS Security Extensions (DNSSEC) specifications [RFC4033] 79 [RFC4034] [RFC4035] support multiple signature algorithms. A DNS 80 zone can be signed simultaneously with multiple algorithms, but there 81 is no provision in the current specifications to negotiate the 82 selective delivery of signatures of a specific algorithm in DNS 83 responses. 85 In contrast, many other security protocols, like TLS, IKE, SSH and 86 others, support an algorithm or cipher suite negotiation mechanism to 87 enable the client and server to select the "best" algorithm they 88 jointly support. 90 This means that DNS servers have to send responses with signatures of 91 all algorithms that the requested data are signed with, which can 92 result in significantly large responses. Not only is this 93 inefficient in terms of the additional communication and processing 94 overhead, but it often causes a variety of operational problems. 95 Most DNS queries and responses utilize UDP transport today. While 96 the EDNS0 specification can support very large DNS over UDP payload 97 sizes, once they exceed the common Internet Path MTU (typically about 98 1,500 octets), they need to be fragmented at the IP layer. Many 99 studies [add citations] have shown that IP fragmentation does not 100 work reliably on today's Internet, because fragments are often 101 blocked by network security devices. Furthermore, fragments can 102 cause a variety of security and operational issues, as documented in 103 [frag-bad], and previous attempts to deprecate fragments in the IETF. 104 Constraining DNS message sizes to sit comfortably within the 105 network's Path MTU can avoid these problems, and in fact modern UDP 106 Usage Guidelines [RFC8085] strongly recommend this. 108 DNS can run over other transports that can obviate the IP 109 fragmentation problem, such as TCP (with Path MTU discovery or a 110 suitably configured Maximum Segment Size) and TLS. In fact, some 111 operators are known to truncate a DNS payload in preference to 112 emitting a a response that is likely to be fragmented, instructing 113 the client to re-query over TCP. However, these alternative 114 transports have not been widely deployed in the field, and there is 115 some reluctance by operators to make wide use of TCP or TLS because 116 of their added processing and performing costs. This situation may 117 change over time, but at least today, the dominant transport for DNS 118 query and response remains UDP. 120 The response size issue is also a significant barrier to the 121 introduction of new algorithms in DNSSEC. As can be readily seen 122 from the RSA to ECDSA transition, very few zones have transitioned 123 from RSA to ECDSA, and furthermore, very few have been willing to 124 sign their zones with multiple algorithms. Newer DNSSEC algorithms 125 have already appeared or are being proposed: EdDSA [RFC8080], NSEC5 126 [nsec5], and it is expected that some time in the future, there will 127 be post quantum signature algorithms for DNSSEC. 129 It is often not feasible to deploy only a new algorithm before the 130 field of deployed validating resolvers have been updated to 131 understand it. This would cause the zone to appear unsigned to those 132 validators, negating the security that DNSSEC provides, and posing 133 critical security problems for applications like DANE [RFC6698] 134 [RFC7671] that rely on DNSSEC authentication. Thus new algorithms 135 will require zone operators to simultaneously deploy multiple 136 algorithms, and support older algorithms for an extended period of 137 time until the population of validators have upgraded themselves to 138 support the newer algorithms. 140 This document proposes a new mechanism by which a DNS client when 141 sending a query can indicate an ordered list of DNSSEC signature 142 algorithms it desires to use. The DNS server can use this 143 information to selectively construct a response with only the 144 signatures using the most preferred algorithm that it supports. 146 2. DNSSEC Preferred Algorithms Option 148 The EDNS0 specification outlined in [RFC6891] defines a way to 149 include new options using a standardized mechanism. These options 150 are contained in the RDATA of the OPT meta resource record. This 151 document defines a new EDNS0 option called "DNSSEC Preferred 152 Algorithms" used by a client to indicate an ordered list of DNSSEC 153 signature algorithms that it supports and prefers. This option can 154 appear only once in an OPT RR. 156 0 8 16 157 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 158 | OPTION-CODE | 159 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 160 | LIST-LENGTH | 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 | ALG-CODE | ... | 163 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 165 OPTION-CODE is the code (TBD) assigned by IANA for this EDNS0 option. 167 LIST-LENGTH is the length of the list of digital signatures or hash 168 algorithm codes in octets. Each algorithm code occupies a single 169 octet. 171 ALG-CODE is the list of assigned values of DNSSEC zone signature 172 algorithms that the client prefers to be used. The algorithms are 173 listed in the order preferred by the client. 175 3. Why not use RFC 6975 for Algorithm Signaling? 177 The new EDNS0 option described in this document is very similar to 178 the DNSSEC Algorithm Understood (DAU) option defined in [RFC6975] 179 (Signaling Cryptographic Algorithm Understanding). That 180 specification has not seen much adoption or even implementation, and 181 it has been suggested that it could be repurposed to implement the 182 algorithm negotiation mechanism described in this document. 184 This document proposes a new option instead, because the RFC6975 185 option could not be reused without significantly revising its 186 semantics. For example, it currently says that the list of algorithm 187 codes is unordered, and that the server must not infer any ordering 188 or preferences from the list. Furthermore, it states that the option 189 must not trigger any special processing on the server side. 191 In addition to algorithm negotiation, this new option could also 192 subsume the additional function of signaling algorithm understanding 193 originally intended by RFC 6975. 195 4. Changes to Clients 197 A client is defined to be any DNS speaker that issues a query, e.g. a 198 stub resolver, a resolver issuing outbound queries to authoritative 199 servers, or to other resolvers etc. 201 A client implementing this specification and configured to use it, 202 adds an EDNS0 DNSSEC Preferred Algorithms option to the OPT Pseudo 203 Resource Record in the Additional Section of the query, listing its 204 desired DNSSEC algorithm numbers in preferred order. It only makes 205 sense to add this option if the client is requesting DNSSEC 206 signatures, so the DNSSEC-OK bit in the EDNS Flags field MUST also be 207 set. 209 As a general rule, to maximize security, the client should prefer 210 stronger DNSSEC algorithms to weaker ones. 212 5. Changes to Servers 214 A server is defined to be any DNS speaker that sends DNS responses, 215 e.g. an authoritative server, or a resolver when answering queries 216 from downstream clients. 218 Upon receipt of a query with the DNSSEC-OK bit set, and the DNSSEC 219 Preferred Algorithms EDNS0 option, an Authoritative Server SHOULD 220 include in its response, DNSSEC signatures using only the most 221 preferred algorithm that it supports. It also includes the Preferred 222 Algorithms EDNS0 option in the response, to indicate that it 223 recognizes the option and has acted on it. 225 If an Authoritative Server has no algorithms in common with the 226 Preferred Algorithms list in the incoming query, it MUST send back a 227 SERVFAIL response (Response Code 2). This response MUST contain the 228 list of algorithms supported by the server in the EDNS0 Preferred 229 Algorithms option. [Note: this specific behavior may be 230 controversial since it is a depature from plain DNSSEC's fail open 231 behavior. Alternative behavior could be specified, such as returning 232 a NOERROR response with no signatures.] 234 If a resolver receives a query from a downstream validating client 235 with a Preferred Algorithms list different from its own, then it 236 should send outbound queries with the client's preferred list, and 237 return answers appropriately. 239 6. Cache Considerations 241 A Validating Resolver answering queries with the DNSSEC-OK bit set 242 from data in its cache needs to take a few additional steps. If the 243 query does not include the Preferred Algorithms option, and the 244 resolver has selectively cached signatures of a subset of algorithms 245 supported by the zone containing the query domain name, then it MUST 246 re-send outbound queries to the authoritative server without the 247 Preferred Algorithms option in order to retrieve the entire set of 248 signatures for the query. If the query includes the Preferred 249 Algorithms option, but prefers algorithms known to be supported for 250 the name, but different from what has been cached, the resolver MUST 251 again send outbound queries to retrieve answers with signatures the 252 client prefers, by copying the client's Preferred Algorithms option 253 into the outbound query. 255 7. Preventing Downgrade Attacks 257 There is no cryptographic integrity protection of EDNS0 options. In 258 theory, Transaction Signatures [RFC2845] could be deployed to 259 integrity protect the entire query message with per-client keys in 260 closed populations of DNS speakers, but this is not a viable 261 mechanism in the general case of arbitrary DNS clients and servers on 262 the Internet. 264 Hence an active man-in-the-middle attacker could strip out stronger 265 algorithms from the client's preferred algorithms list and force the 266 server to send back signatures with a weaker algorithm than it might 267 have otherwise sent. 269 In order to detect such attacks, the client MUST compare the zone 270 signing algorithms listed in the zone's authenticated DNSKEY RRset, 271 and the preferred list in the query that it sent, to the algorithms 272 seen in the response signatures. If signatures by the most preferred 273 algorithm they have in common have not been sent, this may indicate 274 an algorithm downgrade attack. 276 8. Dealing with Proxies and Middleboxes 278 EDNS is a hop-by-hop mechanism. Hence all DNS speakers in the path 279 from the querier invoking this option to the responding server need 280 to support this mechanism for it to work correctly. DNS proxies 281 along the path that transparently relay requests and responses, and 282 largely comply with the implementation guidelines described in 283 [RFC5625] should not be a problem. But more complicated proxies, 284 middleboxes, forwarding resolvers, etc that actively interpret DNS 285 messages, but do not understand this new option, will likely strip 286 off the unrecognized option in their outbound queries. The result 287 will be that the responding server will send back signatures made 288 with the full set of algorithms. 290 There is always a danger that a misbehaving middlebox might block or 291 drop a DNS packet with an unrecognized EDNS option, but this is a 292 threat that applies to almost all DNS extension proposals. 293 Deployment of new DNS options provides an opportunity to identify and 294 remove or fix such misbehaving devices. 296 An alternative end-to-end mechanism is described in [dnssec-nego] to 297 workaround DNS speaking middleboxes that haven't been upgraded to 298 recognize this option. It involves the client encoding the ordered 299 list of algorithms in a sequence of labels prepended to the query 300 name, and the addition of a new DNSKEY RR (with a new algorithm 301 number) at the authoritative server to signal to clients that the 302 server recognizes these specially constructed query names. No 303 further details of this alternative mechanism are provided in this 304 document, but could be incorporated in future revisions if there is 305 interest in developing that solution. 307 9. Acknowledgements 309 This specification builds on earlier work on DNSSEC algorithm 310 negotiation by Amir Herzberg and Haya Shulman in [dnssec-nego]. 312 10. Security Considerations 314 [ TODO ] 316 11. IANA Considerations 318 This specification requires the registration of a new value in the 319 DNS EDNS0 Option Code Registry, maintained by IANA. 321 12. References 323 12.1. Normative References 325 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 326 Rose, "DNS Security Introduction and Requirements", 327 RFC 4033, DOI 10.17487/RFC4033, March 2005, 328 . 330 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 331 Rose, "Resource Records for the DNS Security Extensions", 332 RFC 4034, DOI 10.17487/RFC4034, March 2005, 333 . 335 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 336 Rose, "Protocol Modifications for the DNS Security 337 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 338 . 340 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 341 for DNS (EDNS(0))", STD 75, RFC 6891, 342 DOI 10.17487/RFC6891, April 2013, . 345 12.2. Informative References 347 [dnssec-nego] 348 Herzberg, A. and H. Shulman, "Cipher-Suite Negotiation for 349 DNSSEC: Hop-by-Hop or End-to-End?", in IEEE Internet 350 Computing, February 2015, 351 . 353 [frag-bad] 354 Herzberg, A. and H. Shulman, "Fragmentation Considered 355 Poisonous", in IEEE Conference on Communications and 356 Network Security, October 2013, 357 . 359 [nsec5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 360 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 361 Existence", . 364 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 365 Wellington, "Secret Key Transaction Authentication for DNS 366 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 367 . 369 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 370 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 371 . 373 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 374 of Named Entities (DANE) Transport Layer Security (TLS) 375 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 376 2012, . 378 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 379 Algorithm Understanding in DNS Security Extensions 380 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 381 . 383 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 384 Authentication of Named Entities (DANE) Protocol: Updates 385 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 386 October 2015, . 388 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 389 Algorithm (EdDSA) for DNSSEC", RFC 8080, 390 DOI 10.17487/RFC8080, February 2017, . 393 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 394 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 395 March 2017, . 397 Authors' Addresses 399 Shumon Huque 400 Salesforce 402 Email: shuque@gmail.com 404 Haya Shulman 405 Fraunhofer Institute 407 Email: haya.shulman@gmail.com 409 Shane Kerr 410 Oracle Dyn 412 Email: shane@time-travellers.org