idnits 2.17.1 draft-reddy-dprive-bootstrap-dns-server-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2019) is 1859 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 (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-19 ** Downref: Normative reference to an Informational RFC: RFC 5054 ** 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 8120 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-05) exists of draft-camwinget-tls-use-cases-04 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 7 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 27, 2019 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 March 26, 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-02 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 September 27, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Bootstrapping Endpoint Devices . . . . . . . . . . . . . . . 5 60 4. Bootstrapping IoT Devices and CPE . . . . . . . . . . . . . . 6 61 5. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Resolution . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Connection handshake and service invocation . . . . . . . . . 9 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 66 8.1. Privacy Extension Syntax . . . . . . . . . . . . . . . . 10 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. Application Service & Application Protocol Tags . . . . . 10 69 9.1.1. DNS Application Service Tag Registration . . . . . . 10 70 9.1.2. dns.tls Application Protocol Tag Registration . . . . 11 71 9.1.3. dns.dtls Application Protocol Tag Registration . . . 11 72 9.1.4. dns.https Application Protocol Tag Registration . . . 11 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 11.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 Traditionally a caching DNS server has been provided by the local 82 network. This provides benefits like low latency to that DNS server 83 (due to its network proximity to the endpoint). However, if an 84 endpoint is configured to use Internet-hosted or public DNS- 85 over-(D)TLS [RFC7858] [RFC8094] or DNS-over-HTTPS [RFC8484] servers, 86 the local DNS server cannot serve the DNS requests from the 87 endpoints. If public DNS servers are used instead of using local DNS 88 servers, the operational problems are listed below: 90 o "Split DNS" [RFC2775] to use the special internal-only domain 91 names (e.g., "internal.example.com") in enterprise networks will 92 not work, and ".local" and "home.arpa" names cannot be locally 93 resolved in home networks. 95 o Content Delivery Networks (CDNs) that map traffic based on DNS may 96 lose the ability to direct end-user traffic to a nearby cluster in 97 cases where a DNS service is being used that is not affiliated 98 with the local network and which does not send "EDNS Client 99 Subnet" (ECS) information [RFC7871] to the CDN's DNS authorities 100 [CDN]. 102 o Some clients have pre-configured specific public DNS servers (such 103 as Mozilla using Cloudflare's DNS-over-HTTPS server). If 104 endpoints continue to use pre-configured public DNS servers, this 105 has a risk of relying on few centralized DNS services. 107 If public DNS servers are used instead of using local DNS servers, 108 the following paragraph discusses the impact on Network-based 109 security: 111 Various network security services are provided by Enterprise, secure 112 home and wall-gardened networks to protect endpoints (e.g,. Hosts, 113 IoT devices). [I-D.camwinget-tls-use-cases] discusses some of the 114 Network-based security use cases. These network security services 115 act on DNS requests from endpoints. However, if an endpoint is 116 configured to use public DNS-over-(D)TLS or DNS-over-HTTPS servers, 117 network security services cannot act efficiently on DNS requests from 118 the endpoints. In order to act on DNS requests from endpoints, 119 network security services can block DNS-over-(D)TLS traffic by 120 dropping outgoing packets to destination port 853. Identifying DNS- 121 over-HTTPS traffic is far more challenging than DNS-over-(D)TLS 122 traffic. Network security services can try to identify the domains 123 offering DNS-over-HTTPS servers, and DNS-over-HTTPS traffic can be 124 blocked by dropping outgoing packets to these domains. If the 125 endpoint has enabled strict privacy profile (Section 5 of [RFC8310]), 126 and the network security service blocks the traffic to the public DNS 127 server, DNS service is not available to the endpoint and ultimately 128 the endpoint cannot access Internet. If the endpoint has enabled 129 opportunistic privacy profile (Section 5 of [RFC8310]), and the 130 network security service blocks traffic to the public DNS server, the 131 endpoint will either fallback to an encrypted connection without 132 authenticating the DNS server provided by the local network or 133 fallback to clear text DNS, and cannot exchange encrypted DNS 134 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 a 146 Manufacturer Usage Description (MUD) file [I-D.ietf-opsawg-mud] 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 rules based on domain names (Section 8 150 of [I-D.ietf-opsawg-mud]). 152 If the network security service sucessfully 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 incorrect and malicious servers. 162 To overcome the above threats, the document proposes a mechanism to 163 automatically bootstrap the endpoints to discover and authenticate 164 the DNS-over-(D)TLS and DNS-over-HTTPS servers provided by the local 165 network. The overall procedure can be structured into the following 166 steps: 168 o Bootstrapping phase (Section 3 and Section 4) is meant to 169 automatically bootstrap endpoints with local network's CA 170 certificates and DNS server certificate. 172 o Discovery phase (Section 5) is meant to discover the privacy- 173 enabling protocols supported by the DNS server and usable DNS 174 server IP addresses and port numbers. 176 o Connection handshake and service invocation: The DNS client 177 initiates (D)TLS handshake with the DNS server learned in the 178 discovery phase. Furthermore, DNS client uses the credentials 179 discovered during the bootstrapping phase to validate the server 180 certificate. 182 Note: The strict and opportunistic privacy profiles as defined in 183 [RFC8310] only applies to DNS-over-(D)TLS protocols, there has been 184 no such distinction made for DNS-over-HTTPS protocol. 186 2. Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119][RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 (D)TLS is used for statements that apply to both Transport Layer 195 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 196 Specific terms are used for any statement that applies to either 197 protocol alone. 199 This document uses the terms defined in [RFC8499]. 201 3. Bootstrapping Endpoint Devices 203 The following steps explain the mechanism to automatically bootstrap 204 an endpoint with the local network's CA certificates and DNS server 205 certificate: 207 1. The endpoint authenticates to the local network and discovers the 208 EST server using DNS-based Service Discovery [RFC6763]. 210 2. The endpoint establishes provisional TLS connection with the EST 211 server, i.e. the endpoint provisionally accepts the unverified 212 TLS server certificate. However, the endpoint MUST authenticate 213 the EST server before it can accept the CA certificates. The 214 endpoint either uses Secure Remote Password protocol (SRP) 215 [SRP-6] as an authentication method for the Transport Layer 216 Security protocol [RFC5054] or uses the mutual authentication 217 scheme discussed in [RFC8120] to authenticate the discovered EST 218 server. SRP is an authentication method that allows the use of 219 usernames and passwords over unencrypted channels without 220 revealing the password to an eavesdropper. Similarty, the mutual 221 authentication scheme is based on password-based authenticated 222 key exchange (PAKE) and provides mutual authentication between a 223 HTTP client and an HTTP server using username and password as 224 credentials. 226 3. If the EST server authentication is successful, the endpoint 227 requests the full EST distribution of current CA certificates and 228 validates the EST server certificate. If the EST server 229 certificate cannot be verified using the CA certificates 230 downloaded, the TLS connection is immediately discarded and the 231 endpoint abandons the attempt to bootstrap from the EST server 232 and discards the CA certificates conveyed by the EST server. If 233 the EST server certificate is verified using the CA certificates 234 downloaded, the endpoint stores the CA certificates as Explicit 235 Trust Anchor database entries. The endpoint uses the Explicit 236 Trust Anchor database to validate the DNS server certificate. 237 The endpoint needs to perform SCRAM authentication the first time 238 it connects EST server. On subsequent connections to the EST 239 server, the endpoint can validate the EST server certificate 240 using the Explicit Trust Anchor database. 242 4. The endpoint learns the End-Entity certificates [RFC8295] from 243 the EST server. The certificate provisioned to the DNS server in 244 the local network will be treated as a End-Entity certificate. 245 The endpoint needs to identify the certificate provisioned to the 246 DNS server. The SRV-ID identifier type [RFC6125] within 247 subjectAltName entry can be used to identify the DNS server 248 certificate. For example, DNS server certificate will include 249 SRV-ID "_domain-s.example.net" along with DNS-ID "example.net". 250 This specification defines SRV service label "domain-s" in 251 Section 9. As a reminder, the protocol component is not included 252 in the SRV-ID [RFC4985]. 254 4. Bootstrapping IoT Devices and CPE 256 The following steps explain the mechanism to automatically bootstrap 257 IoT devices with local network's CA certificates and DNS server 258 certificate. The below steps can also be used by CPE acting as DNS 259 forwarder to discover and authenticate DNS-over-(D)TLS and DNS-over- 260 HTTPS servers provided by the access network. 262 o Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed 263 in [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 264 secure automated bootstrap of devices. BRSKI specifies means to 265 provision credentials on devices to be used to operationally 266 access networks. In addition, BRSKI provides an automated 267 mechanism for the bootstrap distribution of CA certificates from 268 the EST server. The IoT device can use BRSKI to automatically 269 bootstrap the IoT device using the IoT manufacturer provisioned 270 X.509 certificate, in combination with a registrar provided by the 271 local network and IoT device manufacturer's authorizing service 272 (MASA). 274 1. The IoT device authenticates to the local network using the 275 IoT manufacturer provisioned X.509 certificate. The IoT 276 device can request and get a voucher from the MASA service via 277 the registrar. The voucher is signed by the MASA service and 278 includes the local network's CA public key. 280 2. The IoT device validates the signed voucher using the 281 manufacturer installed trust anchor associated with the MASA, 282 stores the CA's public key and validates the provisional TLS 283 connection to the registrar. 285 3. The IoT device requests the full Enrollment over Secure 286 Transport (EST) [RFC7030] distribution of current CA 287 certificates (Section 5.9.1 in 288 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 289 operating as a BRSKI-EST server. The IoT devices stores the 290 CA certificates as Explicit Trust Anchor database entries. 291 The IoT device uses the Explicit Trust Anchor database to 292 validate the DNS server certificate. 294 4. The IoT device learns the End-Entity certificates [RFC8295] 295 from the BRSKI-EST server. The certificate provisioned to the 296 DNS server in the local network will be treated as a End- 297 Entity certificate. The IoT device needs to identify the 298 certificate provisioned to the DNS server. The SRV-ID 299 identifier type [RFC6125] within subjectAltName entry can be 300 used to identify the DNS server certificate. For example, DNS 301 server certificate will include SRV-ID "_domain-s.example.net" 302 along with DNS-ID "example.net". This specification defines 303 SRV service label "domain-s" in Section 9. As a reminder, the 304 protocol component is not included in the SRV-ID [RFC4985]. 306 5. Discovery Procedure 308 A DNS client discovers the DNS server in the local network supporting 309 DNS-over-TLS, DNS-over-DTLS and DNS-over-HTTPS protocols by using the 310 following discovery mechanism: 312 o The DNS client retrieves the authentication domain name for the 313 DNS server from the DNS-ID identifier type within subjectAltName 314 entry in the DNS server certificate. 316 o The DNS client then uses the authentication domain name for 317 S-NAPTR [RFC3958] lookup to learn the protocols DNS-over-TLS, DNS- 318 over-DTLS, and DNS-over-HTTPS supported by the DNS server and the 319 DNS privacy protocol preferred by the DNS server administrators, 320 as specified in Section 5.1 and Section 9.1. This specification 321 adds a SRV service label "domain-s" for privacy-enabling DNS 322 servers. In the example below, for authentication domain name 323 'example.net', the resolution algorithm will result in the 324 privacy-enabling protocols supported by the DNS server and usable 325 DNS server IP addresses and port numbers. 327 example.net. 328 IN NAPTR 100 10 "" DPRIVE:dns.tls "" dns1.example.net. 329 IN NAPTR 200 10 "" DPRIVE:dns.dtls "" dns2.example.net. 331 dns1.example.net. 332 IN NAPTR 100 10 S DPRIVE:dns.tls "" _domain-s._tcp.example.net. 334 dns2.example.net. 335 IN NAPTR 100 10 S DPRIVE:dns.dtls "" _domain-s._udp.example.net. 337 _domain-s._tcp.example.net. 338 IN SRV 0 0 853 a.example.net. 340 _domain-s._udp.example.net. 341 IN SRV 0 0 853 a.example.net. 343 a.example.net. 344 IN A 192.0.2.1 345 IN AAAA 2001:db8:8:4::2 347 Figure 1 349 o If DNS-over-HTTPS protocol is supported by the DNS server, the DNS 350 client finds the URI template of the DNS-over-HTTPS server using 351 one of the mechanisms discussed in 352 [I-D.ietf-doh-resolver-associated-doh] to use the https URI scheme 353 (Section 3 of [RFC8484]). 355 5.1. Resolution 357 Once the DNS client has retrieved the authentication domain name for 358 the DNS server, an S-NAPTR lookup with 'DPRIVE' application service 359 and the desired protocol tag is made to obtain information necessary 360 to securely connect to the DNS server. The S-NAPTR lookup is 361 performed using an recursive DNS resolver discovered from an 362 untrusted source (such as DHCP). 364 This specification defines "DPRIVE" as an application service tag 365 (Section 9.1.1) and "dns.tls" (Section 9.1.2), "dns.dtls" 366 (Section 9.1.3), and "dns.https" (Section 9.1.4) as application 367 protocol tags. 369 If no DNS-specific S-NAPTR records can be retrieved, the discovery 370 procedure fails for this authentication domain name. However, before 371 retrying a lookup that has failed, a DNS client MUST wait a time 372 period that is appropriate for the encountered error (e.g., NXDOMAIN, 373 timeout, etc.). 375 6. Connection handshake and service invocation 377 The DNS client initiates (D)TLS handshake with the DNS server, the 378 server presents its certificate in ServerHello message, and the DNS 379 client matches the DNS server certificate downloaded in step 4 in 380 Section 3 and Section 4 with the certificate provided by the DNS 381 server in (D)TLS handshake. If the match is successful, the DNS 382 client validates the server certificate using the Explicit Trust 383 Anchor database entries downloaded in step 3 in Section 3 and 384 Section 4. 386 If the match is successful and server certificate is successfully 387 validated, the client continues with the connection as normal. 388 Otherwise, the client MUST treat the server certificate validation 389 failure as a non-recoverable error. If the DNS client cannot reach 390 or establish an authenticated and encrypted connection with the 391 privacy-enabling DNS server provided by the local network, the DNS 392 client can fallback to the privacy-enabling public DNS server. 394 7. Security Considerations 396 The bootstrapping procedure to discover and authenticate DNS- 397 over-(D)TLS and DNS-over-HTTPS Servers MUST be enabled by the 398 endpoint in a trusted network (e.g. Enterprise, Secure home 399 networks) and disabled in a untrusted network (e.g. Public WiFi 400 network), similar to the way VPN connection from the endpoint to a 401 VPN gateway is disconnected in a trusted network and VPN connection 402 is established in a untrusted network. 404 If the endpoint has enabled strict privacy profile, and the network 405 security service blocks the traffic to the privacy-enabling public 406 DNS server, a hard failure occurs and the user is notified. The user 407 has a choice to switch to another network or if the user trusts the 408 network, the user can enable strict privacy profile with the DNS- 409 over-(D)TLS or DNS-over-HTTPS server discovered in the network 410 instead of downgrading to opportunistic privacy profile. 412 The primary attacks against the methods described in Section 5 are 413 the ones that would lead to impersonation of a DNS server and 414 spoofing the DNS response to indicate that the DNS server does not 415 support any privacy-enabling protocols. To protect against DNS- 416 vectored attacks, secured DNS (DNSSEC) can be used to ensure the 417 validity of the DNS records received. The explicit trust anchor 418 database entries downloaded in step 3 in Section 3 and Section 4 can 419 be used by the endpoint to validate the DNSSEC signature. 420 Impersonation of the DNS server is prevented by validating the 421 certificate presented by the DNS server. If the BRSKI-EST server 422 conveys the DNS server certificate, but the S-NAPTR lookup indicates 423 that the DNS server does not support any privacy-enabling protocols, 424 the client can detect the DNS response is spoofed. 426 Security considerations in [I-D.ietf-anima-bootstrapping-keyinfra], 427 [RFC5054] and [RFC8120] need to be taken into consideration. 429 8. Privacy Considerations 431 [RFC7626] discusses DNS privacy considerations in both "on the wire" 432 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 433 [RFC7626] contexts. The endpoint may not know if the DNS-over-(D)TLS 434 or DNS-over-HTTPS server in the local network has a privacy 435 preserving data policy. A new privacy certificate extension is 436 defined that identifies the privacy preserving data policy of the DNS 437 server. The extension contains a URL that points to the privacy 438 preserving data policy. 440 8.1. Privacy Extension Syntax 442 The syntax for the privacy extension is: 444 Privacy ::= CHOICE { 445 none NULL, -- No privacy policy provided 446 pURL PrivacyURL } -- Privacy preserving data policy 448 PrivacyURL ::= IA5String -- MUST use https scheme 450 9. IANA Considerations 452 IANA is requested to allocate the SRV service name of "domain-s" for 453 DNS-over-(D)TLS and DNS-over-HTTPS. 455 9.1. Application Service & Application Protocol Tags 457 This document requests IANA to make the following allocations from 458 the registry available at: https://www.iana.org/assignments/s-naptr- 459 parameters/s-naptr-parameters.xhtml. 461 9.1.1. DNS Application Service Tag Registration 463 o Application Protocol Tag: DPRIVE 465 o Intended Usage: See Section 5.1 467 o Security Considerations: See Section 7 469 o Contact Information: 471 9.1.2. dns.tls Application Protocol Tag Registration 473 o Application Protocol Tag: dns.tls 475 o Intended Usage: See Section 5.1 477 o Security Considerations: See Section 7 479 o Contact Information: 481 9.1.3. dns.dtls Application Protocol Tag Registration 483 o Application Protocol Tag: dns.dtls 485 o Intended Usage: See Section 5.1 487 o Security Considerations: See Section 7 489 o Contact Information: 491 9.1.4. dns.https Application Protocol Tag Registration 493 o Application Protocol Tag: dnshttps 495 o Intended Usage: See Section 5.1 497 o Security Considerations: See Section 7 499 o Contact Information: 501 10. Acknowledgments 503 Thanks to Joe Hildebrand, Harsha Joshi, Shashank Jain, Patrick 504 McManus, Eliot Lear and Sara Dickinson for the discussion and 505 comments. 507 11. References 509 11.1. Normative References 511 [I-D.ietf-anima-bootstrapping-keyinfra] 512 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 513 S., and K. Watsen, "Bootstrapping Remote Secure Key 514 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 515 keyinfra-19 (work in progress), March 2019. 517 [I-D.ietf-doh-resolver-associated-doh] 518 Hoffman, P., "Associating a DoH Server with a Resolver", 519 draft-ietf-doh-resolver-associated-doh-03 (work in 520 progress), March 2019. 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 528 Service Location Using SRV RRs and the Dynamic Delegation 529 Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, 530 January 2005, . 532 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 533 Subject Alternative Name for Expression of Service Name", 534 RFC 4985, DOI 10.17487/RFC4985, August 2007, 535 . 537 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 538 "Using the Secure Remote Password (SRP) Protocol for TLS 539 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 540 2007, . 542 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 543 Verification of Domain-Based Application Service Identity 544 within Internet Public Key Infrastructure Using X.509 545 (PKIX) Certificates in the Context of Transport Layer 546 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 547 2011, . 549 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 550 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 551 January 2012, . 553 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 554 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 555 . 557 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 558 "Enrollment over Secure Transport", RFC 7030, 559 DOI 10.17487/RFC7030, October 2013, 560 . 562 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 563 and P. Hoffman, "Specification for DNS over Transport 564 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 565 2016, . 567 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 568 Transport Layer Security (DTLS)", RFC 8094, 569 DOI 10.17487/RFC8094, February 2017, 570 . 572 [RFC8120] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi, 573 T., and Y. Ioku, "Mutual Authentication Protocol for 574 HTTP", RFC 8120, DOI 10.17487/RFC8120, April 2017, 575 . 577 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 578 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 579 May 2017, . 581 [RFC8295] Turner, S., "EST (Enrollment over Secure Transport) 582 Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, 583 . 585 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 586 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 587 . 589 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 590 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 591 . 593 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 594 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 595 January 2019, . 597 11.2. Informative References 599 [CDN] "End-User Mapping: Next Generation Request Routing for 600 Content Delivery", 2015, 601 . 604 [I-D.camwinget-tls-use-cases] 605 Andreasen, F., Cam-Winget, N., and E. Wang, "TLS 1.3 606 Impact on Network-Based Security", draft-camwinget-tls- 607 use-cases-04 (work in progress), March 2019. 609 [I-D.ietf-opsawg-mud] 610 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 611 Description Specification", draft-ietf-opsawg-mud-25 (work 612 in progress), June 2018. 614 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 615 DOI 10.17487/RFC2775, February 2000, 616 . 618 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 619 DOI 10.17487/RFC7626, August 2015, 620 . 622 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 623 Kumari, "Client Subnet in DNS Queries", RFC 7871, 624 DOI 10.17487/RFC7871, May 2016, 625 . 627 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 628 for DNS over TLS and DNS over DTLS", RFC 8310, 629 DOI 10.17487/RFC8310, March 2018, 630 . 632 [SRP-6] "SRP-6: Improvements and Refinements to the Secure Remote 633 Password Protocol", October 2002, 634 . 636 Authors' Addresses 638 Tirumaleswar Reddy 639 McAfee, Inc. 640 Embassy Golf Link Business Park 641 Bangalore, Karnataka 560071 642 India 644 Email: kondtir@gmail.com 646 Dan Wing 647 USA 649 Email: dan@danwing.org 650 Michael C. Richardson 651 Sandelman Software Works 652 USA 654 Email: mcr+ietf@sandelman.ca 656 Mohamed Boucadair 657 Orange 658 Rennes 35000 659 France 661 Email: mohamed.boucadair@orange.com