Oblivious Client:

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

Oblivious Proxy:

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

Oblivious Target:

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

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

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

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

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>;

version:

The version of Oblivious DoH for which this configuration is used. Clients MUST ignore any ObliviousDoHConfig structure with a version they do not support. The version of Oblivious DoH specified in this document is 0x0001.

length:

The length, in bytes, of the next field.

contents:

An opaque byte string whose contents depend on the version. For this specification, the contents are an ObliviousDoHConfigContents structure.

kem_id:

The hybrid public key encryption (HPKE) key encapsulation mechanism (KEM) identifier corresponding to public_key. Clients MUST ignore any ObliviousDoHConfig structure with a key using a KEM they do not support.

kdf_id:

The HPKE key derivation function (KDF) identifier corresponding to public_key. Clients MUST ignore any ObliviousDoHConfig structure with a key using a KDF they do not support.

aead_id:

The HPKE authenticated encryption with associated data (AEAD) identifier corresponding to public_key. Clients MUST ignore any ObliviousDoHConfig structure with a key using an AEAD they do not support.

public_key:

The HPKE public key used by the Client to encrypt Oblivious DoH queries.

1. A DNS message, which is either a Query or Response, depending on context.
2. Padding of arbitrary length, which MUST contain all zeros.

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;

message_type:

A one-byte identifier for the type of message. Query messages use message_type 0x01, and Response messages use message_type 0x02.

key_id:

The identifier of the corresponding ObliviousDoHConfigContents key. This is computed as Expand(Extract("", config), "odoh key id", Nh), where config is the ObliviousDoHConfigContents structure and Extract, Expand, and Nh are as specified by the HPKE cipher suite KDF corresponding to config.kdf_id.

encrypted_message:

An encrypted message for the Oblivious Target (for Query messages) or Client (for Response messages). Implementations MAY enforce limits on the size of this field, depending on the size of plaintext DNS messages. (DNS queries, for example, will not reach the size limit of 2^16-1 in practice.)

• encrypt_query_body: Encrypt an Oblivious DoH query.

def encrypt_query_body(pkR, key_id, Q_plain):
  enc, context = SetupBaseS(pkR, "odoh query")
  aad = 0x01 || len(key_id) || key_id
  ct = context.Seal(aad, Q_plain)
  Q_encrypted = enc || ct
  return Q_encrypted

• decrypt_response_body: Decrypt an Oblivious DoH response.

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

• setup_query_context: Set up an HPKE context used for decrypting an Oblivious DoH query.

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

• decrypt_query_body: Decrypt an Oblivious DoH query.

def decrypt_query_body(context, key_id, Q_encrypted):
  aad = 0x01 || len(key_id) || key_id
  enc || ct = Q_encrypted
  Q_plain, error = context.Open(aad, ct)
  return Q_plain, error

• derive_secrets: Derive keying material used for encrypting an Oblivious DoH response.

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

• encrypt_response_body: Encrypt an Oblivious DoH response.

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

1. Creates an ObliviousDoHQuery structure, carrying the message M and padding, to produce Q_plain.
2. Deserializes config.public_key to produce a public key pkR of type config.kem_id.
3. Computes the encrypted message as Q_encrypted = encrypt_query_body(pkR, key_id, Q_plain), where key_id is as computed in Section 6. Note also that len(key_id) outputs the length of key_id as a two-byte unsigned integer.
4. Outputs an ObliviousDoHMessage message Q, where Q.message_type = 0x01, Q.key_id carries key_id, and Q.encrypted_message = Q_encrypted.

1. Look up the ObliviousDoHConfigContents information according to Q.key_id. If no such key exists, the Target MAY discard the query, and if so, it MUST return a 401 (Unauthorized) response to the Proxy. Otherwise, let skR be the private key corresponding to this public key, or one chosen for trial decryption.
2. Compute context = setup_query_context(skR, Q.key_id, Q.encrypted_message).
3. Compute Q_plain, error = decrypt_query_body(context, Q.key_id, Q.encrypted_message).
4. If no error was returned and Q_plain.padding is valid (all zeros), resolve Q_plain.dns_message as needed, yielding a DNS message M. Otherwise, if an error was returned or the padding was invalid, return a 400 (Client Error) response to the Proxy.
5. Create an ObliviousDoHResponseBody structure, carrying the message M and padding, to produce R_plain.
6. Create a fresh nonce resp_nonce = random(max(Nn, Nk)).
7. Compute aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce).
8. Compute R_encrypted = encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce). The key_id field used for encryption carries resp_nonce in order for Clients to derive the same secrets. Also, the Seal function is the function that is associated with the HPKE AEAD.
9. Output an ObliviousDoHMessage message R, where R.message_type = 0x02, R.key_id = resp_nonce, and R.encrypted_message = R_encrypted.

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)

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

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 DNSrequests and responses encoded as ObliviousDoHMessage values, as definedin Section 6.1.

Security considerations:

See this document. The content is an encrypted DNSmessage, and not executable code.

Interoperability considerations:

This document specifies the format ofconforming messages and the interpretation thereof; see Section 6.1.

Published specification:

This document

Applications that use this media type:

This media type is intendedto be used by Clients wishing to hide their DNS queries whenusing DNS over HTTPS.

Additional information:

N/A

Person and email address to contact for further information:

See theAuthors' Addresses section.

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

Tommy Pauly (tpauly@apple.com)

Change controller:

IETF

Provisional registration? (standards tree only):

No

[HPKE]

R. Barnes, K. Bhargavan, B. Lipp, and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022,
<https://www.rfc-editor.org/info/rfc9180>.

[HTTP]

R. Fielding, M. Nottingham, and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC6570]

J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/info/rfc6570>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8446]

E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.

[RFC8467]

A. Mayrhofer, "Padding Policies for Extension Mechanisms for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, October 2018,
<https://www.rfc-editor.org/info/rfc8467>.

[RFC8484]

P. Hoffman, and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.

[RFC9209]

M Nottingham, 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>.

[Dolev-Yao]

D Dolev, and A. C. Yao, "On the Security of Public Key Protocols", DOI 10.1109/TIT.1983.1056650, March 1983,
<https://www.cs.huji.ac.il/~dolev/pubs/dolev-yao-ieee-01056650.pdf>.

[OBLIVIOUS-DNS]

Salesforce, , , , and , "Oblivious DNS - Strong Privacy for DNS Queries", Internet-Draft draft-annee-dprive-oblivious-dns-00, July 2018,
<https://datatracker.ietf.org/doc/html/draft-annee-dprive-oblivious-dns-00>.

[OHTP]

Cloudflare, , and C.A. Wood, "Oblivious HTTP", Internet-Draft draft-ietf-ohai-ohttp-01, February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp-01>.

[RFC7239]

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

[RFC7871]

C. Contavalli, W. van der Gaast, D. Lawrence, and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.

1. Tor is meant to be a generic connection-level anonymity system, and it incurs higher latency costs and protocol complexity for the purpose of proxying individual DNS queries. In contrast, Oblivious DoH is a lightweight protocol built on DoH, implemented as an application-layer proxy, that can be enabled as a default mode for users that need increased privacy.
2. As a one-hop proxy, Oblivious DoH encourages connectionless proxies to mitigate Client query correlation with few round trips. In contrast, multi-hop systems such as Tor often run secure connections (TLS) end to end, which means that DoH servers could track queries over the same connection. Using a fresh DoH connection per query would incur a non-negligible penalty in connection setup time.

Eric Kinnear

Patrick McManus

Tommy Pauly

Tanya Verma

Christopher A. Wood