idnits 2.17.1 draft-btw-add-home-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 : ---------------------------------------------------------------------------- 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 (March 6, 2020) is 1512 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) == Missing Reference: 'ThisDocument' is mentioned on line 658, but not defined == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-terminology-ter-01 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-07 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track T. Reddy 5 Expires: September 7, 2020 McAfee 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 March 6, 2020 12 DNS-over-HTTPS and DNS-over-TLS server Discovery and Deployment 13 Considerations for Home and Mobile Networks 14 draft-btw-add-home-01 16 Abstract 18 This document discusses DoT/DoH deployment considerations for home 19 networks. It particularly sketches the required steps to use DoT/DoH 20 capabilities provided by local networks. 22 One of the goals of this document is to assess to what extent 23 existing tools can be used to provide a DoT/DoH service. As an 24 outcome, new DHCP and Router Advertisement Options are specified in 25 order to convey a DNS Authentication Domain Name. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 7, 2020. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Sample Deployment Scenarios . . . . . . . . . . . . . . . . . 4 64 4. DNS Reference Identifier Option . . . . . . . . . . . . . . . 6 65 4.1. DHCPv6 DNS Reference Identifier Option . . . . . . . . . 7 66 4.2. DHCP DNS Reference Identifier Option . . . . . . . . . . 8 67 4.3. RA DNS Reference Identifier Option . . . . . . . . . . . 8 68 5. Locating DoH/DoT Servers . . . . . . . . . . . . . . . . . . 9 69 6. DNS-over-TLS and DNS-over-HTTPS Server Discovery Procedure . 11 70 7. Hosting DoH/DoT Forwarder in the CPE . . . . . . . . . . . . 12 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 9.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 14 74 9.2. DHCP Option . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.3. RA Option . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.4. Service Name . . . . . . . . . . . . . . . . . . . . . . 15 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 11.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 Internet Service Providers (ISPs) traditionally provide DNS resolvers 86 to their customers. Typically, ISPs deploy the following mechanisms 87 to advertise a list of DNS Recursive DNS server(s) to their 88 customers: 90 o Protocol Configuration Options in cellular networks [TS.24008]. 91 o DHCP [RFC2132] (Domain Name Server Option) or DHCPv6 92 [RFC8415][RFC3646] (OPTION_DNS_SERVERS). 93 o IPv6 Router Advertisement [RFC4861][RFC8106] (Type 25 (Recursive 94 DNS Server Option)). 96 The communication between a customer's device (UE) (possibly via 97 Customer Premise Equipment (CPE)) and an ISP-supplied DNS resolver 98 takes place by using cleartext DNS messages (Do53, 99 [I-D.ietf-dnsop-terminology-ter]). Some examples are depicted in 100 Figure 1. In the case of cellular networks, connectivity can be 101 provided to a UE or to a CPE. Do53 mechanisms used within the LAN 102 are similar in both fixed and cellular CPE-based broadband service 103 offerings. 105 (a) Fixed Networks 107 ,--,--,--. ,--,--,--. 108 ,-' +--+ `-. ,-' ISP `-. 109 ( LAN |UE| CPE----( DNS Server ) 110 `-. +--+ ,-' `-. ,-' 111 `--'|-'--' `--'--'--' 112 | | 113 |<=======Do53========>| 115 (b) Cellular Networks 117 |<===========Do53=========>| 118 ,--,-|,--. | 119 ,-' +--+ `-. ,--,--,--. 120 ( LAN |UE| CPE------------+ \ 121 `-. +--+ ,-' ,' ISP `-. 122 `--'--'--' ( DNS Server ) 123 +-----+-. ,-' 124 +--+ | `--'--'--' 125 |UE+-----------+ 126 +--+ 128 Figure 1: Sample Legacy Deployments 130 ISPs use DNS to provide additional services such as (but not limited 131 to) malware filtering, parental control, or VoD (Video on Demand) 132 optimization. DNS is also a central component for mastering the 133 quality of experience for current latency-sensitive services, but 134 also emerging ones (such as those services that pertain to the Ultra 135 Reliability and Low Latency Communications (uRLLC) or Enhanced Mobile 136 Broadband (eMBB). 138 For example, the latency targets set in the context of 5G are 1ms 139 (uRLLC) and 4ms (eMBB). An ISP will be able to address such 140 demanding latency requirements assuming the corresponding services 141 rely upon resources (network, compute, storage) that are located 142 as close to the user as possible (e.g., by means of Edge Computing 143 techniques and resources). Such latency requirements are likely 144 to be addressed by means of optimized designs (DNS, in 145 particular), too. 147 Relying upon local DNS resolvers will therefore contribute to meet 148 the aforementioned service requirements. The use of external 149 resolvers is likely to induce an extra service delay which exceeds by 150 far the service target. 152 This document focuses on the support of DNS-over-HTTPS (DoH) 153 [RFC8484] or DNS-over-TLS (DoT) [RFC7858] in local networks. In 154 particular, the document describes how a local DoH/DoT server can be 155 discovered and used by connected hosts. This document specifies 156 DHCP/RA options that allows DNS clients to discover local DoT/DoH 157 servers. Section 4 describes DHCPv4, DHCPv6 and RA options to convey 158 the authentication domain name information (ADN, defined in 159 [RFC8310]). 161 Some ISPs rely upon external resolvers (e.g., outsourced service or 162 public resolvers); these ISPs provide their customers with the IP 163 addresses of these resolvers. These addresses are typically 164 configured on CPEs using the same mechanisms listed above. This 165 document permits such deployments. It is up to an ISP to decide 166 which list of DNS resolvers to advertise to its serviced devices. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 172 "OPTIONAL" in this document are to be interpreted as described in BCP 173 14 [RFC2119][RFC8174] when, and only when, they appear in all 174 capitals, as shown here. 176 This document makes use of the terms defined in [RFC8499] and 177 [I-D.ietf-dnsop-terminology-ter]. 179 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 181 3. Sample Deployment Scenarios 183 ISPs have developed an expertise in managing service-specific 184 configuration information (e.g., CPE WAN Management Protocol 185 [TR-069]). For example, these tools may be used to provision 186 authentication domain name information (ADN, defined in [RFC8310]) to 187 managed CPEs if DoH/DoT is supported by a local network similar to 188 what is depicted in Figure 2. 190 DNS clients may try to establish DoH/DoT sessions with discovered DNS 191 servers to determine whether these servers support DoH and/or DoT 192 (Section 5). Alternatively, a DNS client may discover whether the 193 DNS server in the local network supports DoH/DoT by using the 194 mechanism discussed in Section 6. 196 (a) Fixed Networks 198 ,--,--,--. ,--,--,--. 199 ,-' +--+ `-. ,-' ISP `-. 200 ( LAN |UE| CPE----( DNS Server ) 201 `-. +--+ ,-' `-. ,-' 202 `--'|-'--' `--'--'--' 203 | | 204 |<=======DoH/DoT=====>| 206 (b) Cellular Networks 208 |<===========DoH/DoT======>| 209 ,--,-|,--. | 210 ,-' +--+ `-. ,--,--,--. 211 ( LAN |UE| CPE------------+ \ 212 `-. +--+ ,-' ,' ISP `-. 213 `--'--'--' ( DNS Server ) 214 +-----+-. ,-' 215 +--+ | `--'--'--' 216 |UE+-----------+ 217 +--+ 219 Figure 2: DoH/DoT in the WAN 221 Figure 2 shows the scenario where the CPE relays the list of DoT/DoH 222 servers it learns for the network by using mechanisms like DHCP or a 223 specific Router Advertisement message. In such context, direct DoH/ 224 DoT sessions will be established between a host serviced by a CPE and 225 an ISP-supplied DoT/DoH server (see the example depicted in Figure 3 226 for a DoH/DoT-capable host). 228 ,--,--,--. ,--,--,--. 229 ,-' `-. ,-' ISP `-. 230 UE----( LAN CPE----( DNS Server ) 231 | `-. ,-' `-. ,-' 232 | `--'--'--' `--'--'--' 233 | | 234 |<==============DoT/DoH============>| 236 Figure 3: Direct DoH/DoT Sessions 238 Figure 4 shows a deployment where the CPE embeds a caching DNS 239 forwarder. The CPE advertises itself as the default DNS server to 240 the hosts it serves. The CPE relies upon DHCP or RA to advertise 241 itself to internal hosts as the default DoT/DoH/Do53 server. When 242 receiving a DNS request it cannot handle locally, the CPE forwards 243 the request to an upstream DoH/DoT/Do53 resolver. Such deployment is 244 required for IPv4 service continuity purposes (e.g., 245 [I-D.ietf-v6ops-rfc7084-bis]) or for supporting advanced services 246 within the home (e.g., malware filtering, parental control, 247 Manufacturer Usage Description (MUD, [RFC8520] to only allow intended 248 communications to and from an IoT device). When the CPE behaves as a 249 DNS forwarder, DNS communications can be decomposed into two legs: 251 o The leg between an internal host and the CPE. 253 o The leg between the CPE and an upstream DNS resolver. 255 Also, an ISP that wants to offer DoH/DoT to its customers may enable 256 DoH/DoT in both legs as shown in Figure 4. Additional considerations 257 related to this approach are discussed in Section 7. 259 ,--,--,--. ,--,--,--. 260 ,-' `-. ,-' ISP `-. 261 UE----( LAN CPE----( DNS Server ) 262 | `-. ,-'| `-. ,-' 263 | `--'--'--' | `--'--'--' 264 | | | 265 |<======DoT/DoH======>|<==DoT/DoH==>| 267 Figure 4: Proxied DoH/DoT Sessions 269 4. DNS Reference Identifier Option 271 This section describes how a DNS client can discover the ADN of local 272 DoH/DoT server(s) using DHCP (Sections 4.1 and 4.2) and RA 273 (Section 4.3). 275 As reported in Section 1.7.2 of [RFC6125]: 277 "few certification authorities issue server certificates based on 278 IP addresses, but preliminary evidence indicates that such 279 certificates are a very small percentage (less than 1%) of issued 280 certificates". 282 In order to allow for PKIX-based authentication between a DNS client 283 and a DoH/DoT server while accommodating the current best practices 284 for issuing certificates, this document allows for configuring an 285 authentication domain name to be presented as a reference identifier 286 for DNS authentication purposes. 288 The DNS client establishes a DoH/DoT session with the discovered DNS 289 IP address(es) (Section 5) and uses the mechanism discussed in 290 Section 8 of [RFC8310] to authenticate the DNS server certificate 291 using the authentication domain name conveyed in the DNS Reference 292 Identifier. 294 If the DNS Reference Identifier is discovered by a host using both RA 295 and DHCP, the rules discussed in Section 5.3.1 of [RFC8106] MUST be 296 followed. 298 4.1. DHCPv6 DNS Reference Identifier Option 300 The DHCPv6 DNS Reference Identifier option is used to configure an 301 authentication domain name of the DoH/DoT server. The format of this 302 option is shown in Figure 5. 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | OPTION_V6_DNS_RI | Option-length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 | authentication-domain-name | 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 5: DHCPv6 DNS Reference Identifier Option 315 The fields of the option shown in Figure 5 are as follows: 317 o Option-code: OPTION_V6_DNS_RI (TBA1, see Section 9.1) 318 o Option-length: Length of the authentication-domain-name field in 319 octets. 320 o authentication-domain-name: A fully qualified domain name of the 321 DoH/DoT server. This field is formatted as specified in 322 Section 10 of [RFC8415]. 324 An example of the authentication-domain-name encoding is shown in 325 Figure 6. This example conveys the FQDN "doh1.example.com.". 327 +------+------+------+------+------+------+------+------+------+ 328 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 329 +------+------+------+------+------+------+------+------+------+ 330 | m | p | l | e | 0x03 | c | o | m | 0x00 | 331 +------+------+------+------+------+------+------+------+------+ 333 Figure 6: An example of the authentication-domain-name Encoding 335 4.2. DHCP DNS Reference Identifier Option 337 The DHCP DNS Reference Identifier option is used to configure an 338 authentication domain name of the DoH/DoT server. The format of this 339 option is illustrated in Figure 7. 341 Code Length Authentication domain name 342 +-----+-----+-----+-----+-----+-----+-----+-- 343 |TBA2 | n | s1 | s2 | s3 | s4 | s5 | ... 344 +-----+-----+-----+-----+-----+-----+-----+-- 346 The values s1, s2, s3, etc. represent the domain name labels in the 347 domain name encoding. 349 Figure 7: DHCPv4 DNS Reference Identifier Option 351 The fields of the option shown in Figure 7 are as follows: 353 o Code: OPTION_V4_DNS_RI (TBA2, see Section 9.2). 354 o Length: Includes the length of the "authentication domain name" 355 field in octets. 356 o Authentication domain name: The domain name of the DoH/DoT server. 357 This field is formatted as specified in Section 10 of [RFC8415]. 359 4.3. RA DNS Reference Identifier Option 361 The IPv6 Router Advertisement (RA) DNS Reference Identifier option is 362 used to configure an authentication domain name of the DoH/DoT 363 server. The format of this option is illustrated in Figure 8. 365 0 1 2 3 366 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Type | Length | Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Lifetime | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 : authentication-domain-name : 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 8: RA DNS Reference Identifier Option 379 The fields of the option shown in Figure 8 are as follows: 381 o Type: 8-bit identifier of the DNS Reference Identifier Option as 382 assigned by IANA (TBA3, see Section 9.3). 383 o Length: 8-bit unsigned integer. The length of the option 384 (including the Type and Length fields) is in units of 8 octets. 385 o Reserved: This field is unused. It MUST be initialized to zero by 386 the sender and MUST be ignored by the receiver. 387 o Lifetime: 32-bit unsigned integer. The maximum time in seconds 388 (relative to the time the packet is received) over which the 389 authentication domain name MAY be used as a DNS Reference 390 Identifier. The value of Lifetime SHOULD by default be at least 3 391 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 392 interval as defined in [RFC4861]. A value of all one bits 393 (0xffffffff) represents infinity. A value of zero means that the 394 DNS Reference Identifier MUST no longer be used. 395 o Authentication domain name: The domain name of the DoH/DoT server. 396 This field is formatted as specified in Section 10 of [RFC8415]. 398 5. Locating DoH/DoT Servers 400 A CPE or a host relies upon discovery mechanisms (such as PCO, DHCP, 401 or RA) to retrieve DoH and DoT servers' reachability information. In 402 the various scenarios sketched in Section 3, Do53, DoH, and DoT may 403 terminate on the same IP address (or distinct IP addresses as 404 depicted in Figure 9). Terminating Do53/DoH/DoT on the same or 405 distinct IP addresses is deployment-specific. 407 From an IP reachability standpoint, DoH/DoT servers SHOULD be located 408 by their address literals rather than their names. This avoids 409 adding a dependency on another server to resolve the DoH/DoT name. 410 Concretely, if Do53/DoH/DoT terminate on same IP addresses, existing 411 discovery mechanisms [RFC2132][RFC3646][RFC8106] can be leveraged to 412 learn the IP addresses of DoT/DoH servers while an authentication 413 domain name is supplied by one of the options discussed in Section 4. 415 Legacy Do53 416 client 417 |<===RA======| 418 | {RI,S1,S2} | | 419 | | | 420 |========Do53 Query=======>| 421 | | --,--,- 422 ,+-,--,--. | ,/ S1 \. 423 ,-' `-. | ,-' ISP `-. 424 DoH/DoT --( LAN CPE----( DNS Servers ) 425 capable `-. ,-'| `-. S2 ,-' 426 | `--'--'--' | `--'--'--' 427 |<=========RA==========| | 428 | {RI, S1,S2} | | 429 | | 430 |<===============DoT/DoH===========->| 432 Figure 9: Locating DoH/DoT/Do53 using RFC8106 434 Additional considerations are discussed below for the use of DoH and 435 DoT servers provided by local networks: 437 o If the DNS server's IP address discovered by using DHCP/RA is pre- 438 configured in the OS or Browser as a trusted resolver, the DNS 439 client may auto-upgrade to use the pre-configured DoH/DoT server 440 tied to the discovered DNS server IP address. In such a case the 441 DNS client may perform additional check out of band, such as 442 confirming that the Do53 IP address and the DoH server are owned 443 and operated by the same organisation. 445 o If the DNS reference identity (Section 4) is provided by means of 446 DHCP/RA, the DNS client matches the domain name in the DNS 447 Reference Identifier DHCP/RA option with the 'DNS-ID' identifier 448 type within subjectAltName entry in the server certificate 449 conveyed in the TLS handshake. 451 Additional options are discussed below: 453 o The Wi-Fi Alliance has released the Device Provisioning Protocol 454 (DPP). If DPP is used, the configurator can securely configure 455 devices in the home network with the local DoT/DoH server using 456 DPP. 458 o If a CPE is co-located with security services within the home 459 network, the CPE can use WPA-PSK but with unique pre-shared keys 460 for different endpoints to deal with security issues. In such 461 networks, [I-D.reddy-dprive-bootstrap-dns-server] may be used to 462 securely bootstrap endpoint devices with the authentication domain 463 name (ADN) and DNS server certificate of the local network's DoH/ 464 DoT server. 466 The OS would not know if the WPA pre-shared-key is the same for 467 all clients or a unique pre-shared key is assigned to the host. 468 Hence, the user has to indicate to the system that a unique pre- 469 shared key is assigned to trigger the bootstrapping procedure. 471 If the device joins a home network using a single shared password 472 among all the attached devices, a compromised device can host a 473 fake access point, and the device cannot be securely bootstrapped 474 with the home network's DoH/DoT server. 476 6. DNS-over-TLS and DNS-over-HTTPS Server Discovery Procedure 478 A DNS client discovers the DNS server in the local network supporting 479 DNS-over-TLS and DNS-over-HTTPS protocols by using DNS-based Service 480 Discovery (DNS-SD) [RFC6763]. DNS-SD provides generic solution for 481 discovering services available in a local network. DNS-SD defines a 482 set of naming rules for certain DNS record types that they use for 483 advertising and discovering services. Section 4.1 of [RFC6763] 484 specifies that a service instance name in DNS-SD has the following 485 structure: 487 . . 489 The portion specifies the authentication domain name (ADN). 490 The portion of the DNS service instance name MUST be 491 "_domain-s._tcp" or "_doh._tcp". If no DNS-SD records can be 492 retrieved, the discovery procedure fails for this authentication 493 domain name. However, before retrying a lookup that has failed, a 494 DNS client MUST wait a time period that is appropriate for the 495 encountered error (e.g., NXDOMAIN, timeout, etc.). If no DNS-SD 496 records can be retrieved, the DNS client can try connecting to the 497 pre-configured public DNS servers (if any). 499 If DoH is supported by the DNS server, the DNS client may request the 500 URI resource record type [RFC7553] using the domain name discovered 501 using DNS Reference Identifier DHCP/RA option (Section 4) to use the 502 HTTPS URI scheme (Section 3 of [RFC8484]). 504 7. Hosting DoH/DoT Forwarder in the CPE 506 The following mechanisms can be used to host a DoH/DoT forwarder in 507 the CPE: 509 o If a CPE is co-located with security services (e.g., malware 510 filtering, parental control, MUD), the ISP can assign a unique 511 FQDN (e.g., cpe1.example.com) and a domain-validated public 512 certificate to the DoH/DoT forwarder hosted on the CPE. Automatic 513 Certificate Management Environment (ACME) [RFC8555] can be used to 514 automate certificate management functions such as domain 515 validation procedure, certificate issuance and certificate 516 revocation. 518 o Alternatively, the security service provider can assign a unique 519 FQDN to the managed CPE. The DoT/DoH forwarder will act like a 520 public DoT/DoH server but will only be accessible from within the 521 home network. DNS queries received outside the home network must 522 be discarded by the DoH/DoT forwarder. This behavior adheres to 523 REQ#8 in [RFC6092], and must apply for both IPv4 and IPv6. 525 o If the ISP DoH resolver is pre-configured as a trusted resolver in 526 browsers, the CPE is managed by the ISP, and the ISP has assigned 527 a domain-validated public certificate to the DoH forwarder hosted 528 on the CPE, the ISP can configure the CPE to convey the ISP DoH/ 529 DoT resolver IP addresses and the ISP DoH/DoT ADN in DHCP/RA to 530 internal hosts (Section 4). If the ISP DNS server IP address is 531 pre-configured in the browser as a trusted resolver, the DNS 532 client auto-upgrades to use the DoH/DoT server tied with the 533 discovered DNS server IP address. 535 If the ADN in DHCP/RA is pre-configured in the OS or browser as a 536 trusted resolver, the client auto-upgrades to establish DoH 537 session with the ADN. 539 Once the DoH session is established, the ISP DoH/DoT server uses 540 HTTP redirection (Section 6.4.4 in [RFC7231]) to redirect the DNS 541 client to the DoH forwarder hosted on the CPE. The DNS client 542 uses Do53 to resolve the domain name in the redirected URI and 543 eventually establishes DoH session with the DoH forwarder on the 544 CPE. 546 8. Security Considerations 548 An attacker can get a domain name, domain-validated public 549 certificate from a CA, host a DoT/DoH server and claim the best DNS 550 privacy preservation policy. Also, an attacker within the home 551 network can use the public IP address, get an 'IP address'-validated 552 public certificate from a CA, host a DoT/DoH server and claim the 553 best DNS privacy preservation policy. 555 Because DHCP/RA messages are not encrypted or protected against 556 modification in any way, their content can be spoofed or modified by 557 compromised devices within the home network. An attacker can spoof 558 the DHCP/RA response to provide the attacker's DoT/DoH server. Note 559 that such an attacker can launch other attacks as discussed in 560 Section 22 of [RFC8415]. Furthermore, if the browser or the OS is 561 pre-configured with a list of DNS servers and some of which perform 562 malware filtering while others do not, an attacker can prevent 563 contacting the preferred filtering DNS servers causing a downgrade 564 attack to a non-filtering DNS server, which the attacker can leverage 565 to deliver malware. 567 The primary attacks against the methods described in Section 6 are 568 the ones that would lead to impersonation of a DNS server and 569 spoofing the DNS response to indicate that the DNS server does not 570 support DoH or DoT. To protect against DNS-vectored attacks, secured 571 DNS (DNSSEC) can be used to ensure the validity of the received DNS 572 records received. Impersonation of a DoH/DoT server is prevented by 573 validating the certificate presented by the DoH/DoT server. If DHCP/ 574 RA conveys an ADN, but the DNS-SD lookup indicates that the DNS 575 server does not support DoH/DoT, the DNS client can detect the DNS 576 response is spoofed. 578 The use of DoH/DoT also depends on the user's policies. For example, 579 the user may indicate his/her consent to use (or not) the locally- 580 discovered DoH/DoT server. The DNS client must adhere to these 581 policies. 583 DoH/DoT servers discovered using insecure discovery mechanisms like 584 DHCP/RA are used by a DNS client if the insecurely discovered DoH/DoT 585 server is pre-configured in the OS or the browser. 587 If the insecurely discovered DoH/DoT server is not pre-configured in 588 the OS or browser, its policy information must be cryptographically 589 attested by the ISP (e.g., [I-D.reddy-dprive-dprive-privacy-policy]); 590 user consent is required to use the locally-discovered DoH/DoT 591 server. 593 DoT/DoH sessions with rogue servers spoofing the IP address of a DNS 594 server will fail because the DNS client will fail to authenticate 595 that rogue server based upon PKIX authentication [RFC6125] based upon 596 the authentication domain name in the Reference Identifier Option. 597 DNS clients that ignore authentication failures and accept spoofed 598 certificates will be subject to attacks (e.g., redirect to malicious 599 servers, intercept sensitive data). 601 9. IANA Considerations 603 9.1. DHCPv6 Option 605 IANA is requested to assign the following new DHCPv6 Option Code in 606 the registry maintained in: https://www.iana.org/assignments/dhcpv6- 607 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 609 +-------+------------------+---------+-------------+----------------+ 610 | Value | Description | Client | Singleton | Reference | 611 | | | ORO | Option | | 612 +-------+------------------+---------+-------------+----------------+ 613 | TBA1 | OPTION_V6_DNS_RI | Yes | Yes | [ThisDocument] | 614 +-------+------------------+---------+-------------+----------------+ 616 9.2. DHCP Option 618 IANA is requested to assign the following new DHCP Option Code in the 619 registry maintained in: https://www.iana.org/assignments/bootp-dhcp- 620 parameters/bootp-dhcp-parameters.xhtml#options. 622 +------+------------------+-------+----------------+----------------+ 623 | Tag | Name | Data | Meaning | Reference | 624 | | | Length| | | 625 +------+------------------+-------+----------------+----------------+ 626 | TBA2 | OPTION_V4_DNS_RI | N | DoT/DoH server | [ThisDocument] | 627 | | | | authentication | | 628 | | | | domain name | | 629 +------+------------------+-------+----------------+----------------+ 631 9.3. RA Option 633 IANA is requested to assign the following new IPv6 Neighbor Discovery 634 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 635 registry under the "Internet Control Message Protocol version 6 636 (ICMPv6) Parameters" registry maintained in 637 http://www.iana.org/assignments/icmpv6-parameters/ 638 icmpv6-parameters.xhtml#icmpv6-parameters-5. 640 +------+---------------------------------+----------------+ 641 | Type | Description | Reference | 642 +------+---------------------------------+----------------+ 643 | TBA3 | DNS Reference Identifier Option | [ThisDocument] | 644 +------+---------------------------------+----------------+ 646 9.4. Service Name 648 IANA is requested to allocate the following service name from the 649 registry available at: https://www.iana.org/assignments/service- 650 names-port-numbers/service-names-port-numbers.xhtml. 652 Service Name: doh 653 Port Number: N/A 654 Transport Protocol(s): TCP 655 Description: DNS-over-HTTPS 656 Assignee: IESG 657 Contact: IETF Chair 658 Reference: [ThisDocument] 660 10. Acknowledgements 662 Many thanks to Christian Jacquenet for the review. 664 11. References 666 11.1. Normative References 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, 670 DOI 10.17487/RFC2119, March 1997, 671 . 673 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 674 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 675 . 677 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 678 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 679 DOI 10.17487/RFC4861, September 2007, 680 . 682 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 683 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 684 . 686 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 687 and P. Hoffman, "Specification for DNS over Transport 688 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 689 2016, . 691 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 692 "IPv6 Router Advertisement Options for DNS Configuration", 693 RFC 8106, DOI 10.17487/RFC8106, March 2017, 694 . 696 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 697 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 698 May 2017, . 700 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 701 for DNS over TLS and DNS over DTLS", RFC 8310, 702 DOI 10.17487/RFC8310, March 2018, 703 . 705 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 706 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 707 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 708 RFC 8415, DOI 10.17487/RFC8415, November 2018, 709 . 711 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 712 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 713 . 715 11.2. Informative References 717 [I-D.ietf-dnsop-terminology-ter] 718 Hoffman, P., "Terminology for DNS Transports and 719 Location", draft-ietf-dnsop-terminology-ter-01 (work in 720 progress), February 2020. 722 [I-D.ietf-v6ops-rfc7084-bis] 723 Palet, J., "Basic Requirements for IPv6 Customer Edge 724 Routers", draft-ietf-v6ops-rfc7084-bis-04 (work in 725 progress), June 2017. 727 [I-D.reddy-dprive-bootstrap-dns-server] 728 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 729 "A Bootstrapping Procedure to Discover and Authenticate 730 DNS-over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 731 dprive-bootstrap-dns-server-07 (work in progress), 732 February 2020. 734 [I-D.reddy-dprive-dprive-privacy-policy] 735 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 736 "DNS Server Privacy Statement and Filtering Policy with 737 Assertion Token", draft-reddy-dprive-dprive-privacy- 738 policy-03 (work in progress), March 2020. 740 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 741 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 742 DOI 10.17487/RFC3646, December 2003, 743 . 745 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 746 Capabilities in Customer Premises Equipment (CPE) for 747 Providing Residential IPv6 Internet Service", RFC 6092, 748 DOI 10.17487/RFC6092, January 2011, 749 . 751 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 752 Verification of Domain-Based Application Service Identity 753 within Internet Public Key Infrastructure Using X.509 754 (PKIX) Certificates in the Context of Transport Layer 755 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 756 2011, . 758 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 759 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 760 DOI 10.17487/RFC7231, June 2014, 761 . 763 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 764 Identifier (URI) DNS Resource Record", RFC 7553, 765 DOI 10.17487/RFC7553, June 2015, 766 . 768 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 769 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 770 January 2019, . 772 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 773 Description Specification", RFC 8520, 774 DOI 10.17487/RFC8520, March 2019, 775 . 777 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 778 Kasten, "Automatic Certificate Management Environment 779 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 780 . 782 [TR-069] The Broadband Forum, "CPE WAN Management Protocol", March 783 2018, . 786 [TS.24008] 787 3GPP, "Mobile radio interface Layer 3 specification; Core 788 network protocols; Stage 3 (Release 16)", December 2019, 789 . 791 Authors' Addresses 793 Mohamed Boucadair 794 Orange 795 Rennes 35000 796 France 798 Email: mohamed.boucadair@orange.com 800 Tirumaleswar Reddy 801 McAfee, Inc. 802 Embassy Golf Link Business Park 803 Bangalore, Karnataka 560071 804 India 806 Email: TirumaleswarReddy_Konda@McAfee.com 808 Dan Wing 809 Citrix Systems, Inc. 810 USA 812 Email: dwing-ietf@fuggles.com 814 Neil Cook 815 Open-Xchange 816 UK 818 Email: neil.cook@noware.co.uk