Status of This Memo

This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.¶

This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9230.¶

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1.Introduction

DNS over HTTPS (DoH)[RFC8484] defines a mechanism to allow DNS messages to betransmitted in HTTP messages protected with TLS. This provides improved confidentialityand authentication for DNS interactions in various circumstances.¶

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

Proposals such as Oblivious DNS[OBLIVIOUS-DNS] increase privacyby ensuring that no single DNS server is aware of both the client IP address and the messagecontents.¶

This document defines Oblivious DoH, an experimental protocol built on DoH that permits proxiedresolution, in which DNS messages are encrypted so that no server can independently readboth the client IP address and the DNS message contents.¶

As with DoH, DNS messages exchanged over Oblivious DoH are fully formed DNS messages.Clients that want to receive answers that are relevant to the network they are on withoutrevealing their exact IP address can thus use the EDNS0 Client Subnet option ([RFC7871],Section 7.1.2)to provide a hint to the resolver using Oblivious DoH.¶

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

This experimental protocol has been developed outside the IETF and is published here toguide implementation, ensure interoperability among implementations, and enablewide-scale experimentation. SeeSection 10 for more details about the experiment.¶

2.Terminology

This document defines the following terms:¶

Oblivious Client:

A client that sends DNS queries to an Oblivious Target, through an Oblivious Proxy. The Client is responsible for selecting the combination of Proxy and Target to use for a given query.¶

Oblivious Proxy:

An HTTP server that proxies encrypted DNS queries and responses between an Oblivious Client and anOblivious Target and is identified by a URI Template[RFC6570] (seeSection 4.1).Note that this Oblivious Proxy is not acting as a full HTTP proxy but is instead a specializedserver used to forward Oblivious DNS messages.¶

Oblivious Target:

An HTTP server that receives and decrypts encrypted Oblivious Client DNS queries from an Oblivious Proxyand returns encrypted DNS responses via that same Proxy. In order to provide DNS responses, the Targetcan be a DNS resolver, be co-located with a resolver, or forward to a resolver.¶

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

3.Deployment Requirements

Oblivious DoH requires, at a minimum:¶

• An Oblivious Proxy server, identified by a URI Template.¶
• An Oblivious Target server. The Target and Proxy are expected to be non-colluding (seeSection 11).¶
• One or more Target public keys for encrypting DNS queries sent to a Target via a Proxy(Section 5). These keys guarantee that only the intended Target can decrypt Client queries.¶

The mechanism for discovering and provisioning the Proxy URI Template and Target public keysis out of scope for this document.¶

4.HTTP Exchange

Unlike direct resolution, oblivious hostname resolution over DoH involves three parties:¶

1. The Client, which generates queries.¶
2. The Proxy, which receives encrypted queries from the Client and passes them on to a Target.¶
3. The Target, which receives proxied queries from the Client via the Proxy and produces proxiedanswers.¶

     --- [ Request encrypted with Target public key ] -->+---------+             +-----------+             +-----------+| Client  +-------------> Oblivious +-------------> Oblivious ||         <-------------+   Proxy   <-------------+  Target   |+---------+             +-----------+             +-----------+    <-- [   Response encrypted with symmetric key   ] ---

https://dnsproxy.example/dns-query{?targethost,targetpath}https://dnsproxy.example/{targethost}/{targetpath}

:method = POST:scheme = https:authority = dnsproxy.example:path = /dns-query?targethost=dnstarget.example&targetpath=/dns-queryaccept = application/oblivious-dns-messagecontent-type = application/oblivious-dns-messagecontent-length = 106<Bytes containing an encrypted Oblivious DNS query>

:method = POST:scheme = https:authority = dnstarget.example:path = /dns-queryaccept = application/oblivious-dns-messagecontent-type = application/oblivious-dns-messagecontent-length = 106<Bytes containing an encrypted Oblivious DNS query>

:status = 200content-type = application/oblivious-dns-messagecontent-length = 154<Bytes containing an encrypted Oblivious DNS response>

5.Configuration and Public Key Format

In order to send a message to a Target, the Client needs to know a public key to usefor encrypting its queries. The mechanism for discovering this configuration isout of scope for this document.¶

Servers ought to rotate public keys regularly. It isRECOMMENDED that servers rotate keysevery day. Shorter rotation windows reduce the anonymity set of Clients that might usethe public key, whereas longer rotation windows widen the time frame of possible compromise.¶

An Oblivious DNS public key configuration is a structure encoded, using TLS-styleencoding[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>;

TheObliviousDoHConfigs structure contains one or moreObliviousDoHConfig structures in decreasing order ofpreference. This allows a server to support multiple versions of Oblivious DoH and multiple sets of Oblivious DoHparameters.¶

AnObliviousDoHConfig structure contains a versioned representation of an Oblivious DoH configuration,with the following fields.¶

version:

The version of Oblivious DoH for which this configuration is used. ClientsMUST ignore anyObliviousDoHConfig structure with a version they do not support. The version of Oblivious DoHspecified 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 thisspecification, the contents are anObliviousDoHConfigContents structure.¶

AnObliviousDoHConfigContents structure contains the information needed to encrypt a message underObliviousDoHConfigContents.public_key such that only the owner of the corresponding privatekey can decrypt the message. The values forObliviousDoHConfigContents.kem_id,ObliviousDoHConfigContents.kdf_id, andObliviousDoHConfigContents.aead_idare described inSection 7 of [HPKE]. The fields in this structureare as follows:¶

kem_id:

The hybrid public key encryption (HPKE) key encapsulation mechanism (KEM) identifier corresponding topublic_key. ClientsMUST ignore anyObliviousDoHConfig structure with a key using a KEM they do not support.¶

kdf_id:

The HPKE key derivation function (KDF) identifier corresponding topublic_key. ClientsMUST ignore anyObliviousDoHConfig structure with a key using a KDF they do not support.¶

aead_id:

The HPKE authenticated encryption with associated data (AEAD) identifier corresponding topublic_key. ClientsMUST 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

This section includes encoding and wire format details for Oblivious DoH, as wellas routines for encrypting and decrypting encoded values.¶

struct {   opaque dns_message<1..2^16-1>;   opaque padding<0..2^16-1>;} ObliviousDoHMessagePlaintext;

ObliviousDoHMessagePlaintext ObliviousDoHQuery;ObliviousDoHMessagePlaintext ObliviousDoHResponse;

struct {   uint8  message_type;   opaque key_id<0..2^16-1>;   opaque encrypted_message<1..2^16-1>;} ObliviousDoHMessage;

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

def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce):  aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce)  aad = 0x02 || len(resp_nonce) || resp_nonce  R_plain, error = Open(key, nonce, aad, R_encrypted)  return R_plain, error

def setup_query_context(skR, key_id, Q_encrypted):  enc || ct = Q_encrypted  context = SetupBaseR(enc, skR, "odoh query")  return context

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

def derive_secrets(context, Q_plain, resp_nonce):  secret = context.Export("odoh response", Nk)  salt = Q_plain || len(resp_nonce) || resp_nonce  prk = Extract(salt, secret)  key = Expand(odoh_prk, "odoh key", Nk)  nonce = Expand(odoh_prk, "odoh nonce", Nn)  return key, nonce

def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce):  aad = 0x02 || len(resp_nonce) || resp_nonce  R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain)  return R_encrypted

7.Oblivious Client Behavior

LetM be a DNS message (query) a Client wishes to protect with Oblivious DoH.When sending an Oblivious DoH Query for resolvingM to an Oblivious Target withObliviousDoHConfigContentsconfig, a Client does the following:¶

1. Creates anObliviousDoHQuery structure, carrying the message M and padding, to produce Q_plain.¶
2. Deserializesconfig.public_key to produce a public key pkR of typeconfig.kem_id.¶
3. Computes the encrypted message asQ_encrypted = encrypt_query_body(pkR, key_id, Q_plain),wherekey_id is as computed inSection 6. Note also thatlen(key_id) outputs the length ofkey_idas a two-byte unsigned integer.¶
4. Outputs anObliviousDoHMessage messageQ, whereQ.message_type = 0x01,Q.key_id carrieskey_id,andQ.encrypted_message = Q_encrypted.¶

The Client then sendsQ to the Proxy according toSection 4.1.Once the Client receives a responseR, encrypted as specified inSection 8,it usesdecrypt_response_body to decryptR.encrypted_message (usingR.key_id asa nonce) and produce R_plain. ClientsMUST validateR_plain.padding (as all zeros)before usingR_plain.dns_message.¶

8.Oblivious Target Behavior

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

1. Look up theObliviousDoHConfigContents information according toQ.key_id. If no such key exists,the TargetMAY discard the query, and if so, itMUST return a 401 (Unauthorized) responseto the Proxy. Otherwise, letskR be the private key corresponding to this public key,or one chosen for trial decryption.¶
2. Computecontext = setup_query_context(skR, Q.key_id, Q.encrypted_message).¶
3. ComputeQ_plain, error = decrypt_query_body(context, Q.key_id, Q.encrypted_message).¶
4. If no error was returned andQ_plain.padding is valid (all zeros), resolveQ_plain.dns_message as needed, yielding a DNS message M. Otherwise, if an errorwas returned or the padding was invalid, return a 400 (Client Error) response to the Proxy.¶
5. Create anObliviousDoHResponseBody structure, carrying the messageM and padding,to produceR_plain.¶
6. Create a fresh nonceresp_nonce = random(max(Nn, Nk)).¶
7. Computeaead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce).¶
8. ComputeR_encrypted = encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce).Thekey_id field used for encryption carriesresp_nonce in order for Clients toderive the same secrets. Also, theSeal function is the function that is associated with theHPKE AEAD.¶
9. Output anObliviousDoHMessage messageR, whereR.message_type = 0x02,R.key_id = resp_nonce, andR.encrypted_message = R_encrypted.¶

The Target then sendsR in a 2xx (Successful) response to the Proxy; seeSection 4.3.The Proxy forwards the messageR without modification back to the Client as the HTTP responseto the Client's original HTTP request. In the event of an error (non-2xx status code), theProxy forwards the Target error to the Client; seeSection 4.3.¶

9.Compliance Requirements

Oblivious DoH uses HPKE for public key encryption[HPKE].In the absence of an application profile standard specifying otherwise, a compliantOblivious DoH implementationMUST support the following HPKE cipher suite:¶

KEM:

DHKEM(X25519, HKDF-SHA256) (see[HPKE],Section 7.1)¶

KDF:

HKDF-SHA256 (see[HPKE],Section 7.2)¶

AEAD:

AES-128-GCM (see[HPKE],Section 7.3)¶

10.Experiment Overview

This document describes an experimental protocol built on DoH. The purpose of thisexperiment is to assess deployment configuration viability and related performanceimpacts on DNS resolution by measuring key performance indicators such as resolutionlatency. Experiment participants will test various parameters affecting service operationand performance, including mechanisms for discovery and configuration of DoH Proxiesand Targets, as well as performance implications of connection reuse and pools whereappropriate. The results of this experiment will be used to influence future protocoldesign and deployment efforts related to Oblivious DoH, such as Oblivious HTTP[OHTP]. Implementations of DoH that are not involved in theexperiment will not recognize this protocol and will not participate in the experiment.It is anticipated that the use of Oblivious DoH will be widespread and that this experiment will be of long duration.¶

11.Security Considerations

Oblivious DoH aims to keep knowledge of the true query origin and its contents known only to Clients.As a simplified model, consider a case where there exist two Clients C1 and C2, one Proxy P, andone Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker[Dolev-Yao] that can observe allnetwork activity and can adaptively compromise either P or T, but not C1 or C2. Note that compromisingboth P and T is equivalent to collusion between these two parties in practice. Once compromised,the attacker has access to all session information and private key material. (This generalizes toarbitrarily many Clients, Proxies, and Targets, with the constraints that (1) not all Targets and Proxiesare simultaneously compromised and (2) at least two Clients are left uncompromised.) The attacker isprohibited from sending Client-identifying information, such as IP addresses, to Targets. (This wouldallow the attacker to trivially link a query to the corresponding Client.)¶

In this model, both C1 and C2 send Oblivious DoH queries Q1 and Q2, respectively, through P to T,and T provides answers A1 and A2. The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), respectively.The attacker succeeds if this linkability is possible without any additional interaction. (For example,if T is compromised, it could return a DNS answer corresponding to an entity it controls and then observethe subsequent connection from a Client, learning its identity in the process. Such attacks are out ofscope for this model.)¶

Oblivious DoH security prevents such linkability. Informally, this means:¶

1. Queries and answers are known only to Clients and Targets in possession of the correspondingresponse key and HPKE keying material. In particular, Proxies know the origin and destinationof an oblivious query, yet do not know the plaintext query. Likewise, Targets know only the obliviousquery origin, i.e., the Proxy, and the plaintext query. Only the Client knows both the plaintextquery contents and destination.¶
2. Target resolvers cannot link queries from the same Client in the absence of unique per-Clientkeys.¶

Traffic analysis mitigations are outside the scope of this document. In particular, this documentdoes not prescribe padding lengths forObliviousDoHQuery andObliviousDoHResponse messages.ImplementationsSHOULD follow the guidance in[RFC8467] for choosing padding length.¶

Oblivious DoH security does not depend on Proxy and Target indistinguishability. Specifically, anon-path attacker could determine whether a connection to a specific endpoint is used for oblivious ordirect DoH queries. However, this has no effect on the confidentiality goals listed above.¶

12.IANA Considerations

This document makes changes to the "Media Types" registry.The changes are described in the following subsection.¶

Appendix A.Use of Generic Proxy Services

Using DoH over anonymizing proxy services such as Tor can also achieve the desired goal of separatingquery origins from their contents. However, there are several reasons why such systems are undesirableas contrasted with Oblivious DoH:¶

1. Tor is meant to be a generic connection-level anonymity system, and it incurs higher latency costsand protocol complexity for the purpose of proxying individual DNS queries. In contrast, Oblivious DoHis a lightweight protocol built on DoH, implemented as an application-layer proxy, that can be enabledas a default mode for users that need increased privacy.¶
2. As a one-hop proxy, Oblivious DoH encourages connectionless proxies to mitigate Client query correlationwith 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 connectionper query would incur a non-negligible penalty in connection setup time.¶

Acknowledgments

This work is inspired by Oblivious DNS[OBLIVIOUS-DNS]. Thanks to all of theauthors of that document. Thanks toNafeez Ahamed,Elliot Briggs,Marwan Fayed,Jonathan Hoyland,Frederic Jacobs,Tommy Jensen,Erik Nygren,Paul Schmitt,Brian Swander, andPeter Wufor their feedback and input.¶

Authors' Addresses