idnits 2.17.1 draft-pauly-dprive-oblivious-doh-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 01, 2019) is 1638 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) -- Looks like a reference, but probably isn't: '32' on line 331 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-00 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'I-D.irtf-cfrg-hpke') == Outdated reference: A later version (-01) exists of draft-pauly-dprive-adaptive-dns-privacy-00 ** Downref: Normative reference to an Experimental RFC: RFC 8467 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Kinnear 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track P. McManus 5 Expires: May 4, 2020 Fastly 6 T. Pauly 7 C. Wood 8 Apple Inc. 9 November 01, 2019 11 Oblivious DNS Over HTTPS 12 draft-pauly-dprive-oblivious-doh-01 14 Abstract 16 This document describes an extension to DNS Over HTTPS (DoH) that 17 allows hiding client IP addresses via proxying encrypted DNS 18 transactions. This improves privacy of DNS operations by not 19 allowing any one server entity to be aware of both the client IP 20 address and the content of DNS queries and answers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 4, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Specification of Requirements . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Deployment Requirements . . . . . . . . . . . . . . . . . . . 3 60 4. HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. HTTP Request . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. HTTP Request Example . . . . . . . . . . . . . . . . . . 5 63 4.3. HTTP Response . . . . . . . . . . . . . . . . . . . . . . 6 64 4.4. HTTP Response Example . . . . . . . . . . . . . . . . . . 6 65 5. Public Key Discovery . . . . . . . . . . . . . . . . . . . . 6 66 6. Oblivious DoH Public Key Format . . . . . . . . . . . . . . . 6 67 7. Oblivious DoH Message Format . . . . . . . . . . . . . . . . 7 68 7.1. Oblivious Queries . . . . . . . . . . . . . . . . . . . . 7 69 7.2. Oblivious Responses . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Oblivious DoH Message Media Type . . . . . . . . . . . . 11 74 9.2. Oblivious DoH Public Key DNS Parameter . . . . . . . . . 12 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 11.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 DNS Over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS 84 messages to be transmitted in encrypted HTTP messages. This provides 85 improved confidentiality and authentication for DNS interactions in 86 various circumstances. 88 While DoH can prevent eavesdroppers from directly reading the 89 contents of DNS exchanges, it does not allow clients to send DNS 90 queries and receive answers from servers without revealing their 91 local IP address, and thus information about the identity or location 92 of the client. 94 Proposals such as Oblivious DNS ([I-D.annee-dprive-oblivious-dns]) 95 allow increased privacy by not allowing any single DNS server to be 96 aware of both the client IP address and the message contents. 98 This document defines Oblivious DoH, an extension to DoH that allows 99 for a proxied mode of resolution, in which DNS messages are encrypted 100 in such a way that no DoH server can independently read both the 101 client IP address and the DNS message contents. 103 This mechanism is intended to be used as one option for resolving 104 privacy-sensitive content in the broader context of Adaptive DNS 105 [I-D.pauly-dprive-adaptive-dns-privacy]. 107 1.1. Specification of Requirements 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 2. Terminology 117 This document defines the following terms: 119 Oblivious Proxy: A server that proxies encrypted client DNS queries 120 to a resolution server that will be able to decrypt the query (the 121 Oblivious Target). Oblivious DoH servers can function as proxies, 122 but other non-resolver proxy servers could also be used. 124 Oblivious Target: A resolution server that receives encrypted client 125 DNS queries and generates encrypted DNS responses transferred via 126 an Oblivious Proxy. 128 3. Deployment Requirements 130 Oblivious DoH requires, at a minimum: 132 o Two DoH servers, where one can act as an Oblivious Proxy, and the 133 other can act as an Oblivious Target. 135 o Public keys for encrypting DNS queries that are passed from a 136 client through a proxy to a target (Section 6). These keys 137 guarantee that only the intended Oblivious Target can decrypt 138 client queries. 140 o Client ability to generate random [RFC4086] one-time-use symmetric 141 keys to encrypt DNS responses. These symmetric keys ensure that 142 only the client will be able to decrypt the response from the 143 Oblivious Target. They are only used once to prevent the 144 Oblivious Target from tracking clients based on keys. 146 The mechanism for discovering and provisioning the DoH URI Templates 147 and public keys is via parameters added to DNS resource records. The 148 mechanism for discovering the public key is decribed in Section 5. 149 The mechanism for discovering a DoH URI Template is described in 150 [I-D.pauly-dprive-adaptive-dns-privacy]. 152 4. HTTP Exchange 154 Unlike direct resolution, oblivious hostname resolution over DoH 155 involves three parties: 157 1. The Client, which generates queries. 159 2. The Oblivious Proxy, which is a resolution server that receives 160 encrypted queries from the client and passes them on to another 161 resolution server. 163 3. The Oblivious Target, which is a resolution server that receives 164 proxied queries from the client via the Oblivious Proxy. 166 --- [ Request encrypted with target public key ] --> 167 +---------+ +-----------+ +-----------+ 168 | Client +-------------> Oblivious +-------------> Oblivious | 169 | <-------------+ Proxy <-------------+ Target | 170 +---------+ +-----------+ +-----------+ 171 <-- [ Response encrypted with client symmetric key ] --- 173 Figure 1: Obvlivious DoH Exchange 175 4.1. HTTP Request 177 Oblivious DoH queries are created by the Client, and sent to the 178 Oblivious Proxy. Requests to the Oblivious Proxy indicate which DoH 179 server to use as an Oblivious Target by specifying two variables: 180 "targethost", which indicates the host name of the Oblivious Target 181 server, and "targetpath", which indicates the path on which the 182 Oblivious Target's DoH server is running. See Section 4.2 for an 183 example request. 185 Oblivious DoH messages have no cache value since both requests and 186 responses are encrypted using ephemeral key material. Clients SHOULD 187 prefer using HTTP methods and headers that will prevent unhelpful 188 cache storage of these exchanges (i.e., preferring POST instead of 189 GET). 191 Clients MUST set the HTTP Content-Type header to "application/ 192 oblivious-dns-message" to indicate that this request is an Oblivious 193 DoH query intended for proxying. Clients also SHOULD set this same 194 value for the HTTP Accept header. 196 Upon receiving a request that contains a "application/oblivious-dns- 197 message" Content-Type, the DoH server looks for the "targethost" and 198 "targetpath" variables. If the variables are not present, then it is 199 the target of the query, and it can decrypt the query (Section 7). 200 If the variables are present, then the DoH server is acting as an 201 Oblivious Proxy. If it is a proxy, it is expected to send the 202 request on to the Oblivious Target using the URI template constructed 203 as "https://targethost/targetpath". 205 4.2. HTTP Request Example 207 The following example shows how a client requests that an Oblivious 208 Proxy, "dnsproxy.example.net", forwards an encrypted message to 209 "dnstarget.example.net". The URI template for the Oblivious Proxy is 210 "https://dnsproxy.example.net/dns-query{?targethost,targetpath}". 211 The URI template for the Oblivious Target is 212 "https://dnstarget.example.net/dns-query". 214 :method = POST 215 :scheme = https 216 :authority = dnsproxy.example.net 217 :path = /dns-query?targethost=dnstarget.example.net&targetpath=/dns-query 218 accept = application/oblivious-dns-message 219 cache-control = no-cache, no-store 220 content-type = application/oblivious-dns-message 221 content-length = 106 223 225 The Oblivious Proxy then sends the following request on to the 226 Oblivious Target: 228 :method = POST 229 :scheme = https 230 :authority = dnstarget.example.net 231 :path = /dns-query 232 accept = application/oblivious-dns-message 233 cache-control = no-cache, no-store 234 content-type = application/oblivious-dns-message 235 content-length = 106 237 239 4.3. HTTP Response 241 The response to an Oblivious DoH query is generated by the Oblivious 242 Target. It MUST set the Content-Type HTTP header to "application/ 243 oblivious-dns-message" for all successful responses. The body of the 244 response contains a DNS message that is encrypted with the client's 245 symmetric key (Section 7). 247 All other aspects of the HTTP response and error handling are 248 inherited from standard DoH. 250 4.4. HTTP Response Example 252 The following example shows a response that can be sent from an 253 Oblivious Target to a client via an Oblivious Proxy. 255 :status = 200 256 content-type = application/oblivious-dns-message 257 content-length = 154 259 261 5. Public Key Discovery 263 In order to use a DoH server as an Oblivious Target, the client must 264 know a public key to use for encrypting its queries. This key can be 265 discovered using the SVCB or HTTPSSVC record type 266 ([I-D.nygren-dnsop-svcb-httpssvc]) for a name owned by the server. 268 The Service Binding key name is "odohkey" (Section 9). If present, 269 this key/value pair contains the public key to use when encrypting 270 Oblivious DoH messages that will be targeted at a DoH server. The 271 format of the key is defined in (Section 6). 273 Clients MUST only use keys that were retrieved from records protected 274 by DNSSEC [RFC4033] to encrypt messages to an Oblivious Target. 276 6. Oblivious DoH Public Key Format 278 An Oblivious DNS public key is a structure encoded, using TLS-style 279 encoding [RFC8446], as follows: 281 struct { 282 uint16 kem_id; 283 uint16 kdf_id; 284 uint16 aead_id; 285 opaque public_key<1..2^16-1>; 286 } ObliviousDNSKey; 287 It contains the information needed to encrypt a message under 288 ObliviousDNSKey.public_key such that only the owner of the 289 corresponding private key can decrypt the message. The values for 290 ObliviousDNSKey.kem_id, ObliviousDNSKey.kdf_id, and 291 ObliviousDNSKey.aead_id are described in [I-D.irtf-cfrg-hpke] 292 Section 7. For convenience, let Identifier(ObliviousDNSKey) be 293 defined as the SHA256 value of ObliviousDNSKey serialized. 295 7. Oblivious DoH Message Format 297 There are two types of Oblivious DoH messages: Queries (0x01) and 298 Responses (0x02). Both are encoded as follows: 300 struct { 301 uint8 message_type; 302 opaque key_id<0..2^16-1>; 303 opaque encrypted_message<1..2^16-1>; 304 } ObliviousDNSMessage; 306 ObliviousDNSMessage.message_type = 0x01 for Query messages and 307 ObliviousDNSMessage.message_type = 0x02 for Response messages. 308 ObliviousDNSMessage.key_id contains the identifier of the 309 corresponding ObliviousDNSKey key. 310 ObliviousDNSMessage.encrypted_message contains an encrypted message 311 for the Oblivious Target (for Query messages) or client (for Response 312 messages). The following sections describe how these meessage bodies 313 are constructed. 315 7.1. Oblivious Queries 317 Oblivious DoH Query messages must carry the following information: 319 1. A symmetric key under which the DNS response will be encrypted. 320 The AEAD algorithm used for the client's response key is the one 321 associated with the server's public key. 323 2. A DNS query message which the client wishes to resolve. 325 3. Padding of arbitrary length which MUST contain all zeros. 327 The key and message are encoded using the following structure: 329 struct { 330 opaque dns_message<1..2^16-1>; 331 opaque response_seed[32]; 332 opaque padding<0..2^16-1>; 333 } ObliviousDNSQueryBody; 334 Let M be a DNS message a client wishes to protect with Oblivious DoH. 335 When sending an Oblivious DoH Query for resolving M to an Oblivious 336 Target with ObliviousDNSKey key pk, a client does the following: 338 1. Generate a random response seed of length 32 octets according to 339 the guidelines in [RFC4086]. 341 2. Create an ObliviousDNSQueryBody structure, carrying the message 342 M, response_seed, and padding, to produce Q_plain. 344 3. Unmarshal pk.public_key to produce a public key pkR of type 345 pk.kem_id. 347 4. Compute the encrypted message as Q_encrypted = 348 encrypt_query_body(pkR, key_id, Q_plain). key_id is defined as 349 Identifier(pk). 351 5. Output a ObliviousDNSMessage message Q where Q.message_type = 352 0x01, Q.key_id carries Identifier(pk), and Q.encrypted_message = 353 Q_encrypted. 355 The client then sends Q to the Oblivious Proxy according to 356 Section 4.1. 358 def encrypt_query_body(pkR, key_id, Q_plain): 359 enc, context = SetupBaseI(pkR, "odns-query") 360 aad = 0x01 || key_id 361 ct = context.Seal(aad, Q_plain) 362 Q_encrypted = enc || ct 363 return Q_encrypted 365 7.2. Oblivious Responses 367 An Oblivious DoH Response message carries the DNS response 368 (dns_message) along with padding. This message is encrypted with the 369 client's chosen response key. 371 struct { 372 opaque dns_message<1..2^16-1>; 373 opaque padding<0..2^16-1>; 374 } ObliviousDNSResponseBody; 376 Targets that receive a Query message Q decrypt and process it as 377 follows: 379 1. Look up the ObliviousDNSKey according to Q.key_id. If no such 380 key exists, the Target MAY discard the query. Otherwise, let skR 381 be the private key corresponding to this public key, or one 382 chosen for trial decryption, and pk be the corresponding 383 ObliviousDNSKey. 385 2. Compute Q_plain, error = decrypt_query_body(skR, Q.key_id, 386 Q.encrypted_message). 388 3. If no error was returned, and Q_plain.padding is valid (all 389 zeros), resolve Q_plain.dns_message as needed, yielding a DNS 390 message M. 392 4. Create an ObliviousDNSResponseBody structure, carrying the 393 message M and padding, to produce R_plain. 395 5. Compute akey, anonce = derive_keys(Q_plain). (See definition for 396 derive_keys below. Hash, Expand, Extract, Nn, and Nk are 397 functions and parameters bound to the target's HPKE public key.) 399 6. Compute R_encrypted = encrypt_response_body(R_plain, akey, 400 anonce). (See definition for encrypt_response_body below. The 401 key_id field used for encryption is empty, yielding 0x0000 as 402 part of the AAD.) 404 7. Output a ObliviousDNSMessage message R where R.message_type = 405 0x02, R.key_id = nil, and R.encrypted_message = R_encrypted. 407 def derive_keys(Q_plain): 408 context = Hash(Q_plain.dns_message) 409 key = Expand(Q_plain.response_seed, concat("odoh key", context), Nk) 410 nonce = Expand(Q_plain.response_seed, concat("odoh nonce", context), Nn) 411 return key, nonce 413 def decrypt_query_body(skR, key_id, Q_encrypted): 414 enc || ct = Q_encrypted 415 dec, context = SetupBaseR(skR, "odns-query") 416 aad = 0x01 || key_id 417 Q_plain, error = context.Open(aad, ct) 418 return Q_plain, error 420 def encrypt_response_body(R_plain, akey, anonce): 421 aad = 0x02 || 0x0000 // 0x0000 represents a 0-length KeyId 422 R_encrypted = Seal(akey, anonce, aad, R_plain) 423 return R_encrypted 425 The Target then sends R to the Proxy according to Section 4.3. 427 The Proxy forwards the message R without modification back to the 428 client as the HTTP response to the client's original HTTP request. 430 Once the client receives the response, it can use its known 431 response_seed to derive the decryption key and nonce, decrypt 432 R.encrypted_message using decrypt_response_body (defined below), and 433 produce R_plain. Clients MUST validate R_plain.padding (as all 434 zeros) before using R_plain.dns_message. 436 def decrypt_response_body(R_encrypted): 437 aad = 0x02 || 0x0000 438 R_plain = Open(response_key, 0^Nn, aad, R_encrypted) 439 return R_plain 441 8. Security Considerations 443 DISCLAIMER: this is a work in progress draft and has not yet seen 444 significant security analysis. 446 Oblivious DoH aims to keep knowledge of the true query origin and its 447 contents known to only clients. In particular, it assumes a Dolev- 448 Yao style attacker which can observe all client queries, including 449 those forwarded by oblivious proxies, and does not collude with 450 target resolvers. (Indeed, if a target colludes with the network 451 attacker, then said attacker can learn the true query origin and its 452 contents.) Oblivious DoH aims to achieve the following 453 confidentiality goals in the presence of this attacker: 455 1. Queries and answers are known only to clients and targets in 456 possession of the corresponding response key and HPKE keying 457 material. In particular, proxies know the origin and destination 458 of an oblivious query, yet do not know the plaintext query. 459 Likewise, targets know only the oblivious query origin, i.e., the 460 proxy, and the plaintext query. Only the client knows both the 461 plaintext query contents and destination. 463 2. Target resolvers cannot link queries from the same client in the 464 absence of unique per-client keys. 466 Traffic analysis mitigations are outside the scope of this document. 467 In particular, this document does not recommend padding lengths for 468 ObliviousDNSQueryBody and ObliviousDNSResponseBody messages. 469 Implementations SHOULD follow the guidance for choosing padding 470 length in [RFC8467]. 472 Oblivious DoH security does not depend on proxy and target 473 indistinguishability. Specifically, an on-path attacker could 474 determine whether a connection a specific endpoint is used for 475 oblivious or direct DoH queries. However, this has no effect on 476 confidentiality goals listed above. 478 8.1. Denial of Service 480 Malicious clients (or proxies) may send bogus Oblivious DoH queries 481 to targets as a Denial-of-Service (DoS) attack. Target servers may 482 throttle processing requests if such an event occurs. 484 Malicious targets or proxies may send bogus answers in response to 485 Oblivious DoH queries. Response decryption failure is a signal that 486 either the proxy or target is misbehaving. Clients can choose to 487 stop using one or both of these servers in the event of such failure. 489 9. IANA Considerations 491 9.1. Oblivious DoH Message Media Type 493 This document registers a new media type, "application/oblivious-dns- 494 message". 496 Type name: application 498 Subtype name: oblivious-dns-message 500 Required parameters: N/A 502 Optional parameters: N/A 504 Encoding considerations: This is a binary format, containing 505 encrypted DNS requests and responses, as defined in this document. 507 Security considerations: See this document. The content is an 508 encrypted DNS message, and not executable code. 510 Interoperability considerations: This document specifies format of 511 conforming messages and the interpretation thereof. 513 Published specification: This document. 515 Applications that use this media type: This media type is intended to 516 be used by clients wishing to hide their DNS queries when using DNS 517 over HTTPS. 519 Additional information: None 521 Person and email address to contact for further information: See 522 Authors' Addresses section 524 Intended usage: COMMON 525 Restrictions on usage: None 527 Author: IETF 529 Change controller: IETF 531 9.2. Oblivious DoH Public Key DNS Parameter 533 This document defines one new key to be added to the Service Binding 534 (SVCB) Parameter Registry [I-D.nygren-dnsop-svcb-httpssvc]. 536 Name: odohkey 538 SvcParamKey: TBD 540 Meaning: Public key used to encrypt messages in Oblivious DoH 542 Reference: This document. 544 10. Acknowledgments 546 This work is inspired by Oblivious DNS 547 [I-D.annee-dprive-oblivious-dns]. Thanks to all of the authors of 548 that document. Thanks to Frederic Jacobs, Elliot Briggs, Paul 549 Schmitt, Brian Swander, and Tommy Jensen for the feedback and input. 551 11. References 553 11.1. Normative References 555 [I-D.irtf-cfrg-hpke] 556 Barnes, R. and K. Bhargavan, "Hybrid Public Key 557 Encryption", draft-irtf-cfrg-hpke-00 (work in progress), 558 July 2019. 560 [I-D.nygren-dnsop-svcb-httpssvc] 561 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 562 and parameter specification via the DNS (DNS SVCB and 563 HTTPSSVC)", draft-nygren-dnsop-svcb-httpssvc-00 (work in 564 progress), September 2019. 566 [I-D.pauly-dprive-adaptive-dns-privacy] 567 Kinnear, E., Pauly, T., Wood, C., and P. McManus, 568 "Adaptive DNS: Improving Privacy of Name Resolution", 569 draft-pauly-dprive-adaptive-dns-privacy-00 (work in 570 progress), October 2019. 572 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 573 Rose, "DNS Security Introduction and Requirements", 574 RFC 4033, DOI 10.17487/RFC4033, March 2005, 575 . 577 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 578 "Randomness Requirements for Security", BCP 106, RFC 4086, 579 DOI 10.17487/RFC4086, June 2005, 580 . 582 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 583 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 584 . 586 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 587 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 588 October 2018, . 590 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 591 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 592 . 594 11.2. Informative References 596 [I-D.annee-dprive-oblivious-dns] 597 Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin, 598 "Oblivious DNS - Strong Privacy for DNS Queries", draft- 599 annee-dprive-oblivious-dns-00 (work in progress), July 600 2018. 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, 604 DOI 10.17487/RFC2119, March 1997, 605 . 607 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 608 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 609 May 2017, . 611 Authors' Addresses 613 Eric Kinnear 614 Apple Inc. 615 One Apple Park Way 616 Cupertino, California 95014 617 United States of America 619 Email: ekinnear@apple.com 620 Patrick McManus 621 Fastly 623 Email: mcmanus@ducksong.com 625 Tommy Pauly 626 Apple Inc. 627 One Apple Park Way 628 Cupertino, California 95014 629 United States of America 631 Email: tpauly@apple.com 633 Chris Wood 634 Apple Inc. 635 One Apple Park Way 636 Cupertino, California 95014 637 United States of America 639 Email: cawood@apple.com