idnits 2.17.1 draft-reddy-add-server-policy-selection-02.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The DNS client constructs a reference identifier for the DNS server based on the ADN or the domain portion in the URI of the DNS server identity. The domain name in the DNS-ID identifier type within subjectAltName entry in the DNS server certificate conveyed in the TLS handshake is matched with the reference identifier. If the match is not successful, the client MUST not accept the PAT for further processing. -- The document date (May 27, 2020) is 1430 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-06 == 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-09 == Outdated reference: A later version (-02) exists of draft-pp-add-resinfo-01 -- 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 (~~), 6 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: November 28, 2020 Citrix 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 May 27, 2020 12 DNS Server Selection: DNS Server Information with Assertion Token 13 draft-reddy-add-server-policy-selection-02 15 Abstract 17 The document defines a mechanism that allows communication of DNS 18 resolver information to DNS clients for use in server selection 19 decisions. In particular, the document defines a mechanism for a DNS 20 server to communicate its filtering policy and privacy statement URL 21 to DNS clients. This information is cryptographically signed to 22 attest its authenticity. Such information is used for the selection 23 of DNS 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 encrypted DNS (e.g., DNS-over-TLS and 29 DNS-over-HTTPS) servers that are either public resolvers or are 30 discovered in a local 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 November 28, 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 . . . . . . . . . . . 7 73 5.3. 'x5u' (X.509 URL) Header Parameter . . . . . . . . . . . 7 74 5.4. An Example of PAT Header . . . . . . . . . . . . . . . . 7 75 6. PAT Payload . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . 12 86 9.1. Example PAT Deterministic JSON Form . . . . . . . . . . . 12 87 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 88 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . 16 95 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 98 14.2. Informative References . . . . . . . . . . . . . . . . . 17 99 Appendix A. Example ES256 based PAT JWS Serialization and 100 Signature . . . . . . . . . . . . . . . . . . . . . 19 101 A.1. X.509 Private Key in PKCS#8 Format for ES256 Example** . 21 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** . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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. Examples of protocols that provide encrypted 114 channels between DNS clients and servers are DNS-over-HTTPS (DoH) 115 [RFC8484] and DNS-over-TLS (DoT) [RFC7858]. 117 DNS clients can discover and authenticate encrypted DNS (e.g., DoH 118 and DoT) servers provided by a local network, for example using the 119 techniques proposed in [I-D.btw-add-home]. If the mechanism used to 120 discover the encrypted DNS server is insecure, the DNS client needs 121 evidence about the encrypted server to assess its trustworthiness and 122 a way to appraise such evidence. The mechanism specified in this 123 document can be used by the DNS client to cryptographically identify 124 it is connecting to an encrypted DNS server hosted by a specific 125 organization (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 feed 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 encrypted DNS server advertised using DHCP/RA in Home and 171 Mobile networks is insecure, the mechanism specified in this 172 document can be used by the DNS client to validate the signatory 173 (e.g., 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 encrypted DNS 187 server does not meet the privacy preserving data policy and 188 filtering requirements of the user, the DNS client can take 189 appropriate actions. For example, the action can be to use the 190 discovered DNS server only to access internal-only DNS names and 191 use another DNS server (adhering with the user's expectations) for 192 public domains. 194 o The policy information signals the presence of DNS-based content 195 filtering in the attached network. If the network is well-known 196 to the DNS client and the local DNS server meets the privacy 197 requirements of the user, the DNS client can continue to use 198 encrypted connection with the local encrypted DNS server. If the 199 error code returned by the DNS server indicates access to the 200 domain is blocked because of internal security policy 201 [I-D.ietf-dnsop-extended-error], the DNS client can securely 202 identify access to the domain is censored by the network. 204 o The signed policy contains an URL that points to a human-readable 205 privacy policy information of the DNS server for the user to 206 review and can make an informed decision whether the DNS server is 207 trustworthy to honor the privacy of the user. The DNS Push 208 Notifications mechanism defined in [I-D.ietf-dnssd-push] can be 209 used by the DNS client to be asynchronously notified when the 210 policy change occurs. The client automatically learns updates to 211 the policy of the DNS server, and whenever the privacy statement 212 of the DNS server changes, the client can notify the user to re- 213 evaluate the updated privacy statement. As a reminder, DNS Push 214 Notification is only defined for TLS over TCP. DNS client 215 implementations that do not support DNS Push Notifications can use 216 the mechanism discussed in Section 6.1.2 to identify policy 217 updates. 219 3. Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in BCP 224 14 [RFC2119][RFC8174] when, and only when, they appear in all 225 capitals, as shown here. 227 This document makes use of the terms defined in [RFC8499] and 228 [I-D.ietf-dnsop-terminology-ter]. 230 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 232 'Encrypted DNS' refers to a DNS protocol that provides an encrypted 233 channel between a DNS client and server (e.g., DoT or DoH). 235 4. Policy Assertion Token (PAT): Overview 237 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 238 and related specifications define a standard token format that can be 239 used as a way of encapsulating claimed or asserted information with 240 an associated digital signature using X.509 based certificates. JWT 241 provides a set of claims in JSON format that can accommodate asserted 242 policy information of the DoH/DoT server. Additionally, JWS provides 243 a path for updating methods and cryptographic algorithms used for the 244 associated digital signatures. 246 JWS defines the use of JSON data structures in a specified canonical 247 format for signing data corresponding to JOSE header, JWS Payload, 248 and JWS Signature. The next sections define the header and claims 249 that MUST be minimally used with JWT and JWS for privacy assertion 250 token. 252 The Policy Assertion Token (PAT) specifically uses this token format 253 and defines claims that convey the policy information of DoH/DoT 254 server. After the DoT/DoH session is established, the client can 255 retrieve the PAT object using the RESINFO RRtype and QNAME of 256 "resolver-info.arpa/IN" defined in [I-D.pp-add-resinfo]. The 257 signature of PAT object can be validated by the DNS client. If the 258 signer and the contents of the PAT object comply with the user's 259 requirements, the user's client software can use that DNS server. 261 The PAT object is signed by the DNS server's domain that is 262 authoritative to assert the DNS server policy information. This 263 authority is represented by the certificate credentials and the 264 signature. 266 For example, the PAT object could be created by the organization 267 hosting the DoH/DoT server and optionally by a third party who 268 performed privacy and security audit of the DoH/DoT server. The DNS 269 client needs to have the capability to verify the digital signature 270 and to parse the PAT object. 272 5. PAT Header 274 The JWS token header is a JOSE header (Section 4 of [RFC7515]) that 275 defines the type and encryption algorithm used in the token. 277 PAT header MUST include, at a minimum, the header parameters defined 278 in Sections 5.1, 5.2, and 5.3. 280 5.1. 'typ' (Type) Header Parameter 282 The 'typ' (Type) Header Parameter is defined Section 4.1.9 of 283 [RFC7515] to declare the media type of the complete JWS. 285 For PAT Token the 'typ' header MUST be the string 'pat'. This 286 represents that the encoded token is a JWT of type pat. 288 5.2. 'alg' (Algorithm) Header Parameter 290 The 'alg' (Algorithm) Header Parameter is defined in Section 4.1.1 of 291 [RFC7515]. It specifies the JWS signature cryptographic algorithm. 292 It also refers to a list of defined 'alg' values as part of a 293 registry established by JSON Web Algorithms (JWA) [RFC7518] 294 Section 3.1. 296 For the creation and verification of PAT tokens and their digital 297 signatures, implementations MUST support ES256 as defined in 298 Section 3.4 of [RFC7518]. Implementations MAY support other 299 algorithms registered in the JSON Web Signature and Encryption 300 Algorithms registry created by [RFC7518]. The content of that 301 registry may be updated in the future depending on cryptographic 302 strength requirements guided by current security best practice. The 303 mandatory-to-support algorithm for PAT tokens may likewise be updated 304 in the future. 306 Implementations of PAT digital signatures using ES256 as defined 307 above SHOULD use deterministic ECDSA when supported for the reasons 308 stated in [RFC6979]. 310 5.3. 'x5u' (X.509 URL) Header Parameter 312 As defined in Section 4.1.5 of [RFC7515], the 'x5u' header parameter 313 defines a URI [RFC3986] referring to the resource for the X.509 314 public key certificate or certificate chain [RFC5280] corresponding 315 to the key used to digitally sign the JWS. Generally, as defined in 316 Section 4.1.5 of [RFC7515] this corresponds to an HTTPS or DNSSEC 317 resource using integrity protection. 319 5.4. An Example of PAT Header 321 An example of the PAT header is shown in Figure 1. It includes the 322 specified PAT type, ES256 algorithm, and an URI referencing the 323 network location of the certificate needed to validate the PAT 324 signature. 326 { 327 "typ":"pat", 328 "alg":"ES256", 329 "x5u":"https://cert.example.com/pat.cer" 330 } 332 Figure 1: A PAT Header Example 334 6. PAT Payload 336 The token claims consists of the policy information of the DNS server 337 which needs to be verified at the DNS client. These claims follow 338 the definition of a JWT claim (Secion 4 of [RFC7519]) and are encoded 339 as defined by the JWS Payload (Section 3 of [RFC7515]). 341 PAT defines the use of a standard JWT-defined claim as well as custom 342 claims corresponding to the DoT or DoH servers. 344 Claim names MUST use the US-ASCII character set. Claim values MAY 345 contain characters that are outside the ASCII range, however they 346 MUST follow the default JSON serialization defined in Section 7 of 347 [RFC7519]. 349 6.1. JWT Defined Claims 351 6.1.1. 'iat' - Issued At Claim 353 The JSON claim MUST include the 'iat' (Section 4.1.6 of [RFC7519]) 354 defined claim "Issued At". The 'iat' should be set to the date and 355 time of issuance of the JWT. The time value should be of the format 356 (NumericDate) defined in Section 2 of [RFC7519]. 358 6.1.2. 'exp' - Expiration Time Claim 360 The JSON claim MUST include the 'exp' (Section 4.1.4 of [RFC7519]) 361 defined "claim Expiration Time". The 'exp' should be set to specify 362 the expiration time on or after which the JWT is not accepted for 363 processing. The PAT object should expire after a reasonable 364 duration. A short expiration time for the PAT object periodically 365 reaffirms the policy information of the DNS server to the DNS client 366 and ensures the DNS client does not use outdated policy information. 367 If the DNS client knows the PAT object has expired, it should make 368 another request to get the new PAT object from the DNS server. For 369 example, the client can compute a hash of the resolver information, 370 retreive the information after the expiration time, computes the hash 371 of the newly retrieved resolver information, and compares with the 372 old hash to detect policy updates. A quality implementation can 373 perform automatic analysis and avoid presenting this information to 374 the user if the DNS server's policies have not changed. 376 6.2. PAT Specific Claims 377 6.2.1. DNS Server Identity Claims 379 The DNS server identity is represented by a claim that is required 380 for PAT: the 'server' claim. The 'server' MUST contain claim values 381 that are identity claim JSON objects where the child claim name 382 represents an identity type and the claim value is the identity 383 string, both defined in subsequent subsections. 385 These identities can be represented as either authentication domain 386 name (ADN) (defined in [RFC8310]) or Uniform Resource Indicators 387 (URI). 389 The DNS client constructs a reference identifier for the DNS server 390 based on the ADN or the domain portion in the URI of the DNS server 391 identity. The domain name in the DNS-ID identifier type within 392 subjectAltName entry in the DNS server certificate conveyed in the 393 TLS handshake is matched with the reference identifier. If the match 394 is not successful, the client MUST not accept the PAT for further 395 processing. 397 6.2.1.1. 'adn' - Authentication Domain Name Identity 399 If the DNS server identity is an ADN, the claim name representing the 400 identity MUST be 'adn'. The claim value for the 'adn' claim is the 401 ADN. 403 6.2.1.2. 'uri' - URI Identity 405 If the DNS server identity is of the form URI, as defined in 406 [RFC3986], the claim name representing the identity MUST be 'uri' and 407 the claim value is the URI form of the DNS server identity. 409 As a reminder, if DoH is supported by the DNS server, the DNS client 410 uses the https URI scheme (Section 3 of [RFC8484]). 412 6.2.2. 'policyinfo' (Policy Information) Claim 414 The 'policyinfo' claim MUST be formatted as a JSON object. The 415 'policyinfo' claim contains the policy information of the DNS server, 416 it includes the following attributes: 418 filtering: If the DNS server changes some of the answers that it 419 returns based on policy criteria, such as to prevent access to 420 malware sites or objectionable content. This optional attribute 421 has the following structure: 423 malwareblocking: The DNS server offers malware blocking service. 424 If access to domains is blocked on threat data, the parameter 425 value is set to 'true'. 427 policyblocking: If access to domains is blocked on a blacklist or 428 objectionable content, the parameter value is set to 'true'. 430 qnameminimization: If the DNS server implements QNAME minimisation 431 [RFC7816] to improve DNS privacy. If the parameter value is set 432 to 'true', QNAME minimisation is supported by the DNS server. 433 This is a mandatory attribute. 435 privacyurl: A URL that points to the privacy policy information of 436 the DNS server. This is a mandatory attribute. 438 auditurl: A URL that points to the security (including privacy) 439 assessment report of the DNS server by a third party auditor. 440 This is an optional attribute. 442 6.2.3. Example 444 Figure 2 shows an example of policy information. 446 { 447 "server":{ 448 "adn":["example.com"] 449 }, 450 "iat":1443208345, 451 "exp":1443640345, 452 "policyinfo": { 453 "filtering": { 454 "malwareblocking": true, 455 "policyblocking": false 456 }, 457 "qnameminimization":false, 458 "privacyurl": "https://example.com/commitment-to-privacy/" 459 } 460 } 462 Figure 2: An Example of Policy Information 464 7. PAT Signature 466 The signature of the PAT is created as specified in Section 5.1 of 467 [RFC7515] (Steps 1 through 6). PAT MUST use the JWS Protected 468 Header. 470 For the JWS Payload and the JWS Protected Header, the lexicographic 471 ordering and white space rules described in Section 5 and Section 6, 472 and JSON serialization rules in Section 9 MUST be followed. 474 The PAT is cryptographically signed by the domain hosting the DNS 475 server and optionally by a third party who performed privacy and 476 security audit of the DNS server. 478 The policy information is attested using "Organization Validation" 479 (OV) or "Extended Validation" (EV) certificates to avoid bad actors 480 taking advantage of this mechanism to advertise encrypted DNS servers 481 for illegitimate and fraudulent purposes meant to trick DNS clients 482 into believing that they are using a legitimate encrypted DNS server 483 hosted to provide privacy for DNS transactions. 485 Alternatively, a DNS client has to be configured to trust the leaf of 486 the signer of the PAT object. That is, trust of the signer MUST NOT 487 be determined by validating the signer via the OS or the browser 488 trust chain because that would allow any arbitrary entity to operate 489 a DNS server and assert any sort of policy. 491 Appendix A provides an example of how to follow the steps to create 492 the JWS Signature. 494 JWS JSON serialization (Step 7 in Section 5.1 of [RFC7515]) is 495 supported for PAT to enable multiple signatures to be applied to the 496 PAT object. For example, the PAT object can be cryptographically 497 signed by the domain hosting the DNS server and by a third party who 498 performed privacy and security audit of the DNS server. 500 Appendix B includes an example of the full JWS JSON serialization 501 representation with multiple signatures. 503 Section 5.1 of [RFC7515] (Step 8) describes the method to create the 504 final JWS Compact Serialization form of the PAT Token. 506 8. Extending PAT 508 PAT includes the minimum set of claims needed to securely assert the 509 policy information of the DNS server. JWT supports a mechanism to 510 add additional asserted or signed information by simply adding new 511 claims. PAT can be extended beyond the defined base set of claims to 512 represent other DNS server information requiring assertion or 513 validation. Specifying new claims follows the baseline JWT 514 procedures (Section 10.1 of [RFC7519]). Understanding new claims on 515 the DNS client is optional. The creator of a PAT object cannot 516 assume that the DNS client will understand the new claims. 518 9. Deterministic JSON Serialization 520 JSON objects can include spaces and line breaks, and key value pairs 521 can occur in any order. It is therefore a non-deterministic string 522 format. In order to make the digital signature verification work 523 deterministically, the JSON representation of the JWS Protected 524 Header object and JWS Payload object MUST be computed as follows. 526 The JSON object MUST follow the following rules. These rules are 527 based on the thumbprint of a JSON Web Key (JWK) as defined in 528 Section 3 of [RFC7638] (Step 1). 530 1. The JSON object MUST contain no whitespace or line breaks before 531 or after any syntactic elements. 533 2. JSON objects MUST have the keys ordered lexicographically by the 534 Unicode [UNICODE] code points of the member names. 536 3. JSON value literals MUST be lowercase. 538 4. JSON numbers are to be encoded as integers unless the field is 539 defined to be encoded otherwise. 541 5. Encoding rules MUST be applied recursively to member values and 542 array values. 544 9.1. Example PAT Deterministic JSON Form 546 This section demonstrates the deterministic JSON serialization for 547 the example PAT Payload shown in Section 6.2.3. 549 The initial JSON object is shown in Figure 3. 551 { 552 "server":{ 553 "adn":["example.com"] 554 }, 555 "iat":1443208345, 556 "exp":1443640345, 557 "policyinfo": { 558 "qnameminimization":false, 559 "privacyurl": "https://example.com/commitment-to-privacy/" 560 } 561 } 563 Figure 3: Initial JSON Object 565 The parent members of the JSON object are as follows, in 566 lexicographic order: "exp", "iat", "policyinfo", "server". 568 The final constructed deterministic JSON serialization 569 representation, with whitespace and line breaks removed, (with line 570 breaks used for display purposes only) is: 572 {"exp":1443640345,"iat":1443208345, 573 "policyinfo":{"privacyurl":"https://example.com/commitment-to-privacy/", 574 "qnameminimization":false},"server":{"adn":["example.com"]}} 576 Figure 4: Deterministic JSON Form 578 10. Privacy Considerations 580 Users are expected to indicate to their system in some way that they 581 trust certain PAT signers (e.g., if working for Example, Inc., the 582 user's system is configured to trust "example.com" signing the PAT). 583 By doing so, the DNS client can automatically discover encrypted DNS 584 server in specific networks, validate the PAT signature and the user 585 can check if the human readable privacy policy information of the DNS 586 server complies with user's privacy needs, prior to using that 587 encrypted DNS server for DNS queries. 589 The DNS client MUST retrieve the human-readable privacy statement 590 from the 'privacyurl' attribute to assist with that decision (e.g., 591 display the privacy statement when it changes, show differences in 592 previously-retrieved version, etc.). With the steps above, user can 593 review the human-readable privacy policy information of the DoH/DoT 594 server. 596 Another scenario is bootstrapping a networking device to use the 597 encrypted DNS server in the local network. Secure Zero Touch 598 Provisioning [RFC8572] defines a bootstrapping strategy for enabling 599 devices to securely obtain the required configuration information 600 with no user input. If the encrypted DNS server is insecurely 601 discovered and not pre-configured in the networking device, the 602 client can validate the Policy Assertion Token signature using the 603 owner certificate as per Section 3.2 of [RFC8572]. 605 11. Security Considerations 607 The use of PAT object based on the validation of the digital 608 signature and the associated certificate requires consideration of 609 the authentication and authority or reputation of the signer to 610 attest the policy information of the DNS server being asserted. Bad 611 actors can host encrypted DNS servers, and claim the servers offer 612 privacy but exactly do the opposite to invade the privacy of the 613 user. Bad actor can get a domain name, host encrypted DNS servers, 614 and get the DNS server certificate signed by a CA. The policy 615 information will have to be attested using OV/EV certificates or a 616 PAT object signer trusted by the DNS client to prevent the attack. 618 The CA that issued the OV/EV certificate does not attest the resolver 619 information. The organization hosting the DNS server attests the 620 resolver information using the OV/EV certificate and the client uses 621 the OV/EV certificate to identify the organization (e.g., ISP or 622 Enterprise) hosting the DNS server. 624 If the PAT object is asserted by a third party, it can do a "time of 625 check" but the DNS server is susceptible of "time of use" attack. 626 For example, changes to the policy of the DNS server can cause a 627 disagreement between the auditor and the DNS server operation, hence 628 the PAT object needs to be also asserted by the domain hosting the 629 DNS server. In addition, the PAT object needs to have a short 630 expiration time (e.g., 7 days) to ensure the DNS server's domain re- 631 asserts the policy information and limits the damage from change in 632 policy and mis-issuance. 634 12. IANA Considerations 636 12.1. Media Type Registration 638 12.1.1. Media Type Registry Contents Additions Requested 640 This section registers the 'application/pat' media type [RFC2046] in 641 the 'Media Types' registry in the manner described in [RFC6838], 642 which can be used to indicate that the content is a PAT defined JWT. 644 o Type name: application 646 o Subtype name: pat 648 o Required parameters: n/a 650 o Optional parameters: n/a 652 o Encoding considerations: 8bit; application/pat values are encoded 653 as a series of base64url-encoded values (some of which may be the 654 empty string) separated by period ('.') characters.. 656 o Security considerations: See the Security Considerations 657 Section of [RFC7515]. 659 o Interoperability considerations: n/a 660 o Published specification: [TODO this document] 662 o Applications that use this media type: DNS 664 o Fragment identifier considerations: n/a 666 o Additional information: 668 Magic number(s): n/a File extension(s): n/a Macintosh file type 669 code(s): n/a 671 o Person & email address to contact for further information: 672 Tirumaleswar Reddy, kondtir@gmail.com 674 o Intended usage: COMMON 676 o Restrictions on usage: none 678 o Author: Tirumaleswar Reddy, kondtir@gmail.com 680 o Change Controller: IESG 682 o Provisional registration? No 684 12.2. JSON Web Token Claims Registration 686 12.2.1. Registry Contents Additions Requested 688 o Claim Name: 'server' 690 o Claim Description: DNS server identity 692 o Change Controller: IESG 694 o Specification Document(s): Section 6.2.1 of [TODO this document] 696 o Claim Name: 'policyinfo' 698 o Claim Description: Policy information of DNS server. 700 o Change Controller: IESG 702 o Specification Document(s): Section 6.2.2 of [TODO this document] 704 12.3. DNS Resolver Information Registration 706 IANA will add the names filtering, qnameminimization, privacyurl and 707 auditurl to the DNS Resolver Information registry defined in 708 Section 4.2 of [I-D.pp-add-resinfo]. 710 13. Acknowledgments 712 This specification leverages some of the work that has been done in 713 [RFC8225]. Thanks to Ted Lemon, Paul Wouters, Neil Cook and Shashank 714 Jain for the discussion and comments. 716 14. References 718 14.1. Normative References 720 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 721 Extensions (MIME) Part Two: Media Types", RFC 2046, 722 DOI 10.17487/RFC2046, November 1996, 723 . 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 731 Resource Identifier (URI): Generic Syntax", STD 66, 732 RFC 3986, DOI 10.17487/RFC3986, January 2005, 733 . 735 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 736 Housley, R., and W. Polk, "Internet X.509 Public Key 737 Infrastructure Certificate and Certificate Revocation List 738 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 739 . 741 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 742 Specifications and Registration Procedures", BCP 13, 743 RFC 6838, DOI 10.17487/RFC6838, January 2013, 744 . 746 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 747 Algorithm (DSA) and Elliptic Curve Digital Signature 748 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 749 2013, . 751 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 752 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 753 2015, . 755 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 756 DOI 10.17487/RFC7518, May 2015, 757 . 759 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 760 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 761 . 763 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 764 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 765 2015, . 767 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 768 and P. Hoffman, "Specification for DNS over Transport 769 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 770 2016, . 772 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 773 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 774 May 2017, . 776 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 777 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 778 . 780 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 781 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 782 January 2019, . 784 14.2. Informative References 786 [I-D.btw-add-home] 787 Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, 788 "Encrypted DNS Discovery and Deployment Considerations for 789 Home Networks", draft-btw-add-home-06 (work in progress), 790 May 2020. 792 [I-D.ietf-dnsop-extended-error] 793 Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 794 Lawrence, "Extended DNS Errors", draft-ietf-dnsop- 795 extended-error-16 (work in progress), May 2020. 797 [I-D.ietf-dnsop-terminology-ter] 798 Hoffman, P., "Terminology for DNS Transports and 799 Location", draft-ietf-dnsop-terminology-ter-01 (work in 800 progress), February 2020. 802 [I-D.ietf-dnssd-push] 803 Pusateri, T. and S. Cheshire, "DNS Push Notifications", 804 draft-ietf-dnssd-push-25 (work in progress), October 2019. 806 [I-D.ietf-dprive-bcp-op] 807 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 808 Mankin, "Recommendations for DNS Privacy Service 809 Operators", draft-ietf-dprive-bcp-op-09 (work in 810 progress), May 2020. 812 [I-D.pp-add-resinfo] 813 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 814 publication", draft-pp-add-resinfo-01 (work in progress), 815 May 2020. 817 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 818 DOI 10.17487/RFC7626, August 2015, 819 . 821 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 822 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 823 . 825 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 826 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 827 . 829 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 830 for DNS over TLS and DNS over DTLS", RFC 8310, 831 DOI 10.17487/RFC8310, March 2018, 832 . 834 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 835 Touch Provisioning (SZTP)", RFC 8572, 836 DOI 10.17487/RFC8572, April 2019, 837 . 839 [UNICODE] The Unicode Consortium, "The Unicode Standard", June 2016, 840 . 842 Appendix A. Example ES256 based PAT JWS Serialization and Signature 844 For PAT, there will always be a JWS with the following members: 846 o 'protected', with the value BASE64URL(UTF8(JWS Protected Header)) 848 o 'payload', with the value BASE64URL (JWS Payload) 850 o 'signature', with the value BASE64URL(JWS Signature) 852 This example will follow the steps in JWS [RFC7515] Section 5.1, 853 steps 1-6 and 8 and incorporates the additional serialization steps 854 required for PAT. 856 Step 1 for JWS references the JWS Payload, an example PAT Payload is 857 as follows: 859 { 860 "server":{ 861 "adn":["example.com"] 862 }, 863 "iat":1443208345, 864 "exp":1443640345, 865 "policyinfo": { 866 "filtering": { 867 "malwareblocking": true, 868 "policyblocking": false 869 }, 870 "qnameminimization":false, 871 "privacyurl": "https://example.com/commitment-to-privacy/" 872 } 873 } 875 This would be serialized to the form (with line break used for 876 display purposes only): 878 {"exp":1443640345,"iat":1443208345,"policyinfo":{ 879 "filtering":{"malwareblocking": true,"policyblocking": false}, 880 "privacyurl":"https://example.com/commitment-to-privacy/", 881 "qnameminimization":false},"server":{"adn":["example.com"]}} 883 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 884 line break used for display purposes only): 886 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6e 887 yJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9ja2 888 luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9jb21 889 taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNlfSwi 890 c2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0 892 For Step 3, an example PAT Protected Header comprising the JOSE 893 Header is as follows: 895 { 896 "alg":"ES256", 897 "typ":"pat", 898 "x5u":"https://cert.example.com/pat.cer" 899 } 901 This would be serialized to the form (with line break used for 902 display purposes only): 904 {"alg":"ES256","typ":"pat","x5u":"https://cert.example.com 905 /pat.cer"} 907 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 908 and encoding produces this value (with line break used for display 909 purposes only): 911 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 912 eGFtcGxlLmNvbS9wYXQuY2VyIn0 914 Step 5 and Step 6 performs the computation of the digital signature 915 of the PAT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 916 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 917 algorithm and the BASE64URL(JWS Signature). 919 4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBktWVnlmbmyHs05G 920 KauRBdIFnfp3oDPbE0Jq4w 922 Step 8 describes how to create the final PAT token, concatenating the 923 values in the order Header.Payload.Signature with period ('.') 924 characters. For the above example values this would produce the 925 following (with line breaks between period used for readability 926 purposes only): 928 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 929 eGFtcGxlLmNvbS9wYXQuY2VyIn0 930 . 931 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6e 932 yJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9ja2 933 luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9jb21 934 taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNlfSwi 935 c2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0 936 . 937 4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBktWVnlmbmyHs05G 938 KauRBdIFnfp3oDPbE0Jq4w 940 A.1. X.509 Private Key in PKCS#8 Format for ES256 Example** 942 -----BEGIN PRIVATE KEY----- 943 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 944 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 945 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 946 -----END PRIVATE KEY----- 948 A.2. X.509 Public Key for ES256 Example** 950 -----BEGIN PUBLIC KEY----- 951 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 952 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 953 -----END PUBLIC KEY----- 955 Appendix B. Complete JWS JSON Serialization Representation with 956 multiple Signatures 958 The JWS payload used in this example as follows. 960 { 961 "server":{ 962 "adn":["example.com"] 963 }, 964 "iat":1443208345, 965 "exp":1443640345, 966 "policyinfo": { 967 "filtering": { 968 "malwareblocking": true, 969 "policyblocking": false 970 }, 971 "qnameminimization":false, 972 "privacyurl": "https://example.com/commitment-to-privacy/" 973 } 974 } 975 This would be serialized to the form (with line break used for 976 display purposes only): 978 {"exp":1443640345,"iat":1443208345,"policyinfo":{ 979 "filtering":{"malwareblocking": true,"policyblocking": false}, 980 "privacyurl":"https://example.com/commitment-to-privacy/", 981 "qnameminimization":false},"server":{"adn":["example.com"]}} 983 The JWS protected Header value used for the first signature is same 984 as that used in the example in Appendix A. The X.509 private key 985 used for generating the first signature is same as that used in the 986 example in Appendix A.1. 988 The JWS Protected Header value used for the second signature is: 990 { 991 "alg":"ES384", 992 "typ":"pat", 993 "x5u":"https://cert.audit-example.com/pat.cer" 994 } 996 The complete JWS JSON Serialization for these values is as follows 997 (with line breaks within values for display purposes only): 999 { 1000 "payload": 1001 "eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicG9saWN5aW5mbyI6 1002 eyJmaWx0ZXJpbmciOnsibWFsd2FyZWJsb2NraW5nIjp0cnVlLCJwb2xpY3libG9j 1003 a2luZyI6ZmFsc2V9LCJwcml2YWN5dXJsIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9j 1004 b21taXRtZW50LXRvLXByaXZhY3kvIiwicW5hbWVtaW5pbWl6YXRpb24iOmZhbHNl 1005 fSwic2VydmVyIjp7ImFkbiI6WyJleGFtcGxlLmNvbSJdfX0", 1006 "signatures":[ 1007 {"protected":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 1008 zOi8vY2VydC5leGFtcGxlLmNvbS9wYXQuY2VyIn0", 1009 "signature": "4vQEAF_Vlp1Tr6sJmS4pnIKDRmIjH8EZzY5BMT2qJCHD8PmjBk 1010 tWVnlmbmyHs05GKauRBdIFnfp3oDPbE0Jq4w"}, 1011 {"protected":"eyJhbGciOiJFUzM4NCIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 1012 zOi8vY2VydC5hdWRpdC1leGFtcGxlLmNvbS9wYXQuY2VyIn0", 1013 "signature":666ag_mAqDa3Oyxo1DGXUocr0MmRjpXwq8kWp1S21mvs2-kPCIq3 1014 0xsBJt4apy-sq3VyJgIqzjijoFYURhHvupF0obo-IFUGSZ1YHBCX_MiyBwJQJjtp 1015 S91ujDatRTtZ"}] 1016 } 1018 B.1. X.509 Private Key in PKCS#8 format for E384 Example** 1019 -----BEGIN PRIVATE KEY----- 1020 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 1021 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 1022 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 1023 -----END PRIVATE KEY----- 1025 B.2. X.509 Public Key for ES384 Example** 1027 -----BEGIN PUBLIC KEY----- 1028 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 1029 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 1030 -----END PUBLIC KEY----- 1032 Authors' Addresses 1034 Tirumaleswar Reddy 1035 McAfee, Inc. 1036 Embassy Golf Link Business Park 1037 Bangalore, Karnataka 560071 1038 India 1040 Email: kondtir@gmail.com 1042 Dan Wing 1043 Citrix Systems, Inc. 1044 USA 1046 Email: dwing-ietf@fuggles.com 1048 Michael C. Richardson 1049 Sandelman Software Works 1050 USA 1052 Email: mcr+ietf@sandelman.ca 1054 Mohamed Boucadair 1055 Orange 1056 Rennes 35000 1057 France 1059 Email: mohamed.boucadair@orange.com