Oblivious DNS Over HTTPS
draft-pauly-dprive-oblivious-doh-07

Network Working Group                                         E. Kinnear
Internet-Draft                                                Apple Inc.
Intended status: Experimental                                 P. McManus
Expires: 6 March 2022                                             Fastly
                                                                T. Pauly
                                                              Apple Inc.
                                                                T. Verma
                                                               C.A. Wood
                                                              Cloudflare
                                                        2 September 2021

                        Oblivious DNS Over HTTPS
                  draft-pauly-dprive-oblivious-doh-07

Abstract

   This document describes an extension to DNS Over HTTPS (DoH) that
   allows hiding client IP addresses via proxying encrypted DNS
   transactions.  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 extension is 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 6 March 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Kinnear, et al.           Expires 6 March 2022                  [Page 1]
Internet-Draft                Oblivious DoH               September 2021

   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.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Specification of Requirements . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deployment Requirements . . . . . . . . . . . . . . . . . . .   4
   4.  HTTP Exchange . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  HTTP Request  . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  HTTP Request Example  . . . . . . . . . . . . . . . . . .   6
     4.3.  HTTP Response . . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  HTTP Response Example . . . . . . . . . . . . . . . . . .   7
     4.5.  HTTP Metadata . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Configuration and Public Key Format . . . . . . . . . . . . .   8
   6.  Protocol Encoding . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Message Format  . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Encryption and Decryption Routines  . . . . . . . . . . .  11
   7.  Oblivious Client Behavior . . . . . . . . . . . . . . . . . .  12
   8.  Oblivious Target Behavior . . . . . . . . . . . . . . . . . .  13
   9.  Compliance Requirements . . . . . . . . . . . . . . . . . . .  14
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
     10.1.  Denial of Service  . . . . . . . . . . . . . . . . . . .  15
     10.2.  Proxy Policies . . . . . . . . . . . . . . . . . . . . .  15
     10.3.  Authentication . . . . . . . . . . . . . . . . . . . . .  16
     10.4.  General Proxy Services . . . . . . . . . . . . . . . . .  16
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  Oblivious DoH Message Media Type . . . . . . . . . . . .  16
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     13.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   DNS Over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS
   messages to be transmitted in encrypted HTTP messages.  This provides
   improved confidentiality and authentication for DNS interactions in
   various circumstances.

Kinnear, et al.           Expires 6 March 2022                  [Page 2]
Internet-Draft                Oblivious DoH               September 2021

   While DoH can prevent eavesdroppers from directly reading the
   contents of DNS exchanges, clients cannot send DNS queries and
   receive answers from servers without revealing their local IP
   address, and thus information about the identity or location of the
   client.

   Proposals such as Oblivious DNS ([I-D.annee-dprive-oblivious-dns])
   increase privacy by ensuring no single DNS server is aware of both
   the client IP address and the message contents.

   This document defines Oblivious DoH, an experimental extension to DoH
   that permits proxied resolution, in which DNS messages are encrypted
   so that no DoH server can independently read both the client IP
   address and the DNS message contents.

   This mechanism is intended to be used as one mechanism for resolving
   privacy-sensitive content in the broader context of DNS privacy.

   This experimental extension is developed outside the IETF and is
   published here to guide implementation, ensure interoperability among
   implementations, and enable wide-scale experimentation.

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 Server:  A DoH server that acts as either an Oblivious
      Proxy or Oblivious Target.

   Oblivious Proxy:  An Oblivious Server that proxies encrypted DNS
      queries and responses between a client and an Oblivious Target.

   Oblivious Target:  An Oblivious Server that receives and decrypts
      encrypted 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.

Kinnear, et al.           Expires 6 March 2022                  [Page 3]
Internet-Draft                Oblivious DoH               September 2021

   Throughout the rest of this document, we use the terms Proxy and
   Target to refer to an Oblivious Proxy and Oblivious Target,
   respectively.

3.  Deployment Requirements

   Oblivious DoH requires, at a minimum:

   *  Two Oblivious Servers, where one can act as a Proxy, and the other
      can act as a Target.

   *  Public keys for encrypting DNS queries that are passed from a
      client through a Proxy to a Target (Section 5).  These keys
      guarantee that only the intended Target can decrypt client
      queries.

   The mechanism for discovering and provisioning the DoH URI Templates
   and public keys is out of scope of 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: Obvlivious DoH Exchange

Kinnear, et al.           Expires 6 March 2022                  [Page 4]
Internet-Draft                Oblivious DoH               September 2021

4.1.  HTTP Request

   Oblivious DoH queries are created by the Client, and sent to the
   Proxy as an HTTP request using the POST method.  Requests to the
   Proxy indicate which DoH server to use as a Target by specifying two
   variables: "targethost", which indicates the host name of the Target
   server, and "targetpath", which indicates the path on which the
   Target's DoH server is running.  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.  Clients SHOULD
   indicate this using the "Cache-Control" header with "no-cache" and
   "no-store" specified [RFC7234].

   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.

   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" [I-D.ietf-httpbis-proxy-status].  A correctly
   encoded request has the HTTP Content-Type header "application/
   oblivious-dns-message", and HTTP method POST.  If the proxy does not
   operate as a target, then the request must additionally contain
   "targethost" and "targetpath" variables.

   Upon receiving a request that contains a "application/oblivious-dns-
   message" Content-Type, the DoH server looks for the "targethost" and
   "targetpath" variables.  If the variables are not present, then it is
   the target of the query, and it can decrypt the query (Section 6).
   If the variables are present, then the DoH server is acting as a
   Proxy.  If it is a proxy, it is expected to send the request on to
   the Target using the URI template constructed as "https://targethost/
   targetpath".

   Note that "targethost" MAY contain a port.  Proxies MAY choose to not
   forward connections to non-standard ports.  In such cases, proxies
   MUST return a 4xx (Client Error) response to the client request,
   along with Proxy-Status response header with an "error" parameter of
   type "http_request_error".

   If the proxy cannot establish a connection to "targethost", it MUST
   return a 502 (Bad Gateway) response to the client request, along with
   Proxy-Status response header with an "error" parameter whose type
   indicates the reason.  For example, if DNS resolution fails, the

Kinnear, et al.           Expires 6 March 2022                  [Page 5]
Internet-Draft                Oblivious DoH               September 2021

   error type might be "dns_timeout", whereas if the TLS connection
   failed the error type might be "tls_protocol_error".  Proxies SHOULD
   choose an error type that best captures the connection failure.

4.2.  HTTP Request Example

   The following example shows how a client requests that a Proxy,
   "dnsproxy.example.net", forwards an encrypted message to
   "dnstarget.example.net".  The URI template for the Proxy is
   "https://dnsproxy.example.net/dns-query{?targethost,targetpath}".
   The URI template for the Target is "https://dnstarget.example.net/
   dns-query".

:method = POST
:scheme = https
:authority = dnsproxy.example.net
:path = /dns-query?targethost=dnstarget.example.net&targetpath=/dns-query
accept = application/oblivious-dns-message
cache-control = no-cache, no-store
content-type = application/oblivious-dns-message
content-length = 106

<Bytes containing the encrypted payload for an Oblivious DNS query>

   The Proxy then sends the following request on to the Target:

   :method = POST
   :scheme = https
   :authority = dnstarget.example.net
   :path = /dns-query
   accept = application/oblivious-dns-message
   cache-control = no-cache, no-store
   content-type = application/oblivious-dns-message
   content-length = 106

   <Bytes containing the encrypted payload for an 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" which MUST be forwarded by the
   Proxy to the Client.  A Client MUST only consider a response which
   contains the Content-Type header in the response before processing

Kinnear, et al.           Expires 6 March 2022                  [Page 6]
Internet-Draft                Oblivious DoH               September 2021

   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 MUST forward any Target responses with 2xx, 4xx, or 5xx
   response codes unmodified to the client.  Target responses with 1xx
   response codes MUST NOT be forwarded to the client.  If a proxy
   receives a successful response from a target without the
   "application/oblivious-dns-message" HTTP Content-Type header, it MUST
   return a 502 (Bad Gateway) response to the client request, along with
   Proxy-Status response header with an "error" parameter of type
   "http_protocol_error".

   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 3.1 of
   [RFC7235]).  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 6.5.1 of [RFC7231]).

   Even in 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 similar to how DoH
   [RFC8484] handles HTTP response codes.

   In case of server error, the usual HTTP status code 500 (see
   Section 6.6.1 of [RFC7231]) applies.

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 the encrypted payload for an Oblivious DNS response>

Kinnear, et al.           Expires 6 March 2022                  [Page 7]
Internet-Draft                Oblivious DoH               September 2021

4.5.  HTTP Metadata

   Proxies forward requests and responses between clients and targets as
   specified in Section 4.1.  Metadata sent with these messages may
   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 10.3 for related
   discussion about client authentication information.

5.  Configuration and Public Key Format

   In order to use a DoH server as a Target, the client must know a
   public key to use for encrypting its queries.  The mechanism for
   discovering this configuration is out of scope of this document.

   Servers SHOULD 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 timeframe 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.

Kinnear, et al.           Expires 6 March 2022                  [Page 8]
Internet-Draft                Oblivious DoH               September 2021

   An "ObliviousDoHConfig" 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" 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
   [I-D.irtf-cfrg-hpke] Section 7.  The fields in this structure are as
   follows:

   kem_id  The HPKE 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 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 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

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.

Kinnear, et al.           Expires 6 March 2022                  [Page 9]
Internet-Draft                Oblivious DoH               September 2021

   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" is carried in a
   "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 a
   "ObliviousDoHQuery" if the message is a Query, and
   "ObliviousDoHResponse" if the message is a Response.

Kinnear, et al.           Expires 6 March 2022                 [Page 10]
Internet-Draft                Oblivious DoH               September 2021

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, response_nonce):
  aead_key, aead_nonce = derive_secrets(context, Q_plain, response_nonce)
  aad = 0x02 || len(response_nonce) || response_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.

Kinnear, et al.           Expires 6 March 2022                 [Page 11]
Internet-Draft                Oblivious DoH               September 2021

   def derive_secrets(context, Q_plain, response_nonce):
     secret = context.Export("odoh response", Nk)
     salt = Q_plain || len(response_nonce) || response_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, response_nonce):
  aad = 0x02 || len(response_nonce) || response_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.  Create an "ObliviousDoHQuery" structure, carrying the message M
       and padding, to produce Q_plain.

   2.  Deserialize "config.public_key" to produce a public key pkR of
       type "config.kem_id".

   3.  Compute 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.  Output a 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".

Kinnear, et al.           Expires 6 March 2022                 [Page 12]
Internet-Draft                Oblivious DoH               September 2021

8.  Oblivious Target Behavior

   Targets that receive a Query message Q decrypt and process it as
   follows:

   1.  Look up the "ObliviousDoHConfigContents" according to "Q.key_id".
       If no such key exists, the Target MAY discard the query, and if
       so, it MUST return a 400 (Client Error) 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 "response_nonce = random(max(Nn, Nk))".

   7.  Compute "aead_key, aead_nonce = derive_secrets(context, Q_plain,
       response_nonce)".

   8.  Compute "R_encrypted = encrypt_response_body(R_plain, aead_key,
       aead_nonce, response_nonce)".  The "key_id" field used for
       encryption carries "response_nonce" in order for clients to
       derive the same secrets.  Also, the "Seal" function is that which
       is associated with the HPKE AEAD.

   9.  Output a "ObliviousDoHMessage" message "R" where "R.message_type
       = 0x02", "R.key_id = response_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.

Kinnear, et al.           Expires 6 March 2022                 [Page 13]
Internet-Draft                Oblivious DoH               September 2021

9.  Compliance Requirements

   Oblivious DoH uses HPKE for public key encryption
   [I-D.irtf-cfrg-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 [I-D.irtf-cfrg-hpke],
      Section 7.1)

   *  KDF: HKDF-SHA256 (see [I-D.irtf-cfrg-hpke], Section 7.2)

   *  AEAD: AES-128-GCM (see [I-D.irtf-cfrg-hpke], Section 7.3)

10.  Security Considerations

   Oblivious DoH aims to keep knowledge of the true query origin and its
   contents known to only clients.  As a simplified model, consider a
   case where there exists two clients C1 and C2, one proxy P, and one
   target T.  Oblivious DoH assumes an extended Dolev-Yao style attacker
   which can observe all network activity and can adaptively compromise
   either P or T, but not C1 or C2.  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 not all targets and proxies are simultaneously
   compromised, and 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 an 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 may 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:

Kinnear, et al.           Expires 6 March 2022                 [Page 14]
Internet-Draft                Oblivious DoH               September 2021

   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 recommend padding lengths for
   ObliviousDoHQuery and ObliviousDoHResponse messages.  Implementations
   SHOULD follow the guidance for choosing padding length in [RFC8467].

   Oblivious DoH security does not depend on proxy and target
   indistinguishability.  Specifically, an on-path attacker could
   determine whether a connection a specific endpoint is used for
   oblivious or direct DoH queries.  However, this has no effect on
   confidentiality goals listed above.

10.1.  Denial of Service

   Malicious clients (or proxies) may send bogus Oblivious DoH queries
   to targets as a Denial-of-Service (DoS) attack.  Target servers may
   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 may throttle specific clients in response to these
   errors.

   Malicious Targets or Proxies may 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 above, malicious Targets and Proxies are out of scope for
   the threat model.

10.2.  Proxy Policies

   Proxies are free to enforce any forwarding policy they desire for
   clients.  For example, they may only forward requests to known or
   otherwise trusted targets.

Kinnear, et al.           Expires 6 March 2022                 [Page 15]
Internet-Draft                Oblivious DoH               September 2021

10.3.  Authentication

   Depending on the deployment scenario, Proxies and Targets MAY 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 SHOULD 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 Unauthorized response codes due to client key
   mismatch; see Section 4.3.

10.4.  General Proxy Services

   Using DoH over anonymizing proxy services such as Tor would also
   achieve the desired goal of separating query origins from their
   contents.  However, there are several reasons why such systems are
   undesirable in comparison Oblivious DoH:

   1.  Tor is also meant as a generic connection-level anonymity system,
       and thus seems overly complex and costly for the purpose of
       proxying individual DoH queries.  In contrast, Oblivious DoH is a
       lightweight extension to standard DoH, implemented as an
       application-layer proxy, that can be enabled as a default mode
       for users which need increased privacy.

   2.  As a one-hop proxy, Oblivious DoH encourages connection-less
       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.

11.  IANA Considerations

11.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

Kinnear, et al.           Expires 6 March 2022                 [Page 16]
Internet-Draft                Oblivious DoH               September 2021

   Required parameters: N/A

   Optional parameters: N/A

   Encoding considerations: This is a binary format, containing
   encrypted DNS requests and responses, as defined in this document.

   Security considerations: See this document.  The content is an
   encrypted DNS message, and not executable code.

   Interoperability considerations: This document specifies format of
   conforming messages and the interpretation thereof.

   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
   Authors' Addresses section

   Intended usage: COMMON

   Restrictions on usage: N/A

   Author: Tommy Pauly tpauly@apple.com (mailto:tpauly@apple.com)

   Change controller: Tommy Pauly tpauly@apple.com
   (mailto:tpauly@apple.com)

   Provisional registration? (standards tree only): No

12.  Acknowledgments

   This work is inspired by Oblivious DNS
   [I-D.annee-dprive-oblivious-dns].  Thanks to all of the authors of
   that document.  Thanks to Nafeez Ahamed, Elliot Briggs, Marwan Fayed,
   Frederic Jacobs, Tommy Jensen, Jonathan Hoyland, Paul Schmitt, Brian
   Swander, Erik Nygren, and Peter Wu for the feedback and input.

13.  References

13.1.  Normative References

Kinnear, et al.           Expires 6 March 2022                 [Page 17]
Internet-Draft                Oblivious DoH               September 2021

   [I-D.ietf-httpbis-proxy-status]
              Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
              Response Header Field", Work in Progress, Internet-Draft,
              draft-ietf-httpbis-proxy-status-06, 16 August 2021,
              <https://www.ietf.org/archive/id/draft-ietf-httpbis-proxy-
              status-06.txt>.

   [I-D.irtf-cfrg-hpke]
              Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood,
              "Hybrid Public Key Encryption", Work in Progress,
              Internet-Draft, draft-irtf-cfrg-hpke-12, 2 September 2021,
              <https://www.ietf.org/archive/id/draft-irtf-cfrg-hpke-
              12.txt>.

   [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>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
              RFC 7234, DOI 10.17487/RFC7234, June 2014,
              <https://www.rfc-editor.org/info/rfc7234>.

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <https://www.rfc-editor.org/info/rfc7235>.

   [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>.

Kinnear, et al.           Expires 6 March 2022                 [Page 18]
Internet-Draft                Oblivious DoH               September 2021

   [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>.

13.2.  Informative References

   [I-D.annee-dprive-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://www.ietf.org/archive/id/
              draft-annee-dprive-oblivious-dns-00.txt>.

   [RFC7239]  Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
              RFC 7239, DOI 10.17487/RFC7239, June 2014,
              <https://www.rfc-editor.org/info/rfc7239>.

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

Kinnear, et al.           Expires 6 March 2022                 [Page 19]
Internet-Draft                Oblivious DoH               September 2021

   Tanya Verma
   Cloudflare
   101 Townsend St
   San Francisco,
   United States of America

   Email: vermatanyax@gmail.com

   Christopher A. Wood
   Cloudflare
   101 Townsend St
   San Francisco,
   United States of America

   Email: caw@heapingbits.net

Kinnear, et al.           Expires 6 March 2022                 [Page 20]