idnits 2.17.1 draft-reddy-dprive-bootstrap-dns-server-08.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 7, 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) == Outdated reference: A later version (-12) exists of draft-btw-add-home-01 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Experimental RFC: RFC 8121 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-37 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DPRIVE WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: September 8, 2020 Citrix 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 March 7, 2020 12 A Bootstrapping Procedure to Discover and Authenticate DNS-over-TLS and 13 DNS-over-HTTPS Servers 14 draft-reddy-dprive-bootstrap-dns-server-08 16 Abstract 18 This document specifies mechanisms to automatically bootstrap 19 endpoints (e.g., hosts, Customer Equipment) to discover and 20 authenticate DNS-over-TLS and DNS-over-HTTPS servers provided by a 21 local network. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 8, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Bootstrapping Endpoint Devices . . . . . . . . . . . . . . . 6 61 5. Bootstrapping IoT Devices . . . . . . . . . . . . . . . . . . 8 62 6. DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure 9 63 7. Connection Handshake and Service Invocation . . . . . . . . . 10 64 8. EST Service Discovery Procedure . . . . . . . . . . . . . . . 10 65 8.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. Network Reattachment . . . . . . . . . . . . . . . . . . . . 11 67 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 14.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 Traditionally a caching DNS server has been provided by local 79 networks. This provides benefits such as low latency to reach that 80 DNS server (owing to its network proximity to the endpoint). 81 However, if an endpoint is configured to use Internet-hosted or 82 public DNS-over-TLS [RFC7858] or DNS-over-HTTPS [RFC8484] servers, 83 any available local DNS server cannot serve DNS requests from local 84 endpoints. If public DNS servers are used instead of using local DNS 85 servers, some operational problems can occur such as those listed 86 below: 88 o "Split DNS" [RFC2775] to use the special internal-only domain 89 names (e.g., "internal.example.com") in enterprise networks will 90 not work, and ".local" and "home.arpa" names cannot be locally 91 resolved in home networks. 93 o Content Delivery Networks (CDNs) that map traffic based on DNS may 94 lose the ability to direct end-user traffic to a nearby service- 95 specific cluster in cases where a DNS service is being used that 96 is not affiliated with the local network and which does not send 97 "EDNS Client Subnet" (ECS) information [RFC7871] to the CDN's DNS 98 authorities [CDN]. 100 If public DNS servers are used instead of using local DNS servers, 101 the following discusses the impact on network-based security: 103 o Various network security services are provided by Enterprise 104 networks to protect endpoints (e.g,. Hosts, IoT devices). 105 Network-based security solutions such as Firewalls (FW) and 106 Intrusion Prevention Systems (IPS) rely on network traffic 107 inspection to implement perimeter-based security policies. The 108 network security services may for example prevent malware 109 download, block known malicious URLs, enforce use of strong 110 ciphers, stop data exfiltration, etc. These network security 111 services act on DNS requests originating from endpoints. 113 o However, if an endpoint is configured to use public DNS-over-TLS 114 or DNS-over-HTTPS servers, network security services cannot act on 115 DNS requests from these endpoints. 117 o In order to act on DNS requests from endpoints, network security 118 services can block DNS-over-TLS traffic by dropping outgoing 119 packets to destination port 853. Identifying DNS-over-HTTPS 120 traffic is far more challenging than DNS-over-TLS traffic. 121 Network security services may try to identify the domains offering 122 DNS-over-HTTPS servers, and DNS-over-HTTPS traffic can be blocked 123 by dropping outgoing packets to these domains. If an endpoint has 124 enabled strict privacy profile (Section 5 of [RFC8310]), and the 125 network security service blocks the traffic to the public DNS 126 server, the DNS service won't be available to the endpoint and 127 ultimately the endpoint cannot access Internet-reachable services. 129 o If an endpoint has enabled opportunistic privacy profile 130 (Section 5 of [RFC8310]), and the network security service blocks 131 traffic to the public DNS server, the endpoint will either 132 fallback to an encrypted connection without authenticating the DNS 133 server provided by the local network or fallback to clear text 134 DNS, and cannot exchange encrypted DNS messages. 136 If the network security service fails to block DNS-over-TLS or DNS- 137 over-HTTPS traffic, this can compromise the endpoint security; some 138 of the potential security threats are listed below: 140 o The network security service cannot prevent an endpoint from 141 accessing malicious domains. 143 o If the endpoint is an IoT device which is configured to use public 144 DNS-over-TLS or DNS-over-HTTPS servers, and if a policy 145 enforcement point in the local network is programmed using, for 146 example, a Manufacturer Usage Description (MUD) file [RFC8520] by 147 a MUD manager to only allow intented communications to and from 148 the IoT device, the policy enforcement point cannot enforce the 149 network Access Control List (ACL) rules based on domain names 150 (Section 8 of [RFC8520]). 152 If the network security service successfully blocks DNS-over-TLS and 153 DNS-over-HTTPS traffic, this can still compromise the endpoint 154 security and privacy; some of the potential security threats are 155 listed below: 157 o Pervasive monitoring of DNS traffic. 159 o An internal attacker can modify the DNS responses to re-direct the 160 client to malicious servers. 162 In addition, the local network's DNS server is advertised using DHCP/ 163 RA which is insecure and also provides no mechanism to securely 164 authenticate the DNS server. To overcome the above threats, this 165 document specifies a mechanism to automatically bootstrap endpoints 166 to discover and authenticate the DNS-over-TLS and DNS-over-HTTPS 167 servers provided by their local network. The overall procedure can 168 be structured into the following steps: 170 o Bootstrapping (Section 4) is necessary only when connecting to a 171 new network or when the network's DNS certificate has changed. 172 Bootstrapping authenticates the Enrollment over Secure Transport 173 (EST) [RFC7030] server to the endpoint. After authenticating the 174 EST server, DNS server certificate used by the local network is 175 downloaded to the endpoint. This DNS server certificate enables 176 subsequent authenticated encrypted communication with the local 177 DNS server (e.g., DNS-over-HTTPS) during in the connection phase. 179 o Discovery (Section 6) is performed by a previously bootstrapped 180 endpoint whenever connecting to a network. During discovery, the 181 endpoint is instructed which privacy-enabling DNS protocol(s), 182 port number(s), and IP addresses are supported on a local network. 183 This effectively takes the place of DNS server IP address 184 traditionally provided by IPv4 or IPv6 DHCP or by IPv6 Router 185 Advertisement [RFC8106]. 187 o Connection handshake and service invocation (Section 7): The DNS 188 client initiates a TLS handshake with the DNS server learned in 189 the discovery phase, and validates the DNS server's identity using 190 the credentials obtained in the bootstrapping phase. 192 Note: The strict and opportunistic privacy profiles as defined in 193 [RFC8310] only applies to DNS-over-TLS protocol, there has been no 194 such distinction made for DNS-over-HTTPS protocol. 196 2. Scope 198 The problems discussed in Section 1 will be encountered in Enterprise 199 networks. Typically Enterprise networks do not assume that all 200 devices in their network are managed by the IT team or Mobile Device 201 Management (MDM) devices, especially in the quite common BYOD ("Bring 202 Your Own Device") scenario. The mechanisms specified in this 203 document can be used by BYOD devices to discover and authenticate 204 DNS-over-TLS and DNS-over-HTTPS servers provided by the Enterprise 205 network. This mechanism can also be used by IoT devices (managed by 206 IT team) after onboarding to discover and authenticate DNS- over-TLS 207 and DNS-over-HTTPS servers provided by the Enterprise network. 209 WiFi as frequently deployed is vulnerable to various attacks 210 ([Evil-Twin],[Krack] and [Dragonblood]). Because of these attacks, 211 only cryptographically authenticated communications are trusted on 212 WiFi networks. This means information provided by the network via 213 DHCPv4, DHCPv6, or RA (e.g., NTP server, DNS server, default domain) 214 are un-trusted because DHCP and RA are not authenticated. 216 The users have to indicate to their system in some way that they 217 desire bootstrapping to be performed only when connecting to a 218 specific network (e.g., organization for which a user works or a user 219 works temporarily within another corporation), similar to the way 220 users disable VPN connection in specific network (e.g., Enterprise 221 network) and enable VPN connection by default in other networks. If 222 the discovered DNS server meets the privacy preserving data policy 223 requirements of the user, the user can select to use the discovered 224 DNS-over-TLS and DNS-over-HTTPS servers. In addition, if the 225 discovered DNS-over-TLS and DNS-over-HTTPS servers is pre-configured 226 in the OS or browser, user can inform the system to use the servers 227 in untrusted networks (e.g. coffee shops, airports etc.). It is 228 strongly recommended to configure the DNS server to be used in 229 untrusted networks provided the DNS server meets the privacy 230 preserving data policy requirements of the user, offers malware 231 filtering service and is pre-configured in the OS or browser. 233 3. Terminology 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 237 "OPTIONAL" in this document are to be interpreted as described in BCP 238 14 [RFC2119][RFC8174] when, and only when, they appear in all 239 capitals, as shown here. 241 This document uses the terms defined in [RFC8499]. 243 4. Bootstrapping Endpoint Devices 245 The following steps detail the mechanism to automatically bootstrap 246 an endpoint with the local network's DNS server certificate: 248 1. The endpoint authenticates to the local network and discovers the 249 Enrollment over Secure Transport (EST) [RFC7030] server using the 250 procedure discussed in Section 8. 252 2. The endpoint establishes provisional TLS connection with that EST 253 server, i.e., the endpoint provisionally accepts the unverified 254 TLS server certificate. However, the endpoint MUST authenticate 255 the EST server before it accepts the DNS server certificate. The 256 endpoint either uses password-based authenticated key exchange 257 (PAKE) with TLS 1.3 [I-D.barnes-tls-pake] as an authentication 258 method or uses the mutual authentication protocol for HTTP 259 [RFC8120] to authenticate the discovered EST server. 261 As a reminder, PAKE is an authentication method that allows the 262 use of usernames and passwords over unencrypted channels without 263 revealing the passwords to an eavesdropper. Similarly, the 264 mutual authentication for HTTP is based on PAKE and provides 265 mutual authentication between an HTTP client and an HTTP server 266 using username and password as credentials. The cryptographic 267 algorithms to use with the mutual authentication protocol for 268 HTTP are defined in [RFC8121]. 270 3. The endpoint needs to use PAKE scheme to perform authentication 271 the first time it connects to an EST server. If the EST server 272 authentication is successful, the server's identity can be used 273 to authenticate subsequent TLS connections to that EST server. 274 The endpoint configures the reference identifier for the EST 275 server using the DNS-ID identifier type in the EST server 276 certificate. On subsequent connections to the EST server, the 277 endpoint MUST validate the EST server certificate using the 278 Implict Trust Anchor database (i.e, the EST server certificate 279 must pass PKIX certification path validation) and match the 280 reference identifier against the EST server's identity according 281 to the rules specified in Section 6.4 of [RFC6125]. 283 4. The endpoint learns the End-Entity certificates [RFC8295] from 284 the EST server. The certificate provisioned to the DNS server in 285 the local network will be treated as a End-Entity certificate. 286 As a reminder, the End-Entity certificates must be validated by 287 the endpoint using an authorized trust anchor (Section 3.2 of 288 [RFC8295]). The endpoint needs to identify the certificate 289 provisioned to the DNS server. The SRV-ID identifier type 290 [RFC6125] within subjectAltName entry MUST be used to identify 291 the DNS server certificate. 293 For example, DNS server certificate will include SRV-ID "_domain- 294 s.example.net" along with DNS-ID "example.net". The SRV service 295 label "domain-s" is defined in Section 6 of [RFC7858]. As a 296 reminder, the protocol component is not included in the SRV-ID 297 [RFC4985]. 299 5. The endpoint configures the authentication domain name (ADN) 300 (defined in [RFC8310]) for the DNS server from the DNS-ID 301 identifier type within subjectAltName entry in the DNS server 302 certificate. The DNS server certificate is associated with the 303 ADN to be matched with the certificate given by the DNS server in 304 TLS. To some extent, this approach is similar to certificate 305 usage PKIX-EE(1) defined in [RFC7671]. 307 Figure 1 illustrates a sequence diagram for bootstrapping an endpoint 308 with the local network's DNS server certificate. 310 +----------+ +--------+ +--------+ 311 | Endpoint | | EST | | DNS | 312 | | | Server | | Server | 313 +----------+ +--------+ +--------+ 314 | DNS-SD query to discover the EST server | | 315 |-------------------------------------------------------->| 316 | | | 317 | optional: mDNS query to | | 318 | discover the EST server | | 319 |--------------------------------------------->| | 320 | | | 321 | Establish provisional TLS connection | | 322 |<-------------------------------------------->| | 323 | | | 324 | PAKE scheme to authenticate the EST server | | 325 |<-------------------------------------------->| | 326 | | | 327 [Generate reference identifier for the EST server | | 328 to compare with the EST server certificate | | 329 in subsequent TLS connections] | | 330 | | | 331 | Get EE certificates | | 332 |--------------------------------------------->| | 333 | | | 334 [Identify the DNS server certificate in EE | | 335 certificates to match with the certificate | | 336 by the DNS server in TLS handshake] | | 337 | | 338 [Configure ADN and associate DNS server certificate] | | 339 | | | 341 Figure 1: Bootstrapping Endpoint Devices 343 5. Bootstrapping IoT Devices 345 The following steps explain the mechanism to automatically bootstrap 346 IoT devices with local network's CA certificates and DNS server 347 certificate: 349 o Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed 350 in [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 351 secure automated bootstrap of devices. BRSKI specifies means to 352 provision credentials on devices to be used to operationally 353 access networks. In addition, BRSKI provides an automated 354 mechanism for the bootstrap distribution of CA certificates from 355 the EST server. The IoT device can use BRSKI to automatically 356 bootstrap the IoT device using the IoT manufacturer provisioned 357 X.509 certificate, in combination with a registrar provided by the 358 local network and IoT device manufacturer's authorizing service 359 (MASA): 361 1. The IoT device authenticates to the local network using the 362 IoT manufacturer provisioned X.509 certificate. The IoT 363 device can request and get a voucher from the MASA service via 364 the registrar. The voucher is signed by the MASA service and 365 includes the local network's CA public key. 367 2. The IoT device validates the signed voucher using the 368 manufacturer installed trust anchor associated with the MASA, 369 stores the CA's public key and validates the provisional TLS 370 connection to the registrar. 372 3. The IoT device requests the full EST distribution of current 373 CA certificates (Section 5.9.1 in 374 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 375 operating as a BRSKI-EST server. The IoT devices stores the 376 CA certificates as Explicit Trust Anchor database entries. 377 The IoT device uses the Explicit Trust Anchor database to 378 validate the DNS server certificate. 380 4. The IoT device learns the End-Entity certificates from the 381 BRSKI-EST server. The certificate provisioned to the DNS 382 server in the local network will be treated as an End-Entity 383 certificate. The IoT device needs to identify the certificate 384 provisioned to the DNS server. The SRV-ID identifier type 385 within subjectAltName entry MUST be used to identify the DNS 386 server certificate. 388 5. The endpoint configures the ADN for the DNS server from the 389 DNS-ID identifier type within subjectAltName entry in the DNS 390 server certificate. The DNS server certificate is associated 391 with the ADN to be matched with the certificate given by the 392 DNS server in TLS. 394 6. DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure 396 A DNS client discovers the DNS server in the local network supports 397 DNS-over-TLS and DNS-over-HTTPS protocols by using the mechanism 398 discussed in Section 6 of [I-D.btw-add-home]. If the endpoint has 399 enabled strict privacy profile and access to the pre-configured 400 public DNS servers is blocked, the DNS service won't be available to 401 the endpoint and ultimately the endpoint cannot access Internet- 402 reachable services. If the endpoint has enabled opportunistic 403 privacy profile and access to the pre-configured public DNS servers 404 is blocked, the endpoint will either fallback to an encrypted 405 connection without authenticating the DNS server provided by the 406 local network or fallback to clear text DNS. 408 7. Connection Handshake and Service Invocation 410 The DNS client initiates TLS handshake with the DNS server, the DNS 411 server presents its certificate in ServerHello message, and the DNS 412 client MUST match the DNS server certificate downloaded in Step 4 in 413 Section 4 or Section 5 with the certificate provided by the DNS 414 server in TLS handshake. If the match is successful, the DNS client 415 MUST validate the server certificate using the Implicit Trust Anchor 416 database (i.e., the DNS server certificate must pass PKIX 417 certification path validation). 419 If the match is successful and server certificate is successfully 420 validated, the client continues with the connection as normal. 421 Otherwise, the client MUST treat the server certificate validation 422 failure as a non-recoverable error. If the DNS client cannot reach 423 or establish an authenticated and encrypted connection with the 424 privacy-enabling DNS server provided by the local network, the DNS 425 client can fallback to the privacy-enabling public DNS server. 427 8. EST Service Discovery Procedure 429 A EST client discovers the EST server in the local network by using 430 DNS-based Service Discovery (DNS-SD) [RFC6763] or Multicast DNS 431 (mDNS) [RFC6762]. The portion specifies the DNS sub-domain 432 where the service instance is registered. It may be "local.", 433 indicating the mDNS local domain, or it may be a conventional domain 434 name such as "example.com.". The portion of the EST 435 service instance name MUST be "_est._tcp". 437 8.1. mDNS 439 A EST client application can proactively discover an EST server being 440 advertised in the site by multicasting a PTR query to the following: 442 o "_est._tcp.local" 444 A EST server can send out gratuitous multicast DNS answer packets 445 whenever it starts up, wakes from sleep, or detects a change in EST 446 server configuration. EST client application can receive these 447 gratuitous packets and cache information contained in them. 449 9. Network Reattachment 451 On subsequent attachments to the network, the endpoint discovers the 452 privacy-enabling DNS server using the authentication domain name 453 (configured in Step 5 of Section 4 or Section 5), initiates TLS 454 handshake with the DNS server and follows the mechanism discussed in 455 Section 7 to validate the DNS server certificate. 457 If the DNS server certificate is invalid (e.g., revoked or expired) 458 or the procedure to discover the privacy-enabling DNS server fails 459 (e.g. the domain name of the privacy-enabling DNS server has changed 460 because the Enterprise network has switched to a public privacy- 461 enabling DNS server capable of blocking access to malicious domains), 462 the endpoint discovers and initiates TLS handshake with the EST 463 server, and uses the validation techniques described in [RFC6125] to 464 compare the reference identifier (created in Step 2 of Section 4 in 465 this document) to the EST server certificate and verifies the entire 466 certification path as per [RFC5280]. The endpoint then gets the DNS 467 server certificate from the EST server. If the DNS-ID identifier 468 type within subjectAltName entry in the DNS server certificate does 469 not match the configured ADN, the ADN is replaced with the DNS-ID 470 identifier type. The DNS server certificate associated with the ADN 471 is replaced with the one provided by the EST server. If the ADN has 472 changed, the endpoint discovers the privacy-enabling DNS server, 473 initiates TLS handshake with the DNS server and follows the mechanism 474 discussed in Section 7 to validate the DNS server certificate. 476 Figure 2 illustrates a sequence diagram for re-configuring an 477 endpoint with ADN and local network's DNS server certificate on 478 subsequent attachments to the network. 480 +----------+ +--------+ +--------+ 481 | Endpoint | | EST | | DNS | 482 | | | Server | | Server | 483 +----------+ +--------+ +--------+ 484 | DNS-SD query to discover the EST server | | 485 |-------------------------------------------------------->| 486 | | | 487 | optional: mDNS query to | | 488 | discover the EST server | | 489 |--------------------------------------------->| | 490 | | | 491 | Establish TLS connection | | 492 | and validate EST server certificate | | 493 |<-------------------------------------------->| | 494 | | | 495 | Get EE certificates | | 496 |<-------------------------------------------->| | 497 | | | 498 [Identify the DNS server certificate in EE | | 499 certificates to match with the certificate | | 500 by the DNS server in TLS handshake] | | 501 | | 502 [Re-configure ADN and associate DNS server certificate]| | 503 | | | 505 Figure 2: Bootstrapping Endpoint Devices on subsequent attachments to 506 the network 508 10. Privacy Considerations 510 [RFC7626] discusses DNS privacy considerations in both "on the wire" 511 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 512 [RFC7626] contexts. The mechanism defined in 513 [I-D.reddy-dprive-dprive-privacy-policy] can be used by the DNS 514 server to communicate its privacy statement URL and filtering policy 515 to a DNS client. This communication is cryptographically signed to 516 attest to its authenticity. By evaluating the DNS privacy statement, 517 filtering policy and the signatory, the user can choose to use the 518 discovered DNS server if it meets privacy preserving data policy and 519 filtering requirements of the user. 521 11. Security Considerations 523 The bootstrapping procedure to obtain the certificate of the local 524 networks DNS server uses a client identity and password to 525 authenticate the EST server using PAKE schemes. Security 526 considerations such as those discussed in [I-D.barnes-tls-pake] or 527 [RFC8120] and [RFC8121] need to be taken into consideration. 529 Users cannot be expected to enable or disable the bootstrapping or 530 the discovery procedure as they switch networks. Thus, it is 531 RECOMMENDED that users indicate to their system in some way that they 532 desire bootstrapping to be performed when connecting to a specific 533 network, similar to the way users disable VPN connection in specific 534 network (e.g., Enterprise network) and enable VPN connection by 535 default in other networks. 537 If an endpoint has enabled strict privacy profile, and the network 538 security service blocks the traffic to the privacy-enabling public 539 DNS server, a hard failure occurs and the user is notified. The user 540 has a choice to switch to another network or if the user trusts the 541 network, the user can enable strict privacy profile with the DNS- 542 over-TLS or DNS-over-HTTPS server discovered in the network instead 543 of downgrading to opportunistic privacy profile. 545 The primary attacks against the methods described in Section 6 are 546 the ones that would lead to impersonation of a DNS server and 547 spoofing the DNS response to indicate that the DNS server does not 548 support any privacy-enabling protocols. To protect against DNS- 549 vectored attacks, secured DNS (DNSSEC) can be used to ensure the 550 validity of the DNS records received. Impersonation of the DNS 551 server is prevented by validating the certificate presented by the 552 DNS server. If the EST server conveys the DNS server certificate, 553 but the DNS-SD lookup indicates that the DNS server does not support 554 any privacy-enabling protocols, the client can detect the DNS 555 response is spoofed. 557 If the browser or OS is pre-configured with a list of DNS servers 558 where some perform malware filtering and others do not, an attacker 559 can prevent contacting the preferred filtering DNS servers causing a 560 downgrade attack to a non-filtering DNS server, which the attacker 561 can leverage to deliver malware. To prevent such an attack, it is 562 RECOMMENDED if any pre-configured DNS servers perform malware 563 filtering that all pre-configured DNS servers perform malware 564 filtering. 566 Related to the downgrade attack described in the previous paragraph, 567 if the browser or OS is pre-configured to use a DNS server that 568 filters malware, it MUST NOT use locally-learned DNS servers (e.g., 569 learned via DHCP) unless they also perform malware filtering and also 570 conform to the user's privacy policy. 572 Security considerations in [I-D.ietf-anima-bootstrapping-keyinfra] 573 need to be taken into consideration for IoT devices. 575 12. IANA Considerations 577 IANA is requested to allocate the SRV service name of "est". 579 13. Acknowledgments 581 Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick 582 McManus, Bob Harold, Livingood Jason, Winfield Alister, Eliot Lear, 583 Stephane Bortzmeyer, Ted Lemon and Sara Dickinson for the discussion 584 and comments. 586 14. References 588 14.1. Normative References 590 [I-D.btw-add-home] 591 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, "DNS- 592 over-HTTPS and DNS-over-TLS server Discovery and 593 Deployment Considerations for Home and Mobile Networks", 594 draft-btw-add-home-01 (work in progress), March 2020. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 602 Subject Alternative Name for Expression of Service Name", 603 RFC 4985, DOI 10.17487/RFC4985, August 2007, 604 . 606 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 607 Housley, R., and W. Polk, "Internet X.509 Public Key 608 Infrastructure Certificate and Certificate Revocation List 609 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 610 . 612 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 613 Verification of Domain-Based Application Service Identity 614 within Internet Public Key Infrastructure Using X.509 615 (PKIX) Certificates in the Context of Transport Layer 616 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 617 2011, . 619 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 620 DOI 10.17487/RFC6762, February 2013, 621 . 623 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 624 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 625 . 627 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 628 "Enrollment over Secure Transport", RFC 7030, 629 DOI 10.17487/RFC7030, October 2013, 630 . 632 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 633 and P. Hoffman, "Specification for DNS over Transport 634 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 635 2016, . 637 [RFC8121] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 638 T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: 639 Cryptographic Algorithms Based on the Key Agreement 640 Mechanism 3 (KAM3)", RFC 8121, DOI 10.17487/RFC8121, April 641 2017, . 643 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 645 May 2017, . 647 [RFC8295] Turner, S., "EST (Enrollment over Secure Transport) 648 Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, 649 . 651 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 652 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 653 . 655 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 656 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 657 January 2019, . 659 14.2. Informative References 661 [CDN] "End-User Mapping: Next Generation Request Routing for 662 Content Delivery", 2015, 663 . 666 [Dragonblood] 667 The Unicode Consortium, "Dragonblood: Analyzing the 668 Dragonfly Handshake of WPA3 and EAP-pwd", 669 . 671 [Evil-Twin] 672 The Unicode Consortium, "Evil twin (wireless networks)", 673 . 676 [I-D.barnes-tls-pake] 677 Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", 678 draft-barnes-tls-pake-04 (work in progress), July 2018. 680 [I-D.ietf-anima-bootstrapping-keyinfra] 681 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 682 and K. Watsen, "Bootstrapping Remote Secure Key 683 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 684 keyinfra-37 (work in progress), February 2020. 686 [I-D.reddy-dprive-dprive-privacy-policy] 687 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 688 "DNS Server Privacy Statement and Filtering Policy with 689 Assertion Token", draft-reddy-dprive-dprive-privacy- 690 policy-03 (work in progress), March 2020. 692 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 693 2017, . 695 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 696 DOI 10.17487/RFC2775, February 2000, 697 . 699 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 700 DOI 10.17487/RFC7626, August 2015, 701 . 703 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 704 Authentication of Named Entities (DANE) Protocol: Updates 705 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 706 October 2015, . 708 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 709 Kumari, "Client Subnet in DNS Queries", RFC 7871, 710 DOI 10.17487/RFC7871, May 2016, 711 . 713 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 714 "IPv6 Router Advertisement Options for DNS Configuration", 715 RFC 8106, DOI 10.17487/RFC8106, March 2017, 716 . 718 [RFC8120] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 719 T., and Y. Ioku, "Mutual Authentication Protocol for 720 HTTP", RFC 8120, DOI 10.17487/RFC8120, April 2017, 721 . 723 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 724 for DNS over TLS and DNS over DTLS", RFC 8310, 725 DOI 10.17487/RFC8310, March 2018, 726 . 728 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 729 Description Specification", RFC 8520, 730 DOI 10.17487/RFC8520, March 2019, 731 . 733 Authors' Addresses 735 Tirumaleswar Reddy 736 McAfee, Inc. 737 Embassy Golf Link Business Park 738 Bangalore, Karnataka 560071 739 India 741 Email: kondtir@gmail.com 743 Dan Wing 744 Citrix Systems, Inc. 745 USA 747 Email: dwing-ietf@fuggles.com 749 Michael C. Richardson 750 Sandelman Software Works 751 USA 753 Email: mcr+ietf@sandelman.ca 755 Mohamed Boucadair 756 Orange 757 Rennes 35000 758 France 760 Email: mohamed.boucadair@orange.com