idnits 2.17.1 draft-btw-add-rfc8484-clarification-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 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 10, 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 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-09 Summary: 2 errors (**), 0 flaws (~~), 2 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 12, 2020 T. Reddy 7 McAfee 8 D. Wing 9 Citrix 10 April 10, 2020 12 Supporting Redirect Responses in DNS Queries over HTTPS (DoH) 13 draft-btw-add-rfc8484-clarification-00 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 12, 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 5.1. Response Body . . . . . . . . . . . . . . . . . . . . . . 5 60 5.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Applicability to DoH Server Redirect . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 10.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document clarifies the intent of DNS-over-HTTPS (DoH) [RFC8484] 73 whether redirection is allowed (Section 4), and subsequently 74 specifies how redirection is performed (Sections 5 and 6). 76 This document adheres to Section 4.3 of [I-D.ietf-httpbis-bcp56bis] 77 which discusses the need for protocols using HTTP to specify redirect 78 handling to avoid interoperability problems. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in BCP 85 14 [RFC2119][RFC8174] when, and only when, they appear in all 86 capitals, as shown here. 88 "A/AAAA" is used to refer to "A and/or AAAA records". 90 3. Discussion 92 [RFC8484] indicates that the support of HTTP redirection is one of 93 DoH design goals (Section 1): 95 "The described approach is more than a tunnel over HTTP. It 96 establishes default media formatting types for requests and 97 responses but uses normal HTTP content negotiation mechanisms for 98 selecting alternatives that endpoints may prefer in anticipation 99 of serving new use cases. In addition to this media type 100 negotiation, it aligns itself with HTTP features such as caching, 101 redirection, proxying, authentication, and compression. 103 The integration with HTTP provides a transport suitable for both 104 existing DNS clients and native web applications seeking access to 105 the DNS." 107 Nevertheless, Section 3 of [RFC8484] indicates the following: 109 "This specification does not extend DNS resolution privileges to 110 URIs that are not recognized by the DoH client as configured 111 URIs." 113 This looks like an internal inconsistency of [RFC8484] that is worth 114 the clarification: is redirection allowed or not? 116 Also, Section 3 of [RFC8484] indicates that: 118 "A DoH client MUST NOT use a different URI simply because it was 119 discovered outside of the client's configuration (such as through 120 HTTP/2 server push) or because a server offers an unsolicited 121 response that appears to be a valid answer to a DNS query." 123 Nevertheless, [RFC8484] does not: 125 o specify under which conditions a discovered different URI can be 126 used. 128 o describe how a different URI can be discovered using HTTP/2 server 129 push. The only available example in the mailing list archives 130 clarifies that server push is an example of unsolicited responses. 132 The text was updated late in the publication process to address 133 this comment: https://mailarchive.ietf.org/arch/msg/doh/f_V-tBgB- 134 KRsLZhttx9tGt75cps/. The example provided in the thread (server 135 push) is related to the second part of the above excerpt. 137 o clarify that unsolicited messages from a trusted DoH server should 138 be excluded. 140 A clarification is proposed in Section 4. This clarification focuses 141 on a "different URI" that might be discovered while communicating 142 with an HTTP server. 144 Additionally, assuming that redirection is allowed, this 145 specification recommends how it is achieved, specifically regarding 146 inline resolution of any domain name in the redirect URI. This is 147 required because redirection to a domain-based URI requires DNS 148 resolution of that domain name, which creates a potential 149 bootstrapping problem (e.g., If DoH server is the only configured DNS 150 server, redirecting the client to a new server by presenting a name 151 will fail). 153 4. RFC8484 Update 155 OLD: 157 A DoH client MUST NOT use a different URI simply because it was 158 discovered outside of the client's configuration (such as through 159 HTTP/2 server push) or because a server offers an unsolicited 160 response that appears to be a valid answer to a DNS query. 162 NEW 164 A DoH client MUST NOT use a different URI that was discovered 165 outside of the client's configuration when communicating with HTTP 166 servers except via HTTP redirection from a configured URI 167 (Section 6.4 of [RFC7231]). 169 Also, a DoH client MUST ignore an unsolicited response (such as 170 through HTTP/2 server push) that appears to be a valid answer to a 171 DNS query unless that response comes from a configured URI (as 172 described in Section 5.3). 174 5. Resolving the Redirect Domain 176 Redirection in DoH is slightly different from "regular" HTTP 177 redirection, in that the DoH server may be the only configured DNS 178 resolver for the client (e.g., as per Section 7.1 of [RFC8310]). In 179 that case, and assuming the redirect URI uses a domain name, the 180 client will be unable to contact the URI returned in the redirect 181 response unless the DoH server provides the resolution information 182 for that domain as part of the response. Even if a DoH client has a 183 plaintext DNS resolver configured, using that resolver is considered 184 as a minimal privacy leakage [RFC8310]. 186 There are two possible approaches to resolving the redirect domain, 187 which are not mutually exclusive, but may have different implications 188 for clients: 190 o Returning the required A/AAAA information directly in the body of 191 the redirect response (Section 5.1). 193 o Using server push to provide the client with the required A/AAAA 194 information (Section 5.2). 196 Servers supporting DoH redirect MUST support returning the redirect 197 response body mechanism and MAY support the server push mechanism. 198 Server push has some issues as discussed in Section 4.14 of 199 [I-D.ietf-httpbis-bcp56bis]. 201 5.1. Response Body 203 Returning the required DNS response information in the body of the 204 redirect request is another approach to achieve the same goal. 206 The approach is straightforward; the DoH server returns in the 207 response body a DNS response with an application/dns-message media 208 type as specified in Section 6 of [RFC8484], containing any A and 209 AAAA records for the domain name in the redirect URI, including any 210 CNAMEs. For example if the redirect URI contains the domain name 211 "redirect.example.com", and "redirect.example.com" is a CNAME 212 pointing to "real.example.com", then an example response body would 213 contain: 215 o A CNAME record for redirect.example.com 217 o Any A records for real.example.com 219 o Any AAAA records for real.example.com 221 Advantages of this approach are simplicity; no client or server 222 support of server push is required, and it is also more efficient in 223 terms of the amount of data transmitted. 225 The main disadvantage is that this approach requires new code to be 226 developed in DoH clients to handle the new condition that a redirect 227 response will contain a "application/dns-message" media type in the 228 response body. DoH clients using HTTP stacks to perform redirection 229 transparently may run into problems, as this approach is specific to 230 DoH. 232 5.2. Server Push 234 The DoH specification allows the use of server push to send DNS 235 responses (Section 5.3 of [RFC8484]). The typical use case for 236 server push is when the server knows that the client will need to 237 make a request for a resource, and so provides the answer to that 238 request via the server push mechanism. Sending answers to queries 239 implies that the DoH server performs those queries itself, or 240 retrieves them from its cache. 242 In this case, the DoH server knows that the DoH client will need to 243 resolve the domain returned in the redirect URI. Therefore, after 244 receiving the initial request which would lead to a redirect 245 response, but before returning the response, the server MUST send a 246 push promise frame (Section 8.2.1 of [RFC7540]) request URL to 247 retrieve the A/AAAA resource records for the domain in the redirect 248 response (for example, if the domain has both A and AAAA records, two 249 push promise frames would be sent). Any intermediate CNAME records 250 would result in additional push promise frames. Promise requests 251 cannot contain a request body as specified in Section 8.2.1 of 252 [RFC7540], thus they MUST use the GET method specified in Sections 253 4.1 and 6 of [RFC8484]. The A/AAAA responses are then sent in 254 separate streams as specified in Section 8.2.2 of [RFC7540]. 255 Finally, the redirect response itself is sent. 257 An example of the use of server push for redirection is shown in 258 Figure 1. 260 DoH client DoH server 261 | | 262 |<===== Connect & TLS Negotiation ======================>| 263 |====== DNS Request for example.com/A ==================>| 264 |<===== Push Promise: GET redirect.example.com/A ========| 265 |<===== Push Promise: GET redirect.example.com/AAAA =====| 266 |<===== Redirect Response: https://redirect.example.com =| 267 |<===== Push Response for redirect.example.com/A ========| 268 |<===== Push Response for redirect.example.com/AAAA======| 269 | ... | 271 Figure 1: Redirect using Server Push 273 The advantage of using server push to provide the DNS resolution 274 information of the redirect domain is that, assuming that the DoH 275 client already supports unsolicited server push messages, then this 276 approach should work without any changes. 278 Disadvantages include the possibility that DoH clients do not support 279 server push. 281 6. Applicability to DoH Server Redirect 283 This section specifies how DoH server redirection can be safely used 284 to present a different URI to a requesting DoH client (Section 4). 285 To that aim, the DoH server uses HTTP redirection (Section 6.4 in 286 [RFC7231]) and one of the mechanisms discussed in Section 5 to inform 287 the client about the new URI and location of the DoH server. 289 The mechanism discussed in [RFC7838] MAY be implemented by a DoH 290 server if the DoH service is authoritatively available at a separate 291 network location. This mechanism requires the alternative service to 292 present a certificate for the origin's host name. 294 If the client does not support both server push (or disables server 295 push) and the response body with A/AAAA information (Section 5.1), it 296 will have to resolve the domain name in the redirected URI using 297 Do53. 299 7. Security Considerations 301 DoH-related security considerations are discussed in Section 9 of 302 [RFC8484]. 304 Section 9 of [RFC7838] describes security considerations related to 305 the use of alternate services. 307 DNS clients that ignore authentication failures and accept spoofed 308 certificates will be subject to attacks (e.g., redirect to malicious 309 servers, intercept sensitive data). 311 8. IANA Considerations 313 This document does not request any action from IANA. 315 9. Acknowledgements 317 Many thanks to Christian Jacquenet and Philippe Fouquart for the 318 review. 320 10. References 322 10.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 330 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 331 DOI 10.17487/RFC7231, June 2014, 332 . 334 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 335 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 336 DOI 10.17487/RFC7540, May 2015, 337 . 339 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 340 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 341 April 2016, . 343 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 344 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 345 May 2017, . 347 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 348 for DNS over TLS and DNS over DTLS", RFC 8310, 349 DOI 10.17487/RFC8310, March 2018, 350 . 352 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 353 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 354 . 356 10.2. Informative References 358 [I-D.ietf-httpbis-bcp56bis] 359 Nottingham, M., "Building Protocols with HTTP", draft- 360 ietf-httpbis-bcp56bis-09 (work in progress), November 361 2019. 363 Authors' Addresses 365 Mohamed Boucadair 366 Orange 367 Rennes 35000 368 France 370 Email: mohamed.boucadair@orange.com 372 Neil Cook 373 Open-Xchange 374 UK 376 Email: neil.cook@noware.co.uk 377 Tirumaleswar Reddy 378 McAfee, Inc. 379 Embassy Golf Link Business Park 380 Bangalore, Karnataka 560071 381 India 383 Email: TirumaleswarReddy_Konda@McAfee.com 385 Dan Wing 386 Citrix Systems, Inc. 387 USA 389 Email: dwing-ietf@fuggles.com