Internet-Draft | Oblivious DoH | September 2021 |
Kinnear, et al. | Expires 6 March 2022 | [Page] |
- Workgroup:
- Network Working Group
- Internet-Draft:
- draft-pauly-dprive-oblivious-doh-07
- Published:
- Intended Status:
- Experimental
- Expires:
Oblivious DNS Over HTTPS
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.¶
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.¶
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.¶
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.¶
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:¶
- The Client, which generates queries.¶
- The Proxy, which receives encrypted queries from the client and passes them on to a Target.¶
- The Target, which receives proxied queries from the client via the Proxy and produces proxied answers.¶
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 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 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>¶
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.¶
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 is0x0001
.¶ - 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 anyObliviousDoHConfig
structure with a key using a KEM they do not support.¶ - kdf_id
-
The HPKE KDF identifier corresponding to
public_key
. Clients MUST ignore anyObliviousDoHConfig
structure with a key using a KDF they do not support.¶ - aead_id
-
The HPKE AEAD identifier corresponding to
public_key
. Clients MUST ignore anyObliviousDoHConfig
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:¶
- A DNS message, which is either a Query or Response, depending on context.¶
- 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 usemessage_type
0x02.¶ - key_id
-
The identifier of the corresponding
ObliviousDoHConfigContents
key. This is computed asExpand(Extract("", config), "odoh key id", Nh)
, whereconfig
is the ObliviousDoHConfigContents structure andExtract
,Expand
, andNh
are as specified by the HPKE cipher suite KDF corresponding toconfig.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.¶
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.¶
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:¶
- Create an
ObliviousDoHQuery
structure, carrying the message M and padding, to produce Q_plain.¶ - Deserialize
config.public_key
to produce a public key pkR of typeconfig.kem_id
.¶ - Compute the encrypted message as
Q_encrypted = encrypt_query_body(pkR, key_id, Q_plain)
, wherekey_id
is as computed in Section 6. Note also thatlen(key_id)
outputs the length ofkey_id
as a two-byte unsigned integer.¶ - Output a ObliviousDoHMessage message
Q
whereQ.message_type = 0x01
,Q.key_id
carrieskey_id
, andQ.encrypted_message = Q_encrypted
.¶
The client then sends Q
to the Proxy according to Section 4.1.
Once the client receives a response R
, encrypted as specified in Section 8,
it uses decrypt_response_body
to decrypt R.encrypted_message
(using R.key_id
as
a nonce) and produce R_plain. Clients MUST validate R_plain.padding
(as all zeros)
before using R_plain.dns_message
.¶
8. Oblivious Target Behavior
Targets that receive a Query message Q decrypt and process it as follows:¶
- Look up the
ObliviousDoHConfigContents
according toQ.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, letskR
be the private key corresponding to this public key, or one chosen for trial decryption.¶ - Compute
context = setup_query_context(skR, Q.key_id, Q.encrypted_message)
.¶ - Compute
Q_plain, error = decrypt_query_body(context, Q.key_id, Q.encrypted_message)
.¶ - If no error was returned, and
Q_plain.padding
is valid (all zeros), resolveQ_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.¶ - Create an
ObliviousDoHResponseBody
structure, carrying the messageM
and padding, to produceR_plain
.¶ - Create a fresh nonce
response_nonce = random(max(Nn, Nk))
.¶ - Compute
aead_key, aead_nonce = derive_secrets(context, Q_plain, response_nonce)
.¶ - Compute
R_encrypted = encrypt_response_body(R_plain, aead_key, aead_nonce, response_nonce)
. Thekey_id
field used for encryption carriesresponse_nonce
in order for clients to derive the same secrets. Also, theSeal
function is that which is associated with the HPKE AEAD.¶ - Output a
ObliviousDoHMessage
messageR
whereR.message_type = 0x02
,R.key_id = response_nonce
, andR.encrypted_message = R_encrypted
.¶
The Target then sends R
in a 2xx (Successful) response to the Proxy; see Section 4.3.
The Proxy forwards the message R
without modification back to the client as the HTTP response
to the client's original HTTP request. In the event of an error (non 2xx status code), the
Proxy forwards the Target error to the client; see Section 4.3.¶
9. Compliance Requirements
Oblivious DoH uses HPKE for public key encryption [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:¶
- 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.¶
- 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.¶
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:¶
- 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.¶
- 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¶
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¶
Change controller: Tommy Pauly 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
- [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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8446>.
- [RFC8467]
- Mayrhofer, A., "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, , <https://www.rfc-editor.org/info/rfc8467>.
- [RFC8484]
- Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <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, , <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, , <https://www.rfc-editor.org/info/rfc7239>.