idnits 2.17.1 draft-reddy-dprive-dprive-privacy-policy-03.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 (March 3, 2020) is 1508 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) ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-16) exists of draft-ietf-dnsop-extended-error-14 == Outdated reference: A later version (-14) exists of draft-ietf-dprive-bcp-op-08 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-07 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 4, 2020 Citrix 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 March 3, 2020 12 DNS Server Privacy Statement and Filtering Policy with Assertion Token 13 draft-reddy-dprive-dprive-privacy-policy-03 15 Abstract 17 Users may want to control how their DNS queries are handled by DNS 18 servers so they can configure their system to use DNS servers that 19 comply with their privacy and DNS filtering expectations. 21 This document defines a mechanism for a DNS server to communicate its 22 privacy statement URL and filtering policy to a DNS client. This 23 communication is cryptographically signed to attest its authenticity. 24 By evaluating the DNS privacy statement, filtering policy and the 25 signatory, the user can choose a DNS server that best supports his/ 26 her desired privacy and filtering policy. This token is particularly 27 useful for DNS-over-TLS and DNS-over-HTTPS servers that are either 28 public resolvers or are discovered on a local network. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 4, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Use Cases Overview . . . . . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Policy Assertion Token (PAT): Overview . . . . . . . . . . . 5 68 5. PAT Header . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. 'typ' (Type) Header Parameter . . . . . . . . . . . . . . 6 70 5.2. 'alg' (Algorithm) Header Parameter . . . . . . . . . . . 6 71 5.3. 'x5u' (X.509 URL) Header Parameter . . . . . . . . . . . 6 72 5.4. An Example of PAT Header . . . . . . . . . . . . . . . . 7 73 6. PAT Payload . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6.1. JWT Defined Claims . . . . . . . . . . . . . . . . . . . 7 75 6.1.1. 'iat' - Issued At Claim . . . . . . . . . . . . . . . 7 76 6.1.2. 'exp' - Expiration Time Claim . . . . . . . . . . . . 7 77 6.2. PAT Specific Claims . . . . . . . . . . . . . . . . . . . 8 78 6.2.1. DNS Server Identity Claims . . . . . . . . . . . . . 8 79 6.2.2. 'policyinfo' (Policy Information) Claim . . . . . . . 8 80 6.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 9 81 7. PAT Signature . . . . . . . . . . . . . . . . . . . . . . . . 9 82 8. Extending PAT . . . . . . . . . . . . . . . . . . . . . . . . 10 83 9. Deterministic JSON Serialization . . . . . . . . . . . . . . 11 84 9.1. Example PAT Deterministic JSON Form . . . . . . . . . . . 11 85 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 12.1. Media Type Registration . . . . . . . . . . . . . . . . 13 89 12.1.1. Media Type Registry Contents Additions Requested . . 13 90 12.2. JSON Web Token Claims Registration . . . . . . . . . . . 14 91 12.2.1. Registry Contents Additions Requested . . . . . . . 14 92 12.3. DNS Resolver Information Registration . . . . . . . . . 14 93 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 94 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 96 14.2. Informative References . . . . . . . . . . . . . . . . . 16 97 Appendix A. Example ES256 based PAT JWS Serialization and 98 Signature . . . . . . . . . . . . . . . . . . . . . 17 99 A.1. X.509 Private Key in PKCS#8 Format for ES256 Example** . 19 100 A.2. X.509 Public Key for ES256 Example** . . . . . . . . . . 19 101 Appendix B. Complete JWS JSON Serialization Representation with 102 multiple Signatures . . . . . . . . . . . . . . . . 19 103 B.1. X.509 Private Key in PKCS#8 format for E384 Example** . . 21 104 B.2. X.509 Public Key for ES384 Example** . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 [RFC7626] discusses DNS privacy considerations in both "on the wire" 110 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 111 [RFC7626] contexts. In recent years there has also been an increase 112 in the availability of "public resolvers" [RFC8499] which DNS clients 113 may be pre-configured to use instead of the default network resolver 114 because they offer a specific feature (e.g., good reachability, 115 encrypted transport, strong privacy policy, (lack of) filtering, 116 etc.). The DNS Recursive Operator Privacy (DROP) statement explained 117 in [I-D.ietf-dprive-bcp-op] outlines the recommended contents an DNS 118 operator should publish, thereby providing a means for users to 119 evaluate the privacy properties of a given DNS service. While a 120 human can review the privacy statement of a DNS server operator, but 121 the challenge is the user has to search to find the URL that points 122 to the human readable privacy policy information of the DNS server. 123 Also, a user does not know if a locally-discovered server performs 124 DNS-based filtering. 126 For DNS servers operated on the local network, the DNS client can be 127 securely bootstrapped to discover and authenticate DNS-over-HTTPS 128 (DoH) [RFC8484] and DNS-over-TLS (DoT) [RFC7858] servers provided by 129 a local network, for example using the technique proposed in 130 [I-D.reddy-dprive-bootstrap-dns-server]. This document defines a 131 retrievable DNS server policy permitting the user to consent to using 132 a certain DNS server that meets their needs. 134 The cryptographically signed policy allows a DNS client to connect to 135 multiple DNS servers and prompt the user to review the DNS privacy 136 statements to select the DNS server that adheres to the privacy 137 preserving data policy and DNS filtering expectations of the user. 138 For example, a browser with pre-configured DNS-over-HTTPS server can 139 discover the DNS-over-HTTPS server provided the local network, 140 connects to both the DNS servers, gets the policy information from 141 each of the DNS servers, validates the signatures and prompts the 142 user to review the privacy policy statements of both the local and 143 public DNS server. If both servers meet the privacy preserving data 144 policy and DNS filtering requirements of the user, the user can 145 select to use the local DNS server. A quality implementation can 146 avoid presenting this information to the user if the DNS server's 147 policies have not changed. 149 2. Use Cases Overview 151 The mechanism for a DNS server to communicate its cryptographically 152 signed policies to a DNS client contribute to solve the following 153 problems in various deployments: 155 o Typically Enterprise networks do not assume that all devices in 156 their network are managed by the IT team or Mobile Device 157 Management (MDM) devices, especially in the quite common BYOD 158 (Bring Your Own Device) scenario. The mechanism specified in this 159 document can be used by users of the BYOD devices to determine if 160 the DNS server on the local network complies with the user's 161 privacy policy and DNS filtering expectations. 163 o The user selects specific well-known networks (e.g., organization 164 for which a user works or a user works temporarily within another 165 corporation) to learn the privacy policy statement and filtering 166 policy of the local DNS server. Then, the user can choose to use 167 the discovered DoT or DoH server. If that discovered DoT/DoH 168 server does not meet the privacy preserving data policy and 169 filtering requirements of the user, the user can instruct the DNS 170 client to take appropriate actions. For example, the action can 171 be to use the local DNS server only to access internal-only DNS 172 names and use another DNS server (adhering with his/her 173 expectations) for public domains. 175 o The policy information signals the presence of DNS-based content 176 filtering in the attached network. If the network is well-known 177 to the user and the local DNS server meets the privacy 178 requirements of the user, the DNS client can continue to use 179 encrypted connection with the local DoT/DoH server. If the error 180 code returned by the DNS server indicates access to the domain is 181 blocked because of internal security policy 182 [I-D.ietf-dnsop-extended-error], the DNS client can securely 183 identify access to the domain is censored by the network. 185 o The signed policy contains an URL that points to a human-readable 186 privacy policy information of the DNS server for the user to 187 review and can make an informed decision whether the DNS server is 188 trustworthy to honor the privacy of the user. The DNS Push 189 Notifications mechanism defined in [I-D.ietf-dnsop-extended-error] 190 can be used by the DNS client to be asynchronously notified when 191 the policy change occurs. The client automatically learns updates 192 to the policy of the DNS server, and whenever the privacy 193 statement of the DNS server changes, the client can notify the 194 user to re-evaluate the updated privacy statement. 196 3. Terminology 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119][RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 This document uses the terms defined in [RFC8499]. 206 4. Policy Assertion Token (PAT): Overview 208 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 209 and related specifications define a standard token format that can be 210 used as a way of encapsulating claimed or asserted information with 211 an associated digital signature using X.509 based certificates. JWT 212 provides a set of claims in JSON format that can accommodate asserted 213 policy information of the DoT/DoH server. Additionally, JWS provides 214 a path for updating methods and cryptographic algorithms used for the 215 associated digital signatures. 217 JWS defines the use of JSON data structures in a specified canonical 218 format for signing data corresponding to JOSE header, JWS Payload, 219 and JWS Signature. The next sections define the header and claims 220 that MUST be minimally used with JWT and JWS for privacy assertion 221 token. 223 The Policy Assertion Token (PAT) specifically uses this token format 224 and defines claims that convey the policy information of DoT/ DoH 225 server. The client can retrieve the PAT object using the method 226 discussed in [I-D.ietf-dnsop-resolver-information]. The signature of 227 PAT object can be validated by the DNS client. If the signer and the 228 contents of the PAT object comply with the user's requirements, the 229 user's client software can use that DNS server. 231 The PAT object is signed by the DNS server's domain that is 232 authoritative to assert the DNS server policy information. This 233 authority is represented by the certificate credentials and the 234 signature. 236 For example, the PAT object could be created by the domain hosting 237 the DoT/DoH server and optionally by a third party who performed 238 privacy and security audit of the DoT/DoH server. The DNS client 239 needs to have the capability to verify the digital signature and to 240 parse the PAT object. 242 5. PAT Header 244 The JWS token header is a JOSE header (Section 4 of [RFC7515]) that 245 defines the type and encryption algorithm used in the token. 247 PAT header MUST include, at a minimum, the header parameters defined 248 in Sections 5.1, 5.2, and 5.3. 250 5.1. 'typ' (Type) Header Parameter 252 The 'typ' (Type) Header Parameter is defined Section 4.1.9 of 253 [RFC7515] to declare the media type of the complete JWS. 255 For PAT Token the 'typ' header MUST be the string 'pat'. This 256 represents that the encoded token is a JWT of type pat. 258 5.2. 'alg' (Algorithm) Header Parameter 260 The 'alg' (Algorithm) Header Parameter is defined in Section 4.1.1 of 261 [RFC7515]. It specifies the JWS signature cryptographic algorithm. 262 It also refers to a list of defined 'alg' values as part of a 263 registry established by JSON Web Algorithms (JWA) [RFC7518] 264 Section 3.1. 266 For the creation and verification of PAT tokens and their digital 267 signatures, implementations MUST support ES256 as defined in 268 Section 3.4 of [RFC7518]. Implementations MAY support other 269 algorithms registered in the JSON Web Signature and Encryption 270 Algorithms registry created by [RFC7518]. The content of that 271 registry may be updated in the future depending on cryptographic 272 strength requirements guided by current security best practice. The 273 mandatory-to-support algorithm for PAT tokens may likewise be updated 274 in the future. 276 Implementations of PAT digital signatures using ES256 as defined 277 above SHOULD use deterministic ECDSA when supported for the reasons 278 stated in [RFC6979]. 280 5.3. 'x5u' (X.509 URL) Header Parameter 282 As defined in Section 4.1.5 of [RFC7515], the 'x5u' header parameter 283 defines a URI [RFC3986] referring to the resource for the X.509 284 public key certificate or certificate chain [RFC5280] corresponding 285 to the key used to digitally sign the JWS. Generally, as defined in 286 Section 4.1.5 of [RFC7515] this corresponds to an HTTPS or DNSSEC 287 resource using integrity protection. 289 5.4. An Example of PAT Header 291 An example of the PAT header is shown in Figure 1. It includes the 292 specified PAT type, ES256 algorithm, and an URI referencing the 293 network location of the certificate needed to validate the PAT 294 signature. 296 { 297 "typ":"pat", 298 "alg":"ES256", 299 "x5u":"https://cert.example.com/pat.cer" 300 } 302 Figure 1: A PAT Header Example 304 6. PAT Payload 306 The token claims consists of the policy information of the DNS server 307 which needs to be verified at the DNS client. These claims follow 308 the definition of a JWT claim (Secion 4 of [RFC7519]) and are encoded 309 as defined by the JWS Payload (Section 3 of [RFC7515]). 311 PAT defines the use of a standard JWT-defined claim as well as custom 312 claims corresponding to the DoT or DoH servers. 314 Claim names MUST use the US-ASCII character set. Claim values MAY 315 contain characters that are outside the ASCII range, however they 316 MUST follow the default JSON serialization defined in Section 7 of 317 [RFC7519]. 319 6.1. JWT Defined Claims 321 6.1.1. 'iat' - Issued At Claim 323 The JSON claim MUST include the 'iat' (Section 4.1.6 of [RFC7519]) 324 defined claim "Issued At". The 'iat' should be set to the date and 325 time of issuance of the JWT. The time value should be of the format 326 (NumericDate) defined in Section 2 of [RFC7519]. 328 6.1.2. 'exp' - Expiration Time Claim 330 The JSON claim MUST include the 'exp' (Section 4.1.4 of [RFC7519]) 331 defined "claim Expiration Time". The 'exp' should be set to specify 332 the expiration time on or after which the JWT is not accepted for 333 processing. The PAT object should expire after a reasonable 334 duration. A short expiration time for the PAT object periodically 335 reaffirms the policy information of the DNS server to the DNS client 336 and ensures the DNS client does not use outdated policy information. 337 If the DNS client knows the PAT object has expired, it should make 338 another request to get the new PAT object from the DNS server. 340 6.2. PAT Specific Claims 342 6.2.1. DNS Server Identity Claims 344 The DNS server identity is represented by a claim that is required 345 for PAT: the 'server' claim. The 'server' MUST contain claim values 346 that are identity claim JSON objects where the child claim name 347 represents an identity type and the claim value is the identity 348 string, both defined in subsequent subsections. 350 These identities can be represented as either authentication domain 351 name (ADN) (defined in [RFC8310]) or Uniform Resource Indicators 352 (URI). 354 6.2.1.1. 'adn' - Authentication Domain Name Identity 356 If the DNS server identity is an ADN, the claim name representing the 357 identity MUST be 'adn'. The claim value for the 'adn' claim is the 358 ADN. 360 6.2.1.2. 'uri' - URI Identity 362 If the DNS server identity is of the form URI, as defined in 363 [RFC3986], the claim name representing the identity MUST be 'uri' and 364 the claim value is the URI form of the DNS server identity. 366 As a reminder, if DoH is supported by the DNS server, the DNS client 367 uses the https URI scheme (Section 3 of [RFC8484]). 369 6.2.2. 'policyinfo' (Policy Information) Claim 371 The 'policyinfo' claim MUST be formatted as a JSON object. The 372 'policyinfo' claim contains the policy information of the DNS server, 373 it includes the following attributes: 375 filtering: If the DNS server changes some of the answers that it 376 returns based on policy criteria, such as to prevent access to 377 malware sites or objectionable content. This optional attribute 378 has the following structure: 380 malwareblocking: The DNS server offers malware blocking service. 381 If access to domains is blocked on threat data, the parameter 382 value is set to 'true'. 384 policyblocking: If access to domains is blocked on a blacklist or 385 objectionable content, the parameter value is set to 'true'. 387 qnameminimization: If the DNS server implements QNAME minimisation 388 [RFC7816] to improve DNS privacy. If the parameter value is set 389 to 'true', QNAME minimisation is supported by the DNS server. 390 This is a mandatory attribute. 392 privacyurl: A URL that points to the privacy policy information of 393 the DNS server. This is a mandatory attribute. 395 auditurl: A URL that points to the security assessment report of the 396 DNS server by a third party auditor. This is an optional 397 attribute. 399 6.2.3. Example 401 Figure 2 shows an example of policy information. 403 { 404 "server":{ 405 "adn":["example.com"] 406 }, 407 "iat":1443208345, 408 "exp":1443640345, 409 "policyinfo": { 410 "filtering": { 411 "malwareblocking": true, 412 "policyblocking": false 413 }, 414 "qnameminimization":false, 415 "privacyurl": "https://example.com/commitment-to-privacy/" 416 } 417 } 419 Figure 2: An Example of Policy Information 421 7. PAT Signature 423 The signature of the PAT is created as specified in Section 5.1 of 424 [RFC7515] (Steps 1 through 6). PAT MUST use the JWS Protected 425 Header. 427 For the JWS Payload and the JWS Protected Header, the lexicographic 428 ordering and white space rules described in Section 5 and Section 6, 429 and JSON serialization rules in Section 9 MUST be followed. 431 The PAT is cryptographically signed by the domain hosting the DNS 432 server and optionally by a third party who performed privacy and 433 security audit of the DNS server. 435 The policy information is attested using "Organization Validation" 436 (OV) or "Extended Validation" (EV) certificates to avoid bad actors 437 taking advantage of this mechanism to advertise DoH/DoT servers for 438 illegitimate and fraudulent purposes meant to trick DNS clients into 439 believing that they are using a legitimate DoT/DoH server hosted to 440 provide privacy for DNS transactions. 442 Alternatively, a DNS client has to be configured to trust the leaf of 443 the signer of the PAT object. That is, trust of the signer MUST NOT 444 be determined by validating the signer via the OS or the browser 445 trust chain because that would allow any arbitrary entity to operate 446 a DNS server and assert any sort of policy. 448 Appendix A provides an example of how to follow the steps to create 449 the JWS Signature. 451 JWS JSON serialization (Step 7 in Section 5.1 of [RFC7515]) is 452 supported for PAT to enable multiple signatures to be applied to the 453 PAT object. For example, the PAT object can be cryptographically 454 signed by the domain hosting the DNS server and by a third party who 455 performed privacy and security audit of the DNS server. 457 Appendix B includes an example of the full JWS JSON serialization 458 representation with multiple signatures. 460 Section 5.1 of [RFC7515] (Step 8) describes the method to create the 461 final JWS Compact Serialization form of the PAT Token. 463 8. Extending PAT 465 PAT includes the minimum set of claims needed to securely assert the 466 policy information of the DNS server. JWT supports a mechanism to 467 add additional asserted or signed information by simply adding new 468 claims. PAT can be extended beyond the defined base set of claims to 469 represent other DNS server information requiring assertion or 470 validation. Specifying new claims follows the baseline JWT 471 procedures (Section 10.1 of [RFC7519]). Understanding new claims on 472 the DNS client is optional. The creator of a PAT object cannot 473 assume that the DNS client will understand the new claims. 475 9. Deterministic JSON Serialization 477 JSON objects can include spaces and line breaks, and key value pairs 478 can occur in any order. It is therefore a non-deterministic string 479 format. In order to make the digital signature verification work 480 deterministically, the JSON representation of the JWS Protected 481 Header object and JWS Payload object MUST be computed as follows. 483 The JSON object MUST follow the following rules. These rules are 484 based on the thumbprint of a JSON Web Key (JWK) as defined in 485 Section 3 of [RFC7638] (Step 1). 487 1. The JSON object MUST contain no whitespace or line breaks before 488 or after any syntactic elements. 490 2. JSON objects MUST have the keys ordered lexicographically by the 491 Unicode [UNICODE] code points of the member names. 493 3. JSON value literals MUST be lowercase. 495 4. JSON numbers are to be encoded as integers unless the field is 496 defined to be encoded otherwise. 498 5. Encoding rules MUST be applied recursively to member values and 499 array values. 501 9.1. Example PAT Deterministic JSON Form 503 This section demonstrates the deterministic JSON serialization for 504 the example PAT Payload shown in Section 6.2.3. 506 The initial JSON object is shown in Figure 3. 508 { 509 "server":{ 510 "adn":["example.com"] 511 }, 512 "iat":1443208345, 513 "exp":1443640345, 514 "policyinfo": { 515 "qnameminimization":false, 516 "privacyurl": "https://example.com/commitment-to-privacy/" 517 } 518 } 520 Figure 3: Initial JSON Object 522 The parent members of the JSON object are as follows, in 523 lexicographic order: "exp", "iat", "policyinfo", "server". 525 The final constructed deterministic JSON serialization 526 representation, with whitespace and line breaks removed, (with line 527 breaks used for display purposes only) is: 529 {"exp":1443640345,"iat":1443208345, 530 "policyinfo":{"privacyurl":"https://example.com/commitment-to-privacy/", 531 "qnameminimization":false},"server":{"adn":["example.com"]}} 533 Figure 4: Deterministic JSON Form 535 10. Privacy Considerations 537 Users are expected to indicate to their system in some way that they 538 trust certain PAT signers (e.g., if working for Example, Inc., the 539 user's system is configured to trust "example.com" signing the PAT). 540 By doing so, the DNS client can automatically discover DoT/DoH server 541 in specific networks, validate the PAT signature and the user can 542 check if the human readable privacy policy information of the DNS 543 server complies with user's privacy needs, prior to using that DoT/ 544 DoH server for DNS queries. 546 The DNS client MUST retrieve the human-readable privacy statement 547 from the 'privacyurl' attribute to assist with that decision (e.g., 548 display the privacy statement when it changes, show differences in 549 previously-retrieved version, etc.). With the steps above, user 550 consent is obtained prior to using a DoT/DoH server. 552 11. Security Considerations 554 The use of PAT object based on the validation of the digital 555 signature and the associated certificate requires consideration of 556 the authentication and authority or reputation of the signer to 557 attest the policy information of the DNS server being asserted. Bad 558 actors can host DNS-over-TLS and DNS-over-HTTPS servers, and claim 559 the servers offer privacy but exactly do the opposite to invade the 560 privacy of the user. Bad actor can get a domain name, host DNS-over- 561 TLS and DNS-over-HTTPS servers, and get the DNS server certificate 562 signed by a CA. The policy information will have to be attested 563 using OV/EV certificates or a PAT object signer trusted by the DNS 564 client to prevent the attack. 566 If the PAT object is asserted by a third party, it can do a "time of 567 check" but the DNS server is susceptible of "time of use" attack. 568 For example, changes to the policy of the DNS server can cause a 569 disagreement between the auditor and the DNS server operation, hence 570 the PAT object needs to be also asserted by the domain hosting the 571 DNS server. In addition, the PAT object needs to have a short 572 expiration time (e.g., 7 days) to ensure the DNS server's domain re- 573 asserts the policy information and limits the damage from change in 574 policy and mis-issuance. 576 12. IANA Considerations 578 12.1. Media Type Registration 580 12.1.1. Media Type Registry Contents Additions Requested 582 This section registers the 'application/pat' media type [RFC2046] in 583 the 'Media Types' registry in the manner described in [RFC6838], 584 which can be used to indicate that the content is a PAT defined JWT. 586 o Type name: application 588 o Subtype name: pat 590 o Required parameters: n/a 592 o Optional parameters: n/a 594 o Encoding considerations: 8bit; application/pat values are encoded 595 as a series of base64url-encoded values (some of which may be the 596 empty string) separated by period ('.') characters.. 598 o Security considerations: See the Security Considerations 599 Section of [RFC7515]. 601 o Interoperability considerations: n/a 603 o Published specification: [TODO this document] 605 o Applications that use this media type: DNS 607 o Fragment identifier considerations: n/a 609 o Additional information: 611 Magic number(s): n/a File extension(s): n/a Macintosh file type 612 code(s): n/a 614 o Person & email address to contact for further information: 615 Tirumaleswar Reddy, kondtir@gmail.com 617 o Intended usage: COMMON 618 o Restrictions on usage: none 620 o Author: Tirumaleswar Reddy, kondtir@gmail.com 622 o Change Controller: IESG 624 o Provisional registration? No 626 12.2. JSON Web Token Claims Registration 628 12.2.1. Registry Contents Additions Requested 630 o Claim Name: 'server' 632 o Claim Description: DNS server identity 634 o Change Controller: IESG 636 o Specification Document(s): Section 6.2.1 of [TODO this document] 638 o Claim Name: 'policyinfo' 640 o Claim Description: Policy information of DNS server. 642 o Change Controller: IESG 644 o Specification Document(s): Section 6.2.2 of [TODO this document] 646 12.3. DNS Resolver Information Registration 648 IANA will add the names filtering, qnameminimization, privacyurl and 649 auditurl to the DNS Resolver Information registry defined in 650 Section 5.2 of [I-D.ietf-dnsop-resolver-information]. 652 13. Acknowledgments 654 This specification leverages some of the work that has been done in 655 [RFC8225]. Thanks to Ted Lemon, Paul Wouters and Shashank Jain for 656 the discussion and comments. 658 14. References 660 14.1. Normative References 662 [I-D.ietf-dnsop-resolver-information] 663 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 664 Information Self-publication", draft-ietf-dnsop-resolver- 665 information-01 (work in progress), February 2020. 667 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 668 Extensions (MIME) Part Two: Media Types", RFC 2046, 669 DOI 10.17487/RFC2046, November 1996, 670 . 672 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 673 Requirement Levels", BCP 14, RFC 2119, 674 DOI 10.17487/RFC2119, March 1997, 675 . 677 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 678 Resource Identifier (URI): Generic Syntax", STD 66, 679 RFC 3986, DOI 10.17487/RFC3986, January 2005, 680 . 682 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 683 Housley, R., and W. Polk, "Internet X.509 Public Key 684 Infrastructure Certificate and Certificate Revocation List 685 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 686 . 688 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 689 Specifications and Registration Procedures", BCP 13, 690 RFC 6838, DOI 10.17487/RFC6838, January 2013, 691 . 693 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 694 Algorithm (DSA) and Elliptic Curve Digital Signature 695 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 696 2013, . 698 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 699 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 700 2015, . 702 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 703 DOI 10.17487/RFC7518, May 2015, 704 . 706 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 707 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 708 . 710 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 711 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 712 2015, . 714 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 715 and P. Hoffman, "Specification for DNS over Transport 716 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 717 2016, . 719 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 720 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 721 May 2017, . 723 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 724 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 725 . 727 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 728 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 729 January 2019, . 731 14.2. Informative References 733 [I-D.ietf-dnsop-extended-error] 734 Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 735 Lawrence, "Extended DNS Errors", draft-ietf-dnsop- 736 extended-error-14 (work in progress), January 2020. 738 [I-D.ietf-dprive-bcp-op] 739 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 740 Mankin, "Recommendations for DNS Privacy Service 741 Operators", draft-ietf-dprive-bcp-op-08 (work in 742 progress), January 2020. 744 [I-D.reddy-dprive-bootstrap-dns-server] 745 Reddy.K, T., Wing, D., Richardson, M., and M. Boucadair, 746 "A Bootstrapping Procedure to Discover and Authenticate 747 DNS-over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 748 dprive-bootstrap-dns-server-07 (work in progress), 749 February 2020. 751 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 752 DOI 10.17487/RFC7626, August 2015, 753 . 755 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 756 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 757 . 759 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 760 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 761 . 763 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 764 for DNS over TLS and DNS over DTLS", RFC 8310, 765 DOI 10.17487/RFC8310, March 2018, 766 . 768 [UNICODE] The Unicode Consortium, "The Unicode Standard", June 2016, 769 . 771 Appendix A. Example ES256 based PAT JWS Serialization and Signature 773 For PAT, there will always be a JWS with the following members: 775 o 'protected', with the value BASE64URL(UTF8(JWS Protected Header)) 777 o 'payload', with the value BASE64URL (JWS Payload) 779 o 'signature', with the value BASE64URL(JWS Signature) 781 This example will follow the steps in JWS [RFC7515] Section 5.1, 782 steps 1-6 and 8 and incorporates the additional serialization steps 783 required for PAT. 785 Step 1 for JWS references the JWS Payload, an example PAT Payload is 786 as follows: 788 { 789 "server":{ 790 "adn":["example.com"] 791 }, 792 "iat":1443208345, 793 "exp":1443640345, 794 "policyinfo": { 795 "filtering": { 796 "malwareblocking": true, 797 "policyblocking": false 798 }, 799 "qnameminimization":false, 800 "privacyurl": "https://example.com/commitment-to-privacy/" 801 } 802 } 804 This would be serialized to the form (with line break used for 805 display purposes only): 807 {"exp":1443640345,"iat":1443208345,"policyinfo":{ 808 "filtering":{"malwareblocking": true,"policyblocking": false}, 809 "privacyurl":"https://example.com/commitment-to-privacy/", 810 "qnameminimization":false},"server":{"adn":["example.com"]}} 811 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 812 line break used for display purposes only): 814 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6e 815 yJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9ja2 816 luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9jb21 817 taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNlfSwi 818 c2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0 820 For Step 3, an example PAT Protected Header comprising the JOSE 821 Header is as follows: 823 { 824 "alg":"ES256", 825 "typ":"pat", 826 "x5u":"https://cert.example.com/pat.cer" 827 } 829 This would be serialized to the form (with line break used for 830 display purposes only): 832 {"alg":"ES256","typ":"pat","x5u":"https://cert.example.com 833 /pat.cer"} 835 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 836 and encoding produces this value (with line break used for display 837 purposes only): 839 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 840 eGFtcGxlLmNvbS9wYXQuY2VyIn0 842 Step 5 and Step 6 performs the computation of the digital signature 843 of the PAT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 844 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 845 algorithm and the BASE64URL(JWS Signature). 847 4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBktWVnlmbmyHs05G 848 KauRBdIFnfp3oDPbE0Jq4w 850 Step 8 describes how to create the final PAT token, concatenating the 851 values in the order Header.Payload.Signature with period ('.') 852 characters. For the above example values this would produce the 853 following (with line breaks between period used for readability 854 purposes only): 856 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 857 eGFtcGxlLmNvbS9wYXQuY2VyIn0 858 . 859 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6e 860 yJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9ja2 861 luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9jb21 862 taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNlfSwi 863 c2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0 864 . 865 4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBktWVnlmbmyHs05G 866 KauRBdIFnfp3oDPbE0Jq4w 868 A.1. X.509 Private Key in PKCS#8 Format for ES256 Example** 870 -----BEGIN PRIVATE KEY----- 871 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 872 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 873 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 874 -----END PRIVATE KEY----- 876 A.2. X.509 Public Key for ES256 Example** 878 -----BEGIN PUBLIC KEY----- 879 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 880 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 881 -----END PUBLIC KEY----- 883 Appendix B. Complete JWS JSON Serialization Representation with 884 multiple Signatures 886 The JWS payload used in this example as follows. 888 { 889 "server":{ 890 "adn":["example.com"] 891 }, 892 "iat":1443208345, 893 "exp":1443640345, 894 "policyinfo": { 895 "filtering": { 896 "malwareblocking": true, 897 "policyblocking": false 898 }, 899 "qnameminimization":false, 900 "privacyurl": "https://example.com/commitment-to-privacy/" 901 } 902 } 904 This would be serialized to the form (with line break used for 905 display purposes only): 907 {"exp":1443640345,"iat":1443208345,"policyinfo":{ 908 "filtering":{"malwareblocking": true,"policyblocking": false}, 909 "privacyurl":"https://example.com/commitment-to-privacy/", 910 "qnameminimization":false},"server":{"adn":["example.com"]}} 912 The JWS protected Header value used for the first signature is same 913 as that used in the example in Appendix A. The X.509 private key 914 used for generating the first signature is same as that used in the 915 example in Appendix A.1. 917 The JWS Protected Header value used for the second signature is: 919 { 920 "alg":"ES384", 921 "typ":"pat", 922 "x5u":"https://cert.audit-example.com/pat.cer" 923 } 925 The complete JWS JSON Serialization for these values is as follows 926 (with line breaks within values for display purposes only): 928 { 929 "payload": 930 "eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6 931 eyJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9j 932 a2luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9j 933 b21taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNl 934 fSwic2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0", 935 "signatures":[ 936 {"protected":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 937 zOi8vY2VydC5leGFtcGxlLmNvbS9wYXQuY2VyIn0", 938 "signature": "4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBk 939 tWVnlmbmyHs05GKauRBdIFnfp3oDPbE0Jq4w"}, 940 {"protected":"eyJhbGciOiJFUzM4NCIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 941 zOi8vY2VydC5hdWRpdC1leGFtcGxlLmNvbS9wYXQuY2VyIn0", 942 "signature":666ag_mAqDa3Oyxo1DGXUocr0MmRjpXwq8kWp1S21mvs2-kPCIq3 943 0xsBJt4apy-sq3VyJgIqzjijoFYURhHvupF0obo-IFUGSZ1YHBCX_MiyBwJQJjtp 944 S91ujDatRTtZ"}] 945 } 947 B.1. X.509 Private Key in PKCS#8 format for E384 Example** 949 -----BEGIN PRIVATE KEY----- 950 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 951 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 952 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 953 -----END PRIVATE KEY----- 955 B.2. X.509 Public Key for ES384 Example** 957 -----BEGIN PUBLIC KEY----- 958 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 959 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 960 -----END PUBLIC KEY----- 962 Authors' Addresses 964 Tirumaleswar Reddy 965 McAfee, Inc. 966 Embassy Golf Link Business Park 967 Bangalore, Karnataka 560071 968 India 970 Email: kondtir@gmail.com 971 Dan Wing 972 Citrix Systems, Inc. 973 USA 975 Email: dwing-ietf@fuggles.com 977 Michael C. Richardson 978 Sandelman Software Works 979 USA 981 Email: mcr+ietf@sandelman.ca 983 Mohamed Boucadair 984 Orange 985 Rennes 35000 986 France 988 Email: mohamed.boucadair@orange.com