idnits 2.17.1 draft-reddy-add-server-policy-selection-08.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 REAT for further processing. -- The document date (March 29, 2021) is 1117 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: 'I-D.ietf-add-dnr' is mentioned on line 116, but not defined == Missing Reference: 'I-D.ietf-add-ddr' is mentioned on line 224, but not defined == Missing Reference: 'I-D.reddy-add-resolver-info' is mentioned on line 372, but not defined == Unused Reference: 'RFC7493' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'I-D.btw-add-home' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'I-D.pp-add-resinfo' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC7816' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'RFC8259' is defined on line 760, but no explicit reference was found in the text == Unused Reference: 'RFC8914' is defined on line 775, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6979 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) == Outdated reference: A later version (-04) exists of draft-btw-add-ipsecme-ike-01 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-08 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- 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 (~~), 15 warnings (==), 4 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: September 30, 2021 Citrix 6 M. Richardson 7 Sandelman Software Works 8 M. Boucadair 9 Orange 10 March 29, 2021 12 DNS Server Selection: DNS Server Information with Assertion Token 13 draft-reddy-add-server-policy-selection-08 15 Abstract 17 The document defines a mechanism that is meant to communicate DNS 18 resolver information to DNS clients for use as a criteria for server 19 selection decisions. Such an information that is cryptographically 20 signed to attest its authenticity is used for the selection of DNS 21 resolvers. Typically, evaluating the resolver information and the 22 signatory, DNS clients with minimal or no human intervention can 23 select the DNS servers for resolving domain names. 25 This assertion is useful for encrypted DNS (e.g., DNS-over-TLS, DNS- 26 over-HTTPS, or DNS-over-QUIC) servers that are either public 27 resolvers or discovered in a local network. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 30, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Resolver Assertion Token (REAT): Overview . . . . . . . . . . 4 66 4. REAT Header . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. 'typ' (Type) Header Parameter . . . . . . . . . . . . . . 6 68 4.2. 'alg' (Algorithm) Header Parameter . . . . . . . . . . . 6 69 4.3. 'x5u' (X.509 URL) Header Parameter . . . . . . . . . . . 6 70 4.4. An Example of REAT Header . . . . . . . . . . . . . . . . 7 71 5. REAT Payload . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. JWT Defined Claims . . . . . . . . . . . . . . . . . . . 7 73 5.1.1. 'iat' - Issued At Claim . . . . . . . . . . . . . . . 7 74 5.1.2. 'exp' - Expiration Time Claim . . . . . . . . . . . . 7 75 5.2. REAT Specific Claims . . . . . . . . . . . . . . . . . . 8 76 5.2.1. DNS Server Identity Claims . . . . . . . . . . . . . 8 77 5.2.2. 'resinfo' (Resolver Information) Claim . . . . . . . 8 78 5.2.3. An Example . . . . . . . . . . . . . . . . . . . . . 9 79 6. REAT Signature . . . . . . . . . . . . . . . . . . . . . . . 9 80 7. Extending REAT . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. Deterministic JSON Serialization . . . . . . . . . . . . . . 10 82 8.1. Example REAT Deterministic JSON Form . . . . . . . . . . 11 83 9. Using RESINFO Responses . . . . . . . . . . . . . . . . . . . 11 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 11.1. Media Type Registration . . . . . . . . . . . . . . . . 12 87 11.1.1. Media Type Registry Contents Additions Requested . . 12 88 11.2. JSON Web Token Claims Registration . . . . . . . . . . . 13 89 11.2.1. Registry Contents Additions Requested . . . . . . . 13 90 11.3. DNS Resolver Information Registration . . . . . . . . . 14 91 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 13.2. Informative References . . . . . . . . . . . . . . . . . 16 95 Appendix A. Example of ES256-based REAT JWS Serialization and 96 Signature . . . . . . . . . . . . . . . . . . . . . 17 97 A.1. X.509 Private Key in PKCS#8 Format for ES256 Example** . 19 98 A.2. X.509 Public Key for ES256 Example** . . . . . . . . . . 19 99 Appendix B. Complete JWS JSON Serialization Representation with 100 multiple Signatures . . . . . . . . . . . . . . . . 20 101 B.1. X.509 Private Key in PKCS#8 format for E384 Example** . . 21 102 B.2. X.509 Public Key for ES384 Example** . . . . . . . . . . 21 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 105 1. Introduction 107 [RFC7626] discusses DNS privacy considerations in both "on the wire" 108 (Section 2.4 of [RFC7626]) and "in the server" (Section 2.5 of 109 [RFC7626]) contexts. Examples of protocols that provide encrypted 110 channels between DNS clients and servers are DNS-over-HTTPS (DoH) 111 [RFC8484], DNS-over-TLS (DoT) [RFC7858], and DNS-over-QUIC (DoQ) 112 [I-D.ietf-dprive-dnsoquic]. 114 DNS clients can discover and authenticate encrypted DNS servers 115 provided by a local network, for example using the techniques 116 proposed in [I-D.ietf-add-dnr] and [I-D.ietf-add-ddr]. If the 117 mechanism used to discover the encrypted DNS server is insecure, the 118 DNS client needs evidence about the encrypted server to assess its 119 trustworthiness and a way to appraise such evidence. The mechanism 120 specified in this document can be used by the DNS client to 121 cryptographically identify if it is connecting to an encrypted DNS 122 server hosted by a specific organization (e.g., ISP or Enterprise). 123 This strengthens the protection as clients can detect and reject 124 connections to encrypted DNS servers hosted by attackers. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119][RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 This document makes use of the terms defined in [RFC8499] and 135 [I-D.ietf-dnsop-terminology-ter]. 137 'Encrypted DNS' refers to a DNS protocol that provides an encrypted 138 channel between a DNS client and server (e.g., DoT, DoH, or DoQ). 140 The terms 'Evidence', 'Verifier', 'Background Check', 'Relying 141 Party', 'Appraisal Policy', and 'Attestation Results' are defined in 142 [I-D.ietf-rats-architecture]. 144 3. Resolver Assertion Token (REAT): Overview 146 The mechanism used in this specification resembles the Background- 147 Check Model discussed in Sections 5.2 and 5.3 of Remote attestation 148 procedure (RATS) Architecture [I-D.ietf-rats-architecture]. RATS 149 enables a relying party to establish a level of confidence in the 150 trustworthiness of a remote peer through the creation of Evidence to 151 assess the peer's trustworthiness, and an Appraisal Policy for such 152 Evidence. 154 In this document, the Relying Party is the DNS client and the 155 Attester is the encrypted DNS server. The Encrypted DNS servers MAY 156 use "Domain Validation" (DV) certificates for certificate-based 157 server authentication in TLS connections. 159 The DNS server's resolver information needs to be validated and 160 signed. This signature is called an Attestation Result 161 [I-D.ietf-rats-architecture]. This validation can be performed by 162 the DNS operator itself (signed by the DNS operator's certificate) 163 acting as a verifier or performed by an external Verifier (signed by 164 that external Verifier). The signing certificate can to be an 165 Extended Validation (EV) certificate issued by a public CA in 166 specific scenarios listed below. An EV certificate is issued by the 167 public CA after a thorough Background Check to verify the requesting 168 organization's legal identity. If the signing certificate is a EV 169 certificate, it leaves the client with a better audit trail of the 170 organization hosting the DNS server in comparison with the DV 171 certificate. 173 The use of EV certificate is needed in the following scenarios: 175 o It helps the client to avoid sending DNS queries to an Encrypted 176 DNS server hosted by an attacker discovered insecurely (e.g., 177 using DHCP/RA or DNS). For example, an attacker can get a domain 178 name, domain-validated public certificate from a CA and host a 179 Encrypted DNS server. Furthermore, an attacker can use a public 180 IP address, get an 'IP address'-validated public certificate from 181 a CA and host a Encrypted DNS server. 183 o It can be used by the client to identify the Encrypted DNS server 184 is hosted by a legal organization. 186 The use of EV certificate is not required in the following scenarios: 188 o If the Encrypted DNS server can only be discovered securely (e.g., 189 using IKEv2 [I-D.btw-add-ipsecme-ike]), the signing certificate 190 need not be an EV certificate. 192 o Secure Zero Touch Provisioning [RFC8572] defines a bootstrapping 193 strategy for enabling a networking device to securely obtain the 194 required configuration information with no user input. If the 195 encrypted DNS server is insecurely discovered and not 196 preconfigured in the networking device, the DNS client on the 197 networking device can validate the Resolver Assertion Token 198 signature using the owner certificate as per Section 3.2 of 199 [RFC8572]. 201 JSON Web Token (JWT) [RFC7519] and JSON Web Signature (JWS) [RFC7515] 202 and related specifications define a standard token format that can be 203 used as a way of encapsulating claimed or asserted information with 204 an associated digital signature using X.509 based certificates. JWT 205 provides a set of claims in JSON format that can accommodate asserted 206 resolver information of the Encrypted DNS server. Additionally, JWS 207 provides a path for updating methods and cryptographic algorithms 208 used for the associated digital signatures. 210 JWS defines the use of JSON data structures in a specified canonical 211 format for signing data corresponding to JOSE header, JWS Payload, 212 and JWS Signature. The next sections define the header and claims 213 that MUST be minimally used with JWT and JWS for resolver assertion 214 token. 216 The REsolver Assertion Token (REAT) specifically uses this token 217 format and defines claims that convey the resolver information of 218 Encrypted DNS server. 220 The client can retrieve the REAT object using the RESINFO RRtype 221 defined in [I-D.reddy-add-resolver-info] and QNAME of the domain name 222 that is used to authenticate the DNS server (referred to as ADN in 223 [RFC8310]). If the special use domain name "resolver.arpa" defined 224 in [I-D.ietf-add-ddr] is used to discover the Encrypted DNS server, 225 the client can retrieve the REAT object using the RESINFO RRtype and 226 QNAME of the special use domain name. 228 The signature of REAT object MUST be validated by the DNS client. If 229 signature is invalid, the REAT object is rejected. If signature is 230 valid and signer is trusted, the DNS client can use that encrypted 231 DNS server. 233 4. REAT Header 235 The JWS token header is a JOSE header (Section 4 of [RFC7515]) that 236 defines the type and encryption algorithm used in the token. 238 The REAT header MUST include, at a minimum, the header parameters 239 defined in Sections 4.1, 4.2, and 4.3. 241 4.1. 'typ' (Type) Header Parameter 243 The 'typ' (Type) Header Parameter is defined in Section 4.1.9 of 244 [RFC7515] to declare the media type of the complete JWS. 246 For REAT Token the 'typ' header MUST be the string 'rat'. This 247 represents that the encoded token is a JWT of type rat. 249 4.2. 'alg' (Algorithm) Header Parameter 251 The 'alg' (Algorithm) Header Parameter is defined in Section 4.1.1 of 252 [RFC7515]. It specifies the JWS signature cryptographic algorithm. 253 It also refers to a list of defined 'alg' values as part of a 254 registry established by JSON Web Algorithms (JWA) [RFC7518] 255 Section 3.1. 257 For the creation and verification of REAT tokens and their digital 258 signatures, implementations MUST support ES256 as defined in 259 Section 3.4 of [RFC7518]. Implementations MAY support other 260 algorithms registered in the JSON Web Signature and Encryption 261 Algorithms registry created by [RFC7518]. The content of that 262 registry may be updated in the future depending on cryptographic 263 strength requirements guided by current security best practice. The 264 mandatory-to-support algorithm for REAT tokens may likewise be 265 updated in the future. 267 Implementations of REAT digital signatures using ES256 as defined 268 above SHOULD use deterministic ECDSA when supported for the reasons 269 stated in [RFC6979]. 271 4.3. 'x5u' (X.509 URL) Header Parameter 273 As defined in Section 4.1.5 of [RFC7515], the 'x5u' header parameter 274 defines a URI [RFC3986] referring to the resource for the X.509 275 public key certificate or certificate chain [RFC5280] corresponding 276 to the key used to digitally sign the JWS. Generally, as defined in 277 Section 4.1.5 of [RFC7515] this corresponds to an HTTPS or DNSSEC 278 resource using integrity protection. 280 4.4. An Example of REAT Header 282 An example of the REAT header is shown in Figure 1. It includes the 283 specified REAT type, ES256 algorithm, and an URI referencing the 284 network location of the certificate needed to validate the REAT 285 signature. 287 { 288 "typ":"rat", 289 "alg":"ES256", 290 "x5u":"https://cert.example.com/rat.cer" 291 } 293 Figure 1: A REAT Header Example 295 5. REAT Payload 297 The token claims consist of the resolver information of the DNS 298 server that needs to be verified at the DNS client. These claims 299 follow the definition of a JWT claim (Section 4 of [RFC7519]) and are 300 encoded as defined by the JWS Payload (Section 3 of [RFC7515]). 302 REAT defines the use of a standard JWT-defined claim as well as 303 custom claims corresponding to the DoT or DoH servers. 305 Claim names MUST use the US-ASCII character set. Claim values MAY 306 contain characters that are outside the ASCII range, however they 307 MUST follow the default JSON serialization defined in Section 7 of 308 [RFC7519]. 310 5.1. JWT Defined Claims 312 5.1.1. 'iat' - Issued At Claim 314 The JSON claim MUST include the 'iat' (Section 4.1.6 of [RFC7519]) 315 defined claim "Issued At". The 'iat' should be set to the date and 316 time of issuance of the JWT. The time value should be of the format 317 (NumericDate) defined in Section 2 of [RFC7519]. 319 5.1.2. 'exp' - Expiration Time Claim 321 The JSON claim MUST include the 'exp' (Section 4.1.4 of [RFC7519]) 322 defined "claim Expiration Time". The 'exp' should be set to specify 323 the expiration time on or after which the JWT is not accepted for 324 processing. The REAT object should expire after a reasonable 325 duration. A short expiration time for the REAT object periodically 326 reaffirms the resolver information of the DNS server to the DNS 327 client and ensures the DNS client does not use outdated resolver 328 information. If the DNS client knows the REAT object has expired, it 329 should make another request to get the new REAT object from the DNS 330 server. 332 5.2. REAT Specific Claims 334 5.2.1. DNS Server Identity Claims 336 The DNS server identity is represented by a claim that is required 337 for REAT: the 'server' claim. The 'server' MUST contain claim values 338 that are identity claim JSON objects where the child claim name 339 represents an identity type and the claim value is the identity 340 string, both defined in subsequent subsections. 342 These identities can be represented as either authentication domain 343 name (ADN) (defined in [RFC8310]) or Uniform Resource Indicators 344 (URI). 346 The DNS client constructs a reference identifier for the DNS server 347 based on the ADN or the domain portion in the URI of the DNS server 348 identity. The domain name in the DNS-ID identifier type within 349 subjectAltName entry in the DNS server certificate conveyed in the 350 TLS handshake is matched with the reference identifier. If the match 351 is not successful, the client MUST not accept the REAT for further 352 processing. 354 5.2.1.1. 'adn' - Authentication Domain Name Identity 356 If the DNS server identity is an ADN, the claim name representing the 357 identity MUST be 'adn'. The claim value for the 'adn' claim is the 358 ADN. 360 5.2.1.2. 'uri' - URI Identity 362 If the DNS server identity is of the form URI Template, as defined in 363 [RFC6570], the claim name representing the identity MUST be 'uri' and 364 the claim value is the URI Template form of the DNS server identity. 366 As a reminder, if DoH is supported by the DNS server, the DNS client 367 uses the URI Template (Section 3 of [RFC8484]). 369 5.2.2. 'resinfo' (Resolver Information) Claim 371 The 'resinfo' claim contains the resolver information of the DNS 372 server defined in Section 5 of [I-D.reddy-add-resolver-info]. 374 5.2.3. An Example 376 Figure 2 shows an example of resolver information. 378 { 379 "server":{ 380 "adn":"example.com" 381 }, 382 "iat":1443208345, 383 "exp":1443640345, 384 "resinfo": { 385 "qnameminimization":false, 386 } 387 } 389 Figure 2: An Example of Resolver Information 391 6. REAT Signature 393 The signature of the REAT is created as specified in Section 5.1 of 394 [RFC7515] (Steps 1 through 6). REAT MUST use the JWS Protected 395 Header. 397 For the JWS Payload and the JWS Protected Header, the lexicographic 398 ordering and white space rules described in Section 4 and Section 5, 399 and JSON serialization rules in Section 8 MUST be followed. 401 The REAT is cryptographically signed by the domain hosting the DNS 402 server and optionally by a third party who performed privacy and 403 security audit of the DNS server. 405 The resolver information is attested using "Extended Validation" (EV) 406 certificate to avoid bad actors taking advantage of this mechanism to 407 advertise encrypted DNS servers for illegitimate and fraudulent 408 purposes meant to trick DNS clients into believing that they are 409 using a legitimate encrypted DNS server hosted to provide privacy for 410 DNS transactions. 412 Alternatively, a DNS client has to be configured to trust the leaf of 413 the signer of the REAT object. That is, trust of the signer MUST NOT 414 be determined by validating the signer via the OS or the browser 415 trust chain because that would allow any arbitrary entity to operate 416 a DNS server and assert any sort of resolver information. 418 Appendix A provides an example of how to follow the steps to create 419 the JWS Signature. 421 JWS JSON serialization (Step 7 in Section 5.1 of [RFC7515]) is 422 supported for REAT to enable multiple signatures to be applied to the 423 REAT object. For example, the REAT object can be cryptographically 424 signed by the domain hosting the DNS server and by a third party who 425 performed privacy and security audit of the DNS server. 427 Appendix B includes an example of the full JWS JSON serialization 428 representation with multiple signatures. 430 Section 5.1 of [RFC7515] (Step 8) describes the method to create the 431 final JWS Compact Serialization form of the REAT Token. 433 7. Extending REAT 435 REAT includes the minimum set of claims needed to securely assert the 436 resolver information of the DNS server. JWT supports a mechanism to 437 add additional asserted or signed information by simply adding new 438 claims. REAT can be extended beyond the defined base set of claims 439 to represent other DNS server information requiring assertion or 440 validation. Specifying new claims follows the baseline JWT 441 procedures (Section 10.1 of [RFC7519]). Understanding new claims on 442 the DNS client is optional. The creator of a REAT object cannot 443 assume that the DNS client will understand the new claims. 445 8. Deterministic JSON Serialization 447 JSON objects can include spaces and line breaks, and key value pairs 448 can occur in any order. It is therefore a non-deterministic string 449 format. In order to make the digital signature verification work 450 deterministically, the JSON representation of the JWS Protected 451 Header object and JWS Payload object MUST be computed as follows. 453 The JSON object MUST follow the following rules. These rules are 454 based on the thumbprint of a JSON Web Key (JWK) as defined in 455 Section 3 of [RFC7638] (Step 1). 457 1. The JSON object MUST contain no whitespace or line breaks before 458 or after any syntactic elements. 460 2. JSON objects MUST have the keys ordered lexicographically by the 461 Unicode [UNICODE] code points of the member names. 463 3. JSON value literals MUST be lowercase. 465 4. JSON numbers are to be encoded as integers unless the field is 466 defined to be encoded otherwise. 468 5. Encoding rules MUST be applied recursively to member values and 469 array values. 471 8.1. Example REAT Deterministic JSON Form 473 This section demonstrates the deterministic JSON serialization for 474 the example REAT Payload shown in Section 5.2.3. 476 The initial JSON object is shown in Figure 3. 478 { 479 "server":{ 480 "adn":"example.com" 481 }, 482 "iat":1443208345, 483 "exp":1443640345, 484 "resinfo": { 485 "qnameminimization":false, 486 } 487 } 489 Figure 3: Initial JSON Object 491 The parent members of the JSON object are as follows, in 492 lexicographic order: "exp", "iat", "resinfo", "server". 494 The final constructed deterministic JSON serialization 495 representation, with whitespace and line breaks removed, (with line 496 breaks used for display purposes only) is: 498 {"exp":1443640345,"iat":1443208345, 499 "resinfo":{"qnameminimization":false}, 500 "server":{"adn":"example.com"}} 502 Figure 4: Deterministic JSON Form 504 9. Using RESINFO Responses 506 This document defines the following entry for the IANA DNS Resolver 507 Information Registry that is defined in [I-D.reddy-add-resolver- 508 info]. 510 o The "attested-resinfo" name contains the full REAT object. The 511 REAT header, REAT payload, and REAT signature components comprise 512 a full REAT object. If the "attested-resinfo" name is conveyed to 513 the client, the server need not convey the attributes 514 "resinfourl", "identityurl", "extendeddnserror" and 515 "qnameminimization" attributes separately as that resolver 516 information will be extracted by the client from the REAT payload. 518 10. Security Considerations 520 The use of REAT object based on the validation of the digital 521 signature and the associated certificate requires consideration of 522 the authentication and authority or reputation of the signer to 523 attest the resolver information of the DNS server being asserted. 524 Bad actors can host encrypted DNS servers to invade the privacy of 525 the user. Bad actor can get a domain name, host encrypted DNS 526 servers, and get the DNS server certificate signed by a CA. The 527 resolver information will have to be attested using EV certificates 528 or a REAT object signer trusted by the DNS client to prevent the 529 attack. 531 The CA that issued the EV certificate does not attest the resolver 532 information. The organization hosting the DNS server attests the 533 resolver information using the EV certificate and the client uses the 534 EV certificate to identify the organization (e.g., ISP or Enterprise) 535 hosting the DNS server. 537 If the REAT object is asserted by a third party, it can do a "time of 538 check" but the DNS server is susceptible of "time of use" attack. 539 For example, changes to the DNS server can cause a disagreement 540 between the auditor and the DNS server operation, hence the REAT 541 object needs to be also asserted by the domain hosting the DNS 542 server. In addition, the REAT object needs to have a short 543 expiration time (e.g., 7 days) to ensure the DNS server's domain re- 544 asserts the resolver information and limits the damage from change in 545 behaviour and mis-issuance. 547 11. IANA Considerations 549 11.1. Media Type Registration 551 11.1.1. Media Type Registry Contents Additions Requested 553 This section registers the 'application/rat' media type [RFC2046] in 554 the 'Media Types' registry in the manner described in [RFC6838], 555 which can be used to indicate that the content is a REAT defined JWT. 557 o Type name: application 559 o Subtype name: rat 561 o Required parameters: n/a 562 o Optional parameters: n/a 564 o Encoding considerations: 8bit; application/rat values are encoded 565 as a series of base64url-encoded values (some of which may be the 566 empty string) separated by period ('.') characters.. 568 o Security considerations: See the Security Considerations 569 Section of [RFC7515]. 571 o Interoperability considerations: n/a 573 o Published specification: [THIS_DOCUMENT] 575 o Applications that use this media type: DNS 577 o Fragment identifier considerations: n/a 579 o Additional information: 581 Magic number(s): n/a File extension(s): n/a Macintosh file type 582 code(s): n/a 584 o Person & email address to contact for further information: 585 Tirumaleswar Reddy, kondtir@gmail.com 587 o Intended usage: COMMON 589 o Restrictions on usage: none 591 o Author: Tirumaleswar Reddy, kondtir@gmail.com 593 o Change Controller: IESG 595 o Provisional registration? No 597 11.2. JSON Web Token Claims Registration 599 11.2.1. Registry Contents Additions Requested 601 IANA is requested to assign the following claims in the registry 602 maintained in: https://www.iana.org/assignments/jwt/jwt.xhtml. 604 o Claim Name: 'server' 606 o Claim Description: DNS server identity 608 o Change Controller: IESG 609 o Specification Document(s): Section 5.2.1 of [THIS_DOCUMENT] 611 o Claim Name: 'resinfo' 613 o Claim Description: Resolver information of DNS server. 615 o Change Controller: IESG 617 o Specification Document(s): Section 5.2.2 of [THIS_DOCUMENT] 619 11.3. DNS Resolver Information Registration 621 IANA will add the name "attested-resinfo" to the DNS Resolver 622 Information registry defined in Section 7.2 of [I-D.reddy-add- 623 resolver-info]. 625 12. Acknowledgments 627 This specification leverages some of the work that has been done in 628 [RFC8225]. Thanks to Tommy Jensen, Ted Lemon, Paul Wouters, Neil 629 Cook, Vittorio Bertola, Vinny Parla, Chris Box, Ben Schwartz and 630 Shashank Jain for the discussion and comments. 632 13. References 634 13.1. Normative References 636 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 637 Extensions (MIME) Part Two: Media Types", RFC 2046, 638 DOI 10.17487/RFC2046, November 1996, 639 . 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 647 Resource Identifier (URI): Generic Syntax", STD 66, 648 RFC 3986, DOI 10.17487/RFC3986, January 2005, 649 . 651 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 652 Housley, R., and W. Polk, "Internet X.509 Public Key 653 Infrastructure Certificate and Certificate Revocation List 654 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 655 . 657 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 658 and D. Orchard, "URI Template", RFC 6570, 659 DOI 10.17487/RFC6570, March 2012, 660 . 662 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 663 Specifications and Registration Procedures", BCP 13, 664 RFC 6838, DOI 10.17487/RFC6838, January 2013, 665 . 667 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 668 Algorithm (DSA) and Elliptic Curve Digital Signature 669 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 670 2013, . 672 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 673 DOI 10.17487/RFC7493, March 2015, 674 . 676 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 677 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 678 2015, . 680 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 681 DOI 10.17487/RFC7518, May 2015, 682 . 684 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 685 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 686 . 688 [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) 689 Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 690 2015, . 692 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 693 and P. Hoffman, "Specification for DNS over Transport 694 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 695 2016, . 697 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 698 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 699 May 2017, . 701 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 702 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 703 . 705 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 706 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 707 January 2019, . 709 13.2. Informative References 711 [I-D.btw-add-home] 712 Boucadair, M., Reddy.K, T., Wing, D., Cook, N., and T. 713 Jensen, "DHCP and Router Advertisement Options for 714 Encrypted DNS Discovery", draft-btw-add-home-12 (work in 715 progress), January 2021. 717 [I-D.btw-add-ipsecme-ike] 718 Boucadair, M., Reddy.K, T., Wing, D., and V. Smyslov, 719 "Internet Key Exchange Protocol Version 2 (IKEv2) 720 Configuration for Encrypted DNS", draft-btw-add-ipsecme- 721 ike-01 (work in progress), September 2020. 723 [I-D.ietf-dnsop-terminology-ter] 724 Hoffman, P., "Terminology for DNS Transports and 725 Location", draft-ietf-dnsop-terminology-ter-02 (work in 726 progress), August 2020. 728 [I-D.ietf-dprive-dnsoquic] 729 Huitema, C., Mankin, A., and S. Dickinson, "Specification 730 of DNS over Dedicated QUIC Connections", draft-ietf- 731 dprive-dnsoquic-01 (work in progress), October 2020. 733 [I-D.ietf-rats-architecture] 734 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 735 W. Pan, "Remote Attestation Procedures Architecture", 736 draft-ietf-rats-architecture-08 (work in progress), 737 December 2020. 739 [I-D.pp-add-resinfo] 740 Sood, P. and P. Hoffman, "DNS Resolver Information Self- 741 publication", draft-pp-add-resinfo-02 (work in progress), 742 June 2020. 744 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 745 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 746 2014, . 748 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 749 DOI 10.17487/RFC7626, August 2015, 750 . 752 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 753 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 754 . 756 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 757 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 758 . 760 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 761 Interchange Format", STD 90, RFC 8259, 762 DOI 10.17487/RFC8259, December 2017, 763 . 765 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 766 for DNS over TLS and DNS over DTLS", RFC 8310, 767 DOI 10.17487/RFC8310, March 2018, 768 . 770 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 771 Touch Provisioning (SZTP)", RFC 8572, 772 DOI 10.17487/RFC8572, April 2019, 773 . 775 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 776 Lawrence, "Extended DNS Errors", RFC 8914, 777 DOI 10.17487/RFC8914, October 2020, 778 . 780 [UNICODE] The Unicode Consortium, "The Unicode Standard", June 2016, 781 . 783 Appendix A. Example of ES256-based REAT JWS Serialization and Signature 785 For REAT, there will always be a JWS with the following members: 787 o 'protected', with the value BASE64URL(UTF8(JWS Protected Header)) 789 o 'payload', with the value BASE64URL (JWS Payload) 791 o 'signature', with the value BASE64URL(JWS Signature) 793 This example will follow the steps in JWS [RFC7515] Section 5.1, 794 steps 1-6 and 8 and incorporates the additional serialization steps 795 required for REAT. 797 Step 1 for JWS references the JWS Payload, an example REAT Payload is 798 as follows: 800 { 801 "server":{ 802 "adn":"example.com" 803 }, 804 "iat":1443208345, 805 "exp":1443640345, 806 "resinfo": { 807 "qnameminimization":false 808 } 809 } 811 This would be serialized to the form (with line break used for 812 display purposes only): 814 {"exp":1443640345,"iat":1443208345,"resinfo":{ 815 "qnameminimization":false},"server":{"adn":"example.com"}} 817 Step 2 Computes the BASE64URL(JWS Payload) producing this value (with 818 line break used for display purposes only): 820 eyJleHAiOjE0NDM2NDAzNDUsImlhdCI6MTQ0MzIwODM0NSwicmVzaW5mbyI6ey 821 JxbmFtZW1pbmltaXphdGlvbiI6ZmFsc2V9LCJzZXJ2ZXIiOnsiYWRuIjoiZXhh 822 bXBsZS5jb20ifX0 824 For Step 3, an example REAT Protected Header comprising the JOSE 825 Header is as follows: 827 { 828 "alg":"ES256", 829 "typ":"rat", 830 "x5u":"https://cert.example.com/rat.cer" 831 } 833 This would be serialized to the form (with line break used for 834 display purposes only): 836 {"alg":"ES256","typ":"rat","x5u":"https://cert.example.com 837 /rat.cer"} 839 Step 4 Performs the BASE64URL(UTF8(JWS Protected Header)) operation 840 and encoding produces this value (with line break used for display 841 purposes only): 843 eyJhbGciOiJFUzI1NiIsInR5cCI6InJhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 844 eGFtcGxlLmNvbS9yYXQuY2VyIn0 846 Step 5 and Step 6 performs the computation of the digital signature 847 of the REAT Signing Input ASCII(BASE64URL(UTF8(JWS Protected 848 Header)) || '.' || BASE64URL(JWS Payload)) using ES256 as the 849 algorithm and the BASE64URL(JWS Signature). 851 d1g7szj0roHsWe8psCzYVl4QdN2b7pQnq8EJhc4j3GOJj2NE6M9Em6aidtycnFJ5 852 mRj3ojiUfVF6rK5RksD0rg 854 Step 8 describes how to create the final REAT token, concatenating 855 the values in the order Header.Payload.Signature with period ('.') 856 characters. For the above example values this would produce the 857 following (with line breaks between period used for readability 858 purposes only): 860 eyJhbGciOiJFUzI1NiIsInR5cCI6InJhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 861 eGFtcGxlLmNvbS9yYXQuY2VyIn0 862 . 864 eyJhbGciOiJFUzI1NiIsInR5cCI6InJhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 865 eGFtcGxlLmNvbS9yYXQuY2VyIn0 866 . 867 d1g7szj0roHsWe8psCzYVl4QdN2b7pQnq8EJhc4j3GOJj2NE6M9Em6aidtycnFJ5 868 mRj3ojiUfVF6rK5RksD0rg 870 A.1. X.509 Private Key in PKCS#8 Format for ES256 Example** 872 -----BEGIN PRIVATE KEY----- 873 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 874 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 875 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 876 -----END PRIVATE KEY----- 878 A.2. X.509 Public Key for ES256 Example** 880 -----BEGIN PUBLIC KEY----- 881 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 882 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 883 -----END PUBLIC KEY----- 885 Appendix B. Complete JWS JSON Serialization Representation with 886 multiple Signatures 888 The JWS payload used in this example as follows. 890 { 891 "server":{ 892 "adn":"example.com" 893 }, 894 "iat":1443208345, 895 "exp":1443640345, 896 "resinfo": { 897 "qnameminimization":false 898 } 899 } 901 This would be serialized to the form (with line break used for 902 display purposes only): 904 {"exp":1443640345,"iat":1443208345,"resinfo":{ 905 "qnameminimization":false},"server":{"adn":"example.com"}} 907 The JWS protected Header value used for the first signature is same 908 as that used in the example in Appendix A. The X.509 private key 909 used for generating the first signature is same as that used in the 910 example in Appendix A.1. 912 The JWS Protected Header value used for the second signature is: 914 { 915 "alg":"ES384", 916 "typ":"rat", 917 "x5u":"https://cert.audit-example.com/rat.cer" 918 } 920 The complete JWS JSON Serialization for these values is as follows 921 (with line breaks within values for display purposes only): 923 { 924 "payload": 925 "eyJhbGciOiJFUzI1NiIsInR5cCI6InJhdCIsIng1dSI6Imh0dHBzOi8vY2VydC5l 926 eGFtcGxlLmNvbS9yYXQuY2VyIn0", 927 "signatures":[ 928 {"protected":"eyJhbGciOiJFUzI1NiIsInR5cCI6InJhdCIsIng1dSI6Imh0dHBz 929 Oi8vY2VydC5leGFtcGxlLmNvbS9yYXQuY2VyIn0", 930 "signature":"d1g7szj0roHsWe8psCzYVl4QdN2b7pQnq8EJhc4j3GOJj2NE6M9E 931 m6aidtycnFJ5mRj3ojiUfVF6rK5RksD0rg"}, 932 {"protected":"eyJhbGciOiJFUzM4NCIsInR5cCI6InJhdCIsIng1dSI6Imh0dHB 933 zOi8vY2VydC5hdWRpdC1leGFtcGxlLmNvbS9yYXQuY2VyIn0", 934 "signature":"GnKuEEFql_Y8HdZl_mqd027DlziGRXFHvjMoY_ukX-M0k5v2jSL 935 vsQAYOGdKFnt3JY6t938HfBV1onsWerNhgceMJpx5hAsl-xus3fmNY8K1g6QK39 936 hn2Dhbleeeyp0f"}] 937 } 939 B.1. X.509 Private Key in PKCS#8 format for E384 Example** 941 -----BEGIN PRIVATE KEY----- 942 MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgevZzL1gdAFr88hb2 943 OF/2NxApJCzGCEDdfSp6VQO30hyhRANCAAQRWz+jn65BtOMvdyHKcvjBeBSDZH2r 944 1RTwjmYSi9R/zpBnuQ4EiMnCqfMPWiZqB4QdbAd0E7oH50VpuZ1P087G 945 -----END PRIVATE KEY----- 947 B.2. X.509 Public Key for ES384 Example** 949 -----BEGIN PUBLIC KEY----- 950 MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs/o5+uQbTjL3chynL4wXgUg2R9 951 q9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B+dFabmdT9POxg== 952 -----END PUBLIC KEY----- 954 Authors' Addresses 956 Tirumaleswar Reddy 957 McAfee, Inc. 958 Embassy Golf Link Business Park 959 Bangalore, Karnataka 560071 960 India 962 Email: kondtir@gmail.com 964 Dan Wing 965 Citrix Systems, Inc. 966 USA 968 Email: dwing-ietf@fuggles.com 969 Michael C. Richardson 970 Sandelman Software Works 971 USA 973 Email: mcr+ietf@sandelman.ca 975 Mohamed Boucadair 976 Orange 977 Rennes 35000 978 France 980 Email: mohamed.boucadair@orange.com