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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/