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