idnits 2.17.1 draft-reddy-dnsop-error-page-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2021) is 1196 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) == Unused Reference: 'Chrome-Translate' is defined on line 662, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS-SIG-SCHEME' == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: July 18, 2021 Open-Xchange 6 D. Wing 7 Citrix 8 M. Boucadair 9 Orange 10 January 14, 2021 12 DNS Access Denied Error Page 13 draft-reddy-dnsop-error-page-06 15 Abstract 17 When a DNS server filters a query, the response to such query conveys 18 no detailed explanation that explains 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 July 18, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Error page URI EDNS0 Option Format . . . . . . . . . . . . . 6 62 4. Error Page URI Processing . . . . . . . . . . . . . . . . . . 8 63 5. Sign and Verify . . . . . . . . . . . . . . . . . . . . . . . 10 64 6. Error Page . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 7. Usability Considerations . . . . . . . . . . . . . . . . . . 11 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 9.1. A New Error Page URI EDNS Option . . . . . . . . . . . . 12 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 11.2. Informative References . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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. These network 89 security services act on DNS queries originating from endpoints. 90 For example, DNS firewalls, a method of expressing DNS response 91 policy information inside specially constructed DNS zones, known 92 as Response Policy Zones (RPZs) allows DNS servers to modify their 93 DNS responses in real time in order to stop access to malware and 94 phishing domains. Note that some of the commonly known types of 95 malware are viruses, worms, trojans, bots, ransomware, backdoors, 96 spyware, and adware. 98 o Network devices in a home network offer network security to 99 protect the devices within the home network by performing DNS- 100 based content filtering. The network security service may, for 101 example, block access to specific domains to enforce parental 102 control, block access to malware sites, etc. 104 o Internet Service Providers (ISPs) typically block access to some 105 domains due to a requirement imposed by an external entity (e.g., 106 Law Enforcement Agency) by performing DNS-based content filtering. 108 DNS responses can be filtered by sending a bogus (also called, 109 "forged") A or AAAA response, NXDOMAIN error or empty answer, or an 110 extended DNS error (EDE) code defined in [RFC8914]. Each of these 111 methods have advantages and disadvantages that are discussed below: 113 1. The DNS response is forged to provide a list of IP addresses that 114 point to an HTTP(S) server alerting the end user of the reason 115 for blocking access to the requested domain (e.g., malware). 116 When an HTTP(S) enabled domain name is blocked, the network 117 security device (e.g., CPE, firewall) presents a block page 118 instead of the HTTP response from the content provider hosting 119 that domain. If an HTTP enabled domain name is blocked, the 120 network security device intercepts the HTTP request and returns a 121 block page over HTTP. If an HTTPS enabled domain is blocked, the 122 block page is also served over HTTPS. In order to return a block 123 page over HTTPS, man in the middle (MITM) is enabled on endpoints 124 by generating a local root certificate and an accompanying 125 (local) public/private key pair. The local root certificate is 126 installed on the endpoint while the network security device(s) 127 stores a copy of the private key. During the TLS handshake, the 128 network security device modifies the certificate provided by the 129 server and (re)signs it with the private key from the local root 130 certificate. 132 * However, configuring the local root certificate on endpoints 133 is not a viable option in several deployments like home 134 networks, schools, Small Office/Home Office (SOHO), and Small/ 135 Medium Enterprise (SME). In these cases, the typical behavior 136 is that the forged DNS response directs the user towards a 137 server hosted to display the block page which breaks the TLS 138 connection. For web-browsing this then results in an HTTPS 139 certificate error message indicating that a secure connection 140 could not be established, which gives no information to the 141 end-user about the reason for the error. The typical errors 142 are "The security certificate presented by this website was 143 not issued by a trusted certificate authority" (Internet 144 Explorer/Edge"), "The site's security certificate is not 145 trusted" (Chrome), "This Connection is Untrusted" (Firefox), 146 "Safari can't verify the identity of the website..." (Safari 147 on MacOS)". 149 * Enterprise networks do not assume that all the connected 150 devices are managed by the IT team or Mobile Device Management 151 (MDM) devices, especially in the quite common Bring Your Own 152 Device (BYOD) scenario. In addition, the local root 153 certificate cannot be installed on IoT devices without a 154 device management tool. 156 * An end user does not know why the connection was reset and, 157 consequently, may repeatedly try to reach the domain but with 158 no success. Frustrated, the end user may switch to an 159 alternate network that offers no DNS-level protection against 160 malware and phishing, potentially compromising both security 161 and privacy. Furthermore, certificate errors train users to 162 click through certificate errors, which is a bad security 163 practice. To eliminate the need for an end user to click 164 through certificate errors, an end user may manually install a 165 local root certificate on a host device (e.g. 166 [Chrome-Install-Cert]). Doing so, however, is also a bad 167 security practice as it creates a security vulnerability that 168 may be exploited by a MITM attack. When a manually installed 169 local root certificate expires, the user has to (again) 170 manually install the new local root certificate. 172 2. The DNS response is forged to provide a NXDOMAIN response to 173 cause the DNS lookup to terminate in failure. In this case, an 174 end user does not know why the domain cannot be reached and may 175 repeatedly try to reach the domain but with no success. 176 Frustrated, the end user may use insecure connections to reach 177 the domain, potentially compromising both security and privacy. 179 3. The extended error codes Blocked, Censored, and Filtered defined 180 in Section 4 of [RFC8914] can be returned by a DNS server to 181 provide additional information about the cause of an DNS error. 182 If the extended error code "Forged Answer" defined in Section 4.5 183 of [RFC8914] is returned by the DNS server, the client can 184 identify the DNS response is forged together with the reason for 185 HTTPS certificate error. 187 These extended error codes do not suffer from the limitations 188 discussed in bullets (1) and (2), but the user still does not 189 know the exact reason nor he/she is aware of the exact entity 190 blocking the access to the domain. For example, a DNS server may 191 block access to a domain based on the content category such as 192 "Adult Content" to enforce parental control, "Violence & 193 Terrorism" due to an external requirement imposed by an external 194 entity (e.g., Law Enforcement Agency), etc. These content 195 categories cannot be standardized because the classification of 196 domains into content categories is vendor specific, typically 197 ranges from 40 to 100 types of categories depending on the vendor 198 and the categories keep evolving. Furthermore, the threat data 199 used to categorize domains may sometimes misclassify domains 200 (e.g., domains wrongly classified as Domain Generation Algorithm 201 (DGA) by deep learning techniques, domain wrongly classified as 202 phishing due to crowd sourcing, new domains not categorized by 203 the threat data). A user needs to know the contact details of 204 the IT/InfoSec team to raise a complaint. 206 4. The EXTRA-TEXT field of the EDE option defined in Section 2 of 207 [RFC8914] can include additional textual information about the 208 cause of the error, but the information could be provided in a 209 language that is not understood by the user. When a resolver or 210 forwarder forwards the received EDE option, the EXTRA-TEXT field 211 only conveys the source of the error (Section 3 of [RFC8914]) and 212 does not provide additional textual information about the cause 213 of the error. Most importantly, EDE option does not offer 214 authenticated information; it can thus be be spoofed by an 215 attacker. In addition, the additional textual information may 216 not be able to convey all of the required information about the 217 cause of the DNS error because lengthy EXTRA-TEXT content would 218 be truncated to prevent fragmentation (Section 3 of [RFC8914]). 220 No matter which type of response is generated (forged IP address(es), 221 NXDOMAIN or empty answer, or an extended error code), the user who 222 generated the query has little chance to understand which entity 223 filtered the query, how to report a mistake in the filter, or why the 224 entity filtered it at all. This document describes a mechanism to 225 provide a URI which, when accessed, provides such information to the 226 user. 228 One of the other benefits of this approach is to eliminate the need 229 to "spoof" block pages for HTTPS resources, as the block page no 230 longer needs to create a signed certificate when blocking a 231 destination. Also, the approach avoids the need to install a local 232 root certificate authority on those IT-managed devices. 234 2. Terminology 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described in BCP 239 14 [RFC2119][RFC8174] when, and only when, they appear in all 240 capitals, as shown here. 242 This document makes use of the terms defined in [RFC8499] and 243 [I-D.ietf-dnsop-terminology-ter]. 245 'Encrypted DNS' refers to any encrypted scheme to convey DNS 246 messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS 247 [RFC7858], or DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 249 3. Error page URI EDNS0 Option Format 251 This document uses an EDNS0 [RFC6891] option to include the URI that 252 gives additional information in a DNS response about the cause of 253 blocking access to a domain. This option is structured as depicted 254 in Figure 1. 256 1 1 1 1 1 1 257 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 258 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 259 | OPTION-CODE | 260 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 261 | OPTION-LENGTH | 262 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 263 | ERROR-PAGE-URI-LENGTH (fixed size) | 264 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 265 / ERROR-PAGE-URI (variable size) / 266 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 267 | ERROR-PAGE-SIG-ALG (fixed size) | 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 / ERROR-PAGE-SIG (variable size) / 270 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 272 Figure 1: Error page URI EDNS0 Option Format 274 The description of the fields is as follows: 276 o OPTION-CODE: TBD, indicates the code assigned for Error page URI 277 (Section 6.1.2 of [RFC6891]). [RFC Editor: change TBD to the 278 proper code once assigned by IANA.] 280 o OPTION-LENGTH: See Section 6.1.2 of [RFC6891]. This fields 281 contains the length of the payload (everything after OPTION- 282 LENGTH) in octets. The variability of the option length stems 283 from the variable-length ERROR-PAGE-URI and ERROR-PAGE-SIG fields. 285 o ERROR-PAGE-URI-LENGTH: This 16-bit field indicates the length of 286 ERROR-PAGE-URI. It MUST NOT be set to 0. 288 o ERROR-PAGE-URI: A variable length UTF-8 encoded [RFC5198] text 289 field containing the URI Template [RFC6570] that gives additional 290 information about the cause of blocking access to a domain. The 291 ERROR-PAGE-URI field MUST NOT be zero octets in length. 293 o ERROR-PAGE-SIG-ALG: A 16-bits field that contains the algorithm 294 used to generate the signature for the Error Page URI Template. 295 The values are defined in the TLS SignatureScheme [TLS-SIG-SCHEME] 296 with limitations described in Section 5. 298 o ERROR-PAGE-SIG, a variable length field containing the signature 299 of the Error Page URI Template. The signature generation process 300 is discussed in Section 5. 302 The Error page URI option can be included in any response (SERVFAIL, 303 NXDOMAIN, REFUSED, and even NOERROR, etc) to a query that includes 304 OPT Pseudo-RR [RFC6891]. 306 The URI Template defined in ERROR-PAGE-URI describes how to construct 307 the URL to fetch the error page. The agent acting as HTTPS client on 308 the endpoint encodes a FQDN to which access is denied into an HTTP 309 GET request to retrieve the error page. The HTTPS server returning 310 the error page defines the URI used by the HTTP GET request through 311 the use of a URI Template. The URI Template is processed with a 312 defined variable "target-domain" whose value is set to the FQDN to 313 which access is denied. The FQDN is encoded using base64url 314 [RFC4648] and then provided as the variable value for "target-domain" 315 to expand the URI Template into a URI reference in the HTTP GET 316 request. Padding characters for base64url MUST NOT be included. 318 An example is illustrated below: 320 If the URI Template is "https://block.example.net/block- 321 page{?target-domain}" for the HTTPS server returning the error 322 page and access to the target domain "example.com" is blocked by 323 the encrypted DNS server, the variable "target-domain" has the 324 value "example.com" base64url encoded into an HTTP GET request. 325 In the above example, the expansion of the above URI Template is 326 "https://block.example.net/block-page?target- 327 domain=ZXhhbXBsZS5jb20". 329 HTTP/2 [RFC7540] is the minimum RECOMMENDED HTTP version to use to 330 retrieve the error page. The HTTPS client retrieving the error page 331 MUST verify the entire certification path as per [RFC5280]. The 332 HTTPS client additionally uses validation techniques described in 333 [RFC6125] to compare the domain name in the error page URI to the 334 server certificate provided in TLS handshake. See [RFC7525] for 335 additional TLS recommendations. 337 4. Error Page URI Processing 339 The DNS client MUST follow the following rules to process the Error 340 Page URI EDNS0 option: 342 o The Error Page URI EDNS0 option is susceptible to forgery. In 343 order to defend against this attack the DNS client MUST NOT 344 process the DNS response with Error Page URI EDNS0 option unless 345 DNS messages exchanged are cryptographically protected using 346 encrypted DNS. 348 o If an DNS client has enabled opportunistic privacy profile 349 (Section 5 of [RFC8310]) for DoT, the DNS client will either 350 fallback to an encrypted connection without authenticating the DNS 351 server provided by the local network or fallback to clear text 352 DNS, and cannot exchange encrypted DNS messages. The fallback 353 adversely impacts security and privacy. If the DNS client has 354 enabled opportunistic privacy profile for DoT, the client MUST NOT 355 process the DNS response with Error Page URI EDNS0 option. 357 o If an DNS client has enabled strict privacy profile (Section 5 of 358 [RFC8310]) for DoT, the DNS client requires an encrypted 359 connection and successful authentication of the DNS server; this 360 mitigates both passive eavesdropping and client redirection (at 361 the expense of providing no DNS service if an encrypted, 362 authenticated connection is not available). If the DNS client has 363 enabled strict privacy profile for DoT, the client can process the 364 DNS response with Error Page URI EDNS0 option. Note that the 365 strict and opportunistic privacy profiles as defined in [RFC8310] 366 only applies to DoT protocol, there has been no such distinction 367 made for DoH protocol. 369 o If the DNS response contains more than one Error Page URI EDNS0 370 option, the DNS client MUST discard all Error Page URI EDNS0 371 options in the DNS response. 373 o The Error Page URI EDNS0 option MUST be processed by the DNS 374 client for a "Censored", "Blocked", "Filtered" or "Forged" 375 extended error codes and MUST be ignored for any other type of 376 extended DNS error code. When "Censored", "Blocked", "Filtered" 377 or "Forged" extended error code is returned in conjunction with an 378 Error Page URI EDNS0 option, any other resource records in the 379 answer MUST be ignored by clients supporting this specification. 381 o If the DNS client determines that the encrypted DNS server does 382 not offer DNS filtering service, it MUST reject the Error Page URI 383 EDNS0 option. For example, the DNS client knows whether the pre- 384 configured encrypted DNS resolver performs DNS-based content 385 filtering or not. 387 o The DNS client MUST reject the error page URI if the scheme is not 388 "https". 390 o The DNS client verifies the signature in the ERROR-PAGE-SIG field 391 (Figure 1) following the mechanism discussed in Section 5. If the 392 signature is valid, the client can positively identify that the 393 Error Page URI EDNS0 option has been generated by the encrypted 394 DNS server and the encrypted DNS server did not forward the Error 395 Page URI EDNS0 option from an upstream resolver. If signature 396 validation fails, the DNS client MUST reject the Error Page URI 397 EDNS0 option. 399 A DNS resolver or forwarder MUST NOT propagate a received Error Page 400 URI EDNS0 option over an unencrypted connection because an attacker 401 can insert a bogus URI. However, when a resolver or forwarder 402 receives an Error Page URI EDNS0 option over an encrypted connection, 403 whether or not to pass along Error Page URI EDNS0 option on to the 404 original client is implementation dependent. If the Implementation 405 chooses to forward the Error Page URI EDNS0 option received over an 406 encrypted connection, it MUST create a new Error Page URI EDNS0 407 option that conveys the URI in the received Error Page URI EDNS0 408 option after successful signature validation. The signature for the 409 new Error Page URI EDNS0 option MUST be generated using the private 410 key of the DNS resolver or forwarder end-entity certificate used in 411 the TLS connection to the original client. If signature validation 412 fails for the received Error Page URI EDNS0 option, the DNS resolver 413 or forwarder end-entity certificate MUST reject the Error Page URI 414 EDNS0 option. 416 The DNS resolver or forwarder MUST NOT modify the ERROR-PAGE-URI 417 field (Figure 1) in the forwarded Error Page URI EDNS0 option. 419 If the resolver or forwarder simply forwards the received Error Page 420 URI EDNS0 option without updating the signature in the ERROR-PAGE-SIG 421 field (Figure 1), signature validation by the original client will 422 fail and the forwarded Error Page URI EDNS0 option will be rejected. 423 As a reminder, Section 3 of [RFC8914] discusses the source of the 424 error should be attributed in the EXTRA-TEXT field, since an EDNS0 425 option received by the original client will appear to have come from 426 the resolver or forwarder sending it. Because DNS forwarders (or DNS 427 proxies) are supposed to propagate unknown EDNS0 options (Sections 428 4.1 and 4.4.1 of [RFC5625]), the Error Page URI EDNS0 option may get 429 propagated. To detect this scenario, the Error Page URI Template is 430 protected with an object signature as described in Section 5 to 431 provide authenticated information. 433 5. Sign and Verify 435 The algorithms for generating signature for DNS resource record sets 436 (RRsets) are defined in [DNSKEY-IANA]. The "mandatory-to-implement" 437 algorithms are RSA, Elliptic Curve Digital Signature Algorithm 438 (ECDSA), and Edwards-curve Digital Security Algorithm (EdDSA) 439 [RFC8624]. Along similar lines, the encrypted DNS server's end- 440 entity certificate's public key and the signature algorithm with 441 which the key can be used are RSA, ECDSA, and EdDSA [RFC8446]. If 442 ECDSA is used, it is RECOMMENDED to use the deterministic digital 443 signature generation procedure of the ECDSA, specified in [RFC6979]. 445 The signature is generated by the encrypted DNS server using the 446 Error Page URI Template, private key of the encrypted DNS server's 447 end-entity certificate as inputs to the signature algorithm. The 448 signature algorithm in the ERROR-PAGE-SIG-ALG field MUST be 449 compatible with the key in the DNS server's end-entity certificate. 450 The implementation MUST support the same set of algorithms in the TLS 451 client for validating the signature in the CertificateVerify message 452 from the server in the TLS handshake and in the DNS client to 453 validate the signature for the Error Page URI Template. As a 454 reminder, the server's end-entity certificate's public key will be 455 compatible with the selected authentication algorithm from the 456 client's "signature_algorithms" TLS extension (Section 4.4.2.2 of 457 [RFC8446]). 459 If the signature algorithm in the ERROR-PAGE-SIG-ALG field is not 460 compatible with the key in the DNS server's end-entity certificate, 461 the DNS client MUST reject the Error Page URI EDNS0 option. The DNS 462 client verifies the signature using the signature in the ERROR-PAGE- 463 SIG field, Error Page URI Template and DNS server's end-entity 464 certificate's public key as inputs to the signature algorithm. For 465 example, if Ed25519 is used, Ed25519 signature algorithm and 466 verification of the Ed25519 signature are described in Sections 5.1.6 467 and 5.1.7 of [RFC8032], respectively. 469 6. Error Page 471 The following outlines the RECOMMENDED contents of an error page to 472 assist the operator developing the error page: 474 o The exact reason for blocking access to the domain. If the domain 475 is blocked based on some threat data, the threat type associated 476 with the blocked domain can be provided/displayed to the end user. 477 For example, the reason can indicate the type of malware blocked 478 like spyware and the damage it can do the security and privacy of 479 the user. 481 o The domain name blocked. 483 o If query was blocked by regulation, a pointer to a regulatory text 484 that mandates this query block. 486 o The entity (or organization) blocking the access to the domain and 487 contact details of the IT/InfoSec team to raise a complaint. 489 o The blocked error page to not include Ads and dynamic content. 491 The content of the error page discussed above is non-normative, the 492 above text only provides the guidelines and template for the error 493 page and: 495 o does not attempt to offer an exhaustive list for the contents of 496 an error page. 498 o it is not intended to form the basis of any legal/compliance for 499 developing the error page. 501 7. Usability Considerations 503 The error page SHOULD be returned in the user's preferred language as 504 expressed by the Accept-Language HTTP header. 506 8. Security Considerations 508 Security considerations in Section 6 of [RFC8914] and [RFC8624] need 509 to be taken into consideration. 511 The Error Page URI EDNS0 option causes an HTTPS retrieval by the 512 client. To prevent forgery of the Error Page URI EDNS0 option, this 513 specification requires it only be sent only over an encrypted DNS 514 channel with an authorized DNS server. 516 The client knows it is connecting to a HTTPS server returning the 517 error page. To reduce threat surface the client can retrieve the 518 Error page URL using, for example, an isolated environment and take 519 other precautions such as clearly labeling the page as untrusted or 520 prevent user interaction with the page. Such isolation should 521 prevent transmitting cookies, block JavaScript, block auto-fill of 522 credentials or personal information, and be isolated from the user's 523 normal environment. 525 Browsers perform some of the above restrictions when accessing 526 captive portals (Section 5 of [RFC8910] or [Safari-Cookie]), during 527 private browsing, or using containerization [Facebook-Container]. 529 Note that the means to use a sandbox environment and a user interface 530 presenting the error page are not covered in this document. By its 531 nature, these aspects are implementation specific and best left to 532 the application and user interface designers. 534 The encrypted DNS session provides transport security for the 535 interaction between the DNS client and server, but DNSSEC signing and 536 validation is not possible for the Error Page URI EDNS0 option 537 returning the Error Page URI Template. However, the signature in the 538 Error Page URI EDNS0 option provides authentication for the Error 539 Page URI EDNS0 option. 541 By design, the object referenced by the error page URL potentially 542 exposes additional information about the DNS resolution process that 543 may leak information. An example of this is the reason for blocking 544 the access to the domain name and the entity blocking access to the 545 domain. 547 9. IANA Considerations 549 9.1. A New Error Page URI EDNS Option 551 This document defines a new EDNS(0) option, entitled "Error Page 552 URI", assigned a value of TBD from the "DNS EDNS0 Option Codes (OPT)" 553 registry [to be removed upon publication: 554 [http://www.iana.org/assignments/dns-parameters/dns- 555 parameters.xhtml#dns-parameters-11] 557 Value Name Status Reference 558 ----- ---------------- ------ ------------------ 559 TBD Error Page URI Standard [ This document ] 561 10. Acknowledgements 563 Thanks to Vittorio Bertola, Wes Hardaker, Ben Schwartz, Erid Orth, 564 Viktor Dukhovni, Warren Kumari and Bob Harold for the comments. 566 11. References 568 11.1. Normative References 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, 572 DOI 10.17487/RFC2119, March 1997, 573 . 575 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 576 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 577 . 579 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 580 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 581 . 583 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 584 Housley, R., and W. Polk, "Internet X.509 Public Key 585 Infrastructure Certificate and Certificate Revocation List 586 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 587 . 589 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 590 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 591 . 593 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 594 Verification of Domain-Based Application Service Identity 595 within Internet Public Key Infrastructure Using X.509 596 (PKIX) Certificates in the Context of Transport Layer 597 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 598 2011, . 600 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 601 and D. Orchard, "URI Template", RFC 6570, 602 DOI 10.17487/RFC6570, March 2012, 603 . 605 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 606 for DNS (EDNS(0))", STD 75, RFC 6891, 607 DOI 10.17487/RFC6891, April 2013, 608 . 610 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 611 Algorithm (DSA) and Elliptic Curve Digital Signature 612 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 613 2013, . 615 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 616 "Recommendations for Secure Use of Transport Layer 617 Security (TLS) and Datagram Transport Layer Security 618 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 619 2015, . 621 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 622 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 623 DOI 10.17487/RFC7540, May 2015, 624 . 626 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 627 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 628 May 2017, . 630 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 631 for DNS over TLS and DNS over DTLS", RFC 8310, 632 DOI 10.17487/RFC8310, March 2018, 633 . 635 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 636 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 637 . 639 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 640 Requirements and Usage Guidance for DNSSEC", RFC 8624, 641 DOI 10.17487/RFC8624, June 2019, 642 . 644 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 645 Lawrence, "Extended DNS Errors", RFC 8914, 646 DOI 10.17487/RFC8914, October 2020, 647 . 649 [TLS-SIG-SCHEME] 650 "IANA, TLS SignatureScheme", 651 . 654 11.2. Informative References 656 [Chrome-Install-Cert] 657 "How to manually install the Securly SSL certificate in 658 Chrome", . 662 [Chrome-Translate] 663 "Google Translate", 664 . 668 [DNSKEY-IANA] 669 "IANA, Domain Name System Security (DNSSEC) Algorithm 670 Numbers", 671 . 673 [Facebook-Container] 674 "Facebook container for Firefox", 675 . 678 [I-D.ietf-dnsop-terminology-ter] 679 Hoffman, P., "Terminology for DNS Transports and 680 Location", draft-ietf-dnsop-terminology-ter-02 (work in 681 progress), August 2020. 683 [I-D.ietf-dprive-dnsoquic] 684 Huitema, C., Mankin, A., and S. Dickinson, "Specification 685 of DNS over Dedicated QUIC Connections", draft-ietf- 686 dprive-dnsoquic-01 (work in progress), October 2020. 688 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 689 and P. Hoffman, "Specification for DNS over Transport 690 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 691 2016, . 693 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 694 Signature Algorithm (EdDSA)", RFC 8032, 695 DOI 10.17487/RFC8032, January 2017, 696 . 698 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 699 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 700 . 702 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 703 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 704 January 2019, . 706 [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in 707 DHCP and Router Advertisements (RAs)", RFC 8910, 708 DOI 10.17487/RFC8910, September 2020, 709 . 711 [Safari-Cookie] 712 "Isolated cookie store (CVE-2016-1730)", 713 . 715 Authors' Addresses 717 Tirumaleswar Reddy 718 McAfee, Inc. 719 Embassy Golf Link Business Park 720 Bangalore, Karnataka 560071 721 India 723 Email: kondtir@gmail.com 725 Neil Cook 726 Open-Xchange 727 UK 729 Email: neil.cook@noware.co.uk 731 Dan Wing 732 Citrix Systems, Inc. 733 USA 735 Email: dwing-ietf@fuggles.com 737 Mohamed Boucadair 738 Orange 739 Rennes 35000 740 France 742 Email: mohamed.boucadair@orange.com