doc: Add RFC documents

1 files changed, 961 insertions, 0 deletions

diff --git a/doc/rfc/rfc9230.txt b/doc/rfc/rfc9230.txt
new file mode 100644
index 0000000..9c4b3ac
--- /dev/null
+++ b/doc/rfc/rfc9230.txt
@@ -0,0 +1,961 @@
+
+
+
+
+Independent Submission                                        E. Kinnear
+Request for Comments: 9230                                    Apple Inc.
+Category: Experimental                                        P. McManus
+ISSN: 2070-1721                                                   Fastly
+                                                                T. Pauly
+                                                              Apple Inc.
+                                                                T. Verma
+                                                               C.A. Wood
+                                                              Cloudflare
+                                                               June 2022
+
+
+                        Oblivious DNS over HTTPS
+
+Abstract
+
+   This document describes a protocol that allows clients to hide their
+   IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS
+   (DoH) messages.  This improves privacy of DNS operations by not
+   allowing any one server entity to be aware of both the client IP
+   address and the content of DNS queries and answers.
+
+   This experimental protocol has been developed outside the IETF and is
+   published here to guide implementation, ensure interoperability among
+   implementations, and enable wide-scale experimentation.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9230.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Specification of Requirements
+   2.  Terminology
+   3.  Deployment Requirements
+   4.  HTTP Exchange
+     4.1.  HTTP Request
+     4.2.  HTTP Request Example
+     4.3.  HTTP Response
+     4.4.  HTTP Response Example
+     4.5.  HTTP Metadata
+   5.  Configuration and Public Key Format
+   6.  Protocol Encoding
+     6.1.  Message Format
+     6.2.  Encryption and Decryption Routines
+   7.  Oblivious Client Behavior
+   8.  Oblivious Target Behavior
+   9.  Compliance Requirements
+   10. Experiment Overview
+   11. Security Considerations
+     11.1.  Denial of Service
+     11.2.  Proxy Policies
+     11.3.  Authentication
+   12. IANA Considerations
+     12.1.  Oblivious DoH Message Media Type
+   13. References
+     13.1.  Normative References
+     13.2.  Informative References
+   Appendix A.  Use of Generic Proxy Services
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   DNS over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS
+   messages to be transmitted in HTTP messages protected with TLS.  This
+   provides improved confidentiality and authentication for DNS
+   interactions in various circumstances.
+
+   While DoH can prevent eavesdroppers from directly reading the
+   contents of DNS exchanges, clients cannot send DNS queries to and
+   receive answers from servers without revealing their local IP address
+   (and thus information about the identity or location of the client)
+   to the server.
+
+   Proposals such as Oblivious DNS [OBLIVIOUS-DNS] increase privacy by
+   ensuring that no single DNS server is aware of both the client IP
+   address and the message contents.
+
+   This document defines Oblivious DoH, an experimental protocol built
+   on DoH that permits proxied resolution, in which DNS messages are
+   encrypted so that no server can independently read both the client IP
+   address and the DNS message contents.
+
+   As with DoH, DNS messages exchanged over Oblivious DoH are fully
+   formed DNS messages.  Clients that want to receive answers that are
+   relevant to the network they are on without revealing their exact IP
+   address can thus use the EDNS0 Client Subnet option ([RFC7871],
+   Section 7.1.2) to provide a hint to the resolver using Oblivious DoH.
+
+   This mechanism is intended to be used as one mechanism for resolving
+   privacy-sensitive content in the broader context of DNS privacy.
+
+   This experimental protocol has been developed outside the IETF and is
+   published here to guide implementation, ensure interoperability among
+   implementations, and enable wide-scale experimentation.  See
+   Section 10 for more details about the experiment.
+
+1.1.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Terminology
+
+   This document defines the following terms:
+
+   Oblivious Client:  A client that sends DNS queries to an Oblivious
+      Target, through an Oblivious Proxy.  The Client is responsible for
+      selecting the combination of Proxy and Target to use for a given
+      query.
+
+   Oblivious Proxy:  An HTTP server that proxies encrypted DNS queries
+      and responses between an Oblivious Client and an Oblivious Target
+      and is identified by a URI Template [RFC6570] (see Section 4.1).
+      Note that this Oblivious Proxy is not acting as a full HTTP proxy
+      but is instead a specialized server used to forward Oblivious DNS
+      messages.
+
+   Oblivious Target:  An HTTP server that receives and decrypts
+      encrypted Oblivious Client DNS queries from an Oblivious Proxy and
+      returns encrypted DNS responses via that same Proxy.  In order to
+      provide DNS responses, the Target can be a DNS resolver, be co-
+      located with a resolver, or forward to a resolver.
+
+   Throughout the rest of this document, we use the terms "Client",
+   "Proxy", and "Target" to refer to an Oblivious Client, Oblivious
+   Proxy, and Oblivious Target, respectively.
+
+3.  Deployment Requirements
+
+   Oblivious DoH requires, at a minimum:
+
+   *  An Oblivious Proxy server, identified by a URI Template.
+
+   *  An Oblivious Target server.  The Target and Proxy are expected to
+      be non-colluding (see Section 11).
+
+   *  One or more Target public keys for encrypting DNS queries sent to
+      a Target via a Proxy (Section 5).  These keys guarantee that only
+      the intended Target can decrypt Client queries.
+
+   The mechanism for discovering and provisioning the Proxy URI Template
+   and Target public keys is out of scope for this document.
+
+4.  HTTP Exchange
+
+   Unlike direct resolution, oblivious hostname resolution over DoH
+   involves three parties:
+
+   1.  The Client, which generates queries.
+
+   2.  The Proxy, which receives encrypted queries from the Client and
+       passes them on to a Target.
+
+   3.  The Target, which receives proxied queries from the Client via
+       the Proxy and produces proxied answers.
+
+        --- [ Request encrypted with Target public key ] -->
+   +---------+             +-----------+             +-----------+
+   | Client  +-------------> Oblivious +-------------> Oblivious |
+   |         <-------------+   Proxy   <-------------+  Target   |
+   +---------+             +-----------+             +-----------+
+       <-- [   Response encrypted with symmetric key   ] ---
+
+                      Figure 1: Oblivious DoH Exchange
+
+4.1.  HTTP Request
+
+   Oblivious DoH queries are created by the Client and are sent to the
+   Proxy as HTTP requests using the POST method.  Clients are configured
+   with a Proxy URI Template [RFC6570] and the Target URI.  The scheme
+   for both the Proxy URI Template and the Target URI MUST be "https".
+   The Proxy URI Template uses the Level 3 encoding defined in
+   Section 1.2 of [RFC6570] and contains two variables: "targethost",
+   which indicates the hostname of the Target server; and "targetpath",
+   which indicates the path on which the Target is accessible.  Examples
+   of Proxy URI Templates are shown below:
+
+   https://dnsproxy.example/dns-query{?targethost,targetpath}
+   https://dnsproxy.example/{targethost}/{targetpath}
+
+   The URI Template MUST contain both the "targethost" and "targetpath"
+   variables exactly once and MUST NOT contain any other variables.  The
+   variables MUST be within the path or query components of the URI.
+   Clients MUST ignore configurations that do not conform to this
+   template.  See Section 4.2 for an example request.
+
+   Oblivious DoH messages have no cache value, since both requests and
+   responses are encrypted using ephemeral key material.  Requests and
+   responses MUST NOT be cached.
+
+   Clients MUST set the HTTP Content-Type header to "application/
+   oblivious-dns-message" to indicate that this request is an Oblivious
+   DoH query intended for proxying.  Clients also SHOULD set this same
+   value for the HTTP Accept header.
+
+   A correctly encoded request has the HTTP Content-Type header
+   "application/oblivious-dns-message", uses the HTTP POST method, and
+   contains "targethost" and "targetpath" variables.  If the Proxy fails
+   to match the "targethost" and "targetpath" variables from the path,
+   it MUST treat the request as malformed.  The Proxy constructs the URI
+   of the Target with the "https" scheme, using the value of
+   "targethost" as the URI host and the percent-decoded value of
+   "targetpath" as the URI path.  Proxies MUST check that Client
+   requests are correctly encoded and MUST return a 4xx (Client Error)
+   if the check fails, along with the Proxy-Status response header with
+   an "error" parameter of type "http_request_error" [RFC9209].
+
+   Proxies MAY choose to not forward connections to non-standard ports.
+   In such cases, Proxies can indicate the error with a 403 response
+   status code, along with a Proxy-Status response header with an
+   "error" parameter of type "http_request_denied" and with an
+   appropriate explanation in "details".
+
+   If the Proxy cannot establish a connection to the Target, it can
+   indicate the error with a 502 response status code, along with a
+   Proxy-Status response header with an "error" parameter whose type
+   indicates the reason.  For example, if DNS resolution fails, the
+   error type might be "dns_timeout", whereas if the TLS connection
+   fails, the error type might be "tls_protocol_error".
+
+   Upon receipt of requests from a Proxy, Targets MUST validate that the
+   request has the HTTP Content-Type header "application/oblivious-dns-
+   message" and uses the HTTP POST method.  Targets can respond with a
+   4xx response status code if this check fails.
+
+4.2.  HTTP Request Example
+
+   The following example shows how a Client requests that a Proxy,
+   "dnsproxy.example", forward an encrypted message to
+   "dnstarget.example".  The URI Template for the Proxy is
+   "https://dnsproxy.example/dns-query{?targethost,targetpath}".  The
+   URI for the Target is "https://dnstarget.example/dns-query".
+
+   :method = POST
+   :scheme = https
+   :authority = dnsproxy.example
+   :path = /dns-query?targethost=dnstarget.example&targetpath=/dns-query
+   accept = application/oblivious-dns-message
+   content-type = application/oblivious-dns-message
+   content-length = 106
+
+   <Bytes containing an encrypted Oblivious DNS query>
+
+   The Proxy then sends the following request on to the Target:
+
+   :method = POST
+   :scheme = https
+   :authority = dnstarget.example
+   :path = /dns-query
+   accept = application/oblivious-dns-message
+   content-type = application/oblivious-dns-message
+   content-length = 106
+
+   <Bytes containing an encrypted Oblivious DNS query>
+
+4.3.  HTTP Response
+
+   The response to an Oblivious DoH query is generated by the Target.
+   It MUST set the Content-Type HTTP header to "application/oblivious-
+   dns-message" for all successful responses.  The body of the response
+   contains an encrypted DNS message; see Section 6.
+
+   The response from a Target MUST set the Content-Type HTTP header to
+   "application/oblivious-dns-message", and that same type MUST be used
+   on all successful responses sent by the Proxy to the Client.  A
+   Client MUST only consider a response that contains the Content-Type
+   header before processing the payload.  A response without the
+   appropriate header MUST be treated as an error and be handled
+   appropriately.  All other aspects of the HTTP response and error
+   handling are inherited from standard DoH.
+
+   Proxies forward responses from the Target to the Client, without any
+   modifications to the body or status code.  The Proxy also SHOULD add
+   a Proxy-Status response header with a "received-status" parameter
+   indicating that the status code was generated by the Target.
+
+   Note that if a Client receives a 3xx status code and chooses to
+   follow a redirect, the subsequent request MUST also be performed
+   through a Proxy in order to avoid directly exposing requests to the
+   Target.
+
+   Requests that cannot be processed by the Target result in 4xx (Client
+   Error) responses.  If the Target and Client keys do not match, it is
+   an authorization failure (HTTP status code 401; see Section 15.5.2 of
+   [HTTP]).  Otherwise, if the Client's request is invalid, such as in
+   the case of decryption failure, wrong message type, or
+   deserialization failure, this is a bad request (HTTP status code 400;
+   see Section 15.5.1 of [HTTP]).
+
+   Even in the case of DNS responses indicating failure, such as
+   SERVFAIL or NXDOMAIN, a successful HTTP response with a 2xx status
+   code is used as long as the DNS response is valid.  This is identical
+   to how DoH [RFC8484] handles HTTP response codes.
+
+4.4.  HTTP Response Example
+
+   The following example shows a 2xx (Successful) response that can be
+   sent from a Target to a Client via a Proxy.
+
+   :status = 200
+   content-type = application/oblivious-dns-message
+   content-length = 154
+
+   <Bytes containing an encrypted Oblivious DNS response>
+
+4.5.  HTTP Metadata
+
+   Proxies forward requests and responses between Clients and Targets as
+   specified in Section 4.1.  Metadata sent with these messages could
+   inadvertently weaken or remove Oblivious DoH privacy properties.
+   Proxies MUST NOT send any Client-identifying information about
+   Clients to Targets, such as "Forwarded" HTTP headers [RFC7239].
+   Additionally, Clients MUST NOT include any private state in requests
+   to Proxies, such as HTTP cookies.  See Section 11.3 for related
+   discussion about Client authentication information.
+
+5.  Configuration and Public Key Format
+
+   In order to send a message to a Target, the Client needs to know a
+   public key to use for encrypting its queries.  The mechanism for
+   discovering this configuration is out of scope for this document.
+
+   Servers ought to rotate public keys regularly.  It is RECOMMENDED
+   that servers rotate keys every day.  Shorter rotation windows reduce
+   the anonymity set of Clients that might use the public key, whereas
+   longer rotation windows widen the time frame of possible compromise.
+
+   An Oblivious DNS public key configuration is a structure encoded,
+   using TLS-style encoding [RFC8446], as follows:
+
+   struct {
+      uint16 kem_id;
+      uint16 kdf_id;
+      uint16 aead_id;
+      opaque public_key<1..2^16-1>;
+   } ObliviousDoHConfigContents;
+
+   struct {
+      uint16 version;
+      uint16 length;
+      select (ObliviousDoHConfig.version) {
+         case 0x0001: ObliviousDoHConfigContents contents;
+      }
+   } ObliviousDoHConfig;
+
+   ObliviousDoHConfig ObliviousDoHConfigs<1..2^16-1>;
+
+   The ObliviousDoHConfigs structure contains one or more
+   ObliviousDoHConfig structures in decreasing order of preference.
+   This allows a server to support multiple versions of Oblivious DoH
+   and multiple sets of Oblivious DoH parameters.
+
+   An ObliviousDoHConfig structure contains a versioned representation
+   of an Oblivious DoH configuration, with the following fields.
+
+   version:  The version of Oblivious DoH for which this configuration
+      is used.  Clients MUST ignore any ObliviousDoHConfig structure
+      with a version they do not support.  The version of Oblivious DoH
+      specified in this document is 0x0001.
+
+   length:  The length, in bytes, of the next field.
+
+   contents:  An opaque byte string whose contents depend on the
+      version.  For this specification, the contents are an
+      ObliviousDoHConfigContents structure.
+
+   An ObliviousDoHConfigContents structure contains the information
+   needed to encrypt a message under
+   ObliviousDoHConfigContents.public_key such that only the owner of the
+   corresponding private key can decrypt the message.  The values for
+   ObliviousDoHConfigContents.kem_id, ObliviousDoHConfigContents.kdf_id,
+   and ObliviousDoHConfigContents.aead_id are described in Section 7 of
+   [HPKE].  The fields in this structure are as follows:
+
+   kem_id:  The hybrid public key encryption (HPKE) key encapsulation
+      mechanism (KEM) identifier corresponding to public_key.  Clients
+      MUST ignore any ObliviousDoHConfig structure with a key using a
+      KEM they do not support.
+
+   kdf_id:  The HPKE key derivation function (KDF) identifier
+      corresponding to public_key.  Clients MUST ignore any
+      ObliviousDoHConfig structure with a key using a KDF they do not
+      support.
+
+   aead_id:  The HPKE authenticated encryption with associated data
+      (AEAD) identifier corresponding to public_key.  Clients MUST
+      ignore any ObliviousDoHConfig structure with a key using an AEAD
+      they do not support.
+
+   public_key:  The HPKE public key used by the Client to encrypt
+      Oblivious DoH queries.
+
+6.  Protocol Encoding
+
+   This section includes encoding and wire format details for Oblivious
+   DoH, as well as routines for encrypting and decrypting encoded
+   values.
+
+6.1.  Message Format
+
+   There are two types of Oblivious DoH messages: Queries (0x01) and
+   Responses (0x02).  Both messages carry the following information:
+
+   1.  A DNS message, which is either a Query or Response, depending on
+       context.
+
+   2.  Padding of arbitrary length, which MUST contain all zeros.
+
+   They are encoded using the following structure:
+
+   struct {
+      opaque dns_message<1..2^16-1>;
+      opaque padding<0..2^16-1>;
+   } ObliviousDoHMessagePlaintext;
+
+   Both Query and Response messages use the ObliviousDoHMessagePlaintext
+   format.
+
+   ObliviousDoHMessagePlaintext ObliviousDoHQuery;
+   ObliviousDoHMessagePlaintext ObliviousDoHResponse;
+
+   An encrypted ObliviousDoHMessagePlaintext parameter is carried in an
+   ObliviousDoHMessage message, encoded as follows:
+
+   struct {
+      uint8  message_type;
+      opaque key_id<0..2^16-1>;
+      opaque encrypted_message<1..2^16-1>;
+   } ObliviousDoHMessage;
+
+   The ObliviousDoHMessage structure contains the following fields:
+
+   message_type:  A one-byte identifier for the type of message.  Query
+      messages use message_type 0x01, and Response messages use
+      message_type 0x02.
+
+   key_id:  The identifier of the corresponding
+      ObliviousDoHConfigContents key.  This is computed as
+      Expand(Extract("", config), "odoh key id", Nh), where config is
+      the ObliviousDoHConfigContents structure and Extract, Expand, and
+      Nh are as specified by the HPKE cipher suite KDF corresponding to
+      config.kdf_id.
+
+   encrypted_message:  An encrypted message for the Oblivious Target
+      (for Query messages) or Client (for Response messages).
+      Implementations MAY enforce limits on the size of this field,
+      depending on the size of plaintext DNS messages.  (DNS queries,
+      for example, will not reach the size limit of 2^16-1 in practice.)
+
+   The contents of ObliviousDoHMessage.encrypted_message depend on
+   ObliviousDoHMessage.message_type.  In particular,
+   ObliviousDoHMessage.encrypted_message is an encryption of an
+   ObliviousDoHQuery message if the message is a Query and an encryption
+   of ObliviousDoHResponse if the message is a Response.
+
+6.2.  Encryption and Decryption Routines
+
+   Clients use the following utility functions for encrypting a Query
+   and decrypting a Response as described in Section 7.
+
+   *  encrypt_query_body: Encrypt an Oblivious DoH query.
+
+   def encrypt_query_body(pkR, key_id, Q_plain):
+     enc, context = SetupBaseS(pkR, "odoh query")
+     aad = 0x01 || len(key_id) || key_id
+     ct = context.Seal(aad, Q_plain)
+     Q_encrypted = enc || ct
+     return Q_encrypted
+
+   *  decrypt_response_body: Decrypt an Oblivious DoH response.
+
+   def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce):
+     aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce)
+     aad = 0x02 || len(resp_nonce) || resp_nonce
+     R_plain, error = Open(key, nonce, aad, R_encrypted)
+     return R_plain, error
+
+   The derive_secrets function is described below.
+
+   Targets use the following utility functions in processing queries and
+   producing responses as described in Section 8.
+
+   *  setup_query_context: Set up an HPKE context used for decrypting an
+      Oblivious DoH query.
+
+   def setup_query_context(skR, key_id, Q_encrypted):
+     enc || ct = Q_encrypted
+     context = SetupBaseR(enc, skR, "odoh query")
+     return context
+
+   *  decrypt_query_body: Decrypt an Oblivious DoH query.
+
+   def decrypt_query_body(context, key_id, Q_encrypted):
+     aad = 0x01 || len(key_id) || key_id
+     enc || ct = Q_encrypted
+     Q_plain, error = context.Open(aad, ct)
+     return Q_plain, error
+
+   *  derive_secrets: Derive keying material used for encrypting an
+      Oblivious DoH response.
+
+   def derive_secrets(context, Q_plain, resp_nonce):
+     secret = context.Export("odoh response", Nk)
+     salt = Q_plain || len(resp_nonce) || resp_nonce
+     prk = Extract(salt, secret)
+     key = Expand(odoh_prk, "odoh key", Nk)
+     nonce = Expand(odoh_prk, "odoh nonce", Nn)
+     return key, nonce
+
+   The random(N) function returns N cryptographically secure random
+   bytes from a good source of entropy [RFC4086].  The max(A, B)
+   function returns A if A > B, and B otherwise.
+
+   *  encrypt_response_body: Encrypt an Oblivious DoH response.
+
+   def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce):
+     aad = 0x02 || len(resp_nonce) || resp_nonce
+     R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain)
+     return R_encrypted
+
+7.  Oblivious Client Behavior
+
+   Let M be a DNS message (query) a Client wishes to protect with
+   Oblivious DoH.  When sending an Oblivious DoH Query for resolving M
+   to an Oblivious Target with ObliviousDoHConfigContents config, a
+   Client does the following:
+
+   1.  Creates an ObliviousDoHQuery structure, carrying the message M
+       and padding, to produce Q_plain.
+
+   2.  Deserializes config.public_key to produce a public key pkR of
+       type config.kem_id.
+
+   3.  Computes the encrypted message as Q_encrypted =
+       encrypt_query_body(pkR, key_id, Q_plain), where key_id is as
+       computed in Section 6.  Note also that len(key_id) outputs the
+       length of key_id as a two-byte unsigned integer.
+
+   4.  Outputs an ObliviousDoHMessage message Q, where Q.message_type =
+       0x01, Q.key_id carries key_id, and Q.encrypted_message =
+       Q_encrypted.
+
+   The Client then sends Q to the Proxy according to Section 4.1.  Once
+   the Client receives a response R, encrypted as specified in
+   Section 8, it uses decrypt_response_body to decrypt
+   R.encrypted_message (using R.key_id as a nonce) and produce R_plain.
+   Clients MUST validate R_plain.padding (as all zeros) before using
+   R_plain.dns_message.
+
+8.  Oblivious Target Behavior
+
+   Targets that receive a Query message Q decrypt and process it as
+   follows:
+
+   1.  Look up the ObliviousDoHConfigContents information according to
+       Q.key_id.  If no such key exists, the Target MAY discard the
+       query, and if so, it MUST return a 401 (Unauthorized) response to
+       the Proxy.  Otherwise, let skR be the private key corresponding
+       to this public key, or one chosen for trial decryption.
+
+   2.  Compute context = setup_query_context(skR, Q.key_id,
+       Q.encrypted_message).
+
+   3.  Compute Q_plain, error = decrypt_query_body(context, Q.key_id,
+       Q.encrypted_message).
+
+   4.  If no error was returned and Q_plain.padding is valid (all
+       zeros), resolve Q_plain.dns_message as needed, yielding a DNS
+       message M.  Otherwise, if an error was returned or the padding
+       was invalid, return a 400 (Client Error) response to the Proxy.
+
+   5.  Create an ObliviousDoHResponseBody structure, carrying the
+       message M and padding, to produce R_plain.
+
+   6.  Create a fresh nonce resp_nonce = random(max(Nn, Nk)).
+
+   7.  Compute aead_key, aead_nonce = derive_secrets(context, Q_plain,
+       resp_nonce).
+
+   8.  Compute R_encrypted = encrypt_response_body(R_plain, aead_key,
+       aead_nonce, resp_nonce).  The key_id field used for encryption
+       carries resp_nonce in order for Clients to derive the same
+       secrets.  Also, the Seal function is the function that is
+       associated with the HPKE AEAD.
+
+   9.  Output an ObliviousDoHMessage message R, where R.message_type =
+       0x02, R.key_id = resp_nonce, and R.encrypted_message =
+       R_encrypted.
+
+   The Target then sends R in a 2xx (Successful) response to the Proxy;
+   see Section 4.3.  The Proxy forwards the message R without
+   modification back to the Client as the HTTP response to the Client's
+   original HTTP request.  In the event of an error (non-2xx status
+   code), the Proxy forwards the Target error to the Client; see
+   Section 4.3.
+
+9.  Compliance Requirements
+
+   Oblivious DoH uses HPKE for public key encryption [HPKE].  In the
+   absence of an application profile standard specifying otherwise, a
+   compliant Oblivious DoH implementation MUST support the following
+   HPKE cipher suite:
+
+   KEM:  DHKEM(X25519, HKDF-SHA256) (see [HPKE], Section 7.1)
+
+   KDF:  HKDF-SHA256 (see [HPKE], Section 7.2)
+
+   AEAD:  AES-128-GCM (see [HPKE], Section 7.3)
+
+10.  Experiment Overview
+
+   This document describes an experimental protocol built on DoH.  The
+   purpose of this experiment is to assess deployment configuration
+   viability and related performance impacts on DNS resolution by
+   measuring key performance indicators such as resolution latency.
+   Experiment participants will test various parameters affecting
+   service operation and performance, including mechanisms for discovery
+   and configuration of DoH Proxies and Targets, as well as performance
+   implications of connection reuse and pools where appropriate.  The
+   results of this experiment will be used to influence future protocol
+   design and deployment efforts related to Oblivious DoH, such as
+   Oblivious HTTP [OHTP].  Implementations of DoH that are not involved
+   in the experiment will not recognize this protocol and will not
+   participate in the experiment.  It is anticipated that the use of
+   Oblivious DoH will be widespread and that this experiment will be of
+   long duration.
+
+11.  Security Considerations
+
+   Oblivious DoH aims to keep knowledge of the true query origin and its
+   contents known only to Clients.  As a simplified model, consider a
+   case where there exist two Clients C1 and C2, one Proxy P, and one
+   Target T.  Oblivious DoH assumes an extended Dolev-Yao style attacker
+   [Dolev-Yao] that can observe all network activity and can adaptively
+   compromise either P or T, but not C1 or C2.  Note that compromising
+   both P and T is equivalent to collusion between these two parties in
+   practice.  Once compromised, the attacker has access to all session
+   information and private key material.  (This generalizes to
+   arbitrarily many Clients, Proxies, and Targets, with the constraints
+   that (1) not all Targets and Proxies are simultaneously compromised
+   and (2) at least two Clients are left uncompromised.)  The attacker
+   is prohibited from sending Client-identifying information, such as IP
+   addresses, to Targets.  (This would allow the attacker to trivially
+   link a query to the corresponding Client.)
+
+   In this model, both C1 and C2 send Oblivious DoH queries Q1 and Q2,
+   respectively, through P to T, and T provides answers A1 and A2.  The
+   attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2),
+   respectively.  The attacker succeeds if this linkability is possible
+   without any additional interaction.  (For example, if T is
+   compromised, it could return a DNS answer corresponding to an entity
+   it controls and then observe the subsequent connection from a Client,
+   learning its identity in the process.  Such attacks are out of scope
+   for this model.)
+
+   Oblivious DoH security prevents such linkability.  Informally, this
+   means:
+
+   1.  Queries and answers are known only to Clients and Targets in
+       possession of the corresponding response key and HPKE keying
+       material.  In particular, Proxies know the origin and destination
+       of an oblivious query, yet do not know the plaintext query.
+       Likewise, Targets know only the oblivious query origin, i.e., the
+       Proxy, and the plaintext query.  Only the Client knows both the
+       plaintext query contents and destination.
+
+   2.  Target resolvers cannot link queries from the same Client in the
+       absence of unique per-Client keys.
+
+   Traffic analysis mitigations are outside the scope of this document.
+   In particular, this document does not prescribe padding lengths for
+   ObliviousDoHQuery and ObliviousDoHResponse messages.  Implementations
+   SHOULD follow the guidance in [RFC8467] for choosing padding length.
+
+   Oblivious DoH security does not depend on Proxy and Target
+   indistinguishability.  Specifically, an on-path attacker could
+   determine whether a connection to a specific endpoint is used for
+   oblivious or direct DoH queries.  However, this has no effect on the
+   confidentiality goals listed above.
+
+11.1.  Denial of Service
+
+   Malicious Clients (or Proxies) can send bogus Oblivious DoH queries
+   to Targets as a Denial-of-Service (DoS) attack.  Target servers can
+   throttle processing requests if such an event occurs.  Additionally,
+   since Targets provide explicit errors upon decryption failure, i.e.,
+   if ciphertext decryption fails or if the plaintext DNS message is
+   malformed, Proxies can throttle specific Clients in response to these
+   errors.  In general, however, Targets trust Proxies to not overwhelm
+   the Target, and it is expected that Proxies implement either some
+   form of rate limiting or client authentication to limit abuse; see
+   Section 11.3.
+
+   Malicious Targets or Proxies can send bogus answers in response to
+   Oblivious DoH queries.  Response decryption failure is a signal that
+   either the Proxy or Target is misbehaving.  Clients can choose to
+   stop using one or both of these servers in the event of such failure.
+   However, as noted above, malicious Targets and Proxies are out of
+   scope for the threat model.
+
+11.2.  Proxy Policies
+
+   Proxies are free to enforce any forwarding policy they desire for
+   Clients.  For example, they can choose to only forward requests to
+   known or otherwise trusted Targets.
+
+   Proxies that do not reuse connections to Targets for many Clients may
+   allow Targets to link individual queries to unknown Targets.  To
+   mitigate this linkability vector, it is RECOMMENDED that Proxies pool
+   and reuse connections to Targets.  Note that this benefits
+   performance as well as privacy, since queries do not incur any delay
+   that might otherwise result from Proxy-to-Target connection
+   establishment.
+
+11.3.  Authentication
+
+   Depending on the deployment scenario, Proxies and Targets might
+   require authentication before use.  Regardless of the authentication
+   mechanism in place, Proxies MUST NOT reveal any Client authentication
+   information to Targets.  This is required so Targets cannot uniquely
+   identify individual Clients.
+
+   Note that if Targets require Proxies to authenticate at the HTTP or
+   application layer before use, this ought to be done before attempting
+   to forward any Client query to the Target.  This will allow Proxies
+   to distinguish 401 (Unauthorized) response codes due to
+   authentication failure from 401 response codes due to Client key
+   mismatch; see Section 4.3.
+
+12.  IANA Considerations
+
+   This document makes changes to the "Media Types" registry.  The
+   changes are described in the following subsection.
+
+12.1.  Oblivious DoH Message Media Type
+
+   This document registers a new media type, "application/oblivious-dns-
+   message".
+
+   Type name:  application
+
+   Subtype name:  oblivious-dns-message
+
+   Required parameters:  N/A
+
+   Optional parameters:  N/A
+
+   Encoding considerations:  This is a binary format, containing
+      encrypted DNS requests and responses encoded as
+      ObliviousDoHMessage values, as defined in Section 6.1.
+
+   Security considerations:  See this document.  The content is an
+      encrypted DNS message, and not executable code.
+
+   Interoperability considerations:  This document specifies the format
+      of conforming messages and the interpretation thereof; see
+      Section 6.1.
+
+   Published specification:  This document
+
+   Applications that use this media type:  This media type is intended
+      to be used by Clients wishing to hide their DNS queries when using
+      DNS over HTTPS.
+
+   Additional information:  N/A
+
+   Person and email address to contact for further information:  See the
+      Authors' Addresses section.
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  N/A
+
+   Author:  Tommy Pauly (tpauly@apple.com)
+
+   Change controller:  IETF
+
+   Provisional registration? (standards tree only):  No
+
+13.  References
+
+13.1.  Normative References
+
+   [HPKE]     Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
+              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
+              February 2022, <https://www.rfc-editor.org/info/rfc9180>.
+
+   [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Semantics", STD 97, RFC 9110,
+              DOI 10.17487/RFC9110, June 2022,
+              <https://www.rfc-editor.org/info/rfc9110>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <https://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
+              and D. Orchard, "URI Template", RFC 6570,
+              DOI 10.17487/RFC6570, March 2012,
+              <https://www.rfc-editor.org/info/rfc6570>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8467]  Mayrhofer, A., "Padding Policies for Extension Mechanisms
+              for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
+              October 2018, <https://www.rfc-editor.org/info/rfc8467>.
+
+   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
+              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
+              <https://www.rfc-editor.org/info/rfc8484>.
+
+   [RFC9209]  Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
+              Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
+              June 2022, <https://www.rfc-editor.org/info/rfc9209>.
+
+13.2.  Informative References
+
+   [Dolev-Yao]
+              Dolev, D. and A. C. Yao, "On the Security of Public Key
+              Protocols", IEEE Transactions on Information Theory, Vol.
+              IT-29, No. 2, DOI 10.1109/TIT.1983.1056650, March 1983,
+              <https://www.cs.huji.ac.il/~dolev/pubs/dolev-yao-ieee-
+              01056650.pdf>.
+
+   [OBLIVIOUS-DNS]
+              Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin,
+              "Oblivious DNS - Strong Privacy for DNS Queries", Work in
+              Progress, Internet-Draft, draft-annee-dprive-oblivious-
+              dns-00, 2 July 2018,
+              <https://datatracker.ietf.org/doc/html/draft-annee-dprive-
+              oblivious-dns-00>.
+
+   [OHTP]     Thomson, M. and C.A. Wood, "Oblivious HTTP", Work in
+              Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15
+              February 2022, <https://datatracker.ietf.org/doc/html/
+              draft-ietf-ohai-ohttp-01>.
+
+   [RFC7239]  Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
+              RFC 7239, DOI 10.17487/RFC7239, June 2014,
+              <https://www.rfc-editor.org/info/rfc7239>.
+
+   [RFC7871]  Contavalli, C., van der Gaast, W., Lawrence, D., and W.
+              Kumari, "Client Subnet in DNS Queries", RFC 7871,
+              DOI 10.17487/RFC7871, May 2016,
+              <https://www.rfc-editor.org/info/rfc7871>.
+
+Appendix A.  Use of Generic Proxy Services
+
+   Using DoH over anonymizing proxy services such as Tor can also
+   achieve the desired goal of separating query origins from their
+   contents.  However, there are several reasons why such systems are
+   undesirable as contrasted with Oblivious DoH:
+
+   1.  Tor is meant to be a generic connection-level anonymity system,
+       and it incurs higher latency costs and protocol complexity for
+       the purpose of proxying individual DNS queries.  In contrast,
+       Oblivious DoH is a lightweight protocol built on DoH, implemented
+       as an application-layer proxy, that can be enabled as a default
+       mode for users that need increased privacy.
+
+   2.  As a one-hop proxy, Oblivious DoH encourages connectionless
+       proxies to mitigate Client query correlation with few round
+       trips.  In contrast, multi-hop systems such as Tor often run
+       secure connections (TLS) end to end, which means that DoH servers
+       could track queries over the same connection.  Using a fresh DoH
+       connection per query would incur a non-negligible penalty in
+       connection setup time.
+
+Acknowledgments
+
+   This work is inspired by Oblivious DNS [OBLIVIOUS-DNS].  Thanks to
+   all of the authors of that document.  Thanks to Nafeez Ahamed, Elliot
+   Briggs, Marwan Fayed, Jonathan Hoyland, Frederic Jacobs, Tommy
+   Jensen, Erik Nygren, Paul Schmitt, Brian Swander, and Peter Wu for
+   their feedback and input.
+
+Authors' Addresses
+
+   Eric Kinnear
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, California 95014
+   United States of America
+   Email: ekinnear@apple.com
+
+
+   Patrick McManus
+   Fastly
+   Email: mcmanus@ducksong.com
+
+
+   Tommy Pauly
+   Apple Inc.
+   One Apple Park Way
+   Cupertino, California 95014
+   United States of America
+   Email: tpauly@apple.com
+
+
+   Tanya Verma
+   Cloudflare
+   101 Townsend St
+   San Francisco, California 94107
+   United States of America
+   Email: vermatanyax@gmail.com
+
+
+   Christopher A. Wood
+   Cloudflare
+   101 Townsend St
+   San Francisco, California 94107
+   United States of America
+   Email: caw@heapingbits.net