idnits 2.17.1 draft-reddy-dprive-bootstrap-dns-server-06.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 (January 09, 2020) is 1567 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) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7553 ** Downref: Normative reference to an Experimental RFC: RFC 8094 ** 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-34 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 6 errors (**), 0 flaws (~~), 2 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: July 12, 2020 Citrix 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 January 09, 2020 12 A Bootstrapping Procedure to Discover and Authenticate DNS-over-(D)TLS 13 and DNS-over-HTTPS Servers 14 draft-reddy-dprive-bootstrap-dns-server-06 16 Abstract 18 This document specifies mechanisms to automatically bootstrap 19 endpoints (e.g., hosts, Customer Equipment) to discover and 20 authenticate DNS-over-(D)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 July 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 9. Network Reattachment . . . . . . . . . . . . . . . . . . . . 11 67 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 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-(D)TLS [RFC7858] [RFC8094] or DNS-over-HTTPS 83 [RFC8484] servers, any available local DNS server cannot serve DNS 84 requests from local endpoints. If public DNS servers are used 85 instead of using local DNS servers, some operational problems can 86 occur such as those listed 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- 114 over-(D)TLS or DNS-over-HTTPS servers, network security services 115 cannot act on DNS requests from these endpoints. 117 o In order to act on DNS requests from endpoints, network security 118 services can block DNS-over-(D)TLS traffic by dropping outgoing 119 packets to destination port 853. Identifying DNS-over-HTTPS 120 traffic is far more challenging than DNS-over-(D)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-(D)TLS or 137 DNS-over-HTTPS traffic, this can compromise the endpoint security; 138 some 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-(D)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-(D)TLS 153 and 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-(D)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 (D)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-(D)TLS protocols, there has been 194 no 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-(D)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- 207 over-(D)TLS and DNS-over-HTTPS servers provided by the Enterprise 208 network. 210 WiFi as frequently deployed is vulnerable to various attacks 211 ([Evil-Twin],[Krack] and [Dragonblood]). Because of these attacks, 212 only cryptographically authenticated communications are trusted on 213 WiFi networks. This means information provided by the network via 214 DHCPv4, DHCPv6, or RA (e.g., NTP server, DNS server, default domain) 215 are un-trusted because DHCP and RA are not authenticated. 217 The users have to indicate to their system in some way that they 218 desire bootstrapping to be performed only when connecting to a 219 specific network (e.g., organization for which a user works or a user 220 works temporarily within another corporation), similar to the way 221 users disable VPN connection in specific network (e.g., Enterprise 222 network) and enable VPN connection by default in other networks. If 223 the discovered DNS server meets the privacy preserving data policy 224 requirements of the user, the user can select to use the discovered 225 DNS-over-(D)TLS and DNS-over-HTTPS servers. In addition, if the 226 discovered DNS-over-(D)TLS and DNS-over-HTTPS servers are reachable 227 on the Internet, user can inform the system to use the servers in 228 other networks. It is strongly recommended to configure the DNS 229 server to be used in other networks provided the DNS server meets the 230 privacy preserving data policy requirements of the user and offers 231 malware filtering service. 233 If the device joins a public WiFi without any security credential 234 verification or joins a WiFi using a single shared password among all 235 the attached devices, such networks are typically not known to the 236 user or a compromised devices can spoof the access point or the 237 attacker can host a fake access point, and the device cannot be 238 securely bootstrapped with the network's DNS-over-HTTPS or DNS-over- 239 TLS server. A compromised device may, for example, expose to an 240 attacker secrets (such as single shared password) stored in the 241 device. Such networks can also be misconfigured or malicious. 242 Further, the client cannot know if the discovered DNS-over-HTTPS or 243 DNS-over-(D)TLS server is hosted by the network operator or by an 244 attacker. In such networks, DNS-over-HTTPS and DNS-over-(D)TLS 245 server discovered using insecure discovery mechanisms like DHCP can 246 be used by the client if and only if the insecurely discovered DNS- 247 over-HTTPS and DNS-over-(D)TLS server is previously securely 248 discovered in a different network, offers malware filtering service, 249 meets the privacy preserving data policy requirements of the user and 250 configured to be used in other networks. 252 3. Terminology 254 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 255 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 256 "OPTIONAL" in this document are to be interpreted as described in BCP 257 14 [RFC2119][RFC8174] when, and only when, they appear in all 258 capitals, as shown here. 260 (D)TLS is used for statements that apply to both Transport Layer 261 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 262 Specific terms are used for any statement that applies to either 263 protocol alone. 265 This document uses the terms defined in [RFC8499]. 267 4. Bootstrapping Endpoint Devices 269 The following steps detail the mechanism to automatically bootstrap 270 an endpoint with the local network's DNS server certificate: 272 1. The endpoint authenticates to the local network and discovers the 273 Enrollment over Secure Transport (EST) [RFC7030] server using the 274 procedure discussed in Section 8. 276 2. The endpoint establishes provisional TLS connection with that EST 277 server, i.e., the endpoint provisionally accepts the unverified 278 TLS server certificate. However, the endpoint MUST authenticate 279 the EST server before it accepts the DNS server certificate. The 280 endpoint either uses password-based authenticated key exchange 281 (PAKE) with TLS 1.3 [I-D.barnes-tls-pake] as an authentication 282 method or uses the mutual authentication protocol for HTTP 283 [RFC8120] to authenticate the discovered EST server. 285 As a reminder, PAKE is an authentication method that allows the 286 use of usernames and passwords over unencrypted channels without 287 revealing the passwords to an eavesdropper. Similarly, the 288 mutual authentication for HTTP is based on PAKE and provides 289 mutual authentication between an HTTP client and an HTTP server 290 using username and password as credentials. The cryptographic 291 algorithms to use with the mutual authentication protocol for 292 HTTP are defined in [RFC8121]. 294 3. The endpoint needs to use PAKE scheme to perform authentication 295 the first time it connects to an EST server. If the EST server 296 authentication is successful, the server's identity can be used 297 to authenticate subsequent TLS connections to that EST server. 298 The endpoint configures the reference identifier for the EST 299 server using the DNS-ID identifier type in the EST server 300 certificate. On subsequent connections to the EST server, the 301 endpoint MUST validate the EST server certificate using the 302 Implict Trust Anchor database (i.e, the EST server certificate 303 must pass PKIX certification path validation) and match the 304 reference identifier against the EST server's identity according 305 to the rules specified in Section 6.4 of [RFC6125]. 307 4. The endpoint learns the End-Entity certificates [RFC8295] from 308 the EST server. The certificate provisioned to the DNS server in 309 the local network will be treated as a End-Entity certificate. 310 As a reminder, the End-Entity certificates must be validated by 311 the endpoint using an authorized trust anchor (Section 3.2 of 312 [RFC8295]). The endpoint needs to identify the certificate 313 provisioned to the DNS server. The SRV-ID identifier type 314 [RFC6125] within subjectAltName entry MUST be used to identify 315 the DNS server certificate. 317 For example, DNS server certificate will include SRV-ID "_domain- 318 s.example.net" along with DNS-ID "example.net". The SRV service 319 label "domain-s" is defined in Section 6 of [RFC7858]. As a 320 reminder, the protocol component is not included in the SRV-ID 321 [RFC4985]. 323 5. The endpoint configures the authentication domain name (ADN) 324 (defined in [RFC8310]) for the DNS server from the DNS-ID 325 identifier type within subjectAltName entry in the DNS server 326 certificate. The DNS server certificate is associated with the 327 ADN to be matched with the certificate given by the DNS server in 328 (D)TLS. To some extent, this approach is similar to certificate 329 usage PKIX-EE(1) defined in [RFC7671]. 331 Figure 1 illustrates a sequence diagram for bootstrapping an endpoint 332 with the local network's DNS server certificate. 334 +----------+ +--------+ +--------+ 335 | Endpoint | | EST | | DNS | 336 | | | Server | | Server | 337 +----------+ +--------+ +--------+ 338 | DNS-SD query to discover the EST server | | 339 |-------------------------------------------------------->| 340 | | | 341 | optional: mDNS query to | | 342 | discover the EST server | | 343 |--------------------------------------------->| | 344 | | | 345 | Establish provisional TLS connection | | 346 |<-------------------------------------------->| | 347 | | | 348 | PAKE scheme to authenticate the EST server | | 349 |<-------------------------------------------->| | 350 | | | 351 [Generate reference identifier for the EST server | | 352 to compare with the EST server certificate | | 353 in subsequent TLS connections] | | 354 | | | 355 | Get EE certificates | | 356 |--------------------------------------------->| | 357 | | | 358 [Identify the DNS server certificate in EE | | 359 certificates to match with the certificate | | 360 by the DNS server in (D)TLS handshake] | | 361 | | 362 [Configure ADN and associate DNS server certificate] | | 363 | | | 365 Figure 1: Bootstrapping Endpoint Devices 367 5. Bootstrapping IoT Devices 369 The following steps explain the mechanism to automatically bootstrap 370 IoT devices with local network's CA certificates and DNS server 371 certificate: 373 o Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed 374 in [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 375 secure automated bootstrap of devices. BRSKI specifies means to 376 provision credentials on devices to be used to operationally 377 access networks. In addition, BRSKI provides an automated 378 mechanism for the bootstrap distribution of CA certificates from 379 the EST server. The IoT device can use BRSKI to automatically 380 bootstrap the IoT device using the IoT manufacturer provisioned 381 X.509 certificate, in combination with a registrar provided by the 382 local network and IoT device manufacturer's authorizing service 383 (MASA): 385 1. The IoT device authenticates to the local network using the 386 IoT manufacturer provisioned X.509 certificate. The IoT 387 device can request and get a voucher from the MASA service via 388 the registrar. The voucher is signed by the MASA service and 389 includes the local network's CA public key. 391 2. The IoT device validates the signed voucher using the 392 manufacturer installed trust anchor associated with the MASA, 393 stores the CA's public key and validates the provisional TLS 394 connection to the registrar. 396 3. The IoT device requests the full EST distribution of current 397 CA certificates (Section 5.9.1 in 398 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 399 operating as a BRSKI-EST server. The IoT devices stores the 400 CA certificates as Explicit Trust Anchor database entries. 401 The IoT device uses the Explicit Trust Anchor database to 402 validate the DNS server certificate. 404 4. The IoT device learns the End-Entity certificates from the 405 BRSKI-EST server. The certificate provisioned to the DNS 406 server in the local network will be treated as an End-Entity 407 certificate. The IoT device needs to identify the certificate 408 provisioned to the DNS server. The SRV-ID identifier type 409 within subjectAltName entry MUST be used to identify the DNS 410 server certificate. 412 5. The endpoint configures the ADN for the DNS server from the 413 DNS-ID identifier type within subjectAltName entry in the DNS 414 server certificate. The DNS server certificate is associated 415 with the ADN to be matched with the certificate given by the 416 DNS server in (D)TLS. 418 6. DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure 420 A DNS client discovers the DNS server in the local network supporting 421 DNS-over-TLS, DNS-over-DTLS and DNS-over-HTTPS protocols by using 422 DNS-based Service Discovery (DNS-SD) [RFC6763]. DNS-SD provides 423 generic solution for discovering services available in a local 424 network. DNS-SD defines a set of naming rules for certain DNS record 425 types that they use for advertising and discovering services. 426 Section 4.1 of [RFC6763] specifies that a service instance name in 427 DNS-SD has the following structure: 429 . . 430 The portion specifies the authentication domain name. The 431 portion of the DNS service instance name MUST be 432 "_dprive._udp" or "_dprive._tcp" or "_doh._tcp". If no DNS-SD 433 records can be retrieved, the discovery procedure fails for this 434 authentication domain name. However, before retrying a lookup that 435 has failed, a DNS client MUST wait a time period that is appropriate 436 for the encountered error (e.g., NXDOMAIN, timeout, etc.). If no 437 DNS-SD records can be retrieved, the client can try connecting to the 438 pre-configured public DNS servers. If the endpoint has enabled 439 strict privacy profile and access to the pre-configured public DNS 440 servers is blocked, the DNS service won't be available to the 441 endpoint and ultimately the endpoint cannot access Internet-reachable 442 services. If the endpoint has enabled opportunistic privacy profile 443 and access to the pre-configured public DNS servers is blocked, the 444 endpoint will either fallback to an encrypted connection without 445 authenticating the DNS server provided by the local network or 446 fallback to clear text DNS. 448 If DNS-over-HTTPS protocol is supported by the DNS server, the DNS 449 client can query for the URI resource record type [RFC7553] to use 450 the https URI scheme (Section 3 of [RFC8484]). 452 7. Connection Handshake and Service Invocation 454 The DNS client initiates (D)TLS handshake with the DNS server, the 455 DNS server presents its certificate in ServerHello message, and the 456 DNS client MUST match the DNS server certificate downloaded in Step 4 457 in Section 4 or Section 5 with the certificate provided by the DNS 458 server in (D)TLS handshake. If the match is successful, the DNS 459 client MUST validate the server certificate using the Implicit Trust 460 Anchor database (i.e., the DNS server certificate must pass PKIX 461 certification path validation). 463 If the match is successful and server certificate is successfully 464 validated, the client continues with the connection as normal. 465 Otherwise, the client MUST treat the server certificate validation 466 failure as a non-recoverable error. If the DNS client cannot reach 467 or establish an authenticated and encrypted connection with the 468 privacy-enabling DNS server provided by the local network, the DNS 469 client can fallback to the privacy-enabling public DNS server. 471 8. EST Service Discovery Procedure 473 A EST client discovers the EST server in the local network by using 474 DNS-based Service Discovery (DNS-SD) [RFC6763] or Multicast DNS 475 (mDNS) [RFC6762]. The portion specifies the DNS sub-domain 476 where the service instance is registered. It may be "local.", 477 indicating the mDNS local domain, or it may be a conventional domain 478 name such as "example.com.". The portion of the EST 479 service instance name MUST be "_est._tcp". 481 8.1. mDNS 483 A EST client application can proactively discover an EST server being 484 advertised in the site by multicasting a PTR query to the following: 486 o "_est._tcp.local" 488 A EST server can send out gratuitous multicast DNS answer packets 489 whenever it starts up, wakes from sleep, or detects a change in EST 490 server configuration. EST client application can receive these 491 gratuitous packets and cache information contained in them. 493 9. Network Reattachment 495 On subsequent attachments to the network, the endpoint discovers the 496 privacy-enabling DNS server using the authentication domain name 497 (configured in Step 5 of Section 4 or Section 5), initiates (D)TLS 498 handshake with the DNS server and follows the mechanism discussed in 499 Section 7 to validate the DNS server certificate. 501 If the DNS server certificate is invalid (e.g., revoked or expired) 502 or the procedure to discover the privacy-enabling DNS server fails 503 (e.g. the domain name of the privacy-enabling DNS server has changed 504 because the Enterprise network has switched to a public privacy- 505 enabling DNS server capable of blocking access to malicious domains), 506 the endpoint discovers and initiates TLS handshake with the EST 507 server, and uses the validation techniques described in [RFC6125] to 508 compare the reference identifier (created in Step 2 of Section 4 in 509 this document) to the EST server certificate and verifies the entire 510 certification path as per [RFC5280]. The endpoint then gets the DNS 511 server certificate from the EST server. If the DNS-ID identifier 512 type within subjectAltName entry in the DNS server certificate does 513 not match the configured ADN, the ADN is replaced with the DNS-ID 514 identifier type. The DNS server certificate associated with the ADN 515 is replaced with the one provided by the EST server. If the ADN has 516 changed, the endpoint discovers the privacy-enabling DNS server, 517 initiates (D)TLS handshake with the DNS server and follows the 518 mechanism discussed in Section 7 to validate the DNS server 519 certificate. 521 Figure 2 illustrates a sequence diagram for re-configuring an 522 endpoint with ADN and local network's DNS server certificate on 523 subsequent attachments to the network. 525 +----------+ +--------+ +--------+ 526 | Endpoint | | EST | | DNS | 527 | | | Server | | Server | 528 +----------+ +--------+ +--------+ 529 | DNS-SD query to discover the EST server | | 530 |-------------------------------------------------------->| 531 | | | 532 | optional: mDNS query to | | 533 | discover the EST server | | 534 |--------------------------------------------->| | 535 | | | 536 | Establish TLS connection | | 537 | and validate EST server certificate | | 538 |<-------------------------------------------->| | 539 | | | 540 | Get EE certificates | | 541 |<-------------------------------------------->| | 542 | | | 543 [Identify the DNS server certificate in EE | | 544 certificates to match with the certificate | | 545 by the DNS server in (D)TLS handshake] | | 546 | | 547 [Re-configure ADN and associate DNS server certificate]| | 548 | | | 550 Figure 2: Bootstrapping Endpoint Devices on subsequent attachments to 551 the network 553 10. Privacy Considerations 555 [RFC7626] discusses DNS privacy considerations in both "on the wire" 556 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 557 [RFC7626] contexts. The mechanism defined in [I-D.reddy-dprive- 558 dprive-privacy-policy] can be used by the client to discover the 559 privacy policy information of the DNS server. 561 11. Security Considerations 563 The bootstrapping procedure to obtain the certificate of the local 564 networks DNS server uses a client identity and password to 565 authenticate the EST server using PAKE schemes. Security 566 considerations such as those discussed in [I-D.barnes-tls-pake] or 567 [RFC8120] and [RFC8121] need to be taken into consideration. 569 Users cannot be expected to enable or disable the bootstrapping or 570 the discovery procedure as they switch networks. Thus, it is 571 RECOMMENDED that users indicate to their system in some way that they 572 desire bootstrapping to be performed when connecting to a specific 573 network, similar to the way users disable VPN connection in specific 574 network (e.g., Enterprise network) and enable VPN connection by 575 default in other networks. 577 If an endpoint has enabled strict privacy profile, and the network 578 security service blocks the traffic to the privacy-enabling public 579 DNS server, a hard failure occurs and the user is notified. The user 580 has a choice to switch to another network or if the user trusts the 581 network, the user can enable strict privacy profile with the DNS- 582 over-(D)TLS or DNS-over-HTTPS server discovered in the network 583 instead of downgrading to opportunistic privacy profile. 585 The primary attacks against the methods described in Section 6 are 586 the ones that would lead to impersonation of a DNS server and 587 spoofing the DNS response to indicate that the DNS server does not 588 support any privacy-enabling protocols. To protect against DNS- 589 vectored attacks, secured DNS (DNSSEC) can be used to ensure the 590 validity of the DNS records received. Impersonation of the DNS 591 server is prevented by validating the certificate presented by the 592 DNS server. If the EST server conveys the DNS server certificate, 593 but the DNS-SD lookup indicates that the DNS server does not support 594 any privacy-enabling protocols, the client can detect the DNS 595 response is spoofed. 597 Security considerations in [I-D.ietf-anima-bootstrapping-keyinfra] 598 need to be taken into consideration for IoT devices. 600 12. IANA Considerations 602 IANA is requested to allocate the SRV service name of "dprive" for 603 DNS-over-TLS or DNS-over-DTLS, and the service name of "doh" for DNS- 604 over-HTTPS. 606 IANA is requested to allocate the SRV service name of "est". 608 13. Acknowledgments 610 Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick 611 McManus, Bob Harold, Livingood Jason, Winfield Alister, Eliot Lear, 612 Stephane Bortzmeyer and Sara Dickinson for the discussion and 613 comments. 615 14. References 616 14.1. Normative References 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, 620 DOI 10.17487/RFC2119, March 1997, 621 . 623 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 624 Subject Alternative Name for Expression of Service Name", 625 RFC 4985, DOI 10.17487/RFC4985, August 2007, 626 . 628 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 629 Housley, R., and W. Polk, "Internet X.509 Public Key 630 Infrastructure Certificate and Certificate Revocation List 631 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 632 . 634 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 635 Verification of Domain-Based Application Service Identity 636 within Internet Public Key Infrastructure Using X.509 637 (PKIX) Certificates in the Context of Transport Layer 638 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 639 2011, . 641 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 642 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 643 January 2012, . 645 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 646 DOI 10.17487/RFC6762, February 2013, 647 . 649 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 650 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 651 . 653 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 654 "Enrollment over Secure Transport", RFC 7030, 655 DOI 10.17487/RFC7030, October 2013, 656 . 658 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 659 Identifier (URI) DNS Resource Record", RFC 7553, 660 DOI 10.17487/RFC7553, June 2015, 661 . 663 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 664 and P. Hoffman, "Specification for DNS over Transport 665 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 666 2016, . 668 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 669 Transport Layer Security (DTLS)", RFC 8094, 670 DOI 10.17487/RFC8094, February 2017, 671 . 673 [RFC8121] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 674 T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: 675 Cryptographic Algorithms Based on the Key Agreement 676 Mechanism 3 (KAM3)", RFC 8121, DOI 10.17487/RFC8121, April 677 2017, . 679 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 680 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 681 May 2017, . 683 [RFC8295] Turner, S., "EST (Enrollment over Secure Transport) 684 Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, 685 . 687 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 688 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 689 . 691 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 692 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 693 . 695 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 696 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 697 January 2019, . 699 14.2. Informative References 701 [CDN] "End-User Mapping: Next Generation Request Routing for 702 Content Delivery", 2015, 703 . 706 [Dragonblood] 707 The Unicode Consortium, "Dragonblood: Analyzing the 708 Dragonfly Handshake of WPA3 and EAP-pwd", 709 . 711 [Evil-Twin] 712 The Unicode Consortium, "Evil twin (wireless networks)", 713 . 716 [I-D.barnes-tls-pake] 717 Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", 718 draft-barnes-tls-pake-04 (work in progress), July 2018. 720 [I-D.ietf-anima-bootstrapping-keyinfra] 721 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 722 and K. Watsen, "Bootstrapping Remote Secure Key 723 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 724 keyinfra-34 (work in progress), January 2020. 726 [Krack] The Unicode Consortium, "Key Reinstallation Attacks", 727 2017, . 729 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 730 DOI 10.17487/RFC2775, February 2000, 731 . 733 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 734 DOI 10.17487/RFC7626, August 2015, 735 . 737 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 738 Authentication of Named Entities (DANE) Protocol: Updates 739 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 740 October 2015, . 742 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 743 Kumari, "Client Subnet in DNS Queries", RFC 7871, 744 DOI 10.17487/RFC7871, May 2016, 745 . 747 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 748 "IPv6 Router Advertisement Options for DNS Configuration", 749 RFC 8106, DOI 10.17487/RFC8106, March 2017, 750 . 752 [RFC8120] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 753 T., and Y. Ioku, "Mutual Authentication Protocol for 754 HTTP", RFC 8120, DOI 10.17487/RFC8120, April 2017, 755 . 757 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 758 for DNS over TLS and DNS over DTLS", RFC 8310, 759 DOI 10.17487/RFC8310, March 2018, 760 . 762 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 763 Description Specification", RFC 8520, 764 DOI 10.17487/RFC8520, March 2019, 765 . 767 Authors' Addresses 769 Tirumaleswar Reddy 770 McAfee, Inc. 771 Embassy Golf Link Business Park 772 Bangalore, Karnataka 560071 773 India 775 Email: kondtir@gmail.com 777 Dan Wing 778 Citrix Systems, Inc. 779 USA 781 Email: dwing-ietf@fuggles.com 783 Michael C. Richardson 784 Sandelman Software Works 785 USA 787 Email: mcr+ietf@sandelman.ca 789 Mohamed Boucadair 790 Orange 791 Rennes 35000 792 France 794 Email: mohamed.boucadair@orange.com