idnits 2.17.1 draft-reddy-dnsop-error-page-07.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 (April 20, 2021) is 1095 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 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 == Outdated reference: A later version (-06) exists of draft-reddy-add-resolver-info-03 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track N. Cook 5 Expires: October 22, 2021 Open-Xchange 6 D. Wing 7 Citrix 8 M. Boucadair 9 Orange 10 April 20, 2021 12 DNS Access Denied Error Page 13 draft-reddy-dnsop-error-page-07 15 Abstract 17 When a DNS server filters a query, the response to such query conveys 18 no detailed explanation that elaborates why that query was blocked, 19 leading thus to end-user confusion. A solution to this problem is 20 needed in order to enhance the user experience. 22 This document defines a method to return an URI that explains the 23 reason why a DNS query was filtered by a DNS server. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 22, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Error Page URI EDNS0 Option Format . . . . . . . . . . . . . 6 62 4. Error Page URI Processing . . . . . . . . . . . . . . . . . . 7 63 4.1. Mitigating EDNS0 Forgery . . . . . . . . . . . . . . . . 8 64 5. Error Page . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Usability Considerations . . . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8.1. A New Error Page URI EDNS Option . . . . . . . . . . . . 11 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 DNS filters are deployed for a variety of reasons, including endpoint 78 security, parental filtering, and filtering required by law 79 enforcement. Some of these reasons are discussed in more detail 80 below: 82 o Various network security services are provided by Enterprise 83 networks to protect endpoints (e.g., Hosts including IoT devices). 84 Network-based security solutions such as firewalls and Intrusion 85 Prevention Systems (IPS) rely upon network traffic inspection to 86 implement perimeter-based security policies. The network security 87 services may, for example, prevent malware download, block known 88 malicious domains, block phishing sites, etc. 90 These network security services act on DNS queries originating 91 from endpoints. For example, DNS firewalls, a method of 92 expressing DNS response policy information inside specially 93 constructed DNS zones, known as Response Policy Zones (RPZs) 94 allows DNS servers to modify their DNS responses in real time in 95 order to stop access to malware and phishing domains. Note that 96 some of the commonly known types of malware are viruses, worms, 97 trojans, bots, ransomware, backdoors, spyware, and adware. 99 o Network devices in a home network offer network security to 100 protect the devices within the home network by performing DNS- 101 based content filtering. The network security service may, for 102 example, block access to specific domains to enforce parental 103 control, block access to malware sites, etc. 105 o Internet Service Providers (ISPs) typically block access to some 106 DNS domains due to a requirement imposed by an external entity 107 (e.g., Law Enforcement Agency). Such blocking is performed using 108 DNS-based content filtering. 110 DNS responses can be filtered by sending a bogus (also called, 111 "forged") A or AAAA response, NXDOMAIN error or empty answer, or an 112 extended DNS error (EDE) code defined in [RFC8914]. Each of these 113 methods have advantages and disadvantages that are discussed below: 115 1. The DNS response is forged to provide a list of IP addresses that 116 points to an HTTP(S) server alerting the end user about the 117 reason for blocking access to the requested domain (e.g., 118 malware). When an HTTP(S) enabled domain name is blocked, the 119 network security device (e.g., CPE, firewall) presents a block 120 page instead of the HTTP response from the content provider 121 hosting that domain. If an HTTP enabled domain name is blocked, 122 the network security device intercepts the HTTP request and 123 returns a block page over HTTP. If an HTTPS enabled domain is 124 blocked, the block page is also served over HTTPS. In order to 125 return a block page over HTTPS, man in the middle (MITM) is 126 enabled on endpoints by generating a local root certificate and 127 an accompanying (local) public/private key pair. The local root 128 certificate is installed on the endpoint while the network 129 security device(s) stores a copy of the private key. During the 130 TLS handshake, the network security device modifies the 131 certificate provided by the server and (re)signs it using the 132 private key from the local root certificate. 134 * However, configuring the local root certificate on endpoints 135 is not a viable option in several deployments like home 136 networks, schools, Small Office/Home Office (SOHO), and Small/ 137 Medium Enterprise (SME). In these cases, the typical behavior 138 is that the forged DNS response directs the user towards a 139 server hosted to display the block page which breaks the TLS 140 connection. For web-browsing this then results in an HTTPS 141 certificate error message indicating that a secure connection 142 could not be established, which gives no information to the 143 end-user about the reason for the error. 145 The typical errors are "The security certificate presented by 146 this website was not issued by a trusted certificate 147 authority" (Internet Explorer/Edge"), "The site's security 148 certificate is not trusted" (Chrome), "This Connection is 149 Untrusted" (Firefox), "Safari can't verify the identity of the 150 website..." (Safari on MacOS)". 152 * Enterprise networks do not assume that all the connected 153 devices are managed by the IT team or Mobile Device Management 154 (MDM) devices, especially in the quite common Bring Your Own 155 Device (BYOD) scenario. In addition, the local root 156 certificate cannot be installed on IoT devices without a 157 device management tool. 159 * An end user does not know why the connection was reset and, 160 consequently, may repeatedly try to reach the domain but with 161 no success. Frustrated, the end user may switch to an 162 alternate network that offers no DNS-level protection against 163 malware and phishing, potentially compromising both security 164 and privacy. Furthermore, certificate errors train users to 165 click through certificate errors, which is a bad security 166 practice. To eliminate the need for an end user to click 167 through certificate errors, an end user may manually install a 168 local root certificate on a host device (e.g. 169 [Chrome-Install-Cert]). Doing so, however, is also a bad 170 security practice as it creates a security vulnerability that 171 may be exploited by a MITM attack. When a manually installed 172 local root certificate expires, the user has to (again) 173 manually install the new local root certificate. 175 2. The DNS response is forged to provide a NXDOMAIN response to 176 cause the DNS lookup to terminate in failure. In this case, an 177 end user does not know why the domain cannot be reached and may 178 repeatedly try to reach the domain but with no success. 179 Frustrated, the end user may use insecure connections to reach 180 the domain, potentially compromising both security and privacy. 182 3. The extended error codes Blocked, Censored, and Filtered defined 183 in Section 4 of [RFC8914] can be returned by a DNS server to 184 provide additional information about the cause of an DNS error. 185 If the extended error code "Forged Answer" defined in Section 4.5 186 of [RFC8914] is returned by the DNS server, the client can 187 identify the DNS response is forged together with the reason for 188 HTTPS certificate error. 190 These extended error codes do not suffer from the limitations 191 discussed in bullets (1) and (2), but the user still does not 192 know the exact reason nor he/she is aware of the exact entity 193 blocking the access to the domain. For example, a DNS server may 194 block access to a domain based on the content category such as 195 "Adult Content" to enforce parental control, "Violence & 196 Terrorism" due to an external requirement imposed by an external 197 entity (e.g., Law Enforcement Agency), etc. These content 198 categories cannot be standardized because the classification of 199 domains into content categories is vendor specific, typically 200 ranges from 40 to 100 types of categories depending on the vendor 201 and the categories keep evolving. Furthermore, the threat data 202 used to categorize domains may sometimes misclassify domains 203 (e.g., domains wrongly classified as Domain Generation Algorithm 204 (DGA) by deep learning techniques, domain wrongly classified as 205 phishing due to crowd sourcing, new domains not categorized by 206 the threat data). A user needs to know the contact details of 207 the IT/InfoSec team to raise a complaint. 209 4. The EXTRA-TEXT field of the EDE option defined in Section 2 of 210 [RFC8914] can include additional textual information about the 211 cause of the error, but the information could be provided in a 212 language that is not understood by the user. When a resolver or 213 forwarder forwards the received EDE option, the EXTRA-TEXT field 214 only conveys the source of the error (Section 3 of [RFC8914]) and 215 does not provide additional textual information about the cause 216 of the error. Most importantly, EDE option does not offer 217 authenticated information; it can thus be spoofed by an attacker. 218 In addition, the additional textual information may not be able 219 to convey all of the required information about the cause of the 220 DNS error because lengthy EXTRA-TEXT content would be truncated 221 to prevent fragmentation (Section 3 of [RFC8914]). 223 No matter which type of response is generated (forged IP address(es), 224 NXDOMAIN or empty answer, or an extended error code), the user who 225 triggered the DNS query has little chance to understand which entity 226 filtered the query, how to report a mistake in the filter, or why the 227 entity filtered it at all. This document describes a mechanism to 228 provide an URI which, when accessed, provides such information to the 229 user. 231 One of the other benefits of this approach is to eliminate the need 232 to "spoof" block pages for HTTPS resources. This is achieved as the 233 block page no longer needs to create a signed certificate when 234 blocking a destination. This approach avoids the need to install a 235 local root certificate authority on those IT-managed devices. 237 2. Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 241 "OPTIONAL" in this document are to be interpreted as described in BCP 242 14 [RFC2119][RFC8174] when, and only when, they appear in all 243 capitals, as shown here. 245 This document makes use of the terms defined in [RFC8499]. 247 'Encrypted DNS' refers to any encrypted scheme to convey DNS 248 messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS 249 [RFC7858], or DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 251 3. Error Page URI EDNS0 Option Format 253 This document uses an EDNS0 [RFC6891] option to include the URI that 254 provides additional information in a DNS response about the cause of 255 blocking access to a requested domain. This option is structured as 256 depicted in Figure 1. 258 1 1 1 1 1 1 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 260 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 261 | OPTION-CODE | 262 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 263 | OPTION-LENGTH | 264 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 265 | ERROR-PAGE-URI-LENGTH (fixed size) | 266 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 267 / ERROR-PAGE-URI (variable size) / 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 270 Figure 1: Error Page URI EDNS0 Option Format 272 The description of the fields is as follows: 274 o OPTION-CODE: TBD, indicates the code assigned for Error Page URI 275 (Section 6.1.2 of [RFC6891]). [RFC Editor: change TBD to the 276 proper code once assigned by IANA.] 278 o OPTION-LENGTH: See Section 6.1.2 of [RFC6891]. This field 279 contains the length of the payload (everything after OPTION- 280 LENGTH) in octets. The variability of the option length stems 281 from the variable-length ERROR-PAGE-URI field. 283 o ERROR-PAGE-URI-LENGTH: This 16-bit field indicates the length of 284 ERROR-PAGE-URI. It MUST NOT be set to 0. 286 o ERROR-PAGE-URI: A variable length UTF-8 encoded [RFC5198] text 287 field containing the URI Template [RFC6570] that gives additional 288 information about the cause of blocking access to a domain. The 289 ERROR-PAGE-URI field MUST NOT be zero octets in length. 291 The Error Page URI option can be included in any response (SERVFAIL, 292 NXDOMAIN, REFUSED, and even NOERROR, etc.) to a query that includes 293 OPT Pseudo-RR [RFC6891]. 295 The URI Template defined in ERROR-PAGE-URI describes how to construct 296 the URL to fetch the error page. The agent acting as the HTTPS 297 client on the endpoint encodes an FQDN to which access is denied into 298 an HTTP GET request to retrieve the error page. The HTTPS server 299 returning the error page defines the URI used by the HTTP GET request 300 through the use of a URI Template. The URI Template is processed 301 with a defined variable "target-domain" whose value is set to the 302 FQDN to which access is denied. 304 The FQDN is encoded using base64url [RFC4648] and then provided as 305 the variable value for "target-domain" to expand the URI Template 306 into an URI reference in the HTTP GET request. Padding characters 307 for base64url MUST NOT be included. 309 An example is illustrated below: 311 If the URI Template is "https://resolver.example.net/block- 312 page{?target-domain}" for the HTTPS server returning the error 313 page and access to the target domain "example.com" is blocked by 314 the encrypted DNS server, the variable "target-domain" has the 315 value "example.com" base64url encoded into an HTTP GET request. 316 In the above example, the expansion of the above URI Template is 317 "https://resolver.example.net/block-page?target- 318 domain=ZXhhbXBsZS5jb20". 320 HTTP/2 [RFC7540] is the minimum RECOMMENDED HTTP version to use to 321 retrieve the error page. The HTTPS client retrieving the error page 322 MUST verify the entire certification path as per [RFC5280]. The 323 HTTPS client additionally uses validation techniques described in 324 [RFC6125] to compare the domain name in the error page URI to the 325 server certificate provided in TLS handshake. See [RFC7525] for 326 additional TLS recommendations. 328 4. Error Page URI Processing 330 The DNS client MUST follow the rules below to process the Error Page 331 URI EDNS0 option: 333 o If the DNS response contains more than one Error Page URI EDNS0 334 option, the DNS client MUST discard all Error Page URI EDNS0 335 options in the DNS response. 337 o The Error Page URI EDNS0 option MUST be processed by the DNS 338 client for a "Censored", "Blocked", "Filtered" or "Forged" 339 extended error codes and MUST be ignored for any other type of 340 extended DNS error code. When "Censored", "Blocked", "Filtered" 341 or "Forged" extended error code is returned in conjunction with an 342 Error Page URI EDNS0 option, any other resource records in the 343 answer MUST be ignored by clients supporting this specification. 345 o The DNS client MUST reject the error page URI if the scheme is not 346 "https". 348 4.1. Mitigating EDNS0 Forgery 350 The Error Page URI EDNS0 option is susceptible to forgery. An 351 attacker (e.g., a man in the middle (MITM)) could insert an extended 352 Error Page URI EDNS0 option into the DNS response causing a client to 353 attempt to visit that URI. For instance, the attacker can be located 354 between the stub resolver and DNS recursive server or between the DNS 355 proxy and the upstream resolver. To mitigate that attack, the 356 following measures are enforced: 358 o The DNS client MUST NOT process the DNS response with Error Page 359 URI EDNS0 option unless DNS messages exchanged are 360 cryptographically protected using encrypted DNS. 362 o If a DNS client has enabled opportunistic privacy profile 363 (Section 5 of [RFC8310]) for DoT, the DNS client will either 364 fallback to an encrypted connection without authenticating the DNS 365 server provided by the local network or fallback to clear text 366 DNS, and cannot exchange encrypted DNS messages. Both of these 367 fallback mechanisms adversely impacts security and privacy. If 368 the DNS client has enabled opportunistic privacy profile for DoT, 369 the DNS client MUST ignore Error Page URI EDNS0 option in 370 responses, but SHOULD process other parts of the response. 372 o If a DNS client has enabled strict privacy profile (Section 5 of 373 [RFC8310]) for DoT, the DNS client requires an encrypted 374 connection and successful authentication of the DNS server; this 375 mitigates both passive eavesdropping and client redirection (at 376 the expense of providing no DNS service if an encrypted, 377 authenticated connection is not available). If the DNS client has 378 enabled strict privacy profile for DoT, the client can process the 379 DNS response with Error Page URI EDNS0 option. Note that the 380 strict and opportunistic privacy profiles as defined in [RFC8310] 381 only applies to DoT protocol, there has been no such distinction 382 made for DoH protocol. 384 o If the DNS client determines that the encrypted DNS server does 385 not offer DNS filtering service, it MUST reject the Error Page URI 386 EDNS0 option. For example, the DNS client can learn whether the 387 encrypted DNS resolver performs DNS-based content filtering or not 388 by retrieving resolver information using the method defined in 389 [I-D.reddy-add-resolver-info]. 391 o DNS forwarders (or DNS proxies) are supposed to propagate unknown 392 EDNS0 options (Sections 4.1 and 4.4.1 of [RFC5625]), the Error 393 Page URI EDNS0 option may get propagated by a DNS server that has 394 not implemented this specification. To detect this scenario, the 395 DNS client MUST verify the domain name in the Error Page URI 396 matches the domain name of the encrypted DNS resolver. If this 397 match fails, the DNS client MUST ignore Error Page URI EDNS0 398 option in the response, but SHOULD process other parts of the 399 response. 401 5. Error Page 403 The following outlines the RECOMMENDED contents of an error page to 404 assist the operator developing the error page: 406 o The exact reason for blocking access to the domain. If the domain 407 is blocked based on some threat data, the threat type associated 408 with the blocked domain can be provided/displayed to the end user. 409 For example, the reason can indicate the type of malware blocked 410 like spyware and the damage it can do the security and privacy of 411 the user. 413 o The domain name blocked. 415 o If query was blocked by regulation, a pointer to a regulatory text 416 that mandates this query block. 418 o The entity (or organization) blocking the access to the domain and 419 contact details of the IT/InfoSec team to raise a complaint. 421 o The blocked error page to not include Ads and dynamic content. 423 The content of the error page discussed above is non-normative, the 424 above text only provides the guidelines and template for the error 425 page and: 427 o does not attempt to offer an exhaustive list for the contents of 428 an error page. 430 o it is not intended to form the basis of any legal/compliance for 431 developing the error page. 433 6. Usability Considerations 435 The error page SHOULD be returned in the user's preferred language as 436 expressed by the Accept-Language HTTP header. 438 7. Security Considerations 440 Security considerations in Section 6 of [RFC8914] and [RFC8624] need 441 to be taken into consideration. 443 The Error Page URI EDNS0 option causes an HTTPS retrieval by the 444 client. To prevent forgery of the Error Page URI EDNS0 option, this 445 specification requires it only be sent only over an encrypted DNS 446 channel with an authorized DNS server. 448 The client knows it is connecting to a HTTPS server returning the 449 error page. To reduce threat surface the client can retrieve the 450 Error Page URL using, for example, an isolated environment and take 451 other precautions such as clearly labeling the page as untrusted or 452 prevent user interaction with the page. Such isolation should 453 prevent transmitting cookies, block JavaScript, block auto-fill of 454 credentials or personal information, and be isolated from the user's 455 normal environment. 457 Browsers perform some of the above restrictions when accessing 458 captive portals (Section 5 of [RFC8910] or [Safari-Cookie]), during 459 private browsing, or using containerization [Facebook-Container]. 461 Note that the means to use a sandbox environment and a user interface 462 presenting the error page are not covered in this document. By its 463 nature, these aspects are implementation specific and best left to 464 the application and user interface designers. 466 The encrypted DNS session provides transport security for the 467 interaction between the DNS client and server, but DNSSEC signing and 468 validation is not possible for the Error Page URI EDNS0 option 469 returning the Error Page URI Template. However, this specification 470 mandates the DNS client to not process DNS response with Error Page 471 URI EDNS0 option if domain name in the Error Page URI does not match 472 the domain name of the encrypted DNS server. The validation ensures 473 both the servers are operated by the same entity and have the same 474 origin (similar to the Same Origin Policy (SOP)). 476 By design, the object referenced by the error page URL potentially 477 exposes additional information about the DNS resolution process that 478 may leak information. An example of this is the reason for blocking 479 the access to the domain name and the entity blocking access to the 480 domain. 482 8. IANA Considerations 484 8.1. A New Error Page URI EDNS Option 486 This document defines a new EDNS(0) option, entitled "Error Page 487 URI", assigned a value of TBD from the "DNS EDNS0 Option Codes (OPT)" 488 registry [to be removed upon publication: 489 [http://www.iana.org/assignments/dns-parameters/dns- 490 parameters.xhtml#dns-parameters-11] 492 Value Name Status Reference 493 ----- ---------------- ------ ------------------ 494 TBD Error Page URI Standard [ This document ] 496 9. Acknowledgements 498 Thanks to Vittorio Bertola, Wes Hardaker, Ben Schwartz, Erid Orth, 499 Viktor Dukhovni, Warren Kumari and Bob Harold for the comments. 501 10. References 503 10.1. Normative References 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, 507 DOI 10.17487/RFC2119, March 1997, 508 . 510 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 511 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 512 . 514 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 515 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 516 . 518 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 519 Housley, R., and W. Polk, "Internet X.509 Public Key 520 Infrastructure Certificate and Certificate Revocation List 521 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 522 . 524 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 525 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 526 . 528 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 529 Verification of Domain-Based Application Service Identity 530 within Internet Public Key Infrastructure Using X.509 531 (PKIX) Certificates in the Context of Transport Layer 532 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 533 2011, . 535 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 536 and D. Orchard, "URI Template", RFC 6570, 537 DOI 10.17487/RFC6570, March 2012, 538 . 540 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 541 for DNS (EDNS(0))", STD 75, RFC 6891, 542 DOI 10.17487/RFC6891, April 2013, 543 . 545 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 546 "Recommendations for Secure Use of Transport Layer 547 Security (TLS) and Datagram Transport Layer Security 548 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 549 2015, . 551 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 552 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 553 DOI 10.17487/RFC7540, May 2015, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 561 for DNS over TLS and DNS over DTLS", RFC 8310, 562 DOI 10.17487/RFC8310, March 2018, 563 . 565 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 566 Requirements and Usage Guidance for DNSSEC", RFC 8624, 567 DOI 10.17487/RFC8624, June 2019, 568 . 570 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 571 Lawrence, "Extended DNS Errors", RFC 8914, 572 DOI 10.17487/RFC8914, October 2020, 573 . 575 10.2. Informative References 577 [Chrome-Install-Cert] 578 "How to manually install the Securly SSL certificate in 579 Chrome", . 583 [Facebook-Container] 584 "Facebook container for Firefox", 585 . 588 [I-D.ietf-dprive-dnsoquic] 589 Huitema, C., Mankin, A., and S. Dickinson, "Specification 590 of DNS over Dedicated QUIC Connections", draft-ietf- 591 dprive-dnsoquic-01 (work in progress), October 2020. 593 [I-D.reddy-add-resolver-info] 594 Reddy, T. and M. Boucadair, "DNS Resolver Information", 595 draft-reddy-add-resolver-info-03 (work in progress), April 596 2021. 598 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 599 and P. Hoffman, "Specification for DNS over Transport 600 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 601 2016, . 603 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 604 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 605 . 607 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 608 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 609 January 2019, . 611 [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in 612 DHCP and Router Advertisements (RAs)", RFC 8910, 613 DOI 10.17487/RFC8910, September 2020, 614 . 616 [Safari-Cookie] 617 "Isolated cookie store (CVE-2016-1730)", 618 . 620 Authors' Addresses 622 Tirumaleswar Reddy 623 McAfee, Inc. 624 Embassy Golf Link Business Park 625 Bangalore, Karnataka 560071 626 India 628 Email: kondtir@gmail.com 630 Neil Cook 631 Open-Xchange 632 UK 634 Email: neil.cook@noware.co.uk 636 Dan Wing 637 Citrix Systems, Inc. 638 USA 640 Email: dwing-ietf@fuggles.com 642 Mohamed Boucadair 643 Orange 644 Rennes 35000 645 France 647 Email: mohamed.boucadair@orange.com