idnits 2.17.1 draft-reddy-dprive-bootstrap-dns-server-04.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 (June 14, 2019) is 1770 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) -- Looks like a reference, but probably isn't: '0' on line 675 -- Looks like a reference, but probably isn't: '1' on line 673 -- Looks like a reference, but probably isn't: '2' on line 658 -- Looks like a reference, but probably isn't: '3' on line 659 -- Looks like a reference, but probably isn't: '4' on line 660 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** 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 (-05) exists of draft-camwinget-tls-use-cases-04 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-21 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: December 16, 2019 Citrix 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 June 14, 2019 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-04 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 December 16, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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 . . . . . . . . . . . . . . . 5 61 5. Bootstrapping IoT Devices . . . . . . . . . . . . . . . . . . 7 62 6. DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure 8 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 10.1. Privacy Extension Format . . . . . . . . . . . . . . . . 12 69 10.2. Privacy Extension Syntax . . . . . . . . . . . . . . . . 14 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 12.1. Application Service & Application Protocol Tags . . . . 16 73 12.1.1. DNS Application Service Tag Registration . . . . . . 17 74 12.1.2. dns.tls Application Protocol Tag Registration . . . 17 75 12.1.3. dns.dtls Application Protocol Tag Registration . . . 17 76 12.1.4. dns.https Application Protocol Tag Registration . . 17 77 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 78 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 80 14.2. Informative References . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 Traditionally a caching DNS server has been provided by local 86 networks. This provides benefits such as low latency to reach that 87 DNS server (owing to its network proximity to the endpoint). 88 However, if an endpoint is configured to use Internet-hosted or 89 public DNS-over-(D)TLS [RFC7858] [RFC8094] or DNS-over-HTTPS 90 [RFC8484] servers, any available local DNS server cannot serve DNS 91 requests from local endpoints. If public DNS servers are used 92 instead of using local DNS servers, some operational problems can 93 occur such as those listed below: 95 o "Split DNS" [RFC2775] to use the special internal-only domain 96 names (e.g., "internal.example.com") in enterprise networks will 97 not work, and ".local" and "home.arpa" names cannot be locally 98 resolved in home networks. 100 o Content Delivery Networks (CDNs) that map traffic based on DNS may 101 lose the ability to direct end-user traffic to a nearby service- 102 specific cluster in cases where a DNS service is being used that 103 is not affiliated with the local network and which does not send 104 "EDNS Client Subnet" (ECS) information [RFC7871] to the CDN's DNS 105 authorities [CDN]. 107 If public DNS servers are used instead of using local DNS servers, 108 the following discusses the impact on network-based security: 110 o Various network security services are provided by Enterprise 111 networks to protect endpoints (e.g,. Hosts, IoT devices). 112 [I-D.camwinget-tls-use-cases] discusses some of the network-based 113 security service use cases. These network security services act 114 on DNS requests originating from endpoints. 116 o However, if an endpoint is configured to use public DNS- 117 over-(D)TLS or DNS-over-HTTPS servers, network security services 118 cannot act efficiently on DNS requests from these endpoints. 120 o In order to act on DNS requests from endpoints, network security 121 services can block DNS-over-(D)TLS traffic by dropping outgoing 122 packets to destination port 853. Identifying DNS-over-HTTPS 123 traffic is far more challenging than DNS-over-(D)TLS traffic. 124 Network security services may try to identify the domains offering 125 DNS-over-HTTPS servers, and DNS-over-HTTPS traffic can be blocked 126 by dropping outgoing packets to these domains. If an endpoint has 127 enabled strict privacy profile (Section 5 of [RFC8310]), and the 128 network security service blocks the traffic to the public DNS 129 server, the DNS service won't be available to the endpoint and 130 ultimately the endpoint cannot access Internet-reachable services. 132 o If an endpoint has enabled opportunistic privacy profile 133 (Section 5 of [RFC8310]), and the network security service blocks 134 traffic to the public DNS server, the endpoint will either 135 fallback to an encrypted connection without authenticating the DNS 136 server provided by the local network or fallback to clear text 137 DNS, and cannot exchange encrypted DNS messages. 139 If the network security service fails to block DNS-over-(D)TLS or 140 DNS-over-HTTPS traffic, this can compromise the endpoint security; 141 some of the potential security threats are listed below: 143 o The network security service cannot prevent an endpoint from 144 accessing malicious domains. 146 o If the endpoint is an IoT device which is configured to use public 147 DNS-over-(D)TLS or DNS-over-HTTPS servers, and if a policy 148 enforcement point in the local network is programmed using, for 149 example, a Manufacturer Usage Description (MUD) file [RFC8520] by 150 a MUD manager to only allow intented communications to and from 151 the IoT device, the policy enforcement point cannot enforce the 152 network Access Control List (ACL) rules based on domain names 153 (Section 8 of [RFC8520]). 155 If the network security service successfully blocks DNS-over-(D)TLS 156 and DNS-over-HTTPS traffic, this can still compromise the endpoint 157 security and privacy; some of the potential security threats are 158 listed below: 160 o Pervasive monitoring of DNS traffic. 162 o An internal attacker can modify the DNS responses to re-direct the 163 client to malicious servers. 165 To overcome the above threats, this document specifies a mechanism to 166 automatically bootstrap endpoints to discover and authenticate the 167 DNS-over-(D)TLS and DNS-over-HTTPS servers provided by their local 168 network. The overall procedure can be structured into the following 169 steps: 171 o Bootstrapping (Section 4) is necessary only when connecting to a 172 new network or when the network's DNS certificate has changed. 173 Bootstrapping authenticates the Enrollment over Secure Transport 174 (EST) [RFC7030] server to the endpoint. After authenticating the 175 EST server, DNS server certificate used by the local network is 176 downloaded to the endpoint. This DNS server certificate enables 177 subsequent authenticated encrypted communication with the local 178 DNS server (e.g., DNS-over-HTTPS) during in the connection phase. 180 o Discovery (Section 6) is performed by a previously bootstrapped 181 endpoint whenever connecting to a network. During discovery, the 182 endpoint is instructed which privacy-enabling DNS protocol(s), 183 port number(s), and IP addresses are supported on a local network. 184 This effectively takes the place of DNS server IP address 185 traditionally provided by IPv4 or IPv6 DHCP or by IPv6 Router 186 Advertisement [RFC8106]. 188 o Connection handshake and service invocation (Section 7): The DNS 189 client initiates a (D)TLS handshake with the DNS server learned in 190 the discovery phase, and validates the DNS server's identity using 191 the credentials obtained in the bootstrapping phase. 193 Note: The strict and opportunistic privacy profiles as defined in 194 [RFC8310] only applies to DNS-over-(D)TLS protocols, there has been 195 no such distinction made for DNS-over-HTTPS protocol. 197 2. Scope 199 The problems discussed in Section 1 will be encountered in Enterprise 200 networks. Typically Enterprise networks do not assume that all 201 devices in their network are managed by the IT team or Mobile Device 202 Management (MDM) devices, especially in the quite common BYOD ("Bring 203 Your Own Device") scenario. The mechanisms specified in this 204 document can be used by BYOD devices to discover and authenticate 205 DNS-over-(D)TLS and DNS-over-HTTPS servers provided by the Enterprise 206 network. This mechanism can also be used by IoT devices (managed by 207 IT team) after onboarding to discover and authenticate DNS- 208 over-(D)TLS and DNS-over-HTTPS servers provided by the Enterprise 209 network. 211 3. Terminology 213 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 214 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 215 "OPTIONAL" in this document are to be interpreted as described in BCP 216 14 [RFC2119][RFC8174] when, and only when, they appear in all 217 capitals, as shown here. 219 (D)TLS is used for statements that apply to both Transport Layer 220 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 221 Specific terms are used for any statement that applies to either 222 protocol alone. 224 This document uses the terms defined in [RFC8499]. 226 4. Bootstrapping Endpoint Devices 228 The following steps detail the mechanism to automatically bootstrap 229 an endpoint with the local network's DNS server certificate: 231 1. The endpoint authenticates to the local network and discovers the 232 Enrollment over Secure Transport (EST) [RFC7030] server using the 233 procedure discussed in Section 8. 235 2. The endpoint establishes provisional TLS connection with that EST 236 server, i.e., the endpoint provisionally accepts the unverified 237 TLS server certificate. However, the endpoint MUST authenticate 238 the EST server before it accepts the DNS server certificate. The 239 endpoint either uses password-based authenticated key exchange 240 (PAKE) with TLS 1.3 [I-D.barnes-tls-pake] as an authentication 241 method or uses the mutual authentication protocol for HTTP 242 [RFC8120] to authenticate the discovered EST server. 244 As a reminder, PAKE is an authentication method that allows the 245 use of usernames and passwords over unencrypted channels without 246 revealing the passwords to an eavesdropper. Similarly, the 247 mutual authentication for HTTP is based on PAKE and provides 248 mutual authentication between an HTTP client and an HTTP server 249 using username and password as credentials. The cryptographic 250 algorithms to use with the mutual authentication protocol for 251 HTTP are defined in [RFC8121]. 253 3. The endpoint needs to use PAKE scheme to perform authentication 254 the first time it connects to an EST server. If the EST server 255 authentication is successful, the server's identity can be used 256 to authenticate subsequent TLS connections to that EST server. 257 The endpoint configures the reference identifier for the EST 258 server using the DNS-ID identifier type in the EST server 259 certificate. On subsequent connections to the EST server, the 260 endpoint MUST validate the EST server certificate using the 261 Implict Trust Anchor database (i.e, the EST server certificate 262 must pass PKIX certification path validation) and match the 263 reference identifier against the EST server's identity according 264 to the rules specified in Section 6.4 of [RFC6125]. 266 4. The endpoint learns the End-Entity certificates [RFC8295] from 267 the EST server. The certificate provisioned to the DNS server in 268 the local network will be treated as a End-Entity certificate. 269 As a reminder, the End-Entity certificates must be validated by 270 the endpoint using an authorized trust anchor (Section 3.2 of 271 [RFC8295]). The endpoint needs to identify the certificate 272 provisioned to the DNS server. The SRV-ID identifier type 273 [RFC6125] within subjectAltName entry MUST be used to identify 274 the DNS server certificate. 276 For example, DNS server certificate will include SRV-ID "_domain- 277 s.example.net" along with DNS-ID "example.net". The SRV service 278 label "domain-s" is defined in Section 6 of [RFC7858]. As a 279 reminder, the protocol component is not included in the SRV-ID 280 [RFC4985]. 282 5. The endpoint configures the authentication domain name (ADN) 283 (defined in [RFC8310]) for the DNS server from the DNS-ID 284 identifier type within subjectAltName entry in the DNS server 285 certificate. The DNS server certificate is associated with the 286 ADN to be matched with the certificate given by the DNS server in 287 (D)TLS. To some extent, this approach is similar to certificate 288 usage PKIX-EE(1) defined in [RFC7671]. 290 Figure 1 illustrates a sequence diagram for bootstrapping an endpoint 291 with the local network's DNS server certificate. 293 +----------+ +--------+ +--------+ 294 | Endpoint | | EST | | DNS | 295 | | | Server | | Server | 296 +----------+ +--------+ +--------+ 297 | DNS-SD query to discover the EST server | | 298 |-------------------------------------------------------->| 299 | | | 300 | optional: mDNS query to | | 301 | discover the EST server | | 302 |--------------------------------------------->| | 303 | | | 304 | Establish provisional TLS connection | | 305 |<-------------------------------------------->| | 306 | | | 307 | PAKE scheme to authenticate the EST server | | 308 |<-------------------------------------------->| | 309 | | | 310 [Generate reference identifier for the EST server | | 311 to compare with the EST server certificate | | 312 in subsequent TLS connections] | | 313 | | | 314 | Get EE certificates | | 315 |--------------------------------------------->| | 316 | | | 317 [Identify the DNS server certificate in EE | | 318 certificates to match with the certificate | | 319 by the DNS server in (D)TLS handshake] | | 320 | | 321 [Configure ADN and associate DNS server certificate] | | 322 | | | 324 Figure 1: Bootstrapping Endpoint Devices 326 5. Bootstrapping IoT Devices 328 The following steps explain the mechanism to automatically bootstrap 329 IoT devices with local network's CA certificates and DNS server 330 certificate: 332 o Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed 333 in [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 334 secure automated bootstrap of devices. BRSKI specifies means to 335 provision credentials on devices to be used to operationally 336 access networks. In addition, BRSKI provides an automated 337 mechanism for the bootstrap distribution of CA certificates from 338 the EST server. The IoT device can use BRSKI to automatically 339 bootstrap the IoT device using the IoT manufacturer provisioned 340 X.509 certificate, in combination with a registrar provided by the 341 local network and IoT device manufacturer's authorizing service 342 (MASA): 344 1. The IoT device authenticates to the local network using the 345 IoT manufacturer provisioned X.509 certificate. The IoT 346 device can request and get a voucher from the MASA service via 347 the registrar. The voucher is signed by the MASA service and 348 includes the local network's CA public key. 350 2. The IoT device validates the signed voucher using the 351 manufacturer installed trust anchor associated with the MASA, 352 stores the CA's public key and validates the provisional TLS 353 connection to the registrar. 355 3. The IoT device requests the full EST distribution of current 356 CA certificates (Section 5.9.1 in 357 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 358 operating as a BRSKI-EST server. The IoT devices stores the 359 CA certificates as Explicit Trust Anchor database entries. 360 The IoT device uses the Explicit Trust Anchor database to 361 validate the DNS server certificate. 363 4. The IoT device learns the End-Entity certificates from the 364 BRSKI-EST server. The certificate provisioned to the DNS 365 server in the local network will be treated as an End-Entity 366 certificate. The IoT device needs to identify the certificate 367 provisioned to the DNS server. The SRV-ID identifier type 368 within subjectAltName entry MUST be used to identify the DNS 369 server certificate. 371 5. The endpoint configures the ADN for the DNS server from the 372 DNS-ID identifier type within subjectAltName entry in the DNS 373 server certificate. The DNS server certificate is associated 374 with the ADN to be matched with the certificate given by the 375 DNS server in (D)TLS. 377 6. DNS-over-(D)TLS and DNS-over-HTTPS Server Discovery Procedure 379 This specification defines "DPRIVE" as the application service tag 380 (Section 12.1.1) and "dns.tls" (Section 12.1.2), "dns.dtls" 381 (Section 12.1.3), and "dns.https" (Section 12.1.4) as application 382 protocol tags. A DNS client discovers the DNS server in the local 383 network supporting DNS-over-TLS, DNS-over-DTLS and DNS-over-HTTPS 384 protocols by using the following discovery mechanism: 386 o The DNS client makes an S-NAPTR [RFC3958] lookup with the 387 authentication domain name and the 'DPRIVE' application service 388 tag to learn the protocols DNS-over-TLS, DNS-over-DTLS, and DNS- 389 over-HTTPS supported by the DNS server and the DNS privacy 390 protocol preferred by the DNS server administrators. The S-NAPTR 391 lookup is performed using an recursive DNS resolver discovered 392 from an untrusted source (such as DHCP). 394 o In the example depicted in Figure 2, for authentication domain 395 name 'example.net', the resolution algorithm will result in the 396 privacy-enabling protocols supported by the DNS server and usable 397 DNS server IP addresses and port numbers. 399 example.net. 400 IN NAPTR 100 10 "" DPRIVE:dns.tls "" dns1.example.net. 401 IN NAPTR 200 10 "" DPRIVE:dns.dtls "" dns2.example.net. 403 dns1.example.net. 404 IN NAPTR 100 10 S DPRIVE:dns.tls "" _domain-s._tcp.example.net. 406 dns2.example.net. 407 IN NAPTR 100 10 S DPRIVE:dns.dtls "" _domain-s._udp.example.net. 409 _domain-s._tcp.example.net. 410 IN SRV 0 0 853 a.example.net. 412 _domain-s._udp.example.net. 413 IN SRV 0 0 853 a.example.net. 415 a.example.net. 416 IN A 192.0.2.1 417 IN AAAA 2001:db8:8:4::2 419 Figure 2 421 o If DNS-over-HTTPS protocol is supported by the DNS server, the DNS 422 client finds the URI template of the DNS-over-HTTPS server using 423 one of the mechanisms discussed in 424 [I-D.ietf-doh-resolver-associated-doh] to use the https URI scheme 425 (Section 3 of [RFC8484]). 427 o If no DNS-specific S-NAPTR records can be retrieved, the discovery 428 procedure fails for this authentication domain name. However, 429 before retrying a lookup that has failed, a DNS client MUST wait a 430 time period that is appropriate for the encountered error (e.g., 431 NXDOMAIN, timeout, etc.). 433 7. Connection Handshake and Service Invocation 435 The DNS client initiates (D)TLS handshake with the DNS server, the 436 DNS server presents its certificate in ServerHello message, and the 437 DNS client MUST match the DNS server certificate downloaded in Step 4 438 in Section 4 or Section 5 with the certificate provided by the DNS 439 server in (D)TLS handshake. If the match is successful, the DNS 440 client MUST validate the server certificate using the Implicit Trust 441 Anchor database (i.e., the DNS server certificate must pass PKIX 442 certification path validation). 444 If the match is successful and server certificate is successfully 445 validated, the client continues with the connection as normal. 446 Otherwise, the client MUST treat the server certificate validation 447 failure as a non-recoverable error. If the DNS client cannot reach 448 or establish an authenticated and encrypted connection with the 449 privacy-enabling DNS server provided by the local network, the DNS 450 client can fallback to the privacy-enabling public DNS server. 452 8. EST Service Discovery Procedure 454 DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS 455 (mDNS) [RFC6762] provide generic solutions for discovering services 456 available in a local network. DNS-SD/mDNS define a set of naming 457 rules for certain DNS record types that they use for advertising and 458 discovering services. 460 Section 4.1 of [RFC6763] specifies that a service instance name in 461 DNS-SD has the following structure: 463 . . 465 The portion specifies the DNS sub-domain where the service 466 instance is registered. It may be "local.", indicating the mDNS 467 local domain, or it may be a conventional domain name such as 468 "example.com.". The portion of the EST service instance 469 name MUST be "_est._tcp". 471 8.1. mDNS 473 A EST client application can proactively discover an EST server being 474 advertised in the site by multicasting a PTR query to the following: 476 o "_est._tcp.local" 478 A EST server can send out gratuitous multicast DNS answer packets 479 whenever it starts up, wakes from sleep, or detects a change in EST 480 server configuration. EST client application can receive these 481 gratuitous packets and cache information contained in them. 483 9. Network Reattachment 485 On subsequent attachments to the network, the endpoint discovers the 486 privacy-enabling DNS server using the authentication domain name 487 (configured in Step 5 of Section 4 or Section 5), initiates (D)TLS 488 handshake with the DNS server and follows the mechanism discussed in 489 Section 7 to validate the DNS server certificate. 491 If the DNS server certificate is invalid (e.g., revoked or expired) 492 or the procedure to discover the privacy-enabling DNS server fails 493 (e.g. the domain name of the privacy-enabling DNS server has changed 494 because the Enterprise network has switched to a public privacy- 495 enabling DNS server capable of blocking access to malicious domains), 496 the endpoint discovers and initiates TLS handshake with the EST 497 server, and uses the validation techniques described in [RFC6125] to 498 compare the reference identifier (created in Step 2 of Section 4 in 499 this document) to the EST server certificate and verifies the entire 500 certification path as per [RFC5280]. The endpoint then gets the DNS 501 server certificate from the EST server. If the DNS-ID identifier 502 type within subjectAltName entry in the DNS server certificate does 503 not match the configured ADN, the ADN is replaced with the DNS-ID 504 identifier type. The DNS server certificate associated with the ADN 505 is replaced with the one provided by the EST server. If the ADN has 506 changed, the endpoint discovers the privacy-enabling DNS server, 507 initiates (D)TLS handshake with the DNS server and follows the 508 mechanism discussed in Section 7 to validate the DNS server 509 certificate. 511 Figure 3 illustrates a sequence diagram for re-configuring an 512 endpoint with ADN and local network's DNS server certificate on 513 subsequent attachments to the network. 515 +----------+ +--------+ +--------+ 516 | Endpoint | | EST | | DNS | 517 | | | Server | | Server | 518 +----------+ +--------+ +--------+ 519 | DNS-SD query to discover the EST server | | 520 |-------------------------------------------------------->| 521 | | | 522 | optional: mDNS query to | | 523 | discover the EST server | | 524 |--------------------------------------------->| | 525 | | | 526 | Establish TLS connection | | 527 | and validate EST server certificate | | 528 |<-------------------------------------------->| | 529 | | | 530 | Get EE certificates | | 531 |<-------------------------------------------->| | 532 | | | 533 [Identify the DNS server certificate in EE | | 534 certificates to match with the certificate | | 535 by the DNS server in (D)TLS handshake] | | 536 | | 537 [Re-configure ADN and associate DNS server certificate]| | 538 | | | 540 Figure 3: Bootstrapping Endpoint Devices on subsequent attachments to 541 the network 543 10. Privacy Considerations 545 [RFC7626] discusses DNS privacy considerations in both "on the wire" 546 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 547 [RFC7626] contexts. The endpoint may not know if the DNS-over-(D)TLS 548 or DNS-over-HTTPS server in the local network has a privacy 549 preserving data policy. A new privacy certificate extension is 550 defined that identifies the privacy preserving data policy of the DNS 551 server. 553 10.1. Privacy Extension Format 555 Like all X.509 certificate extensions, the privacy certificate 556 extension is defined using ASN.1 [ASN1-88]. The non-critical privacy 557 extension is identified by id-pe-privacy. 559 PKIX Object Identifier Registry 561 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 562 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 564 PKIX Arcs 565 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } -- modules 566 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } -- private 567 certificate extensions 569 PKIX modules 570 id-mod-privacy-extn OBJECT IDENTIFIER ::= { id-mod TBD2 } 571 id-pe-privacy OBJECT IDENTIFIER ::= { id-pe TBD1 } 573 A non-null privacy always includes a base privacy. The privacy 574 extension includes the following information: 576 o If the client IP address is Personally Identifiable Information 577 (PII) data or non PII-data. 579 o If the user identity that sent the DNS query is logged or not, and 580 if user identity address is indeed logged, the period for which 581 the user identity is logged. User identity such as username, IP 582 address, MAC address or personally identifiable data. Logging 583 duration is represented in hours. A negative one (-1) of logging 584 duration indicates indefinite duration. 586 o If the transaction data (e.g., DNS messages) is logged or not, and 587 if transaction data is logged, the period for which the 588 transaction data is stored. 590 o If the transaction data is logged to notify the user access to 591 certain domains (e.g., malicious domains) is blocked, the period 592 for which the transaction data is stored. If access to malicious 593 domains is logged, the period for which the transaction data is 594 stored. If the transaction data is logged for analytics (e.g. to 595 detect malicious domains), the period for which the transaction 596 data is stored. 598 o If the transaction data is shared with partners or not, and if the 599 transaction data is shared with partners, the names of the 600 partners. If anonymized data or client identifiable data is 601 shared with partners. 603 o If the transaction data is shared or sold to third parties. 605 o If the DNS server will block DNS resolution of certain domains 606 (e.g., malicious domains). 608 o A URL that points to the privacy preserving data policy, and a URL 609 that points to the security assessment report of the DNS server by 610 a third party auditor. 612 10.2. Privacy Extension Syntax 614 The syntax for the privacy extension is as follows: 616 Privacy ::= CHOICE { 617 none NULL, 618 -- No privacy policy provided 619 pPolicy PrivacyPolicy 620 -- Privacy preserving data policy } 622 PrivacyPolicy ::= SEQUENCE { 623 base PrivacyInfo, 624 pURL [0] PrivacyURL OPTIONAL, 625 aURL [1] AuditURL OPTIONAL } 627 PrivacyInfo ::= SEQUENCE { 628 ipaddresspii BOOLEAN, 629 -- TRUE means client IP address is PII 630 log [0] Logging, 631 sdata [2] ShareData, 632 transferdata [3] BOOLEAN, 633 -- TRUE means share or sell data to third parties 634 blockdomains [4] BOOLEAN 635 -- TRUE means domains will be blocked } 637 LoggingTypes ::= BIT STRING { 638 none (0), 639 -- No logging 640 all (1), 641 -- Log all transaction data 642 useridentity (2), 643 -- Log user identity (e.g., username, IP address) 644 notifyuser (3), 645 -- Log to notify user access 646 -- to certain domains is blocked 647 knownmalware (4), 648 -- Log access to malicious domains 649 analytics (5) 650 -- Log transaction data for analytics 651 -- (e.g. to detect malicious domains) } 653 LoggingDuration ::= SEQUENCE { 654 all [0] INTEGER OPTIONAL, 655 -- Number of Hours the 656 -- transcation data is stored 657 useridentity [1] INTEGER OPTIONAL, 658 notifyuser [2] INTEGER OPTIONAL, 659 knownmalware [3] INTEGER OPTIONAL, 660 analytics [4] INTEGER OPTIONAL } 662 Logging ::= SEQUENCE { 663 loggingTypes LoggingTypes DEFAULT {none}, 664 loggingDuration LoggingDuration OPTIONAL 665 -- Transaction data is cleared 666 -- after logging duration, 667 -- Negative one (-1) indicates indefinite 668 -- duration } 670 ShareData ::= SEQUENCE { 671 sharepartners BOOLEAN, 672 -- TRUE means data is shared with partners 673 partners [1] SEQUENCE SIZE (1..MAX) OF UTF8String OPTIONAL, 674 -- Names of the partners 675 anonymizeddata [0] BOOLEAN OPTIONAL 676 -- TRUE means anonymized data 677 -- is shared with partners } 679 PrivacyURL ::= IA5String -- MUST use https scheme 680 AuditURL ::= IA5String -- MUST use https scheme 682 11. Security Considerations 684 The bootstrapping procedure to obtain the certificate of the local 685 networks DNS server uses a client identity and password to 686 authenticate the EST server using PAKE schemes. Security 687 considerations such as those discussed in [I-D.barnes-tls-pake] or 688 [RFC8120] and [RFC8121] need to be taken into consideration. 690 Users cannot be expected to enable or disable the bootstrapping or 691 the discovery procedure as they switch networks. Thus, it is 692 RECOMMENDED that users indicate to their system in some way that they 693 desire bootstrapping to be performed when connecting to a specific 694 network, similar to the way users disable VPN connection in specific 695 network (e.g., Enterprise network) and enable VPN connection by 696 default in other networks. 698 If an endpoint has enabled strict privacy profile, and the network 699 security service blocks the traffic to the privacy-enabling public 700 DNS server, a hard failure occurs and the user is notified. The user 701 has a choice to switch to another network or if the user trusts the 702 network, the user can enable strict privacy profile with the DNS- 703 over-(D)TLS or DNS-over-HTTPS server discovered in the network 704 instead of downgrading to opportunistic privacy profile. 706 The primary attacks against the methods described in Section 6 are 707 the ones that would lead to impersonation of a DNS server and 708 spoofing the DNS response to indicate that the DNS server does not 709 support any privacy-enabling protocols. To protect against DNS- 710 vectored attacks, secured DNS (DNSSEC) can be used to ensure the 711 validity of the DNS records received. Impersonation of the DNS 712 server is prevented by validating the certificate presented by the 713 DNS server. If the EST server conveys the DNS server certificate, 714 but the S-NAPTR lookup indicates that the DNS server does not support 715 any privacy-enabling protocols, the client can detect the DNS 716 response is spoofed. 718 Security considerations in [I-D.ietf-anima-bootstrapping-keyinfra] 719 need to be taken into consideration for IoT devices. 721 12. IANA Considerations 723 IANA is requested to allocate the SRV service name of "est". 725 IANA is requested to add the following entry in the "SMI Security for 726 PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry: 728 Decimal Description References 729 ------- ------------------------------ --------------------- 731 TBD1 id-pe-privacy this document 733 IANA is requested to add the following entry in the "SMI Security for 734 PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry: 736 Decimal Description References 737 ------- ------------------------------ --------------------- 739 TBD2 id-mod-privacy-extn this document 741 12.1. Application Service & Application Protocol Tags 743 This document requests IANA to make the following allocations from 744 the registry available at: https://www.iana.org/assignments/s-naptr- 745 parameters/s-naptr-parameters.xhtml. 747 12.1.1. DNS Application Service Tag Registration 749 o Application Protocol Tag: DPRIVE 751 o Intended Usage: See Section 6 753 o Security Considerations: See Section 11 755 o Contact Information: 757 12.1.2. dns.tls Application Protocol Tag Registration 759 o Application Protocol Tag: dns.tls 761 o Intended Usage: See Section 6 763 o Security Considerations: See Section 11 765 o Contact Information: 767 12.1.3. dns.dtls Application Protocol Tag Registration 769 o Application Protocol Tag: dns.dtls 771 o Intended Usage: See Section 6 773 o Security Considerations: See Section 11 775 o Contact Information: 777 12.1.4. dns.https Application Protocol Tag Registration 779 o Application Protocol Tag: dnshttps 781 o Intended Usage: See Section 6 783 o Security Considerations: See Section 11 785 o Contact Information: 787 13. Acknowledgments 789 Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick 790 McManus, Bob Harold, Livingood Jason, Winfield Alister, Eliot Lear 791 and Sara Dickinson for the discussion and comments. 793 14. References 795 14.1. Normative References 797 [I-D.ietf-doh-resolver-associated-doh] 798 Hoffman, P., "Associating a DoH Server with a Resolver", 799 draft-ietf-doh-resolver-associated-doh-03 (work in 800 progress), March 2019. 802 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 803 Requirement Levels", BCP 14, RFC 2119, 804 DOI 10.17487/RFC2119, March 1997, 805 . 807 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 808 Service Location Using SRV RRs and the Dynamic Delegation 809 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 810 January 2005, . 812 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 813 Subject Alternative Name for Expression of Service Name", 814 RFC 4985, DOI 10.17487/RFC4985, August 2007, 815 . 817 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 818 Housley, R., and W. Polk, "Internet X.509 Public Key 819 Infrastructure Certificate and Certificate Revocation List 820 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 821 . 823 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 824 Verification of Domain-Based Application Service Identity 825 within Internet Public Key Infrastructure Using X.509 826 (PKIX) Certificates in the Context of Transport Layer 827 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 828 2011, . 830 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 831 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 832 January 2012, . 834 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 835 DOI 10.17487/RFC6762, February 2013, 836 . 838 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 839 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 840 . 842 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 843 "Enrollment over Secure Transport", RFC 7030, 844 DOI 10.17487/RFC7030, October 2013, 845 . 847 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 848 and P. Hoffman, "Specification for DNS over Transport 849 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 850 2016, . 852 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 853 Transport Layer Security (DTLS)", RFC 8094, 854 DOI 10.17487/RFC8094, February 2017, 855 . 857 [RFC8121] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 858 T., and Y. Ioku, "Mutual Authentication Protocol for HTTP: 859 Cryptographic Algorithms Based on the Key Agreement 860 Mechanism 3 (KAM3)", RFC 8121, DOI 10.17487/RFC8121, April 861 2017, . 863 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 864 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 865 May 2017, . 867 [RFC8295] Turner, S., "EST (Enrollment over Secure Transport) 868 Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, 869 . 871 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 872 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 873 . 875 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 876 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 877 . 879 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 880 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 881 January 2019, . 883 14.2. Informative References 885 [ASN1-88] "International Telephone and Telegraph Consultative 886 Committee, "Specification of Abstract Syntax Notation One 887 (ASN.1)", CCITT Recommendation X.208, 1988.". 889 [CDN] "End-User Mapping: Next Generation Request Routing for 890 Content Delivery", 2015, 891 . 894 [I-D.barnes-tls-pake] 895 Barnes, R. and O. Friel, "Usage of PAKE with TLS 1.3", 896 draft-barnes-tls-pake-04 (work in progress), July 2018. 898 [I-D.camwinget-tls-use-cases] 899 Andreasen, F., Cam-Winget, N., and E. Wang, "TLS 1.3 900 Impact on Network-Based Security", draft-camwinget-tls- 901 use-cases-04 (work in progress), March 2019. 903 [I-D.ietf-anima-bootstrapping-keyinfra] 904 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 905 S., and K. Watsen, "Bootstrapping Remote Secure Key 906 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 907 keyinfra-21 (work in progress), June 2019. 909 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 910 DOI 10.17487/RFC2775, February 2000, 911 . 913 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 914 DOI 10.17487/RFC7626, August 2015, 915 . 917 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 918 Authentication of Named Entities (DANE) Protocol: Updates 919 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 920 October 2015, . 922 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 923 Kumari, "Client Subnet in DNS Queries", RFC 7871, 924 DOI 10.17487/RFC7871, May 2016, 925 . 927 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 928 "IPv6 Router Advertisement Options for DNS Configuration", 929 RFC 8106, DOI 10.17487/RFC8106, March 2017, 930 . 932 [RFC8120] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 933 T., and Y. Ioku, "Mutual Authentication Protocol for 934 HTTP", RFC 8120, DOI 10.17487/RFC8120, April 2017, 935 . 937 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 938 for DNS over TLS and DNS over DTLS", RFC 8310, 939 DOI 10.17487/RFC8310, March 2018, 940 . 942 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 943 Description Specification", RFC 8520, 944 DOI 10.17487/RFC8520, March 2019, 945 . 947 Authors' Addresses 949 Tirumaleswar Reddy 950 McAfee, Inc. 951 Embassy Golf Link Business Park 952 Bangalore, Karnataka 560071 953 India 955 Email: kondtir@gmail.com 957 Dan Wing 958 Citrix Systems, Inc. 959 USA 961 Email: dwing-ietf@fuggles.com 963 Michael C. Richardson 964 Sandelman Software Works 965 USA 967 Email: mcr+ietf@sandelman.ca 969 Mohamed Boucadair 970 Orange 971 Rennes 35000 972 France 974 Email: mohamed.boucadair@orange.com