idnits 2.17.1 draft-btw-add-rfc8484-clarification-01.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 (April 17, 2020) is 1470 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 (-12) exists of draft-btw-add-home-05 == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-09 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: October 19, 2020 T. Reddy 7 McAfee 8 D. Wing 9 Citrix 10 April 17, 2020 12 Supporting Redirect Responses in DNS Queries over HTTPS (DoH) 13 draft-btw-add-rfc8484-clarification-01 15 Abstract 17 This document clarifies whether DNS-over-HTTPS (DoH) redirection is 18 allowed and specifies how redirection is thus performed. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 19, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 4. RFC8484 Update . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Resolving the Redirect Domain . . . . . . . . . . . . . . . . 4 59 6. Applicability to DoH Server Redirect . . . . . . . . . . . . 5 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 10.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Appendix A. Server Push . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 This document clarifies the intent of DNS-over-HTTPS (DoH) [RFC8484] 72 whether redirection is allowed (Section 4), and subsequently 73 specifies how redirection is performed (Section 5). 75 This document adheres to Section 4.3 of [I-D.ietf-httpbis-bcp56bis] 76 which discusses the need for protocols using HTTP to specify redirect 77 handling to avoid interoperability problems. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in BCP 84 14 [RFC2119][RFC8174] when, and only when, they appear in all 85 capitals, as shown here. 87 "A/AAAA" is used to refer to "A and/or AAAA records". 89 3. Discussion 91 [RFC8484] indicates that the support of HTTP redirection is one of 92 DoH design goals (Section 1): 94 "The described approach is more than a tunnel over HTTP. It 95 establishes default media formatting types for requests and 96 responses but uses normal HTTP content negotiation mechanisms for 97 selecting alternatives that endpoints may prefer in anticipation 98 of serving new use cases. In addition to this media type 99 negotiation, it aligns itself with HTTP features such as caching, 100 redirection, proxying, authentication, and compression. 102 The integration with HTTP provides a transport suitable for both 103 existing DNS clients and native web applications seeking access to 104 the DNS." 106 Nevertheless, Section 3 of [RFC8484] indicates the following: 108 "This specification does not extend DNS resolution privileges to 109 URIs that are not recognized by the DoH client as configured 110 URIs." 112 This looks like an internal inconsistency of [RFC8484] that is worth 113 the clarification: is redirection allowed or not? 115 Also, Section 3 of [RFC8484] indicates that: 117 "A DoH client MUST NOT use a different URI simply because it was 118 discovered outside of the client's configuration (such as through 119 HTTP/2 server push) or because a server offers an unsolicited 120 response that appears to be a valid answer to a DNS query." 122 Nevertheless, [RFC8484] does not: 124 o specify under which conditions a discovered different URI can be 125 used. 127 o describe how a different URI can be discovered using HTTP/2 server 128 push. The only available example in the mailing list archives 129 clarifies that server push is an example of unsolicited responses. 131 The text was updated late in the publication process to address 132 this comment: https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB- 133 KRsLZhttx9tGt75cps/. The example provided in the thread (server 134 push) is related to the second part of the above excerpt. 136 o clarify that unsolicited messages from a trusted DoH server should 137 be excluded. 139 A clarification is proposed in Section 4. This clarification focuses 140 on a "different URI" that might be discovered while communicating 141 with an HTTP server. 143 Additionally, assuming that redirection is allowed, this 144 specification recommends how it is achieved, specifically regarding 145 inline resolution of any domain name in the redirect URI. This is 146 required because redirection to a domain-based URI requires DNS 147 resolution of that domain name, which creates a potential 148 bootstrapping problem (e.g., If DoH server is the only configured DNS 149 server, redirecting the client to a new server by presenting a name 150 will fail). 152 4. RFC8484 Update 154 OLD: 156 A DoH client MUST NOT use a different URI simply because it was 157 discovered outside of the client's configuration (such as through 158 HTTP/2 server push) or because a server offers an unsolicited 159 response that appears to be a valid answer to a DNS query. 161 NEW 163 A DoH client MUST NOT use a different URI that was discovered 164 outside of the client's configuration when communicating with HTTP 165 servers except via HTTP redirection from a configured URI 166 (Section 6.4 of [RFC7231]). 168 Also, a DoH client MUST ignore an unsolicited response (such as 169 through HTTP/2 server push) that appears to be a valid answer to a 170 DNS query unless that response comes from a configured URI (as 171 described in Section 5.3). 173 5. Resolving the Redirect Domain 175 Redirection in DoH is slightly different from "regular" HTTP 176 redirection, in that the DoH server may be the only configured DNS 177 resolver for the client (e.g., as per Section 7.1 of [RFC8310]). In 178 that case, and assuming the redirect URI uses a domain name, the 179 client will be unable to contact the URI returned in the redirect 180 response unless the DoH server provides the resolution information 181 for that domain as part of the response. Even if a DoH client has a 182 plaintext DNS resolver configured, using that resolver is considered 183 as a minimal privacy leakage [RFC8310]. 185 Servers supporting DoH redirect MUST support returning the redirect 186 response body mechanism described hereafter. 188 Note: "MUST" is used here because resolving the redirect name 189 using Do53 (especially for the redirection discussion in 190 Section 6) will fail in some configurations, e.g., 191 https://wiki.mozilla.org/Trusted_Recursive_Resolver 192 (network.trr.mode=3). 194 Concretely, the DoH server returns in the response body a DNS 195 response with an 'application/dns-message' media type as specified in 196 Section 6 of [RFC8484], containing any A and AAAA records for the 197 domain name in the redirect URI, including any CNAMEs. 199 For example, if the redirect URI contains the domain name 200 "redirect.example.com", and "redirect.example.com" is a CNAME 201 pointing to "real.example.com", then an example response body would 202 contain: 204 o A CNAME record for "redirect.example.com" 206 o Any A records for "real.example.com" 208 o Any AAAA records for "real.example.com" 210 This approach is simple; no client or server support of server push 211 is required, and it is also more efficient in terms of the amount of 212 data transmitted. 214 An early version of this document considered the use of server push 215 to provide the client with the required A/AAAA information 216 (Appendix A). Nevertheless, such proposal has issues as discussed in 217 Section 4.14 of [I-D.ietf-httpbis-bcp56bis]. 219 6. Applicability to DoH Server Redirect 221 This section specifies how DoH server redirection can be safely used 222 to present a different URI to a requesting DoH client (Section 4). 223 To that aim, the DoH server may use HTTP redirection (Section 6.4 in 224 [RFC7231] or [RFC7538]) and the mechanism discussed in Section 5 to 225 inform the client about the new URI and location of the DoH server. 227 The mechanism discussed in [RFC7838] MAY be implemented by a DoH 228 server if the DoH service is authoritatively available at a separate 229 network location. This mechanism requires the alternative service to 230 present a certificate for the origin's host name. Nevertheless, 231 [RFC7838] is not an option for some redirection scenarios (e.g., 232 Section 7 of [I-D.btw-add-home]). Additional complications arise to 233 provide redirection for the latter scenarios: 235 1. Every GET request with a new query name will require redirection, 236 which is suboptimal. Indeed, a redirect will only affect a 237 request and the DoH client will need to contact the base server 238 for every request and get redirected. Also, permanent redirects 239 for all these queries would also bloat the client's HTTP cache. 241 2. Using POST would solve the issue. Nevertheless POST responses 242 are not widely cached as per Section 4.2.3 of [RFC7231]. 244 3. What about relaxing [RFC7838] so that the alternate service 245 presents a certificate of a sub-domain of the Origin? 247 4. A solution that provides the same benefits as POST but without 248 the caching issues is needed. Such solution must then rely upon 249 HTTP GET method. A candidate solution using GET is described 250 hereafter. 252 5. At bootstrap, the DoH client sends a GET request against a well- 253 known URI (can also be used to retrieve the URI Templates 254 [I-D.ietf-dnsop-resolver-information]). The server can redirect 255 the client to an alternate server. The server's response will 256 include: the Authentication Domain Name (ADN) of the redirect 257 server, a list of IP addresses to locate the redirect server, a 258 list of URI Templates (e.g., https://cpe123.example.net/dns- 259 query{?dns}), CNAME, etc. Subsequent queries will be sent to the 260 redirected server. 262 An example of such response is depicted in Figure 1. The 263 structure of the response is inspired by Section 4.4.2 of 264 [RFC7975]. 266 { 267 "associated-resolvers": { 268 "adn": [ 269 { 270 "name": "cpe123.example.net", 271 "uri-template": [ 272 "https://cpe123.example.net/dns-query{?dns}" 273 ], 274 "a": [ 275 "192.0.2.1", 276 "192.0.2.2" 277 ], 278 "aaaa": [ 279 "2001:db8::1", 280 "2001:db8::2" 281 ], 282 "ttl": 3600 283 } 284 ] 285 } 286 } 288 Figure 1: Response Example 290 Unlike the GET discussed in the first bullet, this approach does 291 not bloat the cache. 293 7. Security Considerations 295 DoH-related security considerations are discussed in Section 9 of 296 [RFC8484]. 298 Section 9 of [RFC7838] describes security considerations related to 299 the use of alternate services. 301 DNS clients that ignore authentication failures and accept spoofed 302 certificates will be subject to attacks (e.g., redirect to malicious 303 servers, intercept sensitive data). 305 8. IANA Considerations 307 This document does not request any action from IANA. 309 9. Acknowledgements 311 Many thanks to Christian Jacquenet, Philippe Fouquart, and Ben 312 Schwartz for the comments. 314 10. References 316 10.1. Normative References 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, 320 DOI 10.17487/RFC2119, March 1997, 321 . 323 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 324 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 325 DOI 10.17487/RFC7231, June 2014, 326 . 328 [RFC7538] Reschke, J., "The Hypertext Transfer Protocol Status Code 329 308 (Permanent Redirect)", RFC 7538, DOI 10.17487/RFC7538, 330 April 2015, . 332 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 333 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 334 DOI 10.17487/RFC7540, May 2015, 335 . 337 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 338 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 339 April 2016, . 341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 343 May 2017, . 345 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 346 for DNS over TLS and DNS over DTLS", RFC 8310, 347 DOI 10.17487/RFC8310, March 2018, 348 . 350 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 351 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 352 . 354 10.2. Informative References 356 [I-D.btw-add-home] 357 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, "DNS- 358 over-HTTPS and DNS-over-TLS Server Discovery and 359 Deployment Considerations for Home Networks", draft-btw- 360 add-home-05 (work in progress), April 2020. 362 [I-D.ietf-dnsop-resolver-information] 363 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 364 Information Self-publication", draft-ietf-dnsop-resolver- 365 information-01 (work in progress), February 2020. 367 [I-D.ietf-httpbis-bcp56bis] 368 Nottingham, M., "Building Protocols with HTTP", draft- 369 ietf-httpbis-bcp56bis-09 (work in progress), November 370 2019. 372 [RFC7975] Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed., 373 "Request Routing Redirection Interface for Content 374 Delivery Network (CDN) Interconnection", RFC 7975, 375 DOI 10.17487/RFC7975, October 2016, 376 . 378 Appendix A. Server Push 380 The DoH specification allows the use of server push to send DNS 381 responses (Section 5.3 of [RFC8484]). The typical use case for 382 server push is when the server knows that the client will need to 383 make a request for a resource, and so provides the answer to that 384 request via the server push mechanism. Sending answers to queries 385 implies that the DoH server performs those queries itself, or 386 retrieves them from its cache. 388 In this case, the DoH server knows that the DoH client will need to 389 resolve the domain returned in the redirect URI. Therefore, after 390 receiving the initial request which would lead to a redirect 391 response, but before returning the response, the server sends a push 392 promise frame (Section 8.2.1 of [RFC7540]) request URL to retrieve 393 the A/AAAA resource records for the domain in the redirect response 394 (for example, if the domain has both A and AAAA records, two push 395 promise frames would be sent). Any intermediate CNAME records would 396 result in additional push promise frames. Promise requests cannot 397 contain a request body as specified in Section 8.2.1 of [RFC7540], 398 thus they use the GET method specified in Sections 4.1 and 6 of 399 [RFC8484]. The A/AAAA responses are then sent in separate streams as 400 specified in Section 8.2.2 of [RFC7540]. Finally, the redirect 401 response itself is sent. 403 An example of the use of server push for redirection is shown in 404 Figure 2. 406 DoH client DoH server 407 | | 408 |<===== Connect & TLS Negotiation ======================>| 409 |====== DNS Request for example.com/A ==================>| 410 |<===== Push Promise: GET redirect.example.com/A ========| 411 |<===== Push Promise: GET redirect.example.com/AAAA =====| 412 |<===== Redirect Response: https://redirect.example.com =| 413 |<===== Push Response for redirect.example.com/A ========| 414 |<===== Push Response for redirect.example.com/AAAA======| 415 | ... | 417 Figure 2: Redirect using Server Push 419 The advantage of using server push to provide the DNS resolution 420 information of the redirect domain is that, assuming that the DoH 421 client already supports unsolicited server push messages, then this 422 approach should work without any changes. 424 Disadvantages include the possibility that DoH clients do not support 425 server push. 427 Authors' Addresses 428 Mohamed Boucadair 429 Orange 430 Rennes 35000 431 France 433 Email: mohamed.boucadair@orange.com 435 Neil Cook 436 Open-Xchange 437 UK 439 Email: neil.cook@noware.co.uk 441 Tirumaleswar Reddy 442 McAfee, Inc. 443 Embassy Golf Link Business Park 444 Bangalore, Karnataka 560071 445 India 447 Email: TirumaleswarReddy_Konda@McAfee.com 449 Dan Wing 450 Citrix Systems, Inc. 451 USA 453 Email: dwing-ietf@fuggles.com