idnits 2.17.1 draft-btw-add-rfc8484-clarification-02.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 draft header indicates that this document updates RFC8484, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2020) is 1362 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 normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7538 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-09 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD M. Boucadair 3 Internet-Draft Orange 4 Updates: 8484 (if approved) N. Cook 5 Intended status: Standards Track Open-Xchange 6 Expires: January 7, 2021 T. Reddy 7 McAfee 8 D. Wing 9 Citrix 10 July 6, 2020 12 Supporting Redirection for DNS Queries over HTTPS (DoH) 13 draft-btw-add-rfc8484-clarification-02 15 Abstract 17 This document clarifies whether DNS-over-HTTPS (DoH) redirection is 18 allowed, describes potential issues with redirection in DoH, and 19 proposes how DoH redirection might be performed. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 7, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. RFC8484 Update . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Issues with Redirection in DoH . . . . . . . . . . . . . . . 4 60 6. Service-Level Redirect . . . . . . . . . . . . . . . . . . . 6 61 6.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 6 62 7. Resource-Level Redirect . . . . . . . . . . . . . . . . . . . 7 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. resinfo Well-Known URI Suffix . . . . . . . . . . . . . . 8 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 11.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Extending Alternative Services . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 This document clarifies the intent of DNS-over-HTTPS (DoH) [RFC8484] 76 whether redirection is allowed (Section 4), potential issues with 77 redirection in DoH (Section 5) and subsequently makes some proposals 78 for how service-level (Section 6) and resource-level (Section 7) 79 redirection might be performed. 81 This document adheres to Section 4.3 of [I-D.ietf-httpbis-bcp56bis] 82 which discusses the need for protocols using HTTP to specify redirect 83 handling to avoid interoperability problems. 85 2. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119][RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 "A/AAAA" is used to refer to "A and/or AAAA records". 95 3. Discussion 97 [RFC8484] indicates that the support of HTTP [RFC7540] redirection is 98 one of DoH design goals (Section 1): 100 "The described approach is more than a tunnel over HTTP. It 101 establishes default media formatting types for requests and 102 responses but uses normal HTTP content negotiation mechanisms for 103 selecting alternatives that endpoints may prefer in anticipation 104 of serving new use cases. In addition to this media type 105 negotiation, it aligns itself with HTTP features such as caching, 106 redirection, proxying, authentication, and compression. 108 The integration with HTTP provides a transport suitable for both 109 existing DNS clients and native web applications seeking access to 110 the DNS." 112 Nevertheless, Section 3 of [RFC8484] indicates the following: 114 "This specification does not extend DNS resolution privileges to 115 URIs that are not recognized by the DoH client as configured 116 URIs." 118 This looks like an internal inconsistency of [RFC8484] that is worth 119 the clarification: is redirection allowed or not? 121 Also, Section 3 of [RFC8484] indicates that: 123 "A DoH client MUST NOT use a different URI simply because it was 124 discovered outside of the client's configuration (such as through 125 HTTP/2 server push) or because a server offers an unsolicited 126 response that appears to be a valid answer to a DNS query." 128 Nevertheless, [RFC8484] does not: 130 o specify under which conditions a discovered different URI can be 131 used. 133 o describe how a different URI can be discovered using HTTP/2 server 134 push. The only available example in the mailing list archives 135 clarifies that server push is an example of unsolicited responses. 137 The text was updated late in the publication process to address 138 this comment: https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB- 139 KRsLZhttx9tGt75cps/. The example provided in the thread (server 140 push) is related to the second part of the above excerpt. 142 o clarify that unsolicited messages from a configured DoH server 143 should be excluded. 145 A clarification is proposed in Section 4. This clarification focuses 146 on a "different URI" that might be discovered while communicating 147 with an HTTP server. 149 Additionally, assuming that redirection is allowed, this 150 specification recommends how it is achieved. This is required 151 because redirection to a domain-based URI requires DNS resolution of 152 that domain name, which creates a potential bootstrapping problem 153 (e.g., If DoH server is the only configured DNS server, redirecting 154 the client to a new server by presenting a name will fail). 156 4. RFC8484 Update 158 OLD: 160 A DoH client MUST NOT use a different URI simply because it was 161 discovered outside of the client's configuration (such as through 162 HTTP/2 server push) or because a server offers an unsolicited 163 response that appears to be a valid answer to a DNS query. 165 NEW 167 A DoH client MUST NOT use a different URI that was discovered 168 outside of the client's configuration when communicating with HTTP 169 servers except via HTTP redirection from a configured URI 170 (Section 6.4 of [RFC7231]). 172 Also, a DoH client MUST ignore an unsolicited response (such as 173 through HTTP/2 server push) that appears to be a valid answer to a 174 DNS query unless that response comes from a configured URI (as 175 described in Section 5.3 of [RFC8484]). 177 5. Issues with Redirection in DoH 179 There are several potential issues with redirection in DoH, which are 180 summarized below. 182 The first issue to be considered is whether a new document 183 considering redirection is needed at all. Redirection in HTTP is 184 done on a per-resource basis; if the only functionality required is 185 to redirect all requests to an entirely different server under the 186 same administrative control, then the alternative service mechanism 187 described in [RFC7838] might be sufficient. However, there are 188 restrictions on the use of alternative services; specifically the 189 certificate presented by the alternative service must be valid for 190 the origin. This restriction means that alternative services cannot 191 be used for use-cases such as redirecting the client to a locally 192 administered DoH server (e.g., resolver or forwarder) which does not 193 have a certificate valid for the origin. Additionally, alternative 194 services suffer from the bootstrapping issue described below. 196 The second issue with using HTTP redirection is bootstrapping; any 197 client that is relying solely upon a DoH server for resolution must 198 be able to resolve the domain in the redirect response. Even if a 199 DoH client has a plaintext DNS resolver configured, using that 200 resolver is considered as a minimal privacy leakage [RFC8310]. One 201 possible solution is for the DoH client to use the same server that 202 returned the redirect response to perform the resolution, however 203 that may then lead to a further redirect response. Another solution 204 is for the DoH server to include additional information in the 205 response, similar to the "glue" records as defined in [RFC7719]. 207 The final issue is that HTTP redirection is done on a per-resource 208 basis; this presents several problems for DoH: 210 1. Every GET request with a new query name will require redirection, 211 which is suboptimal. Indeed, a redirect will only affect a 212 unique request, and the DoH client will thus need to contact the 213 origin server for every new request and get redirected, requiring 214 two roundtrips. Also, permanent redirects [RFC7538] for all 215 these queries would bloat the client's HTTP cache. 217 2. Using POST requests would solve the issue. Nevertheless POST 218 responses are not widely cached as per Section 4.2.3 of 219 [RFC7231], and mandating the use of POST requests for DoH in 220 order to enable redirection hardly seems reasonable. 222 The above issues would seem to indicate that despite the intention of 223 [RFC8484] to align itself with HTTP redirection, some additional work 224 is required in order for any other mechanism than alternative 225 services (e.g., [RFC7838]) to be deployed with confidence. 227 The rest of this document considers the issue of redirection at two 228 levels: 230 1. Service-level Redirect: Similar to alternative services, this 231 would allow a DoH server to redirect a DoH client to an 232 alternative service for all future queries, rather than on a per- 233 resource basis. 235 2. Resource-Level Redirect: Solving the bootstrapping problem for 236 regular HTTP redirects. Note that this doesn't solve the caching 237 issues described above, and does raise the question of whether 238 regular HTTP redirection is desirable or worthwhile (i.e., are 239 there any valid use-cases for resource-level redirection in 240 DoH?). 242 6. Service-Level Redirect 244 We considered two possibilities for service-level redirect: 246 1. Extending [RFC7838] by relaxing the host authentication checks. 248 2. Using a well-known URI to return information about alternative 249 services. 251 Extending alternative services was considered, but rejected (see 252 Appendix A for the reasons) in favour of the well-known URI approach. 254 6.1. Well-Known URI 256 We propose the use of the well-known URI mechanism [RFC8615], with 257 the name "resinfo" to retrieve resolver information, which could 258 include specifying alternative services, through the use of a JSON 259 object in the response payload. A well-known URI would thus look 260 like "https://doh.example.com/.well-known/resinfo". 262 The example in Figure 1 shows what a JSON object might look like that 263 specified one or more alternative services. The structure of the 264 response is inspired by Section 4.4.2 of [RFC7975]. 266 Note that the response includes "glue" RR information to allow the 267 alternative service to be accessed without further DNS queries, and 268 includes an authenticated domain name to be used for authenticating 269 the alternative service. 271 { 272 "associated-resolvers": { 273 "adn": [ 274 { 275 "name": "cpe123.example.net", 276 "uri-template": [ 277 "https://cpe123.example.net/dns-query{?dns}" 278 ], 279 "a": [ 280 "192.0.2.1", 281 "192.0.2.2" 282 ], 283 "aaaa": [ 284 "2001:db8::1", 285 "2001:db8::2" 286 ], 287 "ttl": 3600 288 } 289 ] 290 } 291 } 293 Figure 1: Response Example with Glue RR Information 295 7. Resource-Level Redirect 297 Notwithstanding the issues with resource-level redirects described in 298 Section 5, this section describes a proposal for returning the "glue" 299 RRs required to avoid the bootstrapping issue described in that 300 section (but not the roundtrip or caching issues). 302 Servers supporting DoH redirect MUST support returning the redirect 303 response body mechanism described hereafter. 305 Note: "MUST" is used here because resolving the redirect name 306 using Do53 will fail in some configurations, e.g., 307 https://wiki.mozilla.org/Trusted_Recursive_Resolver 308 (network.trr.mode=3). 310 Concretely, the DoH server returns in the response body a DNS 311 response with an 'application/dns-message' media type as specified in 312 Section 6 of [RFC8484], containing any A and AAAA records for the 313 domain name in the redirect URI, including any CNAMEs. 315 For example, if the redirect URI contains the domain name 316 "redirect.example.com", and "redirect.example.com" is a CNAME 317 pointing to "real.example.com", then an example response body would 318 contain: 320 o A CNAME record for "redirect.example.com" 322 o Any A records for "real.example.com" 324 o Any AAAA records for "real.example.com" 326 This approach is simple; no client or server support of server push 327 is required, and it is also more efficient in terms of the amount of 328 data transmitted. 330 8. Security Considerations 332 DoH-related security considerations are discussed in Section 9 of 333 [RFC8484]. 335 Section 9 of [RFC7838] describes security considerations related to 336 the use of alternate services. Relaxing the host authentication 337 requirements would certainly warrant additional security 338 considerations. 340 9. IANA Considerations 342 9.1. resinfo Well-Known URI Suffix 344 This document requests IANA to assign the following well-known URI 345 from the registry available at https://www.iana.org/assignments/well- 346 known-uris/well-known-uris.xhtml. 348 URI suffix: resinfo 350 Change controller: IETF 352 Specification document(s): This document 354 Status: permanent 356 10. Acknowledgements 358 Many thanks to Christian Jacquenet, Philippe Fouquart, and Ben 359 Schwartz for the comments. 361 11. References 363 11.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 371 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 372 DOI 10.17487/RFC7231, June 2014, 373 . 375 [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 376 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, 377 April 2015, . 379 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 380 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 381 DOI 10.17487/RFC7540, May 2015, 382 . 384 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 385 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 386 April 2016, . 388 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 389 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 390 May 2017, . 392 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 393 for DNS over TLS and DNS over DTLS", RFC 8310, 394 DOI 10.17487/RFC8310, March 2018, 395 . 397 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 398 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 399 . 401 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 402 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 403 . 405 11.2. Informative References 407 [I-D.ietf-httpbis-bcp56bis] 408 Nottingham, M., "Building Protocols with HTTP", draft- 409 ietf-httpbis-bcp56bis-09 (work in progress), November 410 2019. 412 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 413 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 414 2015, . 416 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 417 "Request Routing Redirection Interface for Content 418 Delivery Network (CDN) Interconnection", RFC 7975, 419 DOI 10.17487/RFC7975, October 2016, 420 . 422 Appendix A. Extending Alternative Services 424 Section 9.2 of [RFC7838] discusses the possibilities for attackers to 425 hijack the communication to an origin. This is the justification for 426 the requirement in Section 2.1 of [RFC7838] that "Clients MUST have 427 reasonable assurances that the alternative service is under control 428 of and valid for the whole origin.". 430 However, when a DoH server presents an alternative DoH service to a 431 DoH client, both the origin and alternative service, as well as the 432 DNS queries and responses, must be, by definition, resistant to MITM 433 attacks. Thus it could be argued that in these circumstances, 434 relaxing the host authentication requirements is justified. The 435 relaxation could be limited, e.g., still requiring some relationship 436 between the origin and the alternative, or unlimited, allowing no 437 such relationship to exist. 439 However the bootstrapping issues described in Section 5 still apply, 440 and there is no mechanism for the DoH server to specify an 441 authenticated domain name to use to authenticate the alternative 442 service, making this proposal unsuitable for deployment. 444 Authors' Addresses 446 Mohamed Boucadair 447 Orange 448 Rennes 35000 449 France 451 Email: mohamed.boucadair@orange.com 452 Neil Cook 453 Open-Xchange 454 UK 456 Email: neil.cook@noware.co.uk 458 Tirumaleswar Reddy 459 McAfee, Inc. 460 Embassy Golf Link Business Park 461 Bangalore, Karnataka 560071 462 India 464 Email: TirumaleswarReddy_Konda@McAfee.com 466 Dan Wing 467 Citrix Systems, Inc. 468 USA 470 Email: dwing-ietf@fuggles.com