idnits 2.17.1 draft-huque-dnssec-alg-nego-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 : ---------------------------------------------------------------------------- ** 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 187: '...t in the EDNS Flags field MUST also be...' RFC 2119 keyword, line 200: '...option, an Authoritative Server SHOULD...' RFC 2119 keyword, line 208: '...he incoming query, it MUST send back a...' RFC 2119 keyword, line 209: '...de 2). This response MUST contain the...' RFC 2119 keyword, line 224: '...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 03, 2017) is 2482 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) == Unused Reference: 'RFC3552' is defined on line 349, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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 04, 2018 Fraunhofer Institute 6 July 03, 2017 8 Algorithm Negotiation in DNSSEC 9 draft-huque-dnssec-alg-nego-00 11 Abstract 13 This document specifies a DNS extension that allows a DNS client to 14 specify a list of DNSSEC algorithms, in preference order, that the 15 client desires to use. A DNS server upon receipt of this extension 16 can choose to selectively respond with DNSSEC signatures using the 17 most preferred algorithm they support. This mechanism may make it 18 easier for DNS zone operators to support signing zone data 19 simultaneously with multiple DNSSEC algorithms, without significantly 20 increasing the size of DNS responses. It will also allow an easier 21 way to transition to new algorithms while still retaining support for 22 older DNS validators that do not yet support the new algorithms. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 04, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. DNSSEC Preferred Algorithms Option . . . . . . . . . . . . . 3 60 3. Why not use RFC 6975 for Algorithm Signaling? . . . . . . . . 4 61 4. Changes to Clients . . . . . . . . . . . . . . . . . . . . . 4 62 5. Changes to Servers . . . . . . . . . . . . . . . . . . . . . 5 63 6. Cache Considerations . . . . . . . . . . . . . . . . . . . . 5 64 7. Preventing Downgrade Attacks . . . . . . . . . . . . . . . . 5 65 8. Dealing with Proxies and Middleboxes . . . . . . . . . . . . 6 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 12.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The DNS Security Extensions (DNSSEC) specifications [RFC4033] 77 [RFC4034] [RFC4035] support multiple signature algorithms. A DNS 78 zone can be signed simultaneously with multiple algorithms, but there 79 is no provision in the current specifications to negotiate the 80 selective delivery of signatures of a specific algorithm in DNS 81 responses. 83 In contrast, many other security protocols, like TLS, IKE, SSH and 84 others, support an algorithm or cipher suite negotiation mechanism to 85 enable the client and server to select the "best" algorithm they 86 jointly support. 88 This means that DNS servers have to send responses with signatures of 89 all algorithms that the requested data are signed with, which can 90 result in significantly large responses. Not only is this 91 inefficient in terms of the additional communication and processing 92 overhead, but it often causes a variety of operational problems. 93 Most DNS queries and responses utilize UDP transport today. While 94 the EDNS0 specification can support very large DNS over UDP payload 95 sizes, once they exceed the common Internet Path MTU (typically about 96 1,500 octets), they need to be fragmented at the IP layer. Many 97 studies [add citations] have shown that IP fragmentation does not 98 work reliably on today's Internet, because fragments are often 99 blocked by network security devices. 101 DNS can run over other transports that can obviate the IP 102 fragmentation problem, such as TCP (with Path MTU discovery or a 103 suitably configured Maximum Segment Size) and TLS. In fact, some 104 operators are known to truncate a DNS payload in preference to 105 emitting a a response that is likely to be fragmented, instructing 106 the client to re-query over TCP. However, these alternative 107 transports have not been widely deployed in the field, and there is 108 some reluctance by operators to make wide use of TCP or TLS because 109 of their added processing and performing costs. This situation may 110 change over time, but at least today, the dominant transport for DNS 111 query and response remains UDP. 113 The response size issue is also a significant barrier to the 114 introduction of new algorithms in DNSSEC. As can be readily seen 115 from the RSA to ECDSA transition, very few zones have transitioned 116 from RSA to ECDSA, and furthermore, very few have been willing to 117 sign their zones with multiple algorithms. Newer DNSSEC algorithms 118 have already appeared or are being proposed: EdDSA [RFC8080], NSEC5 119 [nsec5], and some time time in the near there will be post quantum 120 algorithms. These will likely require zone operators to deploy 121 multiple algorithms, and support older algorithms for an extended 122 period of time until the population of validators have upgraded 123 themselves to support the newer algorithms. 125 This document proposes a new mechanism by which a DNS client when 126 sending a query can indicate an ordered list of DNSSEC signature 127 algorithms it desires to use. The DNS server can use this 128 information to selectively construct a response with only the 129 signatures using the most preferred algorithm that it supports. 131 2. DNSSEC Preferred Algorithms Option 133 The EDNS0 specification outlined in [RFC6891] defines a way to 134 include new options using a standardized mechanism. These options 135 are contained in the RDATA of the OPT meta resource record. This 136 document defines a new EDNS0 option called "DNSSEC Preferred 137 Algorithms" used by a client to indicate an ordered list of DNSSEC 138 signature algorithms that it supports and prefers. This option can 139 appear only once in an OPT RR. 141 0 8 16 142 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 143 | OPTION-CODE | 144 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 145 | LIST-LENGTH | 146 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 147 | ALG-CODE | ... | 148 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 150 OPTION-CODE is the code (TBD) assigned by IANA for this EDNS0 option. 152 LIST-LENGTH is the length of the list of digital signatures or hash 153 algorithm codes in octets. Each algorithm code occupies a single 154 octet. 156 ALG-CODE is the list of assigned values of DNSSEC zone signature 157 algorithms that the client prefers to be used. The algorithms are 158 listed in the order preferred by the client. 160 3. Why not use RFC 6975 for Algorithm Signaling? 162 The new EDNS0 option described in this document is very similar to 163 the DNSSEC Algorithm Understood (DAU) option defined in [RFC6975] 164 (Signaling Cryptographic Algorithm Understanding). That 165 specification has not seen much adoption or even implementation, and 166 it has been suggested that it could be repurposed to implement the 167 algorithm negotiation mechanism described in this document. 169 This document proposes a new option instead, because the RFC6975 170 option could not be reused without significantly revising its 171 semantics. For example, it currently says that the list of algorithm 172 codes is unordered, and that the server must not infer any ordering 173 or preferences from the list. Furthermore, it states that the option 174 must not trigger any special processing on the server side. 176 4. Changes to Clients 178 A client is defined to be any DNS speaker that issues a query, e.g. a 179 stub resolver, a resolver issuing outbound queries to authoritative 180 servers, or to other resolvers etc. 182 A client implementing this specification and configured to use it, 183 adds an EDNS0 DNSSEC Preferred Algorithms option to the OPT Pseudo 184 Resource Record in the Additional Section of the query, listing its 185 desired DNSSEC algorithm numbers in preferred order. It only makes 186 sense to add this option if the client is requesting DNSSEC 187 signatures, so the DNSSEC-OK bit in the EDNS Flags field MUST also be 188 set. 190 As a general rule, to maximize security, the client should prefer 191 stronger DNSSEC algorithms to weaker ones. 193 5. Changes to Servers 195 A server is defined to be any DNS speaker that sends DNS responses, 196 e.g. an authoritative server, or a resolver when answering queries 197 from downstream clients. 199 Upon receipt of a query with the DNSSEC-OK bit set, and the DNSSEC 200 Preferred Algorithms EDNS0 option, an Authoritative Server SHOULD 201 include in its response, DNSSEC signatures using only the most 202 preferred algorithm that it supports. It also includes the Preferred 203 Algorithms EDNS0 option in the response, to indicate that it 204 recognizes the option, and should include the list of algorithms 205 supported at the server. 207 If an Authoritative Server has no algorithms in common with the 208 Preferred Algorithms list in the incoming query, it MUST send back a 209 SERVFAIL response (Response Code 2). This response MUST contain the 210 list of algorithms supported by the server in the EDNS0 Preferred 211 Algorithms option. 213 If a resolver receives a query from a downstream validating client 214 with a Preferred Algorithms list different from its own, then it 215 should send outbound queries with the client's preferred list, and 216 return answers appropriately. 218 6. Cache Considerations 220 A Validating Resolver answering queries with the DNSSEC-OK bit set 221 from data in its cache needs to take a few additional steps. If the 222 query does not include the Preferred Algorithms option, and the 223 resolver has selectively cached signatures of a subset of algorithms 224 supported by the zone containing the query domain name, then it MUST 225 re-send outbound queries to the authoritative server without the 226 Preferred Algorithms option in order to retrieve the entire set of 227 signatures for the query. If the query includes the Preferred 228 Algorithms option, but prefers algorithms known to be supported for 229 the name, but different from what has been cached, the resolver MUST 230 again send outbound queries to retrieve answers with signatures the 231 client prefers, by copying the client's Preferred Algorithms option 232 into the outbound query. 234 7. Preventing Downgrade Attacks 236 There is no cryptographic integrity protection of EDNS0 options. In 237 theory, Transaction Signatures [RFC2845] could be deployed to 238 integrity protect the entire query message with per-client keys in 239 closed populations of DNS speakers, but this is not a viable 240 mechanism in the general case of arbitrary DNS clients and servers on 241 the Internet. 243 Hence an active man-in-the-middle attacker could strip out stronger 244 algorithms from the client's supported algorithms list and force the 245 server to send back signatures with a weaker algorithm than it might 246 have otherwise sent. 248 In order to detect such attacks, the client SHOULD compare the zone 249 signing algorithms listed in the zone's authenticated DNSKEY RRset, 250 and the preferred list in the query that it sent, to the algorithms 251 seen in the response signatures. If signatures by the most preferred 252 algorithm they have in common have not been sent, this may indicate 253 an algorithm downgrade attack. 255 QUESTION: The server may have its own algorithm ranking policy, that 256 might differ from the client. Should we allow the server to select 257 its highest ranked algorithm that it shares in common with the 258 client's list, regardless of the client's preference? This is how 259 some other security protocols do it. But it will likely make it 260 harder for the (DNS) client to reliably detect downgrade attacks, 261 unless there is a common notion of ranking. One way of addressing 262 this is to define a new zone apex resource record that lists the 263 zone's preferred order of algorithm numbers. This could be queried 264 by resolvers in parallel with DNSKEY RRset queries as part of the 265 iterative resolution process, and similarly cached and refreshed. 267 8. Dealing with Proxies and Middleboxes 269 EDNS is a hop-by-hop mechanism. Hence all DNS speakers in the path 270 from the querier invoking this option to the responding server need 271 to support this mechanism for it to work correctly. DNS proxies 272 along the path that transparently relay requests and responses, and 273 largely comply with the implementation guidelines described in 274 [RFC5625] should not be a problem. But more complicated proxies, 275 middleboxes, forwarding resolvers, etc that actively interpret DNS 276 messages, but do not understand this new option, will likely strip 277 off the unrecognized option in their outbound queries. The result 278 will be that the responding server will send back signatures made 279 with the full set of algorithms. 281 There is always a danger that a misbehaving middlebox might block or 282 drop a DNS packet with an unrecognized EDNS option, but this is a 283 threat that applies to almost all DNS extension proposals. 284 Deployment of new DNS options provides an opportunity to identify and 285 remove or fix such misbehaving devices. 287 An alternative end-to-end mechanism is described in [dnssec-nego] to 288 workaround DNS speaking middleboxes that haven't been upgraded to 289 recognize this option. It involves the client encoding the ordered 290 list of algorithms in a sequence of labels prepended to the query 291 name, and the addition of a new DNSKEY RR (with a new algorithm 292 number) at the authoritative server to signal to clients that the 293 server recognizes these specially constructed query names. No 294 further details are provided in this document, but could be 295 incorporated in future revisions if there is interest in developing 296 that solution. 298 9. Acknowledgements 300 This specification builds on earlier work on DNSSEC algorithm 301 negotiation by Amir Herzberg and Haya Shulman in [dnssec-nego]. 303 10. Security Considerations 305 [ TODO ] 307 11. IANA Considerations 309 This specification requires the registration of a new value in the 310 DNS EDNS0 Option Code Registry, maintained by IANA. 312 12. References 314 12.1. Normative References 316 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 317 Rose, "DNS Security Introduction and Requirements", RFC 318 4033, March 2005. 320 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 321 Rose, "Resource Records for the DNS Security Extensions", 322 RFC 4034, March 2005. 324 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 325 Rose, "Protocol Modifications for the DNS Security 326 Extensions", RFC 4035, March 2005. 328 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 329 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 330 . 332 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 333 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 334 RFC6891, April 2013, 335 . 337 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 338 Algorithm Understanding in DNS Security Extensions 339 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 340 . 342 12.2. Informative References 344 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 345 Wellington, "Secret Key Transaction Authentication for DNS 346 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 347 . 349 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 350 Text on Security Considerations", BCP 72, RFC 3552, July 351 2003. 353 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 354 Algorithm (EdDSA) for DNSSEC", RFC 8080, DOI 10.17487/ 355 RFC8080, February 2017, 356 . 358 [dnssec-nego] 359 Herzberg, A. and H. Shulman, "Cipher-Suite Negotiation for 360 DNSSEC: Hop-by-Hop or End-to-End?", in IEEE Internet 361 Computing, February 2015, 362 . 364 [nsec5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 365 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 366 Existence", , . 369 Authors' Addresses 371 Shumon Huque 372 Salesforce 374 Email: shuque@gmail.com 375 Haya Shulman 376 Fraunhofer Institute 378 Email: haya.shulman@gmail.com