idnits 2.17.1 draft-hoffman-resolver-associated-doh-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 2011 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) == Outdated reference: A later version (-11) exists of draft-nottingham-rfc5785bis-08 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 7435 -- Possible downref: Non-RFC (?) normative reference: ref. 'SUDN' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Standards Track October 23, 2018 5 Expires: April 26, 2019 7 Associating a DoH Server with a Resolver 8 draft-hoffman-resolver-associated-doh-04 10 Abstract 12 Browsers and web applications may want to know if there are one or 13 more DoH servers associated with the DNS recursive resolver that the 14 operating system is already using. This would allow them to get DNS 15 responses from a resolver that the user (or, more likely, the user's 16 network administrator) has already chosen. This document describes a 17 protocol for a resolver to tell a client what its associated DoH 18 servers are. 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 April 26, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Finding the DoH Servers Associated with a Resolver . . . . . 3 57 3.1. Step 1: Finding the IP Addresses of a Resolver . . . . . 4 58 3.2. Step 2: Finding the DoH Servers Associated with a 59 Resolver . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. User Interface . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 9.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 DoH [RFC8484] requires that one or more DoH servers be configured for 74 the DoH client. That document does not say how the DoH servers are 75 found, nor how to select from a list of possible DoH servers, nor 76 what the user interface (UI) for the configuration should be. 78 There is a use case for browsers and web applications who have one or 79 more currently-configured DNS recursive resolvers wanting to use DoH 80 for DNS resolution instead. (In the rest of this document "browsers 81 and web applications" are just called "applications".) For example, 82 the recursive resolver knows how to give correct answers to DNS 83 queries that contain names that are only resolvable in the local 84 context. Users typically configure their DNS recursive resolvers 85 with through manual configuration (such as manually editing a /etc/ 86 named.conf file) or through automatic configuration from a protocol 87 such as DHCP. 89 The client that wants to change from its currently-configured Do53 90 recursive resolver(s) to one or more DoH servers might be the stub 91 resolver in an operating system, although at this time it is rare 92 that such stub resolvers can use DoH. A much more likely use case is 93 an application that is getting name resolution through the stub 94 resolver on the computer on which it is running. The user of the 95 application might have a preference for using a DoH server, and they 96 might need to use a DoH server that is associated with the resolver 97 that the computer is currently using so that its queries for non- 98 global names are answered correctly. They may also be required to 99 use only resolvers that are approved by their organization's network 100 operators. 102 To address these use cases, this document defines a new special use 103 domain name (described in [RFC6761]) and a well-known URI 104 [I-D.nottingham-rfc5785bis]. When combined, they allow an 105 application that can use the POSIX "getaddrinfo()" function and 106 resolve HTTP and HTTPS URLs to get a list of the DoH servers 107 associated with at least one of the resolvers being used by the 108 operating system on the system on which the application is being run. 110 It is important to note that using a DoH server based on the protocol 111 defined in this document will currently result in communicating with 112 opportunistic encryption [RFC7435] using "unauthenticated, encrypted 113 communication" instead of "authenticated, encrypted communication". 114 This is covered in more detail in Section 8. 116 The design choices for this protocol, particularly earlier designs 117 that were deemed unusable, are described in Section 5. 119 2. Terminology 121 In this document, the combination of "browsers and web applications" 122 is just called "applications". 124 In this document, "DoT" is used to indicate DNS over TLS as defined 125 in [RFC7858]. 127 In this document, "Do53" is used to indicate DNS over UDP or TCP as 128 defined in [RFC1035]. 130 "DoH client" and "DoH server" are defined in [RFC8484]. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 3. Finding the DoH Servers Associated with a Resolver 140 To find the DoH Servers associated with a resolver, an application 141 uses a special use domain name that causes a resolver to return its 142 IP addresses. It uses those IP addresses as part of a well-known URI 143 to find out the URI templates [RFC6570] to use for the DoH server(s) 144 associated with the resolver. 146 3.1. Step 1: Finding the IP Addresses of a Resolver 148 An application is able to use the POSIX "getaddrinfo()" function to 149 convert host names into IP addresses through the stub resolver in the 150 operating system on which it is running. It can also send queries to 151 a resolver, but it would need to have the address of that resolver 152 first. 154 In order for an application to find the address of the resolver that 155 the operating system is using, it uses the POSIX "getaddrinfo()" 156 function (or some equivalent) with the special use name "resolver- 157 addresses.arpa". When a resolver that understands this special use 158 domain name receives a query for either resolver-addresses.arpa/IN/A 159 or resolver-addresses.arpa/IN/AAAA, it returns its own IP addresses 160 in the answer. 162 3.2. Step 2: Finding the DoH Servers Associated with a Resolver 164 To find the DoH servers associated with a resolver, the client uses 165 the addresses returned from the query to resolver-addresses.arpa and 166 sends a query to: 168 https://ADDRESS/.well-known/doh-servers-associated/ 170 where "ADDRESS" is an IP address discovered in Section 3.1. 172 The resolver replies with a list of its associated DoH servers as URI 173 Templates [RFC6570]. 175 [[ Need to describe the media type; likely JSON; and the list 176 specifics. ]] 178 Note that the well-known URL above uses the HTTPS scheme and no port 179 number. A resolver using the protocol defined in this document MUST 180 provide HTTP over TLS on port 443 as defined in [RFC2818]. 182 A resolver that implements this protocol but has no DoH servers 183 associated with it returns an empty list. 185 The result of Section 3.1 may be a list of more than one IP 186 addresses. This document does not define a way for an application to 187 choose between multiple IP addresses. For example, the application 188 might try all the IP addresses, or try them in random order until it 189 gets a result, and so on. 191 The result of resolving the well-known URI can be a list of more than 192 one URI templates, possibly pointing resources in very different 193 places on the Internet. This document does not define a way for the 194 application to choose which DoH servers to use if presented with 195 multiple choices. 197 An application that is willing to use opportunistic encryption as 198 defined in [RFC7435] MAY ignore authentication failures when 199 resolving the well-known URL. 201 An application that is not willing to use opportunistic encryption as 202 defined in [RFC7435] MUST NOT ignore authentication failures when 203 going to the well-known URL. However, as described in Section 8, 204 such an application is unlikely to be able to exist today. 206 [[ Need to talk about HTTP caching ]] 208 A client MUST try to establish a new list of DoH servers associated 209 with a resolver every time the configured resolver in the operating 210 system changes. 212 4. User Interface 214 For this protocol to be useful in an application, the application 215 needs to have an entry in its configuration interface where the 216 allowed DoH servers are listed that indicates that a DoH server from 217 the configured Do53 or DoT resolver is allowed. That wording might 218 say something like "DoH server associated with my current resolver". 220 This is a place where browsers and web applications are different. 221 Most browsers have configuration interfaces, while most web 222 applications do not. 224 5. Design Choices 226 The primary use case for this protocol is an application that is 227 getting name resolution through the stub resolver on the computer on 228 which it is running wanting to switch its name resolution to DoH. A 229 secondary use case is an OS that wants to make a similar switch. 231 An earlier design suggestion was to use a new RRtype with a query to 232 ./IN/NEWRRTYPE. However, it was pointed out that this would not work 233 going through stub resolvers that validate DNSSEC. 235 An earlier design suggestion was to use DHCP to tell the OS the DoH 236 servers that the stub resolver might use. That protocol is 237 orthogonal to the one in this document in that it addresses a 238 different use case. If both the protocol in this document and a 239 DHCP-based protocol are standardized, they could co-exist. However, 240 there is no current mechanism for a stub resolver to tell an 241 application what DoH server the stub resolver is using, so DoH 242 configuration in the stub resolver would not prevent the application 243 from trying to find a DoH server on its own. 245 An earlier design suggestion was to use an EDNS0 [RFC6891] extension. 246 The design chosen in this document meets the use case better because 247 applications cannot communicate EDNS0 extensions to the stub 248 resolver. 250 An earlier design suggestion used a special use domain name of 251 resolver-associated-doh.arpa with an RRtype of TXT. The design 252 chosen in this document meets the use case better because 253 applications cannot query the stub resolver for types other than 254 address records. 256 6. IANA Considerations 258 IANA will record the domain name "resolver-addresses.arpa." in the 259 "Special-Use Domain Names" registry [SUDN]. IANA MUST NOT delegate 260 resolver-addresses.arpa in the .arpa zone. 262 [[ When this document settles down, need to register ".well-known/ 263 doh-servers-associated" as specified in [I-D.nottingham-rfc5785bis]. 264 ]] 266 7. Privacy Considerations 268 Allowing an application to use DoH instead of Do53 increases 269 communication privacy because of the TLS protection, even if that 270 communication is unauthenticated. If the communication is 271 unauthenticated (which it will be using current technologies; see 272 Section 8), the communication between the application and the DoH 273 server to be private from anyone other than a on-path attacker. 275 When a Do53 or DoT server indicates that a particular DoH server is 276 associated with it, the application might assume that the DoH server 277 has the same information privacy policies as the Do53 or DoT server. 278 Therefore, a Do53 or DoT server SHOULD NOT recommend a DoH server 279 unless that DoH server has the same (or better) information privacy 280 policy as the Do53 or DoT server. 282 8. Security Considerations 284 [RFC7435] defines "unauthenticated, encrypted communication" and 285 "authenticated, encrypted communication". Those definitions make it 286 clear that authentication is needed in every step in order to 287 consider communication authenticated and encrypted. 289 There is currently no way for an application to know whether the 290 operating system's stub resolver is using a transport that assures 291 data integrity such as DoT. This means that the protocol in 292 Section 3.1 is not authenticated. In the future, such a signal might 293 be defined and deployed, but until then, the lack of assurance of 294 authentication in the first step of this protocol (getting the 295 resolver's IP address) means that the result will always be 296 unauthenticated. 298 Even is an application could determine the use of a transport like 299 DoT for Section 3.1, the application would also need to know whether 300 the transport was authenticated or was simply chosen 301 opportunistically. Thus, if in the future, a signal about the DNS 302 transport being used by the stub resolver might be defined and 303 deployed, that signal would also have to specify if the transport is 304 also authenticated. 306 The protocol defined in Section 3.2 explicitly allows ignoring the 307 authentication of the results of resolving the well-known URI. Doing 308 so of course causes the result to be unauthenticated, encrypted 309 communication. 311 9. References 313 9.1. Normative References 315 [I-D.nottingham-rfc5785bis] 316 Nottingham, M., "Well-Known Uniform Resource Identifiers 317 (URIs)", draft-nottingham-rfc5785bis-08 (work in 318 progress), October 2018. 320 [RFC1035] Mockapetris, P., "Domain names - implementation and 321 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 322 November 1987, . 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 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 330 DOI 10.17487/RFC2818, May 2000, 331 . 333 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 334 and D. Orchard, "URI Template", RFC 6570, 335 DOI 10.17487/RFC6570, March 2012, 336 . 338 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 339 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 340 December 2014, . 342 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 343 and P. Hoffman, "Specification for DNS over Transport 344 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 345 2016, . 347 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 348 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 349 May 2017, . 351 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 352 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 353 . 355 [SUDN] "Special-Use Domain Names", n.d., 356 . 359 9.2. Informative References 361 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 362 RFC 6761, DOI 10.17487/RFC6761, February 2013, 363 . 365 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 366 for DNS (EDNS(0))", STD 75, RFC 6891, 367 DOI 10.17487/RFC6891, April 2013, 368 . 370 Acknowledgments 372 The use case in this document was inspired by discussions and the 373 DRIU BoF at IETF 102 and later in the DNSOP Working Group. Vladimir 374 Cunat, Philip Homburg, and Shumon Huque offered useful advice to 375 greatly improve an early version of the protocol. 377 Author's Address 379 Paul Hoffman 380 ICANN 382 Email: paul.hoffman@icann.org