idnits 2.17.1 draft-pp-add-stub-upgrade-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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2020) is 1440 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-02) exists of draft-pp-add-resinfo-00 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Sood 3 Internet-Draft Google 4 Intended status: Standards Track P. Hoffman 5 Expires: November 15, 2020 ICANN 6 May 14, 2020 8 Upgrading Communication from Stub Resolvers to DoT or DoH 9 draft-pp-add-stub-upgrade-01 11 Abstract 13 This document describes methods for a DNS stub resolver to upgrade 14 its communications with a known recursive resolver to include 15 encrytion using DoT or DoH. This protocol is designed for the 16 scenario where the stub resolver already has the IP address of the 17 recursive resolver. 19 Other protocols under develpment address scenarios where the stub 20 resolver wants to discover recursive resolvers that use DoT or DoH. 21 This document does not cover such discovery. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 15, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Using RESINFO Responses for Upgrade . . . . . . . . . . . . . 3 60 2.1. Contacting This Resolver Using DoH . . . . . . . . . . . 3 61 2.2. Contacting This Resolver Using DoT . . . . . . . . . . . 3 62 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Method Overview . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Order of Desired Protocols . . . . . . . . . . . . . . . 6 65 4. Method Details . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Inputs to the process . . . . . . . . . . . . . . . . . . 6 67 4.2. TLS Authentication . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Registration for doh-templates in the IANA DNS Resolver 70 Information Registry . . . . . . . . . . . . . . . . . . 7 71 5.2. Registration for dot-ports in the IANA DNS Resolver 72 Information Registry . . . . . . . . . . . . . . . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 7.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 A stub resolver (hereafter called "a stub") using traditional DNS 82 over port 53 may wish to use encrypted communication with the 83 recursive resolver (hereafter called "a resolver"). In such a 84 scenario, the stub needs to know how to probe the resolver to find 85 out if it can use encrypted communication. This document describes a 86 mechanism for a stub that knows the IP address of the resolver to do 87 so. It is assumed that the IP address was received insecurely, such 88 as through DHCP. 90 The method in this document assumes that a stub wants to attempt to 91 upgrade its communication with the resolver to either DNS-over-TLS 92 (DoT, [RFC7858]) or DNS-over-HTTPS (DoH, [RFC8484]). The method is 93 basically to use a DNS request as defined in [I-D.pp-add-resinfo] to 94 get information about whether the resolver supports DoT or DoH. The 95 method can later be extended to other secure transports for stub-to- 96 resolver communication transports. 98 1.1. Definitions 100 In the rest of this document, the term "resolver" without 101 qualification means "recursive resolver" as defined in [RFC8499]. 102 Also, the term "stub" is used to mean "stub resolver". 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 2. Using RESINFO Responses for Upgrade 112 This document defines two entries for the IANA DNS Resolver 113 Information Registry that is defined in [I-D.pp-add-resinfo]. 115 2.1. Contacting This Resolver Using DoH 117 The "doh-templates" name is used to specify the URI template or 118 templates that can be used by the stub resolver for DoH queries. The 119 value MUST be an array of URI templates. Each element of the array 120 in the value is a JSON string. The host part of the URI template 121 MUST be an IP address. 123 The array in the value can be empty, which indicates that the 124 resolver does not offer DoH service. An empty array and the absence 125 of a name/value pair for "doh-templates" have identical meanings. 127 The value of "doh-templates" is an array of strings instead of just 128 one string because a resolver might have more than one IP address or 129 URL paths. The order of the elements in the array has no meaning; 130 that is, the array could instead be considered a set. 132 2.2. Contacting This Resolver Using DoT 134 The "dot-ports" name is used to specify the port(s) that can be used 135 by the stub resolver for DoT queries. The value MUST be an array of 136 port numbers. Each element of the array in the value is a JSON 137 number. 139 The value of "dot-ports" is an array of numbers instead of just one 140 number because a resolver might support DoT on more than one port. 141 The order of the elements in the array has no meaning; that is, the 142 array could instead be considered a set. 144 The array in the value can be empty, which indicates that the 145 resolver does not offer DoT service. An empty array and the absence 146 of a name/value pair for "dot-ports" have identical meanings. 148 2.3. Examples 150 A resolver has two IP addresses, 192.0.2.222 and 203.0.113.77. It 151 offers DoH service, and offers DoT service on the default port. It's 152 response to the RESINFO query might be either one of: 154 { "dot-ports": [ 853 ], "doh-templates": 155 [ "https://203.0.113.77//dns-query{?dns}", 156 "https://192.0.2.222//dns-query{?dns}" ] } 158 A resolver does not offer DoH service, but does offer DoT service on 159 the default port. It's response to the RESINFO query might be either 160 one of: 162 { "dot-ports": [ 853 ], "doh-templates": [] } 164 or 166 { "dot-ports": [ 853 ] } 168 3. Method Overview 170 The pseudocode for the method is: 172 # Things the stub resolver knows 173 # dohCapable Does the stub know how to do DoH 174 # dotCapable Does the stub know how to do DoT 175 # resIP IP address of resolver 176 # upgradeNoAuth Does the stub want to upgrade even if it can't 177 authenticate the TLS session 178 # insecureOK Does the stub want to use unauthenticated classic 179 DNS if DoH/DoT upgrades fail 181 if dohCapable: 182 send a DNS query of resolver-info.arpa/IN/RESINFO 183 if there is a non-empty "doh-templates" name in the response: 184 for each template in the name/value pair: 185 start TLS session on resIP port 443 186 if it succeeds 187 if it authenticates correctly 188 resolve the URI template 189 if 200-level response 190 use result to do DoH; finished 191 else if 300-level response 192 follow redirect, act appropriately 193 else if 400-level response 194 continue 195 else if upgradeNoAuth: 196 resolve the URI template 197 if 200-level response 198 use result to do DoH; finished 199 else if 300-level response 200 follow redirect, act appropriately 201 else if 400-level response 202 continue 203 else 204 continue 205 else 206 continue 207 # no DoH template worked 209 if dotCapable: 210 send a DNS query of resolver-info.arpa/IN/RESINFO 211 if there is a non-empty "dot-ports" name in the response: 212 for each port in the name/value pair: 213 start TLS session on resIP and the port number 214 if it succeeds 215 if it authenticates correctly 216 start doing DoT; finished 217 else if upgradeNoAuth: 218 start doing DoT; finished 219 else 220 continue 221 else 222 continue 223 # no DoT port worked 225 if insecureOK: 226 Use unencrypted DNS on port 53 227 else 228 DNS transport setup failed 230 3.1. Order of Desired Protocols 232 The pseudocode in the previous section attempts to use DoH, DoT, and 233 unencrypted DNS, in that order. This is done to keep the pseudocode 234 simple while demonstrating one possible order of transport selection. 235 A stub implementation could attempt some or all of the available DNS 236 transports in an implementation-specific or user-defined order. For 237 example, possible lists of transports to attempt might be: 239 o DoH, DoT, classic DNS 241 o DoT, DoH 243 o DoT, classic DNS 245 o Classic DNS 247 4. Method Details 249 4.1. Inputs to the process 251 The method described here requires the following information. It is 252 listed with variable names from the pseudocode in Section 3. 254 resIP The IP address of resolver. This can be either an IPv4 or 255 IPv6 address. 257 dohCapable Set to true if the stub knows how to be a DoH client 259 dohCapable Set to true if the stub knows how to be a DoT client 261 upgradeNoAuth Set to true the stub wants to use unauthenticated DoT 262 or DoH if it is available. Note that using unauthenticated DoT or 263 DoH is inherently insecure because an on-path attacker can 264 impersonate the resolver. 266 insecureOK Set to true if the stub wants to keep using classic 267 (unencrypted) DNS on port 53 if the attempt to upgrade fails. 268 Note that setting this to false will cause further DNS queries to 269 fail if upgrade fails. 271 4.2. TLS Authentication 273 In this mechanism, the stub has an IP address of the resolver. It 274 does not necessarily have a domain name associated with that IP 275 address. 277 In order to authenticate TLS sessions, the stub resolver must have a 278 set of TLS trust anchors, such as those maintained by some operating 279 systems. 281 If the stub has a domain name associated with the resolver's IP 282 address, and if the resolver uses that domain name in one of the 283 subject identifiers in its certificate during the TLS exchange, the 284 stub can use the domain name for authentication of the TLS session. 286 The stub always has an IP address for the resolver. If the resolver 287 uses the same IP address used by the stub in one of the subject 288 identifiers in its certificate during the TLS exchange, the stub can 289 use the IP address for authentication of the TLS session. 291 A resolver that uses this method to publish its information SHOULD, 292 if possible, have a TLS certificate whose subject identifiers contain 293 any of the IP addresses that stubs might be using for the resolver. 294 At the time that this document is published, getting IP addresses in 295 TLS certificates is possible, but there are only a few widely-trusted 296 CAs that issue such certificates. [RFC8738] describes a protocol 297 that may cause IP address certificates to become more common. 299 5. IANA Considerations 301 This document defines two entries for the IANA DNS Resolver 302 Information Registry that is defined in [I-D.pp-add-resinfo]. 304 5.1. Registration for doh-templates in the IANA DNS Resolver 305 Information Registry 307 Name: doh-templates 309 Value type: Array of strings 311 Specification: This document, Section 2.1 313 5.2. Registration for dot-ports in the IANA DNS Resolver Information 314 Registry 316 Name: dot-ports 318 Value type: Array of numbers 320 Specification: This document, Section 2.2 322 6. Security Considerations 324 The method described in this document explicitly allows a stub to 325 perform DNS communications over traditional unencrypted, 326 unauthenticated DNS on port 53. 328 The method described in this document explicitly allows a stub to 329 choose to allow unauthenticated TLS. In this case, the resulting 330 communication will be susceptible to obvious and well-understood 331 attacks from an attacker in the path of the communications. 333 7. References 335 7.1. Normative References 337 [I-D.pp-add-resinfo] 338 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 339 publication", draft-pp-add-resinfo-00 (work in progress), 340 April 2020. 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 348 and P. Hoffman, "Specification for DNS over Transport 349 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 350 2016, . 352 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 353 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 354 May 2017, . 356 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 357 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 358 . 360 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 361 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 362 January 2019, . 364 7.2. Informative References 366 [RFC8738] Shoemaker, R., "Automated Certificate Management 367 Environment (ACME) IP Identifier Validation Extension", 368 RFC 8738, DOI 10.17487/RFC8738, February 2020, 369 . 371 Authors' Addresses 373 Puneet Sood 374 Google 376 Email: puneets@google.com 378 Paul Hoffman 379 ICANN 381 Email: paul.hoffman@icann.org