idnits 2.17.1 draft-reddy-add-server-policy-selection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 9, 2020) is 1478 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-05 == Outdated reference: A later version (-16) exists of draft-ietf-dnsop-extended-error-14 == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-terminology-ter-01 == 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 (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ADD WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: October 11, 2020 Citrix 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 April 9, 2020 12 DNS Server Selection: DNS Server Information with Assertion Token 13 draft-reddy-add-server-policy-selection-01 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 particular, the document defines a mechanism for a DNS server to 20 communicate its filtering policy and 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 in 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 October 11, 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 . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . 14 91 12.1.1. Media Type Registry Contents Additions Requested . . 14 92 12.2. JSON Web Token Claims Registration . . . . . . . . . . . 15 93 12.2.1. Registry Contents Additions Requested . . . . . . . 15 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 . . . . . . . . . . . . . . . . . 17 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** . . . . . . . . . . 21 103 Appendix B. Complete JWS JSON Serialization Representation with 104 multiple Signatures . . . . . . . . . . . . . . . . 21 105 B.1. X.509 Private Key in PKCS#8 format for E384 Example** . . 22 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. Two protocols that provide encrypted channels 114 between DNS clients and servers are DNS-over-HTTPS (DoH) [RFC8484] 115 and DNS-over-TLS (DoT) [RFC7858]. 117 DNS clients can discover and authenticate DoH and DoT servers 118 provided by a local network, for example using the techniques 119 proposed in [I-D.btw-add-home]. If the mechanism used to discover 120 the DoH/DoT server is insecure, the DNS client needs evidence about 121 the DoH/DoT server to assess its trustworthiness and a way to 122 appraise such evidence. The mechanism specified in this document can 123 be used by the DNS client to cryptographically identify it is 124 connecting to a DoT/DoH server hosted by a specific organization 125 (e.g., ISP or Enterprise). 127 The DNS Recursive Operator Privacy (DROP) statement explained in 128 [I-D.ietf-dprive-bcp-op] outlines the recommended contents a DNS 129 operator should publish, thereby providing a means for users to 130 evaluate the privacy properties of a given DNS service. While a 131 human can review the privacy statement of a DNS server operator, the 132 challenge is the user has to search to find the URL that points to 133 the human readable privacy policy information of the DNS server. 134 Also, a user does not know if a DNS server (public or local) performs 135 DNS-based content filtering. 137 This document simplifies the user experience by supporting a 138 mechanism to retrieve the DNS server policy permitting the user to 139 review human-readable privacy policy information of the DNS server 140 and to assess whether that DNS server performs DNS-based content 141 filtering. 143 This document also defines a mechanism for DNS clients to gather a 144 set of information related to discovered (or pre-configured) servers 145 and use that information to fed a DNS server selection procedure. 146 The following parameters are supported in this version: 148 Malware blocking: Indicates whether the DNS server offers malware 149 blocking service. 151 Policy blocking: Indicates whether the DNS server maintains a block- 152 list (e.g., imposed by regulation). 154 QNAME minimization: Indicates whether the DNS server implements 155 QNAME minimisation [RFC7816]. 157 The cryptographically signed policy allows a DNS client to, e.g., 158 connect to multiple DNS servers and prompt the user to review the DNS 159 privacy statements to select the DNS server that adheres to the 160 privacy preserving data policy and DNS filtering expectations of the 161 user. How a user instructs a DNS client about his/her preferences 162 and how/whether the DNS client prompts a user are out of scope. 164 2. Sample Use Cases 166 The mechanism for a DNS server to communicate its cryptographically 167 signed policies to DNS clients contributes to solve the following 168 problems in various deployments: 170 o The DoH/DoT server advertised using DHCP/RA in Home and Mobile 171 networks is insecure, the mechanism specified in this document can 172 be used by the DNS client to validate the signatory (e.g., 173 cryptographically attested by the ISP). 175 o Typically Enterprise networks do not assume that all devices in 176 their network are managed by the IT team or Mobile Device 177 Management (MDM) devices, especially in the quite common BYOD 178 (Bring Your Own Device) scenario. The mechanism specified in this 179 document can be used by users of the BYOD devices to determine if 180 the DNS server on the local network complies with their user's 181 privacy policy and DNS filtering expectations. 183 o The user selects specific well-known networks (e.g., organization 184 for which a user works or a user works temporarily within another 185 corporation) to learn the privacy policy statement and filtering 186 policy of the local DNS server. If the discovered DoH/DoT server 187 does not meet the privacy preserving data policy and filtering 188 requirements of the user, the DNS client can take appropriate 189 actions. For example, the action can be to use the discovered DNS 190 server only to access internal-only DNS names and use another DNS 191 server (adhering with the user's expectations) for public domains. 193 o The policy information signals the presence of DNS-based content 194 filtering in the attached network. If the network is well-known 195 to the DNS client and the local DNS server meets the privacy 196 requirements of the user, the DNS client can continue to use 197 encrypted connection with the local DoH/DoT server. If the error 198 code returned by the DNS server indicates access to the domain is 199 blocked because of internal security policy 200 [I-D.ietf-dnsop-extended-error], the DNS client can securely 201 identify access to the domain is censored by the network. 203 o The signed policy contains an URL that points to a human-readable 204 privacy policy information of the DNS server for the user to 205 review and can make an informed decision whether the DNS server is 206 trustworthy to honor the privacy of the user. The DNS Push 207 Notifications mechanism defined in [I-D.ietf-dnssd-push] can be 208 used by the DNS client to be asynchronously notified when the 209 policy change occurs. The client automatically learns updates to 210 the policy of the DNS server, and whenever the privacy statement 211 of the DNS server changes, the client can notify the user to re- 212 evaluate the updated privacy statement. As a reminder, DNS Push 213 Notification is only defined for TLS over TCP. DNS client 214 implementations that do not support DNS Push Notifications can use 215 the mechanism discussed in Section 6.1.2 to identify policy 216 updates. 218 3. Terminology 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 222 "OPTIONAL" in this document are to be interpreted as described in BCP 223 14 [RFC2119][RFC8174] when, and only when, they appear in all 224 capitals, as shown here. 226 This document makes use of the terms defined in [RFC8499] and 227 [I-D.ietf-dnsop-terminology-ter]. 229 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 231 4. Policy Assertion Token (PAT): Overview 233 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 234 and related specifications define a standard token format that can be 235 used as a way of encapsulating claimed or asserted information with 236 an associated digital signature using X.509 based certificates. JWT 237 provides a set of claims in JSON format that can accommodate asserted 238 policy information of the DoH/DoT server. Additionally, JWS provides 239 a path for updating methods and cryptographic algorithms used for the 240 associated digital signatures. 242 JWS defines the use of JSON data structures in a specified canonical 243 format for signing data corresponding to JOSE header, JWS Payload, 244 and JWS Signature. The next sections define the header and claims 245 that MUST be minimally used with JWT and JWS for privacy assertion 246 token. 248 The Policy Assertion Token (PAT) specifically uses this token format 249 and defines claims that convey the policy information of DoH/DoT 250 server. The client can retrieve the PAT object using the method 251 discussed in [I-D.ietf-dnsop-resolver-information]. The signature of 252 PAT object can be validated by the DNS client. If the signer and the 253 contents of the PAT object comply with the user's requirements, the 254 user's client software can use that DNS server. 256 The PAT object is signed by the DNS server's domain that is 257 authoritative to assert the DNS server policy information. This 258 authority is represented by the certificate credentials and the 259 signature. 261 For example, the PAT object could be created by the organization 262 hosting the DoH/DoT server and optionally by a third party who 263 performed privacy and security audit of the DoH/DoT server. The DNS 264 client needs to have the capability to verify the digital signature 265 and to parse the PAT object. 267 5. PAT Header 269 The JWS token header is a JOSE header (Section 4 of [RFC7515]) that 270 defines the type and encryption algorithm used in the token. 272 PAT header MUST include, at a minimum, the header parameters defined 273 in Sections 5.1, 5.2, and 5.3. 275 5.1. 'typ' (Type) Header Parameter 277 The 'typ' (Type) Header Parameter is defined Section 4.1.9 of 278 [RFC7515] to declare the media type of the complete JWS. 280 For PAT Token the 'typ' header MUST be the string 'pat'. This 281 represents that the encoded token is a JWT of type pat. 283 5.2. 'alg' (Algorithm) Header Parameter 285 The 'alg' (Algorithm) Header Parameter is defined in Section 4.1.1 of 286 [RFC7515]. It specifies the JWS signature cryptographic algorithm. 287 It also refers to a list of defined 'alg' values as part of a 288 registry established by JSON Web Algorithms (JWA) [RFC7518] 289 Section 3.1. 291 For the creation and verification of PAT tokens and their digital 292 signatures, implementations MUST support ES256 as defined in 293 Section 3.4 of [RFC7518]. Implementations MAY support other 294 algorithms registered in the JSON Web Signature and Encryption 295 Algorithms registry created by [RFC7518]. The content of that 296 registry may be updated in the future depending on cryptographic 297 strength requirements guided by current security best practice. The 298 mandatory-to-support algorithm for PAT tokens may likewise be updated 299 in the future. 301 Implementations of PAT digital signatures using ES256 as defined 302 above SHOULD use deterministic ECDSA when supported for the reasons 303 stated in [RFC6979]. 305 5.3. 'x5u' (X.509 URL) Header Parameter 307 As defined in Section 4.1.5 of [RFC7515], the 'x5u' header parameter 308 defines a URI [RFC3986] referring to the resource for the X.509 309 public key certificate or certificate chain [RFC5280] corresponding 310 to the key used to digitally sign the JWS. Generally, as defined in 311 Section 4.1.5 of [RFC7515] this corresponds to an HTTPS or DNSSEC 312 resource using integrity protection. 314 5.4. An Example of PAT Header 316 An example of the PAT header is shown in Figure 1. It includes the 317 specified PAT type, ES256 algorithm, and an URI referencing the 318 network location of the certificate needed to validate the PAT 319 signature. 321 { 322 "typ":"pat", 323 "alg":"ES256", 324 "x5u":"https://cert.example.com/pat.cer" 325 } 327 Figure 1: A PAT Header Example 329 6. PAT Payload 331 The token claims consists of the policy information of the DNS server 332 which needs to be verified at the DNS client. These claims follow 333 the definition of a JWT claim (Secion 4 of [RFC7519]) and are encoded 334 as defined by the JWS Payload (Section 3 of [RFC7515]). 336 PAT defines the use of a standard JWT-defined claim as well as custom 337 claims corresponding to the DoT or DoH servers. 339 Claim names MUST use the US-ASCII character set. Claim values MAY 340 contain characters that are outside the ASCII range, however they 341 MUST follow the default JSON serialization defined in Section 7 of 342 [RFC7519]. 344 6.1. JWT Defined Claims 346 6.1.1. 'iat' - Issued At Claim 348 The JSON claim MUST include the 'iat' (Section 4.1.6 of [RFC7519]) 349 defined claim "Issued At". The 'iat' should be set to the date and 350 time of issuance of the JWT. The time value should be of the format 351 (NumericDate) defined in Section 2 of [RFC7519]. 353 6.1.2. 'exp' - Expiration Time Claim 355 The JSON claim MUST include the 'exp' (Section 4.1.4 of [RFC7519]) 356 defined "claim Expiration Time". The 'exp' should be set to specify 357 the expiration time on or after which the JWT is not accepted for 358 processing. The PAT object should expire after a reasonable 359 duration. A short expiration time for the PAT object periodically 360 reaffirms the policy information of the DNS server to the DNS client 361 and ensures the DNS client does not use outdated policy information. 362 If the DNS client knows the PAT object has expired, it should make 363 another request to get the new PAT object from the DNS server. For 364 example, the client can compute a hash of the resolver information, 365 retreive the information after the expiration time, computes the hash 366 of the newly retrieved resolver information, and compares with the 367 old hash to detect policy updates. A quality implementation can 368 perform automatic analysis and avoid presenting this information to 369 the user if the DNS server's policies have not changed. 371 6.2. PAT Specific Claims 373 6.2.1. DNS Server Identity Claims 375 The DNS server identity is represented by a claim that is required 376 for PAT: the 'server' claim. The 'server' MUST contain claim values 377 that are identity claim JSON objects where the child claim name 378 represents an identity type and the claim value is the identity 379 string, both defined in subsequent subsections. 381 These identities can be represented as either authentication domain 382 name (ADN) (defined in [RFC8310]) or Uniform Resource Indicators 383 (URI). 385 6.2.1.1. 'adn' - Authentication Domain Name Identity 387 If the DNS server identity is an ADN, the claim name representing the 388 identity MUST be 'adn'. The claim value for the 'adn' claim is the 389 ADN. 391 6.2.1.2. 'uri' - URI Identity 393 If the DNS server identity is of the form URI, as defined in 394 [RFC3986], the claim name representing the identity MUST be 'uri' and 395 the claim value is the URI form of the DNS server identity. 397 As a reminder, if DoH is supported by the DNS server, the DNS client 398 uses the https URI scheme (Section 3 of [RFC8484]). 400 6.2.2. 'policyinfo' (Policy Information) Claim 402 The 'policyinfo' claim MUST be formatted as a JSON object. The 403 'policyinfo' claim contains the policy information of the DNS server, 404 it includes the following attributes: 406 filtering: If the DNS server changes some of the answers that it 407 returns based on policy criteria, such as to prevent access to 408 malware sites or objectionable content. This optional attribute 409 has the following structure: 411 malwareblocking: The DNS server offers malware blocking service. 412 If access to domains is blocked on threat data, the parameter 413 value is set to 'true'. 415 policyblocking: If access to domains is blocked on a blacklist or 416 objectionable content, the parameter value is set to 'true'. 418 qnameminimization: If the DNS server implements QNAME minimisation 419 [RFC7816] to improve DNS privacy. If the parameter value is set 420 to 'true', QNAME minimisation is supported by the DNS server. 421 This is a mandatory attribute. 423 privacyurl: A URL that points to the privacy policy information of 424 the DNS server. This is a mandatory attribute. 426 auditurl: A URL that points to the security (including privacy) 427 assessment report of the DNS server by a third party auditor. 428 This is an optional attribute. 430 6.2.3. Example 432 Figure 2 shows an example of policy information. 434 { 435 "server":{ 436 "adn":["example.com"] 437 }, 438 "iat":1443208345, 439 "exp":1443640345, 440 "policyinfo": { 441 "filtering": { 442 "malwareblocking": true, 443 "policyblocking": false 444 }, 445 "qnameminimization":false, 446 "privacyurl": "https://example.com/commitment-to-privacy/" 447 } 448 } 450 Figure 2: An Example of Policy Information 452 7. PAT Signature 454 The signature of the PAT is created as specified in Section 5.1 of 455 [RFC7515] (Steps 1 through 6). PAT MUST use the JWS Protected 456 Header. 458 For the JWS Payload and the JWS Protected Header, the lexicographic 459 ordering and white space rules described in Section 5 and Section 6, 460 and JSON serialization rules in Section 9 MUST be followed. 462 The PAT is cryptographically signed by the domain hosting the DNS 463 server and optionally by a third party who performed privacy and 464 security audit of the DNS server. 466 The policy information is attested using "Organization Validation" 467 (OV) or "Extended Validation" (EV) certificates to avoid bad actors 468 taking advantage of this mechanism to advertise DoH/DoT servers for 469 illegitimate and fraudulent purposes meant to trick DNS clients into 470 believing that they are using a legitimate DoH/DoT server hosted to 471 provide privacy for DNS transactions. 473 Alternatively, a DNS client has to be configured to trust the leaf of 474 the signer of the PAT object. That is, trust of the signer MUST NOT 475 be determined by validating the signer via the OS or the browser 476 trust chain because that would allow any arbitrary entity to operate 477 a DNS server and assert any sort of policy. 479 Appendix A provides an example of how to follow the steps to create 480 the JWS Signature. 482 JWS JSON serialization (Step 7 in Section 5.1 of [RFC7515]) is 483 supported for PAT to enable multiple signatures to be applied to the 484 PAT object. For example, the PAT object can be cryptographically 485 signed by the domain hosting the DNS server and by a third party who 486 performed privacy and security audit of the DNS server. 488 Appendix B includes an example of the full JWS JSON serialization 489 representation with multiple signatures. 491 Section 5.1 of [RFC7515] (Step 8) describes the method to create the 492 final JWS Compact Serialization form of the PAT Token. 494 8. Extending PAT 496 PAT includes the minimum set of claims needed to securely assert the 497 policy information of the DNS server. JWT supports a mechanism to 498 add additional asserted or signed information by simply adding new 499 claims. PAT can be extended beyond the defined base set of claims to 500 represent other DNS server information requiring assertion or 501 validation. Specifying new claims follows the baseline JWT 502 procedures (Section 10.1 of [RFC7519]). Understanding new claims on 503 the DNS client is optional. The creator of a PAT object cannot 504 assume that the DNS client will understand the new claims. 506 9. Deterministic JSON Serialization 508 JSON objects can include spaces and line breaks, and key value pairs 509 can occur in any order. It is therefore a non-deterministic string 510 format. In order to make the digital signature verification work 511 deterministically, the JSON representation of the JWS Protected 512 Header object and JWS Payload object MUST be computed as follows. 514 The JSON object MUST follow the following rules. These rules are 515 based on the thumbprint of a JSON Web Key (JWK) as defined in 516 Section 3 of [RFC7638] (Step 1). 518 1. The JSON object MUST contain no whitespace or line breaks before 519 or after any syntactic elements. 521 2. JSON objects MUST have the keys ordered lexicographically by the 522 Unicode [UNICODE] code points of the member names. 524 3. JSON value literals MUST be lowercase. 526 4. JSON numbers are to be encoded as integers unless the field is 527 defined to be encoded otherwise. 529 5. Encoding rules MUST be applied recursively to member values and 530 array values. 532 9.1. Example PAT Deterministic JSON Form 534 This section demonstrates the deterministic JSON serialization for 535 the example PAT Payload shown in Section 6.2.3. 537 The initial JSON object is shown in Figure 3. 539 { 540 "server":{ 541 "adn":["example.com"] 542 }, 543 "iat":1443208345, 544 "exp":1443640345, 545 "policyinfo": { 546 "qnameminimization":false, 547 "privacyurl": "https://example.com/commitment-to-privacy/" 548 } 549 } 551 Figure 3: Initial JSON Object 553 The parent members of the JSON object are as follows, in 554 lexicographic order: "exp", "iat", "policyinfo", "server". 556 The final constructed deterministic JSON serialization 557 representation, with whitespace and line breaks removed, (with line 558 breaks used for display purposes only) is: 560 {"exp":1443640345,"iat":1443208345, 561 "policyinfo":{"privacyurl":"https://example.com/commitment-to-privacy/", 562 "qnameminimization":false},"server":{"adn":["example.com"]}} 564 Figure 4: Deterministic JSON Form 566 10. Privacy Considerations 568 Users are expected to indicate to their system in some way that they 569 trust certain PAT signers (e.g., if working for Example, Inc., the 570 user's system is configured to trust "example.com" signing the PAT). 571 By doing so, the DNS client can automatically discover DoH/DoT server 572 in specific networks, validate the PAT signature and the user can 573 check if the human readable privacy policy information of the DNS 574 server complies with user's privacy needs, prior to using that DoH/ 575 DoT server for DNS queries. 577 The DNS client MUST retrieve the human-readable privacy statement 578 from the 'privacyurl' attribute to assist with that decision (e.g., 579 display the privacy statement when it changes, show differences in 580 previously-retrieved version, etc.). With the steps above, user can 581 review the human-readable privacy policy information of the DoH/DoT 582 server. 584 Another scenario is bootstrapping a networking device to use the DoH/ 585 DoT server in the local network. Secure Zero Touch Provisioning 586 [RFC8572] defines a bootstrapping strategy for enabling devices to 587 securely obtain the required configuration information with no user 588 input. If the DoH/DoT information is insecurely discovered and not 589 pre-configured in the networking device, the client can validate the 590 Policy Assertion Token signature using the owner certificate as per 591 Section 3.2 of [RFC8572]. 593 11. Security Considerations 595 The use of PAT object based on the validation of the digital 596 signature and the associated certificate requires consideration of 597 the authentication and authority or reputation of the signer to 598 attest the policy information of the DNS server being asserted. Bad 599 actors can host DNS-over-TLS and DNS-over-HTTPS servers, and claim 600 the servers offer privacy but exactly do the opposite to invade the 601 privacy of the user. Bad actor can get a domain name, host DNS-over- 602 TLS and DNS-over-HTTPS servers, and get the DNS server certificate 603 signed by a CA. The policy information will have to be attested 604 using OV/EV certificates or a PAT object signer trusted by the DNS 605 client to prevent the attack. 607 If the PAT object is asserted by a third party, it can do a "time of 608 check" but the DNS server is susceptible of "time of use" attack. 609 For example, changes to the policy of the DNS server can cause a 610 disagreement between the auditor and the DNS server operation, hence 611 the PAT object needs to be also asserted by the domain hosting the 612 DNS server. In addition, the PAT object needs to have a short 613 expiration time (e.g., 7 days) to ensure the DNS server's domain re- 614 asserts the policy information and limits the damage from change in 615 policy and mis-issuance. 617 12. IANA Considerations 618 12.1. Media Type Registration 620 12.1.1. Media Type Registry Contents Additions Requested 622 This section registers the 'application/pat' media type [RFC2046] in 623 the 'Media Types' registry in the manner described in [RFC6838], 624 which can be used to indicate that the content is a PAT defined JWT. 626 o Type name: application 628 o Subtype name: pat 630 o Required parameters: n/a 632 o Optional parameters: n/a 634 o Encoding considerations: 8bit; application/pat values are encoded 635 as a series of base64url-encoded values (some of which may be the 636 empty string) separated by period ('.') characters.. 638 o Security considerations: See the Security Considerations 639 Section of [RFC7515]. 641 o Interoperability considerations: n/a 643 o Published specification: [TODO this document] 645 o Applications that use this media type: DNS 647 o Fragment identifier considerations: n/a 649 o Additional information: 651 Magic number(s): n/a File extension(s): n/a Macintosh file type 652 code(s): n/a 654 o Person & email address to contact for further information: 655 Tirumaleswar Reddy, kondtir@gmail.com 657 o Intended usage: COMMON 659 o Restrictions on usage: none 661 o Author: Tirumaleswar Reddy, kondtir@gmail.com 663 o Change Controller: IESG 665 o Provisional registration? No 667 12.2. JSON Web Token Claims Registration 669 12.2.1. Registry Contents Additions Requested 671 o Claim Name: 'server' 673 o Claim Description: DNS server identity 675 o Change Controller: IESG 677 o Specification Document(s): Section 6.2.1 of [TODO this document] 679 o Claim Name: 'policyinfo' 681 o Claim Description: Policy information of DNS server. 683 o Change Controller: IESG 685 o Specification Document(s): Section 6.2.2 of [TODO this document] 687 12.3. DNS Resolver Information Registration 689 IANA will add the names filtering, qnameminimization, privacyurl and 690 auditurl to the DNS Resolver Information registry defined in 691 Section 5.2 of [I-D.ietf-dnsop-resolver-information]. 693 13. Acknowledgments 695 This specification leverages some of the work that has been done in 696 [RFC8225]. Thanks to Ted Lemon, Paul Wouters and Shashank Jain for 697 the discussion and comments. 699 14. References 701 14.1. Normative References 703 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 704 Extensions (MIME) Part Two: Media Types", RFC 2046, 705 DOI 10.17487/RFC2046, November 1996, 706 . 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 714 Resource Identifier (URI): Generic Syntax", STD 66, 715 RFC 3986, DOI 10.17487/RFC3986, January 2005, 716 . 718 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 719 Housley, R., and W. Polk, "Internet X.509 Public Key 720 Infrastructure Certificate and Certificate Revocation List 721 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 722 . 724 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 725 Specifications and Registration Procedures", BCP 13, 726 RFC 6838, DOI 10.17487/RFC6838, January 2013, 727 . 729 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 730 Algorithm (DSA) and Elliptic Curve Digital Signature 731 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 732 2013, . 734 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 735 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 736 2015, . 738 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 739 DOI 10.17487/RFC7518, May 2015, 740 . 742 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 743 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 744 . 746 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 747 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 748 2015, . 750 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 751 and P. Hoffman, "Specification for DNS over Transport 752 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 753 2016, . 755 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 756 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 757 May 2017, . 759 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 760 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 761 . 763 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 764 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 765 January 2019, . 767 14.2. Informative References 769 [I-D.btw-add-home] 770 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, "DNS- 771 over-HTTPS and DNS-over-TLS Server Discovery and 772 Deployment Considerations for Home Networks", draft-btw- 773 add-home-05 (work in progress), April 2020. 775 [I-D.ietf-dnsop-extended-error] 776 Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 777 Lawrence, "Extended DNS Errors", draft-ietf-dnsop- 778 extended-error-14 (work in progress), January 2020. 780 [I-D.ietf-dnsop-resolver-information] 781 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 782 Information Self-publication", draft-ietf-dnsop-resolver- 783 information-01 (work in progress), February 2020. 785 [I-D.ietf-dnsop-terminology-ter] 786 Hoffman, P., "Terminology for DNS Transports and 787 Location", draft-ietf-dnsop-terminology-ter-01 (work in 788 progress), February 2020. 790 [I-D.ietf-dnssd-push] 791 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 792 draft-ietf-dnssd-push-25 (work in progress), October 2019. 794 [I-D.ietf-dprive-bcp-op] 795 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 796 Mankin, "Recommendations for DNS Privacy Service 797 Operators", draft-ietf-dprive-bcp-op-08 (work in 798 progress), January 2020. 800 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 801 DOI 10.17487/RFC7626, August 2015, 802 . 804 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 805 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 806 . 808 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 809 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 810 . 812 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 813 for DNS over TLS and DNS over DTLS", RFC 8310, 814 DOI 10.17487/RFC8310, March 2018, 815 . 817 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 818 Touch Provisioning (SZTP)", RFC 8572, 819 DOI 10.17487/RFC8572, April 2019, 820 . 822 [UNICODE] The Unicode Consortium, "The Unicode Standard", June 2016, 823 . 825 Appendix A. Example ES256 based PAT JWS Serialization and Signature 827 For PAT, there will always be a JWS with the following members: 829 o 'protected', with the value BASE64URL(UTF8(JWS Protected Header)) 831 o 'payload', with the value BASE64URL (JWS Payload) 833 o 'signature', with the value BASE64URL(JWS Signature) 835 This example will follow the steps in JWS [RFC7515] Section 5.1, 836 steps 1-6 and 8 and incorporates the additional serialization steps 837 required for PAT. 839 Step 1 for JWS references the JWS Payload, an example PAT Payload is 840 as follows: 842 { 843 "server":{ 844 "adn":["example.com"] 845 }, 846 "iat":1443208345, 847 "exp":1443640345, 848 "policyinfo": { 849 "filtering": { 850 "malwareblocking": true, 851 "policyblocking": false 852 }, 853 "qnameminimization":false, 854 "privacyurl": "https://example.com/commitment-to-privacy/" 855 } 856 } 858 This would be serialized to the form (with line break used for 859 display purposes only): 861 {"exp":1443640345,"iat":1443208345,"policyinfo":{ 862 "filtering":{"malwareblocking": true,"policyblocking": false}, 863 "privacyurl":"https://example.com/commitment-to-privacy/", 864 "qnameminimization":false},"server":{"adn":["example.com"]}} 866 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 867 line break used for display purposes only): 869 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6e 870 yJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9ja2 871 luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9jb21 872 taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNlfSwi 873 c2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0 875 For Step 3, an example PAT Protected Header comprising the JOSE 876 Header is as follows: 878 { 879 "alg":"ES256", 880 "typ":"pat", 881 "x5u":"https://cert.example.com/pat.cer" 882 } 884 This would be serialized to the form (with line break used for 885 display purposes only): 887 {"alg":"ES256","typ":"pat","x5u":"https://cert.example.com 888 /pat.cer"} 890 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 891 and encoding produces this value (with line break used for display 892 purposes only): 894 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 895 eGFtcGxlLmNvbS9wYXQuY2VyIn0 897 Step 5 and Step 6 performs the computation of the digital signature 898 of the PAT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 899 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 900 algorithm and the BASE64URL(JWS Signature). 902 4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBktWVnlmbmyHs05G 903 KauRBdIFnfp3oDPbE0Jq4w 905 Step 8 describes how to create the final PAT token, concatenating the 906 values in the order Header.Payload.Signature with period ('.') 907 characters. For the above example values this would produce the 908 following (with line breaks between period used for readability 909 purposes only): 911 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 912 eGFtcGxlLmNvbS9wYXQuY2VyIn0 913 . 914 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6e 915 yJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9ja2 916 luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9jb21 917 taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNlfSwi 918 c2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0 919 . 920 4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBktWVnlmbmyHs05G 921 KauRBdIFnfp3oDPbE0Jq4w 923 A.1. X.509 Private Key in PKCS#8 Format for ES256 Example** 925 -----BEGIN PRIVATE KEY----- 926 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 927 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 928 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 929 -----END PRIVATE KEY----- 931 A.2. X.509 Public Key for ES256 Example** 933 -----BEGIN PUBLIC KEY----- 934 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 935 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 936 -----END PUBLIC KEY----- 938 Appendix B. Complete JWS JSON Serialization Representation with 939 multiple Signatures 941 The JWS payload used in this example as follows. 943 { 944 "server":{ 945 "adn":["example.com"] 946 }, 947 "iat":1443208345, 948 "exp":1443640345, 949 "policyinfo": { 950 "filtering": { 951 "malwareblocking": true, 952 "policyblocking": false 953 }, 954 "qnameminimization":false, 955 "privacyurl": "https://example.com/commitment-to-privacy/" 956 } 957 } 959 This would be serialized to the form (with line break used for 960 display purposes only): 962 {"exp":1443640345,"iat":1443208345,"policyinfo":{ 963 "filtering":{"malwareblocking": true,"policyblocking": false}, 964 "privacyurl":"https://example.com/commitment-to-privacy/", 965 "qnameminimization":false},"server":{"adn":["example.com"]}} 967 The JWS protected Header value used for the first signature is same 968 as that used in the example in Appendix A. The X.509 private key 969 used for generating the first signature is same as that used in the 970 example in Appendix A.1. 972 The JWS Protected Header value used for the second signature is: 974 { 975 "alg":"ES384", 976 "typ":"pat", 977 "x5u":"https://cert.audit-example.com/pat.cer" 978 } 979 The complete JWS JSON Serialization for these values is as follows 980 (with line breaks within values for display purposes only): 982 { 983 "payload": 984 "eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6 985 eyJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9j 986 a2luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9j 987 b21taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNl 988 fSwic2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0", 989 "signatures":[ 990 {"protected":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 991 zOi8vY2VydC5leGFtcGxlLmNvbS9wYXQuY2VyIn0", 992 "signature": "4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBk 993 tWVnlmbmyHs05GKauRBdIFnfp3oDPbE0Jq4w"}, 994 {"protected":"eyJhbGciOiJFUzM4NCIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 995 zOi8vY2VydC5hdWRpdC1leGFtcGxlLmNvbS9wYXQuY2VyIn0", 996 "signature":666ag_mAqDa3Oyxo1DGXUocr0MmRjpXwq8kWp1S21mvs2-kPCIq3 997 0xsBJt4apy-sq3VyJgIqzjijoFYURhHvupF0obo-IFUGSZ1YHBCX_MiyBwJQJjtp 998 S91ujDatRTtZ"}] 999 } 1001 B.1. X.509 Private Key in PKCS#8 format for E384 Example** 1003 -----BEGIN PRIVATE KEY----- 1004 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 1005 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 1006 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 1007 -----END PRIVATE KEY----- 1009 B.2. X.509 Public Key for ES384 Example** 1011 -----BEGIN PUBLIC KEY----- 1012 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 1013 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 1014 -----END PUBLIC KEY----- 1016 Authors' Addresses 1018 Tirumaleswar Reddy 1019 McAfee, Inc. 1020 Embassy Golf Link Business Park 1021 Bangalore, Karnataka 560071 1022 India 1024 Email: kondtir@gmail.com 1025 Dan Wing 1026 Citrix Systems, Inc. 1027 USA 1029 Email: dwing-ietf@fuggles.com 1031 Michael C. Richardson 1032 Sandelman Software Works 1033 USA 1035 Email: mcr+ietf@sandelman.ca 1037 Mohamed Boucadair 1038 Orange 1039 Rennes 35000 1040 France 1042 Email: mohamed.boucadair@orange.com