idnits 2.17.1 draft-reddy-dprive-dprive-privacy-policy-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 (October 3, 2019) is 1667 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) == Missing Reference: 'RFCThis' is mentioned on line 672, but not defined == Outdated reference: A later version (-01) exists of draft-ietf-dnsop-resolver-information-00 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' == Outdated reference: A later version (-14) exists of draft-ietf-dprive-bcp-op-03 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-04 -- 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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: April 5, 2020 Citrix 6 M. Richardson 7 Sandelman Software Works 8 October 3, 2019 10 DNS server privacy policy with assertion token 11 draft-reddy-dprive-dprive-privacy-policy-00 13 Abstract 15 Users want to control how their DNS queries are handled by DNS 16 servers so they can configure their system to use DNS servers that 17 comply with their privacy expectations. 19 This document defines a mechanism for a DNS server to communicate its 20 privacy policy to a DNS client. This communication is 21 cryptographically signed to attest to its authenticity. By 22 evaluating the DNS privacy policy and the signatory, the DNS client 23 can choose a DNS server that best supports its desired privacy 24 policies. The privacy assertion token is particularly useful for 25 DNS-over-TLS and DNS-over-HTTPS servers, both public resolvers and 26 those discovered on the local network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 5, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Privacy assertion token (PAT) overview . . . . . . . . . . . 4 65 4. PAT Header . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 5 67 4.2. "alg" (Algorithm) Header Parameter . . . . . . . . . . . 5 68 4.3. "x5u" (X.509 URL) Header Parameter . . . . . . . . . . . 6 69 4.4. Example PAT header . . . . . . . . . . . . . . . . . . . 6 70 5. PAT Payload . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5.1. JWT defined claims . . . . . . . . . . . . . . . . . . . 7 72 5.1.1. "iat" - Issued At claim . . . . . . . . . . . . . . . 7 73 5.1.2. "exp" - Expiration Time claim . . . . . . . . . . . . 7 74 5.2. PAT specific claims . . . . . . . . . . . . . . . . . . . 7 75 5.2.1. DNS server Identity Claims . . . . . . . . . . . . . 7 76 5.2.2. "privinfo" (Privacy Information) Claim . . . . . . . 8 77 5.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. PAT Signature . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7. Extending PAT . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. Deterministic JSON Serialization . . . . . . . . . . . . . . 12 81 8.1. Example PAT deterministic JSON form . . . . . . . . . . . 13 82 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 11.1. Media Type Registration . . . . . . . . . . . . . . . . 15 86 11.1.1. Media Type Registry Contents Additions Requested . . 15 87 11.2. JSON Web Token Claims Registration . . . . . . . . . . . 16 88 11.2.1. Registry Contents Additions Requested . . . . . . . 16 89 11.3. DNS Resolver Information Registration . . . . . . . . . 16 90 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 13.2. Informative References . . . . . . . . . . . . . . . . . 18 94 Appendix A. Example ES256 based PAT JWS Serialization and 95 Signature . . . . . . . . . . . . . . . . . . . . . 19 96 A.1. X.509 Private Key in PKCS#8 format for ES256 Example** . 21 97 A.2. X.509 Public Key for ES256 Example** . . . . . . . . . . 21 98 Appendix B. Complete JWS JSON Serialization Representation with 99 multiple Signatures . . . . . . . . . . . . . . . . 21 100 B.1. X.509 Private Key in PKCS#8 format for E384 Example** . . 23 101 B.2. X.509 Public Key for ES384 Example** . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 [RFC7626] discusses DNS privacy considerations in both "on the wire" 107 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 108 [RFC7626] contexts. In recent years there has also been an increase 109 in the availability of "public resolvers" 110 [I-D.ietf-dnsop-terminology-bis] which DNS clients may be pre- 111 configured to use instead of the default network resolver because 112 they offer a specific feature (e.g., good reachability, encrypted 113 transport, strong privacy policy, filtering (or lack of), etc.). 114 While a human can read the privacy policy of a DNS server operator, 115 this information is not machine-parsable to allow automatic DNS 116 server selection by the DNS client software. For DNS servers 117 operated on the local network, the DNS client can be securely 118 bootstrapped to discover and authenticate DNS-over-TLS and DNS-over- 119 HTTPS servers provided by a local network using the technique 120 proposed in [I-D.reddy-dprive-bootstrap-dns-server]. By creating a 121 machine-parsable DNS server privacy policy, the DNS client can 122 automatically allow using a DNS server on the local network that 123 complies with the DNS client's privacy policy. 125 This document defines a method for creating and validating a token 126 that cryptographically verifies the privacy policy information of a 127 DNS server, such as a DNS-over-TLS or DNS-over-HTTPS server. 129 The cryptographically signed privacy statement allows a DNS client to 130 connect to multiple DNS servers and select the DNS server that 131 adheres to the privacy preserving data policy requirements of the 132 client. For example, a browser with pre-configured DNS-over-HTTPS 133 server can discover the DNS-over-HTTPS server provided the local 134 network, connects to both the DNS servers, gets the privacy policy 135 information from each of the DNS servers, validates the signatures 136 and uses a server that meets the privacy preserving data policy 137 requirements of the client. If both servers meet the privacy 138 preserving data policy requirements of the client, it can select to 139 use the local DNS server. In addition, the cryptographically signed 140 privacy statement allows a DNS-over-TLS or DNS-over-HTTPS client to 141 securely determine whether the local DNS server performs DNS-based 142 content filtering, and if the local server meets the privacy 143 preserving data policy requirements of the client, the client can 144 continue to use the local DNS-over-TLS server to resolve DNS queries 145 and does not have to switch to the pre-configured public resolver. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119][RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 (D)TLS is used for statements that apply to both Transport Layer 156 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 157 Specific terms are used for any statement that applies to either 158 protocol alone. 160 This document uses the terms defined in [RFC8499]. 162 3. Privacy assertion token (PAT) overview 164 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 165 and related specifications define a standard token format that can be 166 used as a way of encapsulating claimed or asserted information with 167 an associated digital signature using X.509 based certificates. JWT 168 provides a set of claims in JSON format that can conveniently 169 accommodate asserted privacy policy information of the DNS-over-TLS 170 or DNS-over-HTTPS server. Additionally, JWS provides a path for 171 updating methods and cryptographic algorithms used for the associated 172 digital signatures. 174 JWS defines the use of JSON data structures in a specified canonical 175 format for signing data corresponding to JOSE header, JWS Payload, 176 and JWS Signature. JWT defines a set of claims that are represented 177 by specified JSON objects which can be extended with custom keys for 178 specific applications. The next sections define the header and 179 claims that MUST be minimally used with JWT and JWS for privacy 180 assertion token. 182 The privacy assertion token (PAT) specifically uses this token format 183 and defines claims that convey the privacy policy information of DNS- 184 over-TLS or DNS-over-HTTPS server. The signer of a PAT object may or 185 may not correspond to the DNS server's domain. The PAT object can be 186 validated by the DNS client, and if the DNS server meets the privacy 187 preserving data policy requirements of the client and/or end user, it 188 can switch to the privacy-enabling DNS server discovered in the 189 located network. The creation of the PAT object is performed by an 190 entity that is authoritative to assert the DNS server privacy policy 191 information. This authority is represented by the certificate 192 credentials and the signature, and PAT object is created and the 193 client can retrieve the PAT object using the method discussed in 194 [I-D.ietf-dnsop-resolver-information]. 196 For example, the PAT object could be created by the domain hosting 197 the DNS-over-TLS or DNS-over-HTTPS server, or by a third party who 198 performed privacy and security audit of the DNS-over-TLS or DNS-over- 199 HTTPS server. The DNS client needs to have the capability to verify 200 the PAT token and the digital signature. The PAT associated 201 certificate is used to validate the authority of the originating 202 signer, generally via a certificate chain to the trust anchor for the 203 DNS client. 205 4. PAT Header 207 The JWS token header is a JOSE header, [RFC7515] Section 4, that 208 defines the type and encryption algorithm used in the token. 210 PAT header should include, at a minimum, the header parameters 211 defined in the next three subsections. 213 4.1. "typ" (Type) Header Parameter 215 The "typ" (Type) Header Parameter is defined in JWS [RFC7515] 216 Section 4.1.9 to declare the media type of the complete JWS. 218 For PAT Token the "typ" header MUST be the string "pat". This 219 represents that the encoded token is a JWT of type pat. 221 4.2. "alg" (Algorithm) Header Parameter 223 The "alg" (Algorithm) Header Parameter is defined in JWS [RFC7515] 224 Section 4.1.1. This definition includes the ability to specify the 225 use of a cryptographic algorithm for the signature part of the JWS. 226 It also refers to a list of defined "alg" values as part of a 227 registry established by JSON Web Algorithms (JWA) [RFC7518] 228 Section 3.1. 230 For the creation and verification of PAT tokens and their digital 231 signatures, implementations MUST support ES256 as defined in JWA 232 [RFC7518] Section 3.4. Implementations MAY support other algorithms 233 registered in the JSON Web Signature and Encryption Algorithms 234 registry created by [RFC7518]. The contents of that registry may be 235 updated in the future depending on cryptographic strength 236 requirements guided by current security best practice. The 237 mandatory-to-support algorithm for PAT tokens may likewise be updated 238 in future updates to this document. 240 Implementations of PAT digital signatures using ES256 as defined 241 above SHOULD use deterministic ECDSA if/when supported for the 242 reasons stated in [RFC6979]. 244 4.3. "x5u" (X.509 URL) Header Parameter 246 As defined in JWS [RFC7515] Section 4.1.5., the "x5u" header 247 parameter defines a URI [RFC3986] referring to the resource for the 248 X.509 public key certificate or certificate chain [RFC5280] 249 corresponding to the key used to digitally sign the JWS. Generally, 250 as defined in JWS [RFC7515] section 4.1.5, this would correspond to 251 an HTTPS or DNSSEC resource using integrity protection. 253 4.4. Example PAT header 255 An example of the header, would be the following, including the 256 specified pat type, ES256 algorithm, and a URI referencing the 257 network location of the certificate needed to validate the PAT 258 signature. 260 { 261 "typ":"pat", 262 "alg":"ES256", 263 "x5u":"https://cert.example.com/pat.cer" 264 } 266 5. PAT Payload 268 The token claims consists of the privacy policy information of the 269 DNS server which needs to be verified at the DNS client. These 270 claims follow the definition of a JWT claim [RFC7519] Section 4 and 271 are encoded as defined by the JWS Payload [RFC7515] Section 3. 273 PAT defines the use of a standard JWT defined claim as well as custom 274 claims corresponding to the DNS-over-TLS or DNS-over-HTTPS servers. 276 Any claim names MUST use the US-ASCII character set. Any claim 277 values can contain characters that are outside the US-ASCII range, 278 however MUST follow the default JSON serialization defined in 279 [RFC7519] Section 7. 281 5.1. JWT defined claims 283 5.1.1. "iat" - Issued At claim 285 The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined 286 claim Issued At. As defined the "iat" should be set to the date and 287 time of issuance of the JWT. The time value should be of the format 288 defined in [RFC7519] Section 2 NumericDate. 290 5.1.2. "exp" - Expiration Time claim 292 The JSON claim MUST include the "exp" [RFC7519] Section 4.1.4 defined 293 claim Expiration Time. As defined the "exp" should be set to specify 294 the expiration time on or after which the JWT is not accepted for 295 processing. The PAT object should generally expire after a 296 reasonable duration. A short expiration time for the PAT object 297 periodically reaffirms the privacy policy information of the DNS 298 server to the client and ensures the client does not use outdated 299 privacy policy information. If the client knows the PAT object has 300 expired, it makes another request to get the new PAT object from the 301 DNS server. 303 5.2. PAT specific claims 305 5.2.1. DNS server Identity Claims 307 The DNS server identity is represented by a claim that is required 308 for PAT, the "server" claim. The "server" MUST contain claim values 309 that are identity claim JSON objects where the child claim name 310 represents an identity type and the claim value is the identity 311 string, both defined in subsequent subsections. Currently, these 312 identities can be represented as either authentication domain name 313 (ADN) (defined in [RFC8310]) or Uniform Resource Indicators (URI). 315 5.2.1.1. "adn" - authentication domain name identity 317 If the DNS server identity is a ADN, the claim name representing the 318 identity MUST be "adn". The claim value for the "adn" claim is the 319 ADN. 321 5.2.1.2. "uri" - URI identity 323 If the DNS server identity is of the form URI, as defined in 324 [RFC3986], the claim name representing the identity MUST be "uri" and 325 the claim value is the URI form of the DNS server identity. As a 326 reminder, if DNS-over-HTTPS protocol is supported by the DNS server, 327 the DNS client uses the https URI scheme (Section 3 of [RFC8484]). 329 5.2.2. "privinfo" (Privacy Information) Claim 331 The "privinfo" claim MUST be formatted as a JSON object. The 332 "privinfo" claim contains the privacy policy information of the DNS 333 server, it includes the following attributes: 335 ipaddresspii: If the client IP address is Personally Identifiable 336 Information (PII) data or non PII-data. If client IP address is 337 PII, the parameter value is set to 'true'. This is a mandatory 338 attribute. 340 logging: If the transaction data (e.g., DNS messages) is logged and 341 the duration that data is stored. A value of negative one (-1) 342 indicates indefinite duration of logging transaction data. A 343 value of zero (0) indicates no logging. Logging duration is 344 represented in hours. If any of the attributes 'useridentity', 345 'notifyuser' and 'analytics' are not set to the value zero, 346 'logging' attribute MUST NOT be set to the value zero. This is a 347 mandatory attribute. 349 useridentity: If the user identity that sent the DNS query is logged 350 and the duration that data is retained. User identity includes 351 things such as username, IP address, MAC address, user DNS query 352 patterns or any other personally identifiable data. The server 353 should also discard or minimize correlation data (Section 5.2.4 of 354 [I-D.ietf-dprive-bcp-op]) that can be used to identify the end 355 user. A value of negative one (-1) indicates indefinite duration 356 of logging user identity. A value of zero (0) indicates no 357 logging. Logging duration is represented in hours. This is a 358 mandatory attribute. 360 filtering: If the DNS server changes some of the answers that it 361 returns based on policy criteria, such as to prevent access to 362 malware sites or objectionable content. This optional attribute 363 has the following structure: 365 malwareblocking: The DNS server offers malware blocking service. 366 If access to domains is blocked on threat data, the parameter 367 value is set to 'true'. 369 policyblocking: If access to domains is blocked on a blacklist or 370 objectionable content, the parameter value is set to 'true'. 372 notifyuser: If the transaction data is logged to notify the user 373 access to certain domains is blocked, the period for which the 374 transaction data is stored. A value of negative one (-1) 375 indicates indefinite duration of logging transaction data to 376 notify the user. A value of zero (0) indicates no logging. 378 Logging duration is represented in hours. This is an optional 379 attribute. 381 analytics: If the transaction data is logged for analytics (e.g., To 382 detect malicious domains), the period for which the transaction 383 data is stored. A value of negative one (-1) indicates indefinite 384 duration of logging transaction data for analytics. A value of 385 zero (0) indicates no logging. Logging duration is represented in 386 hours. This is an optional attribute. 388 sharedata: If the transaction data is shared with partners or not, 389 and if the transaction data is shared with partners, the names of 390 the partners. If anonymized data or client identifiable data is 391 shared with partners. The term "anonymization" is defined in 392 Section 5.2.2 of [I-D.ietf-dprive-bcp-op]. This mandatory 393 attribute has the following structure: 395 sharepartners: If transaction data is shared with partners, the 396 parameter value is set to 'true'. 398 partners: List of partner names. If 'sharepartners' value is set 399 to false, 'partners' MUST NOT be present in the 'sharedata' 400 structure. 402 anonymizeddata: If anonymized transaction data is shared with 403 partners, the parameter value is set to 'true'. If 404 'sharepartners' value is set to false, 'anonymizeddata' MUST 405 NOT be present in the 'sharedata' structure. 407 transferdata: If the transaction data is shared or sold to third 408 parties. If the parameter value is set to 'true', means share or 409 sell data to third parties. This is a mandatory attribute. 411 qnameminimization: If the DNS server implements QNAME minimisation 412 [RFC7816] to improve DNS privacy. If the parameter value is set 413 to 'true', QNAME minimisation is supported by the DNS server. 414 This is a mandatory attribute. 416 privacyurl: A URL that points to the privacy policy information of 417 the DNS server. This is a mandatory attribute. 419 auditurl: A URL that points to the security assessment report of the 420 DNS server by a third party auditor. This is an optional 421 attribute. 423 upstreamservers: The local DNS server can be configured as a 424 Forwarding DNS server [RFC8499] relying on the upstream resolver 425 (e.g., at an ISP) to perform recursive DNS lookups. The client 426 needs to discover the privacy policy information of both the 427 forwarder and recursive resolvers. This optional attribute has 428 the following structure: 430 securechannel: If DNS-over-TLS or DNS-over-HTTPS is used to 431 encrypt the DNS messages exchanged between the local DNS server 432 and recursive resolver, the parameter value is set to 'true'. 434 upstreamserverspat: The PAT object of the upstream DNS server. 435 If a local DNS server is configured as a Forwarding DNS server, 436 its PAT MUST include the PAT object of the upstream resolver it 437 is using. If the upstream DNS resolver does not communicate 438 its privacy policy, the attribute value must be set to empty 439 string. The client can combine the local and upstream 440 resolver's privacy policies, always combining for the worse 441 privacy values. For example, if the local server does not log 442 queries but the upstream resolver does log queries, the 443 combined PAT policy would indicate queries are logged and the 444 client can evaluate if its privacy preserving data policy 445 requirements are met. The Forwarding DNS server is typically 446 configured with both primary and secondary resolvers as a 447 backup mechanism to handle primary server failure. If the 448 local DNS server is configured to use primary and secondary 449 resolvers, 'upstreamserverspat' MUST include two entries in the 450 array. If the local DNS server is acting as a forwarder, it 451 RECOMMENDED that the DNS client requests the privacy policy 452 information of the server every time the connection is re- 453 established with the server. It allows the client to detect 454 change in the local DNS server configuration to use an 455 alternate resolver. 457 5.2.3. Example 459 The below Figure shows an example of privacy policy information. 461 { 462 "server":{ 463 "adn":["example.com"] 464 }, 465 "iat":1443208345, 466 "exp":1443640345, 467 "privinfo": { 468 "ipaddresspii":true, 469 "logging": 24, 470 "useridentity": 24, 471 "sharedata": { 472 "sharepartners": false 473 }, 474 "transferdata":false, 475 "privacyurl": "https://example.com/commitment-to-privacy/" 476 } 477 } 479 6. PAT Signature 481 The signature of the PAT is created as specified by JWS [RFC7515] 482 Section 5.1 Steps 1 through 6. PAT MUST use the JWS Protected 483 Header. For the JWS Payload and the JWS Protected Header, the 484 lexicographic ordering and white space rules described in Section 4 485 and Section 5, and JSON serialization rules in Section 8 of this 486 document MUST be followed. 488 The PAT is cryptographically signed by the domain hosting the DNS 489 server and optionally by a third party who performed privacy and 490 security audit of the DNS server. The privacy policy information 491 will be attested using "Organization Validation" (OV) or "Extended 492 Validation" (EV) certificates to avoid bad actors taking advantage of 493 this mechanism to advertise DNS-over-TLS and DNS-over-HTTPS servers 494 for illegitimate and fraudulent purposes meant to trick DNS clients 495 into believing that they are using a legitimate DNS-over-TLS or DNS- 496 over-HTTPS server hosted to provide privacy for DNS transactions. 497 Alternatively, the DNS client will have to be configured to trust the 498 leaf of the signer of the PAT object. That is, trust of the signer 499 MUST NOT be determined by validating the signer via the OS or browser 500 trust chain because that would allow any arbitrary entity to operate 501 a DNS server and assert any sort of privacy policy. 503 Appendix A of this document has a detailed example of how to follow 504 the steps to create the JWS Signature. 506 JWS [RFC7515] Section 5.1 Step 7 JWS JSON serialization is supported 507 for PAT to enable multiple signatures to be applied to the PAT 508 object. For example, the PAT object can be cryptographically signed 509 by the domain hosting the DNS server and by a third party who 510 performed privacy and security audit of the DNS server. 512 Appendix B of this document has a example of complete JWS JSON 513 serialization representation with multiple signatures. 515 JWS [RFC7515] Section 5.1 Step 8 describes the method to create the 516 final JWS Compact Serialization form of the PAT Token. 518 7. Extending PAT 520 PAT includes the minimum set of claims needed to securely assert the 521 privacy policy information of the DNS server. JWT supports a 522 straight forward way to add additional asserted or signed information 523 by simply adding new claims. PAT can be extended beyond the defined 524 base set of claims to represent other DNS server information 525 requiring assertion or validation. Specifying new claims follows the 526 baseline JWT procedures ([RFC7519] Section 10.1). Understanding new 527 claims on the DNS client is optional. The creator of a PAT object 528 cannot assume that the DNS client will understand the new claims. 530 8. Deterministic JSON Serialization 532 JSON objects can include spaces and line breaks, and key value pairs 533 can occur in any order. It is therefore a non-deterministic string 534 format. In order to make the digital signature verification work 535 deterministically, the JSON representation of the JWS Protected 536 Header object and JWS Payload object MUST be computed as follows. 538 The JSON object MUST follow the following rules. These rules are 539 based on the thumbprint of a JSON Web Key (JWK) as defined in 540 Section 3 Step 1 of [RFC7638]. 542 1. The JSON object MUST contain no whitespace or line breaks before 543 or after any syntactic elements. 545 2. JSON objects MUST have the keys ordered lexicographically by the 546 Unicode [UNICODE] code points of the member names. 548 3. JSON value literals MUST be lowercase. 550 4. JSON numbers are to be encoded as integers unless the field is 551 defined to be encoded otherwise. 553 5. Encoding rules MUST be applied recursively to member values and 554 array values. 556 8.1. Example PAT deterministic JSON form 558 This section demonstrates the deterministic JSON serialization for 559 the example PAT Payload shown in Section 5.2.3. 561 The initial JSON object is shown here: 563 { 564 "server":{ 565 "adn":["example.com"] 566 }, 567 "iat":1443208345, 568 "exp":1443640345, 569 "privinfo": { 570 "ipaddresspii":true, 571 "logging": 24, 572 "useridentity": 24, 573 "sharedata": { 574 "sharepartners": false 575 }, 576 "transferdata":false, 577 "privacyurl": "https://example.com/commitment-to-privacy/" 578 } 579 } 581 The parent members of the JSON object are as follows, in 582 lexicographic order: "exp", "iat", "privinfo", "server". 584 The final constructed deterministic JSON serialization 585 representation, with whitespace and line breaks removed, (with line 586 breaks used for display purposes only) is: 588 {"exp":1443640345,"iat":1443208345,"privinfo":{"ipaddresspii":true, 589 "logging":24,"privacyurl":"https://example.com/commitment-to-privacy/", 590 "sharedata":{"sharepartners":false},"transferdata":false, 591 "useridentity":24},"server":{"adn":["example.com"]}} 593 9. Privacy Considerations 595 Users are expected to indicate to their system in some way that they 596 trust certain PAT signers (e.g., if working for Example, Inc., the 597 user's system is configured to trust example.com signing the PAT). 598 Separately, the user is expected to indicate to their system their 599 PAT privacy requirements (e.g., logging, etc.). By doing so, the DNS 600 client can automatically discover local DNS-over-TLS or DNS-over- 601 HTTPS server, validate the PAT signature and check if the PAT 602 complies with user's privacy needs, prior to using that DNS-over-TLS 603 or DNS-over-HTTPS server for DNS queries. The client MAY also 604 retrieve the human-readable privacy statement from the 'privacyurl' 605 attribute to assist with that decision (e.g., display the privacy 606 statement when it changes, show differences in previously-retrieved 607 version, etc.). With the steps above, user consent is obtained prior 608 to using a locally-discovered DNS-over-TLS or DNS-over-HTTPS server 609 for DNS queries. 611 An average user may not be able to indicate the privacy preserving 612 data policy requirements to the system. For such users, the DNS 613 client should auto check if the PAT complies with typical users 614 privacy needs. For example, the client by default does not select 615 the local DNS-over-TLS or DNS-over-HTTPS server if it shares non- 616 anonymized DNS transaction data with partners or if it logs the DNS 617 transaction data for a very long duration. 619 10. Security Considerations 621 The use of PAT object based on the validation of the digital 622 signature and the associated certificate requires consideration of 623 the authentication and authority or reputation of the signer to 624 attest the privacy policy information of the DNS server being 625 asserted. Bad actors can host DNS-over-TLS and DNS-over-HTTPS 626 servers, and claim the servers offer privacy but exactly do the 627 opposite to invade the privacy of the user. Bad actor can get a 628 domain name, host DNS-over-TLS and DNS-over-HTTPS servers, and get 629 the DNS server certificate signed by a CA. The privacy policy 630 information will have to be attested using OV/EV certificates or a 631 PAT object signer trusted by the DNS client to prevent the attack. 633 If the PAT object is asserted by a third party, it can do a "time of 634 check" but the DNS server is susceptible of "time of use" attack. 635 For example, changes to privacy policy of the DNS server like sharing 636 identifiable transaction data with partners can cause a disagreement 637 between the PAT object and the DNS server operation. In other words, 638 the DNS server might have complied with the privacy policy when it 639 was audited (by the 3rd party) but could now be in non-compliance 640 with its privacy policy, hence the PAT object needs to be also 641 asserted by the domain hosting the DNS server. In addition, the PAT 642 object needs to have a short expiration time (e.g., 7 days) to ensure 643 the DNS server's domain re-asserts the privacy policy information and 644 limits the damage from change in privacy policy and mis-issuance. 646 11. IANA Considerations 647 11.1. Media Type Registration 649 11.1.1. Media Type Registry Contents Additions Requested 651 This section registers the "application/pat" media type [RFC2046] in 652 the "Media Types" registry in the manner described in [RFC6838], 653 which can be used to indicate that the content is a PAT defined JWT. 655 o Type name: application 657 o Subtype name: pat 659 o Required parameters: n/a 661 o Optional parameters: n/a 663 o Encoding considerations: 8bit; application/pat values are encoded 664 as a series of base64url-encoded values (some of which may be the 665 empty string) separated by period ('.') characters.. 667 o Security considerations: See the Security Considerations 668 Section of [RFC7515]. 670 o Interoperability considerations: n/a 672 o Published specification: [RFCThis] 674 o Applications that use this media type: DNS 676 o Fragment identifier considerations: n/a 678 o Additional information: 680 Magic number(s): n/a File extension(s): n/a Macintosh file type 681 code(s): n/a 683 o Person & email address to contact for further information: 684 Tirumaleswar Reddy, kondtir@gmail.com 686 o Intended usage: COMMON 688 o Restrictions on usage: none 690 o Author: Tirumaleswar Reddy, kondtir@gmail.com 692 o Change Controller: IESG 694 o Provisional registration? No 696 11.2. JSON Web Token Claims Registration 698 11.2.1. Registry Contents Additions Requested 700 o Claim Name: "server" 702 o Claim Description: DNS server identity 704 o Change Controller: IESG 706 o Specification Document(s): Section 5.2.1 of [TODO this document] 708 o Claim Name: "privinfo" 710 o Claim Description: Privacy policy information of DNS server. 712 o Change Controller: IESG 714 o Specification Document(s): Section 5.2.2 of [TODO this document] 716 11.3. DNS Resolver Information Registration 718 IANA will add the names ipaddresspii, logging, useridentity, 719 filtering, notifyuser, analytics, sharedata, transferdata, 720 qnameminimization, privacyurl, auditurl and upstreamserverpat to the 721 DNS Resolver Information registry defined in Section 5.2 of 722 [I-D.ietf-dnsop-resolver-information]. 724 12. Acknowledgments 726 This specification leverages some of the work that has been done in 727 [RFC8225]. Thanks to Ted Lemon and Shashank Jain for the discussion 728 and comments. 730 13. References 732 13.1. Normative References 734 [I-D.ietf-dnsop-resolver-information] 735 Sood, P., Arends, R., and P. Hoffman, "DNS Resolver 736 Information Self-publication", draft-ietf-dnsop-resolver- 737 information-00 (work in progress), August 2019. 739 [I-D.ietf-dnsop-terminology-bis] 740 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 741 Terminology", draft-ietf-dnsop-terminology-bis-14 (work in 742 progress), September 2018. 744 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 745 Extensions (MIME) Part Two: Media Types", RFC 2046, 746 DOI 10.17487/RFC2046, November 1996, 747 . 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 755 Resource Identifier (URI): Generic Syntax", STD 66, 756 RFC 3986, DOI 10.17487/RFC3986, January 2005, 757 . 759 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 760 Housley, R., and W. Polk, "Internet X.509 Public Key 761 Infrastructure Certificate and Certificate Revocation List 762 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 763 . 765 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 766 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 767 January 2012, . 769 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 770 Specifications and Registration Procedures", BCP 13, 771 RFC 6838, DOI 10.17487/RFC6838, January 2013, 772 . 774 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 775 Algorithm (DSA) and Elliptic Curve Digital Signature 776 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 777 2013, . 779 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 780 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 781 2015, . 783 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 784 DOI 10.17487/RFC7518, May 2015, 785 . 787 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 788 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 789 . 791 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 792 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 793 2015, . 795 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 796 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 797 May 2017, . 799 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 800 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 801 . 803 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 804 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 805 . 807 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 808 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 809 January 2019, . 811 [UNICODE] The Unicode Consortium, "The Unicode Standard", June 2016, 812 . 814 13.2. Informative References 816 [I-D.ietf-dprive-bcp-op] 817 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 818 Mankin, "Recommendations for DNS Privacy Service 819 Operators", draft-ietf-dprive-bcp-op-03 (work in 820 progress), July 2019. 822 [I-D.reddy-dprive-bootstrap-dns-server] 823 K, R., Wing, D., Richardson, M., and M. Boucadair, "A 824 Bootstrapping Procedure to Discover and Authenticate DNS- 825 over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 826 dprive-bootstrap-dns-server-04 (work in progress), June 827 2019. 829 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 830 DOI 10.17487/RFC7626, August 2015, 831 . 833 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 834 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 835 . 837 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 838 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 839 . 841 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 842 for DNS over TLS and DNS over DTLS", RFC 8310, 843 DOI 10.17487/RFC8310, March 2018, 844 . 846 Appendix A. Example ES256 based PAT JWS Serialization and Signature 848 For PAT, there will always be a JWS with the following members: 850 o "protected", with the value BASE64URL(UTF8(JWS Protected Header)) 852 o "payload", with the value BASE64URL (JWS Payload) 854 o "signature", with the value BASE64URL(JWS Signature) 856 This example will follow the steps in JWS [RFC7515] Section 5.1, 857 steps 1-6 and 8 and incorporates the additional serialization steps 858 required for PAT. 860 Step 1 for JWS references the JWS Payload, an example PAT Payload is 861 as follows: 863 { 864 "server":{ 865 "adn":["example.com"] 866 }, 867 "iat":1443208345, 868 "exp":1443640345, 869 "privinfo": { 870 "ipaddresspii":true, 871 "logging": 24, 872 "useridentity": 24, 873 "sharedata": { 874 "sharepartners": false 875 }, 876 "transferdata":false, 877 "privacyurl": "https://example.com/commitment-to-privacy/" 878 } 879 } 881 This would be serialized to the form (with line break used for 882 display purposes only): 884 {"exp":1443640345,"iat":1443208345,"privinfo":{"ipaddresspii":true, 885 "logging":24,"privacyurl":"https://example.com/commitment-to-privacy/", 886 "sharedata":{"sharepartners":false},"transferdata":false, 887 "useridentity":24},"server":{"adn":["example.com"]}} 889 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 890 line break used for display purposes only): 892 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicHJpdmluZm8iOnsi 893 aXBhZGRyZXNzcGlpIjp0cnVlLCJsb2dnaW5nIjoyNCwicHJpdmFjeXVybCI6Imh0 894 dHBzOi8vZXhhbXBsZS5jb20vY29tbWl0bWVudC10by1wcml2YWN5LyIsInNoYXJl 895 ZGF0YSI6eyJzaGFyZXBhcnRuZXJzIjpmYWxzZX0sInRyYW5zZmVyZGF0YSI6ZmFs 896 c2UsInVzZXJpZGVudGl0eSI6MjR9LCJzZXJ2ZXIiOnsiYWRuIjpbImV4YW1wbGUu 897 Y29tIl19fQ 899 For Step 3, an example PAT Protected Header comprising the JOSE 900 Header is as follows: 902 { 903 "alg":"ES256", 904 "typ":"pat", 905 "x5u":"https://cert.example.com/pat.cer" 906 } 908 This would be serialized to the form (with line break used for 909 display purposes only): 911 {"alg":"ES256","typ":"pat","x5u":"https://cert.example.com 912 /pat.cer"} 914 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 915 and encoding produces this value (with line break used for display 916 purposes only): 918 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 919 eGFtcGxlLmNvbS9wYXQuY2VyIn0 921 Step 5 and Step 6 performs the computation of the digital signature 922 of the PAT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 923 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 924 algorithm and the BASE64URL(JWS Signature). 926 LEyaZpkJWVeJiQXdh6stCUo5VnLO56p9nTNsG8xhqpQMoJWc4j46Ze_43wPG-vHb 927 Xq7BaVIfdb_Lw3BcKr92Cw 928 Step 8 describes how to create the final PAT token, concatenating the 929 values in the order Header.Payload.Signature with period ('.') 930 characters. For the above example values this would produce the 931 following (with line breaks between period used for readability 932 purposes only): 934 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 935 eGFtcGxlLmNvbS9wYXQuY2VyIn0 936 . 937 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicHJpdmluZm8iOnsi 938 aXBhZGRyZXNzcGlpIjp0cnVlLCJsb2dnaW5nIjoyNCwicHJpdmFjeXVybCI6Imh0 939 dHBzOi8vZXhhbXBsZS5jb20vY29tbWl0bWVudC10by1wcml2YWN5LyIsInNoYXJl 940 ZGF0YSI6eyJzaGFyZXBhcnRuZXJzIjpmYWxzZX0sInRyYW5zZmVyZGF0YSI6ZmFs 941 c2UsInVzZXJpZGVudGl0eSI6MjR9LCJzZXJ2ZXIiOnsiYWRuIjpbImV4YW1wbGUu 942 Y29tIl19fQ 943 . 944 1ysb-n4O3YeN7HwPtzMP3SCEz28I80c78Lke4D_DRiwT8_-zi0p8IwmNU9778lOy 945 Ub9WZehA89G4VMx8DDpm0Q 947 A.1. X.509 Private Key in PKCS#8 format for ES256 Example** 949 -----BEGIN PRIVATE KEY----- 950 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 951 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 952 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 953 -----END PRIVATE KEY----- 955 A.2. X.509 Public Key for ES256 Example** 957 -----BEGIN PUBLIC KEY----- 958 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 959 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 960 -----END PUBLIC KEY----- 962 Appendix B. Complete JWS JSON Serialization Representation with 963 multiple Signatures 965 The JWS payload used in this example as follows. 967 { 968 "server":{ 969 "adn":["example.com"] 970 }, 971 "iat":1443208345, 972 "exp":1443640345, 973 "privinfo": { 974 "ipaddresspii":true, 975 "logging": 24, 976 "useridentity": 24, 977 "sharedata": { 978 "sharepartners": false 979 }, 980 "transferdata":false, 981 "privacyurl": "https://example.com/commitment-to-privacy/", 982 "auditurl": "https://audit-example.com/privacyaudit" 983 } 984 } 986 This would be serialized to the form (with line break used for 987 display purposes only): 989 {"auditurl":"https://audit-example.com/privacyaudit","exp":1443640345, 990 "iat":1443208345,"privinfo":{"ipaddresspii":true,"logging":24, 991 "privacyurl":"https://example.com/commitment-to-privacy/", 992 "sharedata":{"sharepartners":false},"transferdata":false, 993 "useridentity":24},"server":{"adn":["example.com"]}} 995 The JWS protected Header value used for the first signature is same 996 as that used in the example in Appendix A. The X.509 private key 997 used for generating the first signature is same as that used in the 998 example in Appendix A.1. 1000 The JWS Protected Header value used for the second signature is: 1002 { 1003 "alg":"ES384", 1004 "typ":"pat", 1005 "x5u":"https://cert.audit-example.com/pat.cer" 1006 } 1008 The complete JWS JSON Serialization for these values is as follows 1009 (with line breaks within values for display purposes only): 1011 { 1012 "payload": 1013 "eyJhdWRpdHVybCI6Imh0dHBzOi8vYXVkaXQtZXhhbXBsZS5jb20vcHJpdmFjeWF 1014 1ZGl0IiwiZXhwIjoxNDQzNjQwMzQ1LCJpYXQiOjE0NDMyMDgzNDUsInByaXZpbmZ 1015 vIjp7ImlwYWRkcmVzc3BpaSI6dHJ1ZSwibG9nZ2luZyI6MjQsInByaXZhY3l1cmw 1016 iOiJodHRwczovL2V4YW1wbGUuY29tL2NvbW1pdG1lbnQtdG8tcHJpdmFjeS8iLCJ 1017 zaGFyZWRhdGEiOnsic2hhcmVwYXJ0bmVycyI6ZmFsc2V9LCJ0cmFuc2ZlcmRhdGE 1018 iOmZhbHNlLCJ1c2VyaWRlbnRpdHkiOjI0fSwic2VydmVyIjp7ImFkbiI6WyJleGF 1019 tcGxlLmNvbSJdfX0", 1020 "signatures":[ 1021 {"protected":"eyJhbGciOiJFUzI1NiIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 1022 zOi8vY2VydC5leGFtcGxlLmNvbS9wYXQuY2VyIn0", 1023 "signature": 1024 "VeX23b4UNTRE358iXJGBnSnMXkIfrEYeZwA8aVKA1In-Nz5lpGVFXIjArnUY7T 1025 D9vMR01jUzTy4qVbtA0smbUA"}, 1026 {"protected":"eyJhbGciOiJFUzM4NCIsInR5cCI6InBhdCIsIng1dSI6Imh0dHB 1027 zOi8vY2VydC5hdWRpdC1leGFtcGxlLmNvbS9wYXQuY2VyIn0", 1028 "signature": 1029 "PKLgW0O3YZAv5ZlIMbQqOgCegAT_TUo6fshOuuGrPqBSYRgIb2ApfvCENzdp-f 1030 rKQEVUTWj2odSzMaEKBkjIv49GdEEvAxIy6C5uNzugfsGZswu7gyY8-9mZ_OFV 1031 -nWF"}] 1032 } 1034 B.1. X.509 Private Key in PKCS#8 format for E384 Example** 1036 -----BEGIN PRIVATE KEY----- 1037 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 1038 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 1039 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 1040 -----END PRIVATE KEY----- 1042 B.2. X.509 Public Key for ES384 Example** 1044 -----BEGIN PUBLIC KEY----- 1045 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 1046 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 1047 -----END PUBLIC KEY----- 1049 Authors' Addresses 1051 Tirumaleswar Reddy 1052 McAfee, Inc. 1053 Embassy Golf Link Business Park 1054 Bangalore, Karnataka 560071 1055 India 1057 Email: kondtir@gmail.com 1058 Dan Wing 1059 Citrix Systems, Inc. 1060 USA 1062 Email: dwing-ietf@fuggles.com 1064 Michael C. Richardson 1065 Sandelman Software Works 1066 USA 1068 Email: mcr+ietf@sandelman.ca