idnits 2.17.1 draft-btw-add-home-10.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1264 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 1126, but not defined == Unused Reference: 'DPP' is defined on line 1217, but no explicit reference was found in the text == Unused Reference: 'I-D.box-add-requirements' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 1305, but no explicit reference was found in the text == Unused Reference: 'RFC7969' is defined on line 1326, but no explicit reference was found in the text == Unused Reference: 'RFC8305' is defined on line 1335, but no explicit reference was found in the text == Unused Reference: 'RFC8489' is defined on line 1344, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-box-add-requirements-00 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 3 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: May 6, 2021 McAfee 6 D. Wing 7 Citrix 8 N. Cook 9 Open-Xchange 10 November 2, 2020 12 DHCP and Router Advertisement Options for Encrypted DNS Discovery within 13 Home Networks 14 draft-btw-add-home-10 16 Abstract 18 The document specifies new DHCP and Router Advertisement Options to 19 discover encrypted DNS servers (e.g., DoH, DoT, DoQ). Particularly, 20 it allows to learn an Authentication Domain Name together with a list 21 of IP addresses and optionally a port number to reach such encrypted 22 DNS servers. 24 This document focuses on encrypted DNS deployment within home 25 networks. 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 May 6, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Sample Target Deployment Scenarios . . . . . . . . . . . . . 5 64 3.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1.1. Direct DNS . . . . . . . . . . . . . . . . . . . . . 6 66 3.1.2. Proxied DNS . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.1. ISP-facing Unmanaged CPEs . . . . . . . . . . . . . . 8 69 3.2.2. Internal Unmanaged CPEs . . . . . . . . . . . . . . . 8 70 4. Encrypted DNS Discovery Options . . . . . . . . . . . . . . . 9 71 4.1. DHCPv6 Encrypted DNS Options . . . . . . . . . . . . . . 11 72 4.2. DHCPv4 Encrypted DNS Option . . . . . . . . . . . . . . . 14 73 4.3. IPv6 RA Encrypted DNS Options . . . . . . . . . . . . . . 15 74 5. DoH URI Templates . . . . . . . . . . . . . . . . . . . . . . 18 75 6. Make Use of Discovered Encrypted DNS Server . . . . . . . . . 19 76 7. Hosting Encrypted DNS Forwarder in the CPE . . . . . . . . . 20 77 7.1. Managed CPEs . . . . . . . . . . . . . . . . . . . . . . 20 78 7.1.1. DNS Forwarders . . . . . . . . . . . . . . . . . . . 20 79 7.1.2. ACME . . . . . . . . . . . . . . . . . . . . . . . . 20 80 7.1.3. Auto-Upgrade Based on Domains and their Subdomains . 20 81 7.2. Unmanaged CPEs . . . . . . . . . . . . . . . . . . . . . 21 82 8. Legacy CPEs . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 9.1. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 23 85 9.2. Deletion Attacks . . . . . . . . . . . . . . . . . . . . 24 86 9.3. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 24 87 9.4. Wireless Security - Authentication Attacks . . . . . . . 24 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 89 10.1. DHCPv6 Options . . . . . . . . . . . . . . . . . . . . . 25 90 10.2. DHCP Option . . . . . . . . . . . . . . . . . . . . . . 25 91 10.3. RA Options . . . . . . . . . . . . . . . . . . . . . . . 25 92 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 93 12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 26 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 96 13.2. Informative References . . . . . . . . . . . . . . . . . 27 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 100 1. Introduction 102 Internet Service Providers (ISPs) traditionally provide DNS resolvers 103 to their customers. To that aim, ISPs deploy the following 104 mechanisms to advertise a list of DNS Recursive DNS server(s) to 105 their customers: 107 o Protocol Configuration Options in cellular networks [TS.24008]. 109 o DHCPv4 [RFC2132] (Domain Name Server Option) or DHCPv6 110 [RFC8415][RFC3646] (OPTION_DNS_SERVERS). 112 o IPv6 Router Advertisement [RFC4861][RFC8106] (Type 25 (Recursive 113 DNS Server Option)). 115 The communication between a customer's device (possibly via Customer 116 Premises Equipment (CPE)) and an ISP-supplied DNS resolver takes 117 place by using cleartext DNS messages (Do53) 118 [I-D.ietf-dnsop-terminology-ter]. Some examples are depicted in 119 Figure 1. In the case of cellular networks, the cellular network 120 will provide connectivity directly to a host (e.g., smartphone, 121 tablet) or via a CPE. Do53 mechanisms used within the Local Area 122 Network (LAN) are similar in both fixed and cellular CPE-based 123 broadband service offerings. 125 (a) Fixed Networks 126 ,--,--,--. 127 +-+ LAN +---+ ,-' `-. 128 |H+--------------+CPE+---+ ISP ) 129 +-+ +---+ `-. ,-' 130 | `--'--'--' 131 | | 132 |<=============Do53============>| 133 | | 135 (b) Cellular Networks 137 | | 138 |<=============Do53============>| 139 | | 140 | ,--,--,-. 141 +-+ LAN +---+ ,-' . 142 |H+--------------+CPE+---+ \ 143 +-+ +---+ ,' ISP `-. 144 ( ) 145 +-----+-. ,-' 146 +-+ | `--'--'--' 147 |H+----------------+ | 148 +-+ | 149 | | 150 |<=============Do53============>| 151 | | 153 Legend: 154 * H: refers to a host. 156 Figure 1: Sample Legacy Deployments 158 This document focuses on the support of encrypted DNS such as DNS- 159 over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS- 160 over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic] in local networks. In 161 particular, the document describes how a local encrypted DNS server 162 can be discovered and used by connected hosts by means of DHCP, 163 DHCPv6, and RA options (Section 4). These options are designed to 164 convey the following information: the DNS Authentication Domain Name 165 (ADN) [RFC8310], a list of IP addresses, and optionally a port 166 number. 168 Some ISPs rely upon external resolvers (e.g., outsourced service or 169 public resolvers); these ISPs provide their customers with the IP 170 addresses of these resolvers. These addresses are typically 171 configured on CPEs using the same mechanisms listed above. Likewise, 172 users can modify the default DNS configuration of their CPEs (e.g., 173 supplied by their ISP) to configure their favorite DNS servers. This 174 document permits such deployments. 176 Both managed and unmanaged CPEs are discussed in the document 177 (Section 3). Also, considerations related to hosting a DNS forwarder 178 in the CPE are described (Section 7). 180 Hosts and/or CPEs may be connected to multiple networks; each 181 providing their own DNS configuration using the discovery mechanisms 182 specified in this document. Nevertheless, it is out of the scope of 183 this specification to discuss DNS selection of multi-interface 184 devices. The reader may refer to [RFC6731] for a discussion of 185 issues and an example of DNS server selection for multi-interfaced 186 devices. 188 2. Terminology 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in BCP 193 14 [RFC2119][RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 This document makes use of the terms defined in [RFC8499] and 197 [I-D.ietf-dnsop-terminology-ter]. 199 Do53 refers to unencrypted DNS. 201 'Encrypted DNS' refers to a scheme where DNS exchanges are 202 transported over an encrypted channel. Examples of encrypted DNS are 203 DNS-over-TLS (DoT) [RFC7858], DNS-over-HTTPS (DoH) [RFC8484], or DNS- 204 over-QUIC (DoQ) [I-D.ietf-dprive-dnsoquic]. 206 "Managed CPE" refers to a CPE that is managed by the ISP. 208 "Unmanaged CPE" refers to a CPE that is not managed by the ISP. 210 DHCP refers to both DHCPv4 and DHCPv6. 212 3. Sample Target Deployment Scenarios 214 3.1. Managed CPEs 216 This section focuses on CPEs that are managed by ISPs. 218 3.1.1. Direct DNS 220 ISPs have developed an expertise in managing service-specific 221 configuration information (e.g., CPE WAN Management Protocol 222 [TR-069]). For example, these tools may be used to provision the DNS 223 server's ADN to managed CPEs if an encrypted DNS is supported by a 224 local network similar to what is depicted in Figure 2. 226 For example, DoH-capable (or DoT) clients establish the DoH (or DoT) 227 session with the discovered DoH (or DoT) server. 229 The DNS client discovers whether the DNS server in the local network 230 supports DoH/DoT/DoQ by using a dedicated field in the discovery 231 message: Encrypted DNS Types (Section 4). 233 (a) Fixed Networks 235 ,--,--,--. 236 +-+ LAN +---+ ,-' `-. 237 |H+--------------+CPE+---+ ISP ) 238 +-+ +---+ `-. ,-' 239 | `--'--'--' 240 | | 241 |<========Encrypted DNS========>| 242 | | 244 (b) Cellular Networks 246 | | 247 |<========Encrypted DNS========>| 248 | | 249 | ,--,--,-. 250 +-+ LAN +---+ ,-' . 251 |H+--------------+CPE+---+ \ 252 +-+ +---+ ,' ISP `-. 253 ( ) 254 +-----+-. ,-' 255 +-+ | `--'--'--' 256 |H+----------------+ | 257 +-+ | 258 | | 259 |<========Encrypted DNS========>| 260 | | 262 Figure 2: Encrypted DNS in the WAN 264 Figure 2 shows the scenario where the CPE relays the list of 265 encrypted DNS servers it learns for the network by using mechanisms 266 like DHCP or a specific Router Advertisement message. In such 267 context, direct encrypted DNS sessions will be established between a 268 host serviced by a CPE and an ISP-supplied encrypted DNS server (see 269 the example depicted in Figure 3 for a DoH/DoT-capable host). 271 ,--,--,--. ,--,--,--. 272 ,-' `-. ,-' ISP `-. 273 Host---( LAN CPE----( DNS Server ) 274 | `-. ,-' `-. ,-' 275 | `--'--'--' `--'--'--' 276 | | 277 |<=========Encrypted DNS===========>| 279 Figure 3: Direct Encrypted DNS Sessions 281 3.1.2. Proxied DNS 283 Figure 4 shows a deployment where the CPE embeds a caching DNS 284 forwarder. The CPE advertises itself as the default DNS server to 285 the hosts it serves. The CPE relies upon DHCP or RA to advertise 286 itself to internal hosts as the default DoT/DoH/Do53 server. When 287 receiving a DNS request it cannot handle locally, the CPE forwards 288 the request to an upstream DoH/DoT/Do53 resolver. Such deployment is 289 required for IPv4 service continuity purposes (e.g., Section 5.4.1 of 290 [I-D.ietf-v6ops-rfc7084-bis]) or for supporting advanced services 291 within the home (e.g., malware filtering, parental control, 292 Manufacturer Usage Description (MUD) [RFC8520] to only allow intended 293 communications to and from an IoT device). When the CPE behaves as a 294 DNS forwarder, DNS communications can be decomposed into two legs: 296 o The leg between an internal host and the CPE. 298 o The leg between the CPE and an upstream DNS resolver. 300 An ISP that offers encrypted DNS to its customers may enable 301 encrypted DNS in one or both legs as shown in Figure 4. Additional 302 considerations related to this deployment are discussed in Section 7. 304 (a) 305 ,--,--,--. ,--,--,--. 306 ,-' `-. ,-' ISP `-. 307 Host---( LAN CPE----( DNS Server ) 308 | `-. ,-'| `-. ,-' 309 | `--'--'--' | `--'--'--' 310 | | | 311 |<=====Encrypted=====>|<=Encrypted=>| 312 | DNS | DNS | 314 (b) 315 ,--,--,--. ,--,--,--. 316 Legacy ,-' `-. ,-' ISP `-. 317 Host---( LAN CPE----( DNS Server ) 318 | `-. ,-'| `-. ,-' 319 | `--'--'--' | `--'--'--' 320 | | | 321 |<=======Do53========>|<=Encrypted=>| 322 | | DNS | 324 Figure 4: Proxied Encrypted DNS Sessions 326 3.2. Unmanaged CPEs 328 3.2.1. ISP-facing Unmanaged CPEs 330 Customers may decide to deploy unmanaged CPEs (assuming the CPE is 331 compliant with the network access technical specification that is 332 usually published by ISPs). Upon attachment to the network, an 333 unmanaged CPE receives from the network its service configuration 334 (including the DNS information) by means of, e.g., DHCP. That DNS 335 information is shared within the LAN following the same mechanisms as 336 those discussed in Section 3.1. A host can thus establish DoH/DoT 337 session with a DoH/DoT server similar to what is depicted in Figure 3 338 or Figure 4. 340 3.2.2. Internal Unmanaged CPEs 342 Customers may also decide to deploy internal home routers (called 343 hereafter, Internal CPEs) for a variety of reasons that are not 344 detailed here. Absent any explicit configuration on the internal CPE 345 to override the DNS configuration it receives from the ISP-supplied 346 CPE, an Internal CPE relays the DNS information it receives via DHCP/ 347 RA from the ISP-supplied CPE to connected hosts. Encrypted DNS 348 sessions can be established by a host with the DNS servers of the ISP 349 (see Figure 5). 351 ,--,--,--. ,--,--,--. 352 ,-' Internal ,-' ISP `-. 353 Host--( Network#A CPE----CPE---( DNS Server ) 354 | `-. ,-' `-. ,-' 355 | `--'--'--' `--'--'--' 356 | | 357 |<==============Encrypted DNS=============>| 359 Figure 5: Direct Encrypted DNS Sessions with the ISP DNS Resolver 360 (Internal CPE) 362 Similar to managed CPEs, a user may modify the default DNS 363 configuration of an unmanaged CPE to use his/her favorite DNS servers 364 instead. Encrypted DNS sessions can be established directly between 365 a host and a 3rd Party DNS server (see Figure 6). 367 ,--,--,--. ,--, 368 ,' Internal ,-' '- 3rd Party 369 Host--( Network#A CPE----CPE---( ISP )--- DNS Server 370 | `. ,-' `-. -' | 371 | `-'--'--' `--' | 372 | | 373 |<=================Encrypted DNS==================>| 375 Figure 6: Direct Encrypted DNS Sessions with a Third Party DNS 376 Resolver 378 Section 7.2 discusses considerations related to hosting a forwarder 379 in the Internal CPE. 381 4. Encrypted DNS Discovery Options 383 This section describes how a DNS client can discover a local 384 encrypted DNS server(s) using DHCP (Sections 4.1 and 4.2) and 385 Neighbor Discovery protocol (Section 4.3). 387 As reported in Section 1.7.2 of [RFC6125]: 389 "few certification authorities issue server certificates based on 390 IP addresses, but preliminary evidence indicates that such 391 certificates are a very small percentage (less than 1%) of issued 392 certificates". 394 In order to allow for PKIX-based authentication between a DNS client 395 and an encrypted DNS server while accommodating the current best 396 practices for issuing certificates, this document allows for 397 configuring an authentication domain name to be presented as a 398 reference identifier for DNS authentication purposes. 400 To avoid adding a dependency on another server to resolve the ADN, 401 the options return a list of IP addresses to locate the encrypted DNS 402 server. In the various scenarios sketched in Section 3, encrypted 403 DNS servers may terminate on the same IP address or distinct IP 404 addresses. Terminating encrypted DNS servers on the same or distinct 405 IP addresses is deployment specific. It is RECOMMENDED to return 406 both the ADN and a list of IP addresses to a requesting host. 408 Note that in order to optimize the size of discovery messages when 409 all servers terminate on the same IP address, a host may rely upon 410 the discovery mechanisms specified in [RFC2132][RFC3646][RFC8106] to 411 retrieve a list of IP addresses to reach their DNS servers. 412 Nevertheless, this approach requires a client that supports more than 413 one encrypted DNS to probe that list of IP addresses. To avoid such 414 probing, the options defined in the following subsections associate 415 an IP address with an encrypted DNS type. No probing is required in 416 such design. 418 A list of IP addresses to reach an encrypted DNS server can be 419 returned in the option to accommodate current deployments relying 420 upon primary and backup servers. Whether one IP address or more are 421 returned in an option is deployment specific. For example, a home 422 router embedding a forwarder has to include one single IP address 423 pointing to one of its LAN-facing interfaces. This address can be a 424 private IPv4 address, a link-local address, a Unique Local IPv6 425 unicast Address (ULA), or a Global Unicast Address (GUA). 427 If more than one IP address are to be returned in an Encrypted DNS 428 server option, these addresses are ordered in the preference for use 429 by the client. 431 Because DoT and DoQ may make use of customized port numbers instead 432 of default ones, the Encrypted DNS server options are designed to 433 return alternate port numbers. 435 The DNS client establishes an encrypted DNS session with the 436 discovered DNS IP address(es) and port number, and uses the mechanism 437 discussed in Section 8 of [RFC8310] to authenticate the DNS server 438 certificate using the authentication domain name conveyed in the 439 encrypted DNS options. 441 If the encrypted DNS is discovered by a host using both RA and DHCP, 442 the rules discussed in Section 5.3.1 of [RFC8106] MUST be followed. 444 4.1. DHCPv6 Encrypted DNS Options 446 The DHCPv6 Encrypted DNS ADN option is used to configure an 447 authentication domain name of the encrypted DNS server. The format 448 of this option is shown in Figure 7. 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | OPTION_V6_ENC_ADN | Option-length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Enc DNS Flags | | 455 +---------------+ + 456 | | 457 ~ DNS Authentication Domain Name ~ 458 | | 459 +---------------------------------------------------------------+ 461 Figure 7: DHCPv6 Encrypted DNS ADN Option 463 The fields of the option shown in Figure 7 are as follows: 465 o Option-code: OPTION_V6_ENC_ADN (TBA1, see Section 10.1) 466 o Option-length: Length of the enclosed data in octets. 467 o Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 468 encrypted DNS server conveyed in this attribute. The format of 469 this 8-bit field is shown in Figure 8. 471 +-+-+-+-+-+-+-+-+ 472 |U|U|U|U|U|Q|H|T| 473 +-+-+-+-+-+-+-+-+ 475 Figure 8: Encrypted DNS Types 477 T: If set, this bit indicates that the server supports DoT 478 [RFC7858]. 479 H: If set, this bit indicates that the server supports DoH 480 [RFC8484]. 481 Q: If set, this bit indicates that the server supports DoQ 482 [I-D.ietf-dprive-dnsoquic]. 483 U: Unassigned bits. These bits MUST be unset by the sender. 484 Associating a meaning with an unassigned bit can be done via 485 Standards Action [RFC8126]. 487 In a request, these bits are assigned to indicate the requested 488 encrypted DNS server type(s) by the client. In a response, these 489 bits are set as a function of the encrypted DNS supported by the 490 server and the requested encrypted DNS server type(s). 492 To keep the packet small, if more than one encrypted DNS type 493 (e.g., both DoH and DoT) are to be returned to a requesting client 494 and the same ADN is used for these types, the corresponding bits 495 must be set in the 'Encrypted DNS Types' field of the same option 496 instance in a response. For example, if the client requested DoH 497 and DoT and the server supports both with the same ADN, then both 498 T and H bits must be set. 499 o Authentication Domain Name: A fully qualified domain name of the 500 encrypted DNS server. This field is formatted as specified in 501 Section 10 of [RFC8415]. 503 An example of the Authentication Domain Name encoding is shown in 504 Figure 9. This example conveys the FQDN "doh1.example.com.". 506 +------+------+------+------+------+------+------+------+------+ 507 | 0x04 | d | o | h | 1 | 0x07 | e | x | a | 508 +------+------+------+------+------+------+------+------+------+ 509 | m | p | l | e | 0x03 | c | o | m | 0x00 | 510 +------+------+------+------+------+------+------+------+------+ 512 Figure 9: An example of the authentication-domain-name Encoding 514 The DHCPv6 Encrypted DNS Address option is used to configure a list 515 of IP addresses and a port number of the encrypted DNS server. The 516 format of this option is shown in Figure 10. 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | OPTION_V6_ENC_ADD | Option-length | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Enc DNS Flags | Unassigned | Port Number | 523 +---------------+---------------+-------------------------------+ 524 | | 525 | IPv6 Address | 526 | | 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | | 530 | IPv6 Address | 531 | | 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | ... | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 10: DHCPv6 Encrypted DNS Address Option 539 The fields of the option shown in Figure 10 are as follows: 541 o Option-code: OPTION_V6_ENC_ADD (TBA2, see Section 10.1) 543 o Option-length: Length of the enclosed data in octets. 545 o Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 546 encrypted DNS server conveyed in this attribute. The format of 547 this 8-bit field is shown in Figure 8. In a request, these bits 548 are set to indicate the requested encrypted DNS server type(s) by 549 the client. In a response, these bits are set as a function of 550 the encrypted DNS supported by the server and the requested 551 encrypted DNS server type(s). 553 o Unassigned: These bits MUST be unset by the sender. Associating a 554 meaning with an unassigned bit can be done via Standards Action 555 [RFC8126]. 557 o Port Number: If not null, Indicates the port number to be used for 558 the encrypted DNS. If this field is to zero, this indicates that 559 default port numbers should be used. As a reminder, the default 560 port number is 853 for DoT and 443 for DoH. 562 o IPv6 Address(es): Indicates one or more IPv6 addresses to reach 563 the encrypted DNS server. 565 Multiple instances of OPTION_V6_ENC_ADN (or OPTION_V6_ENC_ADD) may be 566 returned to a DHCPv6 client; each pointing to a distinct encrypted 567 DNS server type. 569 To discover an encrypted DNS server, the DHCPv6 client includes 570 OPTION_V6_ENC_ADN and OPTION_V6_ENC_ADD in an Option Request Option 571 (ORO), as in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 572 21.7 of [RFC8415]. The DHCPv6 client sets the Encrypted DNS Types 573 field to the requested encrypted DNS server type(s). 575 If the DHCPv6 client requested more than one encrypted DNS server 576 type, the DHCP client MUST be prepared to receive multiple 577 OPTION_V6_ENC_ADN (or OPTION_V6_ENC_ADD) options; each option is to 578 be treated as a separate encrypted DNS server. 580 If more than one encrypted DNS server types is supported on the same 581 IP address and default port numbers are used, one instance of 582 OPTION_V6_ENC_ADD option with the appropriate bits set in "Encr DNS 583 Types" field should be returned by the DHCP server. 585 4.2. DHCPv4 Encrypted DNS Option 587 The DHCPv4 Encrypted DNS option is used to configure an 588 authentication domain name, a list of IP addresses, and a port number 589 of the encrypted DNS server. The format of this option is 590 illustrated in Figure 11. 592 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | TBA3 | Length | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Enc DNS Flags | Num Addresses | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Port Number | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | 601 ~ IPv4 Address(es) ~ 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | | 605 ~ Authentication Domain Name ~ 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Figure 11: DHCPv4 Encrypted DNS Option 611 The fields of the option shown in Figure 11 are as follows: 613 o Code: OPTION_V4_ENC_DNS (TBA3, see Section 10.2). 614 o Length: Length of the enclosed data in octets. 615 o Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 616 encrypted DNS server conveyed in this attribute. The format of 617 this field is shown in Figure 8. 618 o Num Addresses: Indicates the number of included IPv4 addresses. 619 o Port Number: If not null, it indicates the port number to be used 620 for the encrypted DNS. A null value indicates that default port 621 numbers are used. As a reminder, the default port number is 853 622 for DoT and 443 for DoH. 623 o IPv4 Addresses: Indicates one or more IPv4 addresses to reach the 624 encrypted DNS server. The format of this field is shown in 625 Figure 12. 627 0 8 16 24 32 40 48 628 +-----+-----+-----+-----+-----+-----+-- 629 | a1 | a2 | a3 | a4 | a1 | a2 | ... 630 +-----+-----+-----+-----+-----+-----+-- 631 IPv4 Address 1 IPv4 Address 2 ... 633 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 635 Figure 12: Format of the IPv4 Addresses Field 636 o Authentication Domain Name: The domain name of the encrypted DNS 637 server. This field is formatted as specified in Section 10 of 638 [RFC8415]. The format of this field is shown in Figure 13. 640 +-----+-----+-----+-----+-----+-- 641 | s1 | s2 | s3 | s4 | s5 | ... 642 +-----+-----+-----+-----+-----+-- 643 Authentication Domain Name 645 The values s1, s2, s3, etc. represent the domain name labels in the 646 domain name encoding. 648 Figure 13: Format of the Authentication Domain Name Field 650 OPTION_V4_ENC_DNS is a concatenation-requiring option. As such, the 651 mechanism specified in [RFC3396] MUST be used if OPTION_V4_ENC_DNS 652 exceeds the maximum DHCPv4 option size of 255 octets. 654 To discover an encrypted DNS server, the DHCPv4 client requests the 655 Encrypted DNS server by including OPTION_V4_ENC_DNS in a Parameter 656 Request List option [RFC2132]. The DHCPv4 client sets the Encrypted 657 DNS Types field to the requested encrypted DNS server. 659 If the DHCPv4 client requested more than one encrypted DNS server 660 type, the DHCPv4 client MUST be prepared to receive multiple DHCP 661 OPTION_V4_ENC_DNS options; each option is to be treated as a separate 662 encrypted DNS server. 664 4.3. IPv6 RA Encrypted DNS Options 666 This section defines two Neighbor Discovery [RFC4861]: IPv6 Router 667 Advertisement (RA) Encrypted DNS ADN option and IPv6 RA Encrypted DNS 668 Address option. 670 The IPv6 RA Encrypted DNS ADN option is used to configure an 671 authentication domain name of the encrypted DNS server. The format 672 of this option is illustrated in Figure 14. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | TBA3 | Length | Enc DNS Flags | Unassigned | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Lifetime | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 : Authentication Domain Name : 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 14: RA Encrypted DNS ADN Option 688 The fields of the option shown in Figure 14 are as follows: 690 o Type: 8-bit identifier of the Encrypted DNS Option as assigned by 691 IANA (TBA3, see Section 10.3). 692 o Length: 8-bit unsigned integer. The length of the option 693 (including the Type and Length fields) is in units of 8 octets. 694 o Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 695 encrypted DNS server conveyed in this attribute. The format of 696 this field is shown in Figure 8. 697 o Unassigned: This field is unused. It MUST be initialized to zero 698 by the sender and MUST be ignored by the receiver. 699 o Lifetime: 32-bit unsigned integer. The maximum time in seconds 700 (relative to the time the packet is received) over which the 701 discovered Authentication Domain Name is valid. 703 The value of Lifetime SHOULD by default be at least 3 * 704 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 705 interval as defined in [RFC4861]. 707 A value of all one bits (0xffffffff) represents infinity. 709 A value of zero means that this Authentication Domain Name MUST no 710 longer be used. 711 o Authentication Domain Name: The domain name of the encrypted DNS 712 server. This field is formatted as specified in Section 10 of 713 [RFC8415]. 715 This field MUST be padded with zeros so that its size is a 716 multiple of 8 octets. 718 The IPv6 RA Encrypted DNS Address option is used to configure a port 719 number and a list of IPv6 addresses of the encrypted DNS server. The 720 format of this option is illustrated in Figure 15. All of the 721 addresses share the same Lifetime value. Simialr to [RFC8106], if it 722 is desirable to have different Lifetime values per IP address, 723 multiple Encrypted DNS Address options may be used. 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | TBA5 | Length | Unassigned | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Lifetime | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Enc DNS Flags | Unassigned | Port Number | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | | 735 : IPv6 Address(es) : 736 | | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 Figure 15: RA Encrypted DNS Address Option 741 The fields of the RA Encrypted DNS Address option shown in Figure 15 742 are as follows: 744 o Type: 8-bit identifier of the Encrypted DNS Address Option as 745 assigned by IANA (TBA5, see Section 10.3). 747 o Length: 8-bit unsigned integer. The length of the option 748 (including the Type and Length fields) is in units of 8 octets. 750 o Unassigned: This field is unused. It MUST be initialized to zero 751 by the sender and MUST be ignored by the receiver. 753 o Lifetime: 32-bit unsigned integer. The maximum time in seconds 754 (relative to the time the packet is received) over which the 755 discovered encrypted DNS IPv6 addresses are valid. 757 The value of Lifetime SHOULD by default be at least 3 * 758 MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA 759 interval as defined in [RFC4861]. 761 A value of all one bits (0xffffffff) represents infinity. 763 A value of zero means that these IPv6 addresses MUST no longer be 764 used. 766 o Enc DNS Flags (Encrypted DNS Flags): Indicates the type(s) of the 767 encrypted DNS server conveyed in this attribute. The format of 768 this field is shown in Figure 8. 770 o Port Number: If not null, it indicates the port number to be used 771 for the encrypted DNS. A null value indicates that default port 772 numbers must be used. As a reminder, the default port number is 773 853 for DoT and 443 for DoH. 775 o IPv6 Address(es) : One or more IPv6 addresses of the encrypted DNS 776 server. 778 5. DoH URI Templates 780 DoH servers may support more than one URI Template [RFC8484]. Also, 781 if the resolver hosts several DoH services (e.g., no-filtering, 782 blocking adult content, blocking malware), these services can be 783 discovered as templates. The following discusses a mechanism for a 784 DoH client to retrieve the list of supported templates by a DoH 785 server. 787 Upon discovery of a DoH resolver (Section 4), the DoH client may 788 contact that DoH server to retrieve the list of supported DoH 789 services using the well-known URI. DoH clients repeats that request 790 regularly to retrieve an updated list of supported DoH services. 792 Let's suppose that a host has discovered an encrypted DNS server that 793 is DoH-capable. The host has also discovered the following 794 information: 796 o ADN: doh.example.com 798 o Locator: 2001:db8:1::1 800 The client requests "https://doh.example.com/.well-known/resinfo" to 801 retrieve the list of the URI Templates associated with this 802 discovered server. 804 Alternatively, dedicated DHCP/RA options may be defined to convey an 805 URI template. An example of such option is depicted in Figure 16. 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | OPTION_V6_DOH_TEMPLATE | Option-length | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | | 813 ~ uri-template-data ~ 814 | . . . | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Each instance of the uri-template-data is formatted as follows: 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 820 | uri-template-len | URI Template | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 823 Figure 16: Example of a DHCPv6 URI Template Option 825 Note: More feedback form the WG is needed to decide which approach 826 to follow. 828 How a DoH client makes use of the configured DoH services is out of 829 scope of this document. 831 6. Make Use of Discovered Encrypted DNS Server 833 Even if the use of a discovered encrypted DNS server is beyond the 834 discovery process and falls under encrypted server selection, the 835 following discusses typical conditions under which discovered 836 encrypted DNS server can be used. 838 o If the DNS server's IP address discovered by using DHCP/RA is 839 preconfigured in the OS or Browser as a verified resolver (e.g., 840 part of an auto-upgrade program such as [Auto-upgrade]), the DNS 841 client auto-upgrades to use the preconfigured encrypted DNS server 842 tied to the discovered DNS server IP address. In such a case the 843 DNS client will perform additional checks out of band, such as 844 confirming that the Do53 IP address and the encrypted DNS server 845 are owned and operated by the same organisation. 847 o Similarly, if the ADN conveyed in DHCP/RA (Section 4) is 848 preconfigured in the OS or browser as a verified resolver, the DNS 849 client auto-upgrades to establish an encrypted a DoH/DoT/DoQ 850 session with the ADN. 852 In such case, the DNS client matches the domain name in the 853 Encrypted DNS DHCP/RA option with the 'DNS-ID' identifier type 854 within subjectAltName entry in the server certificate conveyed in 855 the TLS handshake. 857 7. Hosting Encrypted DNS Forwarder in the CPE 859 7.1. Managed CPEs 861 The following mechanisms can be used to host an encrypted DNS 862 forwarder in a managed CPE (Section 3.1). 864 7.1.1. DNS Forwarders 866 The managed CPE should support a configuration parameter to instruct 867 the CPE whether it has to relay the encrypted DNS server received 868 from the ISP's network or has to announce itself as a forwarder 869 within the local network. The default behavior of the CPE is to 870 supply the encrypted DNS server received from the ISP's network. 872 7.1.2. ACME 874 The ISP can assign a unique FQDN (e.g., cpe1.example.com) and a 875 domain-validated public certificate to the encrypted DNS forwarder 876 hosted on the CPE. Automatic Certificate Management Environment 877 (ACME) [RFC8555] can be used by the ISP to automate certificate 878 management functions such as domain validation procedure, certificate 879 issuance and certificate revocation. 881 7.1.3. Auto-Upgrade Based on Domains and their Subdomains 883 If the ADN conveyed in DHCP/RA (Section 4) is pre-configured in 884 popular OSes or browsers as a verified resolver and the auto-upgrade 885 (Section 6) is allowed for both the pre-configured ADN and its sub- 886 domains, the encrypted DNS client will learn the local encrypted DNS 887 forwarder using DHCP/RA and auto-upgrade because the pre-configured 888 ADN would match the subjectAltName value in the server certificate. 889 For example, if the pre-configured ADN is "*.example.com" and the 890 discovered encrypted DNS forwarder is "cpe1.example.com", auto- 891 upgrade will take place. 893 In this case, the CPE can communicate the ADN of the local DoH 894 forwarder (Section 7.1.2) to internal hosts using DHCP/RA 895 (Section 4). 897 Let's suppose that "*.example.net" is pre-configured as a verified 898 resolved in the browser or OS. If the encrypted DNS client discovers 899 a local forwarder "cpe1-internal.example.net", the encrypted DNS 900 client will auto-upgrade because the pre-configured ADN would match 901 subjectAltName value "cpe1-internal.example.net" of type dNSName. As 902 shown in Figure 17, the auto-upgrade to a rogue server advertising 903 "rs.example.org" will fail because it does not match "*.example.net". 905 Encrypted DNS CPE 906 capable client (@i) 907 | | 908 |<=================DHCP===============| 909 | {ADN=cpe1-internal.example.net, @i} | 910 | | 911 | Rogue Server | 912 | (@rs) | 913 | | | 914 X<===========DHCP=========| | 915 |{ADN=rs.example.org, @rs}| | 916 | | | 917 | | 918 |<=================DoH===============>| 919 | | 921 Legend: 922 * @i: internal IP address of the CPE 923 * @rs: IP address of a rogue server 925 Figure 17: A Simplified Example of Auto-upgrade based on Subdomains 927 7.2. Unmanaged CPEs 929 The approach specified in Section 7.1 does not apply for hosting a 930 DNS forwarder in an unmanaged CPE. 932 The unmanaged CPE administrator (referred to as administrator) can 933 host an encrypted DNS forwarder on the unmanaged CPE. This assumes 934 the following: 936 o The encrypted DNS server certificate is managed by the entity in- 937 charge of hosting the encrypted DNS forwarder. 939 Alternatively, a security service provider can assign a unique 940 FQDN to the CPE. The encrypted DNS forwarder will act like a 941 private encrypted DNS server only be accessible from within the 942 home network. 944 o The encrypted DNS forwarder will either be configured to use the 945 ISP's or a 3rd party encrypted DNS server. 947 o The unmanaged CPE will advertise the encrypted DNS forwarder ADN 948 using DHCP/RA to internal hosts. 950 Figure 18 illustrates an example of an unmanaged CPE hosting a 951 forwarder which connects to a 3rd party encrypted DNS server. In 952 this example, the DNS information received from the managed CPE (and 953 therefore from the ISP) is ignored by the Internal CPE hosting the 954 forwarder. 956 ,--,--,--. ,--, 957 ,' Internal Managed ,-' '- 3rd Party 958 Host--( Network#A CPE--------CPE------( ISP )--- DNS Server 959 | `. ,-'| | `-. -' | 960 | `-'--'--' | |<==DHCP==>|`--' | 961 | |<==DHCP==>| | | 962 |<======DHCP=======>| | | 963 | {RI, @i} | | 964 |<==Encrypted DNS==>|<==========Encrypted DNS==========>| 966 Legend: 967 * @i: IP address of the DNS forwarder hosted in the Internal 968 CPE. 970 Figure 18: Example of an Internal CPE Hosting a Forwarder 972 8. Legacy CPEs 974 Hosts serviced by legacy CPEs that can't be upgraded to support the 975 options defined in Section 4 won't be able to learn the encrypted DNS 976 server hosted by the ISP, in particular. If the ADN is not 977 discovered using DHCP/RA, such hosts will have to fallback to use the 978 special-use domain name defined in [I-D.pp-add-resinfo] to discover 979 the encrypted DNS server and to retrieve the list of supported DoH 980 services using the RESINFO RRtype [I-D.pp-add-resinfo]. 982 If the Do53 and Encrypted DNS servers are hosted on different public 983 IP addresses, the DNS server certificate can include the IP address 984 of the Do53 server in the subjectAltName extension. After validating 985 the server certificate, the client can retrieve the IP address in the 986 certificate to identify that both Do53 and Encrypted DNS servers are 987 operated by the same entity. 989 If the Do53 and Encrypted DNS server are hosted on a private IP 990 address, they should use the same private IP address to prove to the 991 client they are operated by the same entity. 993 The DHCP/RA option to discover ADN takes precedence over special-use 994 domain name since the special-use domain name is susceptible to both 995 internal and external attacks whereas DHCP/RA is only vulnerable to 996 internal attacks. 998 9. Security Considerations 1000 9.1. Spoofing Attacks 1002 DHCP/RA messages are not encrypted or protected against modification 1003 within the LAN. Unless mitigated (described below), the content of 1004 DHCP and RA messages can be spoofed or modified by active attackers, 1005 such as compromised devices within the home network. An active 1006 attacker (Section 3.3 of [RFC3552]) can spoof the DHCP/RA response to 1007 provide the attacker's Encrypted DNS server. Note that such an 1008 attacker can launch other attacks as discussed in Section 22 of 1009 [RFC8415]. The attacker can get a domain name, domain-validated 1010 public certificate from a CA, host an Encrypted DNS server and claim 1011 the best DNS privacy preservation policy. Also, an attacker can use 1012 a public IP address, get an 'IP address'-validated public certificate 1013 from a CA, host an Encryptd DNS server and claim the best DNS privacy 1014 preservation policy. 1016 Attacks of spoofed or modified DHCP responses and RA messages by 1017 attackers within the home network may be mitigated by making use of 1018 the following mechanisms: 1020 o DHCPv6-Shield described in [RFC7610], the CPEs discards DHCP 1021 response messages received from any local endpoint. 1023 o RA-Guard described in [RFC7113], the CPE discards RAs messages 1024 received from any local endpoint. 1026 o Source Address Validation Improvement (SAVI) solution for DHCP 1027 described in [RFC7513], the CPE filters packets with forged source 1028 IP addresses. 1030 Encrypted DNS sessions with rogue servers that spoof the IP address 1031 of a DNS server will fail because the DNS client will fail to 1032 authenticate that rogue server based upon PKIX authentication 1033 [RFC6125], particularly the authentication domain name in the 1034 Encrypted DNS Option. DNS clients that ignore authentication 1035 failures and accept spoofed certificates will be subject to attacks 1036 (e.g., redirect to malicious servers, intercept sensitive data). 1038 Encrypted DNS connections received from outside the home network MUST 1039 be discarded by the encrypted DNS forwarder in the CPE. This 1040 behavior adheres to REQ#8 in [RFC6092]; it MUST apply for both IPv4 1041 and IPv6. 1043 9.2. Deletion Attacks 1045 If the DHCP responses or RAs are dropped by the attacker, the client 1046 can fallback to use a pre-configured encrypted DNS server. However, 1047 the use of policies to select servers is out of scope of this 1048 document. 1050 Note that deletion attack is not specific to DHCP/RA. 1052 9.3. Passive Attacks 1054 A passive attacker (Section 3.2 of [RFC3552]) can identify a host is 1055 using DHCP/RA to discover an encrypted DNS server and can infer that 1056 host is capable of using DoH/DoT/DoQ to encrypt DNS messages. 1057 However, a passive attacker cannot spoof or modify DHCP/RA messages. 1059 9.4. Wireless Security - Authentication Attacks 1061 Wireless LAN (WLAN) as frequently deployed in home networks is 1062 vulnerable to various attacks (e.g., [Evil-Twin], [Krack], 1063 [Dragonblood]). Because of these attacks, only cryptographically 1064 authenticated communications are trusted on WLANs. This means 1065 information provided by such networks via DHCP, DHCPv6, or RA (e.g., 1066 NTP server, DNS server, default domain) are untrusted because DHCP 1067 and RA are not authenticated. 1069 With the current deployments (2020), the pre-shared-key is the same 1070 for all clients that connect to the same WLAN. The shared key is 1071 available to all nodes, including attackers, so it is possible to 1072 mount an active on-path attack. Man-in-the-middle attacks are 1073 possible within home networks because WLAN authentication lacks peer 1074 entity authentication. 1076 This leads to the need for provisioning unique credentials for 1077 different clients. Endpoints can be provisioned with unique 1078 credentials (username and password, typically) provided by the home 1079 network administraor to mutually authenticate to the home WLAN Access 1080 Point (e.g., 802.1x Wireless User Authentication on OpenWRT [dot1x], 1081 EAP-pwd [RFC8146]). Not all of endpoint devices (e.g., IoT devices) 1082 support 802.1x supplicant and need an alternate mechanism to connect 1083 to the home network. To address this limitation, unique pre-shared 1084 keys can be created for each such device and WPA-PSK is used (e.g., 1085 [PSK]). 1087 10. IANA Considerations 1089 10.1. DHCPv6 Options 1091 IANA is requested to assign the following new DHCPv6 Option Code in 1092 the registry maintained in [DHCPV6]. 1094 +-------+-------------------+---------+------------+----------------+ 1095 | Value | Description | Client | Singleton | Reference | 1096 | | | ORO | Option | | 1097 +-------+-------------------+---------+------------+----------------+ 1098 | TBA1 | OPTION_V6_ENC_ADN | Yes | No | [ThisDocument] | 1099 | TBA2 | OPTION_V6_ENC_ADD | Yes | No | [ThisDocument] | 1100 +-------+-------------------+---------+------------+----------------+ 1102 10.2. DHCP Option 1104 IANA is requested to assign the following new DHCP Option Code in the 1105 registry maintained in [BOOTP]. 1107 +------+------------------+-------+----------------+----------------+ 1108 | Tag | Name | Data | Meaning | Reference | 1109 | | | Length| | | 1110 +------+------------------+-------+----------------+----------------+ 1111 | TBA3 | OPTION_V4_ENC_DNS| N | Encrypted DNS | [ThisDocument] | 1112 | | | | Server | | 1113 +------+------------------+-------+----------------+----------------+ 1115 10.3. RA Options 1117 IANA is requested to assign the following new IPv6 Neighbor Discovery 1118 Option type in the "IPv6 Neighbor Discovery Option Formats" sub- 1119 registry under the "Internet Control Message Protocol version 6 1120 (ICMPv6) Parameters" registry maintained in [ND]. 1122 +------+----------------------------------+----------------+ 1123 | Type | Description | Reference | 1124 +------+----------------------------------+----------------+ 1125 | TBA4 | DNS Encrypted DNS ADN Option | [ThisDocument] | 1126 | TBA5 | DNS Encrypted DNS Address Option | [ThisDocument] | 1127 +------+----------------------------------+----------------+ 1129 11. Acknowledgements 1131 Many thanks to Christian Jacquenet and Michael Richardson for the 1132 review. 1134 Thanks to Tommy Jensen, Stephen Farrell, Martin Thomson, Vittorio 1135 Bertola, Stephane Bortzmeyer, Ben Schwartz, and Iain Sharp for the 1136 comments. 1138 Thanks to Mark Nottingham for the feedback on HTTP redirection. 1140 The use of DHCP to retrieve an authentication domain name was 1141 discussed in Section 7.3.1 of [RFC8310] and 1142 [I-D.pusateri-dhc-dns-driu]. 1144 12. Contributing Authors 1146 Nicolai Leymann 1147 Deutsche Telekom 1148 Germany 1150 Email: n.leymann@telekom.de 1152 13. References 1154 13.1. Normative References 1156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1157 Requirement Levels", BCP 14, RFC 2119, 1158 DOI 10.17487/RFC2119, March 1997, 1159 . 1161 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1162 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1163 . 1165 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1166 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1167 DOI 10.17487/RFC3396, November 2002, 1168 . 1170 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1171 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1172 DOI 10.17487/RFC4861, September 2007, 1173 . 1175 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1176 "IPv6 Router Advertisement Options for DNS Configuration", 1177 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1178 . 1180 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1181 Writing an IANA Considerations Section in RFCs", BCP 26, 1182 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1183 . 1185 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1186 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1187 May 2017, . 1189 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 1190 for DNS over TLS and DNS over DTLS", RFC 8310, 1191 DOI 10.17487/RFC8310, March 2018, 1192 . 1194 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1195 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1196 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1197 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1198 . 1200 13.2. Informative References 1202 [Auto-upgrade] 1203 The Unicode Consortium, "DoH providers: criteria, process 1204 for Chrome", . 1207 [BOOTP] , . 1210 [DHCPV6] , . 1213 [dot1x] Cisco, "Basic 802.1x Wireless User Authentication", 1214 . 1217 [DPP] The Wi-Fi Alliance, "Device Provisioning Protocol 1218 Specification", . 1221 [Dragonblood] 1222 The Unicode Consortium, "Dragonblood: Analyzing the 1223 Dragonfly Handshake of WPA3 and EAP-pwd", 1224 . 1226 [Evil-Twin] 1227 The Unicode Consortium, "Evil twin (wireless networks)", 1228 . 1231 [I-D.box-add-requirements] 1232 Box, C., Pauly, T., Wood, C., and T. Reddy.K, 1233 "Requirements for Adaptive DNS Discovery", draft-box-add- 1234 requirements-00 (work in progress), September 2020. 1236 [I-D.ietf-dnsop-terminology-ter] 1237 Hoffman, P., "Terminology for DNS Transports and 1238 Location", draft-ietf-dnsop-terminology-ter-02 (work in 1239 progress), August 2020. 1241 [I-D.ietf-dprive-dnsoquic] 1242 Huitema, C., Mankin, A., and S. Dickinson, "Specification 1243 of DNS over Dedicated QUIC Connections", draft-ietf- 1244 dprive-dnsoquic-01 (work in progress), October 2020. 1246 [I-D.ietf-v6ops-rfc7084-bis] 1247 Palet, J., "Basic Requirements for IPv6 Customer Edge 1248 Routers", draft-ietf-v6ops-rfc7084-bis-04 (work in 1249 progress), June 2017. 1251 [I-D.pp-add-resinfo] 1252 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 1253 publication", draft-pp-add-resinfo-02 (work in progress), 1254 June 2020. 1256 [I-D.pusateri-dhc-dns-driu] 1257 Pusateri, T. and W. Toorop, "DHCPv6 Options for private 1258 DNS Discovery", draft-pusateri-dhc-dns-driu-00 (work in 1259 progress), July 2018. 1261 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 1262 2017, . 1264 [ND] , . 1267 [PSK] Cisco, "Identity PSK Feature Deployment Guide", 1268 . 1272 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1273 Text on Security Considerations", BCP 72, RFC 3552, 1274 DOI 10.17487/RFC3552, July 2003, 1275 . 1277 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1278 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1279 DOI 10.17487/RFC3646, December 2003, 1280 . 1282 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1283 Capabilities in Customer Premises Equipment (CPE) for 1284 Providing Residential IPv6 Internet Service", RFC 6092, 1285 DOI 10.17487/RFC6092, January 2011, 1286 . 1288 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1289 Verification of Domain-Based Application Service Identity 1290 within Internet Public Key Infrastructure Using X.509 1291 (PKIX) Certificates in the Context of Transport Layer 1292 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 1293 2011, . 1295 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 1296 Recursive DNS Server Selection for Multi-Interfaced 1297 Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012, 1298 . 1300 [RFC7113] Gont, F., "Implementation Advice for IPv6 Router 1301 Advertisement Guard (RA-Guard)", RFC 7113, 1302 DOI 10.17487/RFC7113, February 2014, 1303 . 1305 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1306 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1307 Transport Layer Security (TLS) and Datagram Transport 1308 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1309 June 2014, . 1311 [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address 1312 Validation Improvement (SAVI) Solution for DHCP", 1313 RFC 7513, DOI 10.17487/RFC7513, May 2015, 1314 . 1316 [RFC7610] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: 1317 Protecting against Rogue DHCPv6 Servers", BCP 199, 1318 RFC 7610, DOI 10.17487/RFC7610, August 2015, 1319 . 1321 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1322 and P. Hoffman, "Specification for DNS over Transport 1323 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1324 2016, . 1326 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 1327 Configuration on the Basis of Network Topology", RFC 7969, 1328 DOI 10.17487/RFC7969, October 2016, 1329 . 1331 [RFC8146] Harkins, D., "Adding Support for Salted Password Databases 1332 to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, 1333 . 1335 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 1336 Better Connectivity Using Concurrency", RFC 8305, 1337 DOI 10.17487/RFC8305, December 2017, 1338 . 1340 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1341 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1342 . 1344 [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 1345 D., Mahy, R., and P. Matthews, "Session Traversal 1346 Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, 1347 February 2020, . 1349 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1350 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1351 January 2019, . 1353 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1354 Description Specification", RFC 8520, 1355 DOI 10.17487/RFC8520, March 2019, 1356 . 1358 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 1359 Kasten, "Automatic Certificate Management Environment 1360 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 1361 . 1363 [TR-069] The Broadband Forum, "CPE WAN Management Protocol", 1364 December 2018, . 1367 [TS.24008] 1368 3GPP, "Mobile radio interface Layer 3 specification; Core 1369 network protocols; Stage 3 (Release 16)", December 2019, 1370 . 1372 Authors' Addresses 1374 Mohamed Boucadair 1375 Orange 1376 Rennes 35000 1377 France 1379 Email: mohamed.boucadair@orange.com 1381 Tirumaleswar Reddy 1382 McAfee, Inc. 1383 Embassy Golf Link Business Park 1384 Bangalore, Karnataka 560071 1385 India 1387 Email: TirumaleswarReddy_Konda@McAfee.com 1389 Dan Wing 1390 Citrix Systems, Inc. 1391 USA 1393 Email: dwing-ietf@fuggles.com 1395 Neil Cook 1396 Open-Xchange 1397 UK 1399 Email: neil.cook@noware.co.uk