[要約] RFC 9230は、Oblivious DNS over HTTPS (ODoH)に関する文書で、DNSクエリのプライバシーを強化するために設計されています。このプロトコルは、クライアントとターゲット間のDNSクエリを中継するプロキシを使用して、クライアントのプライバシーを保護します。利用場面としては、ユーザーがISPや他の中間者による監視からDNSクエリを隠したい場合に有効です。関連するRFCには、HTTPSを使用したDNSクエリの標準化を扱うRFC 8484（DNS over HTTPS、DoH）などがあります。ODoHは、DoHのプライバシー保護をさらに強化する形で提案されています。
Independent Submission E. Kinnear
Request for Comments: 9230 Apple Inc.
Category: Experimental P. McManus
ISSN: 2070-1721 Fastly
T. Pauly
Apple Inc.
T. Verma
C.A. Wood
Cloudflare
June 2022
This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. 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.
このドキュメントは、クライアントが暗号化されたDNS over HTTPS（DoH）メッセージをプロキシしてDNSリゾルバからIPアドレスを隠すことを可能にするプロトコルについて説明しています。これにより、DNS操作のプライバシーが向上し、クライアントのIPアドレスとDNSクエリと回答の内容の両方を把握することができなくなります。
This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation.
この実験プロトコルはIETFの外で開発され、ここに公開されています。実装をガイドし、実装間の相互運用性を確保し、広範囲の実験を可能にするためです。
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.
この文書はインターネットコミュニティのための実験プロトコルを定義しています。これはRFCシリーズへの貢献であり、他のRFCストリームとは独立しています。RFCエディターは、この文書を自己の裁量で公開することを選択し、その実装や展開に対する価値についての声明は行いません。RFCエディターによって公開が承認された文書は、インターネット標準のいかなるレベルの候補ともなりません。RFC 7841のセクション2を参照してください。
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.
この文書の現在の状況、誤り、フィードバック方法に関する情報は、https://www.rfc-editor.org/info/rfc9230 で入手できます。
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書の著者として特定された人々。全著作権所有。
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.
この文書は、この文書の公開日に有効なBCP 78およびIETF文書に関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらの文書を注意深く確認してください。これらは、この文書に関するあなたの権利と制限を説明しています。
1. Introduction
1.1. Specification of Requirements
2. Terminology
3. Deployment Requirements
4. HTTP Exchange
4.1. HTTP Request
4.2. HTTP Request Example
4.3. HTTP Response
4.4. HTTP Response Example
4.5. HTTP Metadata
5. Configuration and Public Key Format
6. Protocol Encoding
6.1. Message Format
6.2. Encryption and Decryption Routines
7. Oblivious Client Behavior
8. Oblivious Target Behavior
9. Compliance Requirements
10. Experiment Overview
11. Security Considerations
11.1. Denial of Service
11.2. Proxy Policies
11.3. Authentication
12. IANA Considerations
12.1. Oblivious DoH Message Media Type
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Use of Generic Proxy Services
Acknowledgments
Authors' Addresses
DNS over HTTPS (DoH) [RFC8484] defines a mechanism to allow DNS messages to be transmitted in HTTP messages protected with TLS. This provides improved confidentiality and authentication for DNS interactions in various circumstances.
DNS over HTTPS（DoH）[RFC8484]は、TLSで保護されたHTTPメッセージでDNSメッセージを送信するメカニズムを定義しています。これにより、さまざまな状況でDNSの相互作用の機密性と認証が向上します。
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 revealing their local IP address (and thus information about the identity or location of the client) to the server.
DoHは盗聴者がDNSのやり取りの内容を直接読むのを防ぐことができますが、クライアントはサーバーに対してDNSクエリを送信し、回答を受け取る際に、自分のローカルIPアドレス（つまりクライアントの身元や位置に関する情報）をサーバーに明かさなければなりません。
Proposals such as Oblivious DNS [OBLIVIOUS-DNS] increase privacy by ensuring that no single DNS server is aware of both the client IP address and the message contents.
提案例として、Oblivious DNS [OBLIVIOUS-DNS] は、クライアントのIPアドレスとメッセージ内容の両方を把握していないことにより、プライバシーを向上させます。
This document defines Oblivious DoH, an experimental protocol built on DoH that permits proxied resolution, in which DNS messages are encrypted so that no server can independently read both the client IP address and the DNS message contents.
このドキュメントは、Oblivious DoHを定義しています。これは、DoH上に構築された実験的なプロトコルで、プロキシされた解決を許可します。DNSメッセージが暗号化されるため、サーバーはクライアントのIPアドレスとDNSメッセージの内容を独立して読むことができません。
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 without revealing 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.
DoHと同様に、Oblivious DoHを介して交換されるDNSメッセージは完全な形式のDNSメッセージです。そのため、正確なIPアドレスを明らかにせずに、自分が属するネットワークに関連する回答を受け取りたいクライアントは、Oblivious DoHを使用してリゾルバにヒントを提供するためにEDNS0クライアントサブネットオプション（[RFC7871]、セクション7.1.2）を使用できます。
This mechanism is intended to be used as one mechanism for resolving privacy-sensitive content in the broader context of DNS privacy.
このメカニズムは、DNSプライバシーの広い文脈におけるプライバシーに配慮したコンテンツを解決するための1つのメカニズムとして使用することを意図しています。
This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. See Section 10 for more details about the experiment.
この実験プロトコルはIETFの外で開発され、ここに公開されています。実装のガイドと相互運用性の確保、広範囲な実験を可能にするためです。実験の詳細についてはセクション10を参照してください。
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.
この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、全て大文字で表記されている場合に限り、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されるべきです。
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.
クライアントは、忘却プロキシを介して忘却対象にDNSクエリを送信します。クライアントは、特定のクエリに使用するプロキシとターゲットの組み合わせを選択する責任があります。
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 [RFC6570] (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クライアントとObliviousターゲットの間で暗号化されたDNSクエリと応答をプロキシするHTTPサーバーであり、URIテンプレート[RFC6570]によって識別されます（セクション4.1を参照）。このObliviousプロキシは完全なHTTPプロキシとして機能しているわけではなく、代わりにOblivious DNSメッセージを転送するために使用される専門のサーバーです。
Oblivious Target:
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.
Oblivious Proxy からの暗号化された Oblivious Client DNS クエリを受信し、復号化する HTTP サーバーがあり、同じプロキシを介して暗号化された DNS 応答を返します。DNS 応答を提供するために、ターゲットは DNS リゾルバであるか、リゾルバと同じ場所にあるか、リゾルバに転送できます。
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.
この文書の残りの部分では、それぞれOblivious Client（無自覚なクライアント）、Oblivious Proxy（無自覚なプロキシ）、Oblivious Target（無自覚なターゲット）を指す用語として、「クライアント」、「プロキシ」、「ターゲット」を使用します。
Oblivious DoH requires, at a minimum:
Oblivious DoH には、最低限以下が必要です：
* An Oblivious Proxy server, identified by a URI Template.
* URIテンプレートで識別される無自覚プロキシサーバ。
* An Oblivious Target server. The Target and Proxy are expected to be non-colluding (see Section 11).
* 無自覚なターゲットサーバー。ターゲットとプロキシは、互いに協力しないことが期待されています（セクション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.
* ターゲットに送信されるDNSクエリを暗号化するための1つ以上のターゲット公開鍵（セクション5）です。これらの鍵は、意図したターゲットのみがクライアントのクエリを復号化できることを保証します。
The mechanism for discovering and provisioning the Proxy URI Template and Target public keys is out of scope for this document.
このドキュメントでは、プロキシURIテンプレートとターゲットの公開鍵を発見および提供するメカニズムは対象外です。
Unlike direct resolution, oblivious hostname resolution over DoH involves three parties:
直接の解決とは異なり、DoHを介した無自覚なホスト名の解決には3つの当事者が関与します。
1. The Client, which generates queries.
1. クライアント、クエリを生成します。
2. The Proxy, which receives encrypted queries from the Client and passes them on to a Target.
2. クライアントから暗号化されたクエリを受け取り、それをターゲットに転送するプロキシ。
3. The Target, which receives proxied queries from the Client via the Proxy and produces proxied answers.
3. クライアントからプロキシを介してプロキシされたクエリを受け取り、プロキシされた回答を生成するターゲット。
--- [ Request encrypted with Target public key ] -->
+---------+ +-----------+ +-----------+
| Client +-------------> Oblivious +-------------> Oblivious |
| <-------------+ Proxy <-------------+ Target |
+---------+ +-----------+ +-----------+
<-- [ Response encrypted with symmetric key ] ---
Figure 1: Oblivious DoH Exchange
図1：Oblivious DoH Exchange
Oblivious DoH queries are created by the Client and are sent to the Proxy as HTTP requests using the POST method. Clients are configured 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". The Proxy URI Template uses the Level 3 encoding defined in Section 1.2 of [RFC6570] and contains two variables: "targethost", which indicates the hostname of the Target server; and "targetpath", which indicates the path on which the Target is accessible. Examples of Proxy URI Templates are shown below:
クライアントによって作成された無自覚なDoHクエリは、POSTメソッドを使用してHTTPリクエストとしてプロキシに送信されます。クライアントはプロキシURIテンプレート[RFC6570]とターゲットURIで構成されています。プロキシURIテンプレートとターゲットURIのスキームはどちらも「https」でなければなりません。プロキシURIテンプレートは[RFC6570]のセクション1.2で定義されたレベル3のエンコーディングを使用し、"targethost"（ターゲットサーバーのホスト名を示す）と"targetpath"（ターゲットがアクセス可能なパスを示す）の2つの変数を含んでいます。プロキシURIテンプレートの例を以下に示します。
https://dnsproxy.example/dns-query{?targethost,targetpath}
https://dnsproxy.example/{targethost}/{targetpath}
The URI Template MUST contain both the "targethost" and "targetpath" variables exactly once and MUST NOT contain any other variables. The variables MUST be within the path or query components of the URI. Clients MUST ignore configurations that do not conform to this template. See Section 4.2 for an example request.
URIテンプレートには、"targethost"と"targetpath"変数が正確に1回ずつ含まれている必要があり、他の変数は含まれていてはなりません。変数はURIのパスまたはクエリコンポーネント内になければなりません。クライアントは、このテンプレートに準拠していない構成を無視しなければなりません。例のリクエストについては、セクション4.2を参照してください。
Oblivious DoH messages have no cache value, since both requests and responses are encrypted using ephemeral key material. Requests and responses MUST NOT be cached.
Oblivious DoH メッセージにはキャッシュ値がありません。リクエストとレスポンスは、一時的な鍵素材を使用して暗号化されているため、キャッシュしてはいけません。
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.
クライアントは、このリクエストがプロキシング用の Oblivious DoH クエリであることを示すために、HTTP Content-Type ヘッダを "application/oblivious-dns-message" に設定する必要があります。クライアントはまた、HTTP Accept ヘッダにも同じ値を設定することが望ましいです。
A correctly encoded request has the HTTP Content-Type header "application/oblivious-dns-message", uses the HTTP POST method, and contains "targethost" and "targetpath" variables. If the Proxy fails to match the "targethost" and "targetpath" variables from the path, it MUST treat the request as malformed. The Proxy constructs the URI of the Target with the "https" scheme, using the value of "targethost" as the URI host and the percent-decoded value of "targetpath" as the URI path. 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" [RFC9209].
正しくエンコードされたリクエストは、HTTP Content-Typeヘッダーが "application/oblivious-dns-message" であり、HTTP POSTメソッドを使用し、"targethost" と "targetpath" 変数を含んでいます。プロキシがパスから "targethost" と "targetpath" 変数を一致させられない場合、リクエストを不正として扱わなければなりません。プロキシは、"https" スキームを使用して、"targethost" の値をURIホストとし、"targetpath" のパーセントデコードされた値をURIパスとして使用して、ターゲットのURIを構築します。プロキシは、クライアントのリクエストが正しくエンコードされていることを確認しなければならず、確認に失敗した場合は、4xx (クライアントエラー) を返さなければなりません。また、"error" パラメータが "http_request_error" [RFC9209] のタイプである Proxy-Status レスポンスヘッダーを返さなければなりません。
Proxies MAY choose to not forward connections to non-standard ports. In such cases, Proxies can indicate the error with a 403 response status code, along with a Proxy-Status response header with an "error" parameter of type "http_request_denied" and with an appropriate explanation in "details".
プロキシは、非標準ポートへの接続を転送しないことを選択する場合があります。そのような場合、プロキシは403の応答ステータスコードとともに、"error"パラメータが "http_request_denied" である Proxy-Status レスポンスヘッダを示すことができ、"details" に適切な説明を含めることができます。
If the Proxy cannot establish a connection to the Target, it can indicate the error with a 502 response status code, along with a 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 fails, the error type might be "tls_protocol_error".
プロキシがターゲットに接続できない場合、502の応答ステータスコードと、Proxy-Status応答ヘッダーがエラーを示すことができます。その際、"error"パラメーターのタイプが理由を示します。たとえば、DNS解決に失敗した場合、エラータイプは"dns_timeout"となり、TLS接続に失敗した場合は"tls_protocol_error"となる可能性があります。
Upon receipt of requests from a Proxy, Targets MUST validate that the request has the HTTP Content-Type header "application/oblivious-dns-message" and uses the HTTP POST method. Targets can respond with a 4xx response status code if this check fails.
プロキシからのリクエストを受け取った場合、ターゲットはリクエストがHTTP Content-Typeヘッダーが "application/oblivious-dns-message" であり、HTTP POSTメソッドを使用していることを検証する必要があります。このチェックに失敗した場合、ターゲットは4xxの応答ステータスコードで応答することができます。
The following example shows how a Client requests that a Proxy, "dnsproxy.example", forward an encrypted message to "dnstarget.example". The URI Template for the Proxy is "https://dnsproxy.example/dns-query{?targethost,targetpath}". The URI for the Target is "https://dnstarget.example/dns-query".
次の例は、クライアントがプロキシである"dnsproxy.example"に暗号化されたメッセージを転送するようリクエストする方法を示しています。プロキシのURIテンプレートは"https://dnsproxy.example/dns-query{?targethost,targetpath}"です。ターゲットのURIは"https://dnstarget.example/dns-query"です。
:method = POST
:scheme = https
:authority = dnsproxy.example
:path = /dns-query?targethost=dnstarget.example&targetpath=/dns-query
accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message
content-length = 106
<Bytes containing an encrypted Oblivious DNS query>
The Proxy then sends the following request on to the Target:
プロキシは次に、以下のリクエストをターゲットに送信します。
:method = POST
:scheme = https
:authority = dnstarget.example
:path = /dns-query
accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message
content-length = 106
<Bytes containing an encrypted Oblivious DNS query>
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.
Oblivious DoHクエリへの応答は、ターゲットによって生成されます。すべての成功した応答に対して、Content-Type HTTPヘッダを "application/oblivious-dns-message" に設定する必要があります。応答の本文には、暗号化されたDNSメッセージが含まれます。セクション6を参照してください。
The response from a Target MUST set the Content-Type HTTP header to "application/oblivious-dns-message", and that same type MUST be used on all successful responses sent by the Proxy to the Client. A Client MUST only consider a response that contains the Content-Type header 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.
Targetからの応答は、Content-Type HTTPヘッダを "application/oblivious-dns-message" に設定する必要があり、同じタイプがプロキシからクライアントに送信されるすべての成功した応答で使用される必要があります。クライアントは、ペイロードを処理する前にContent-Typeヘッダを含む応答のみを考慮する必要があります。適切なヘッダーがない応答はエラーとして扱われ、適切に処理される必要があります。HTTP応答およびエラー処理のその他の側面は、標準のDoHから継承されます。
Proxies forward responses from the Target to the Client, without any modifications to the body or status code. The Proxy also SHOULD add a Proxy-Status response header with a "received-status" parameter indicating that the status code was generated by the Target.
プロキシは、本文やステータスコードに変更を加えることなく、ターゲットからクライアントに応答を転送します。プロキシはまた、ステータスコードがターゲットによって生成されたことを示す "received-status" パラメータを持つ Proxy-Status 応答ヘッダを追加するべきです。
Note that if a Client receives a 3xx status code and chooses to follow a redirect, the subsequent request MUST also be performed through a Proxy in order to avoid directly exposing requests to the Target.
クライアントが3xxステータスコードを受信し、リダイレクトを選択した場合、後続のリクエストもプロキシを介して実行する必要があります。これにより、リクエストが直接ターゲットに公開されるのを避けることができます。
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 15.5.2 of [HTTP]). 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 15.5.1 of [HTTP]).
ターゲットが処理できないリクエストは、4xx（クライアントエラー）の応答となります。ターゲットとクライアントのキーが一致しない場合、認証エラーとなります（HTTPステータスコード401）。それ以外の場合、クライアントのリクエストが無効な場合、例えば復号化失敗、間違ったメッセージタイプ、または逆シリアル化失敗の場合、これは不正なリクエストとなります（HTTPステータスコード400）。
Even in the 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 identical to how DoH [RFC8484] handles HTTP response codes.
DNSの応答がSERVFAILやNXDOMAINなどの失敗を示している場合でも、DNSの応答が有効である限り、2xxステータスコードを持つ成功したHTTP応答が使用されます。これは、DoH[RFC8484]がHTTP応答コードを処理する方法と同じです。
The following example shows a 2xx (Successful) response that can be sent from a Target to a Client via a Proxy.
次の例は、プロキシを介してターゲットからクライアントに送信される、2xx（成功）のレスポンスを示しています。
:status = 200
content-type = application/oblivious-dns-message
content-length = 154
<Bytes containing an encrypted Oblivious DNS response>
Proxies forward requests and responses between Clients and Targets as specified in Section 4.1. Metadata sent with these messages could 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 11.3 for related discussion about Client authentication information.
プロキシは、セクション4.1で指定されたように、クライアントとターゲット間のリクエストとレスポンスを転送します。これらのメッセージと共に送信されるメタデータは、Oblivious DoHのプライバシー特性を誤って弱めたり削除したりする可能性があります。プロキシは、"Forwarded" HTTPヘッダー[RFC7239]など、クライアントを識別する情報をターゲットに送信してはなりません。さらに、クライアントは、HTTPクッキーなどのプライベートな状態をプロキシにリクエストする際に含めてはなりません。クライアントの認証情報に関する議論については、セクション11.3を参照してください。
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 discovering this configuration is out of scope for this document.
ターゲットにメッセージを送信するために、クライアントはクエリを暗号化するために使用する公開鍵を知る必要があります。この構成を発見するメカニズムは、この文書の範囲外です。
Servers ought to 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 time frame of possible compromise.
サーバーは定期的に公開鍵をローテーションするべきです。サーバーが鍵を毎日ローテーションすることが推奨されています。短いローテーションウィンドウは、公開鍵を使用する可能性のあるクライアントの匿名性セットを減少させますが、長いローテーションウィンドウは可能な妥協の時間枠を広げます。
An Oblivious DNS public key configuration is a structure encoded, using TLS-style encoding [RFC8446], as follows:
Oblivious DNS公開鍵構成は、TLSスタイルのエンコーディング[RFC8446]を使用してエンコードされた構造です。
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.
ObliviousDoHConfigs構造体には、好みの順に1つ以上のObliviousDoHConfig構造体が含まれています。これにより、サーバーは複数のOblivious DoHのバージョンと複数のOblivious DoHパラメータのセットをサポートできます。
An ObliviousDoHConfig structure contains a versioned representation of an Oblivious DoH configuration, with the following fields.
An ObliviousDoHConfig構造体には、Oblivious DoH構成のバージョン付き表現が含まれており、次のフィールドがあります。
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.
この構成が使用されるOblivious DoHのバージョン。クライアントは、サポートしていないバージョンのObliviousDoHConfig構造を無視する必要があります。この文書で指定されているOblivious DoHのバージョンは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.
バージョンに依存する内容を持つ不透明なバイト文字列。この仕様では、その内容はObliviousDoHConfigContents構造体です。
An ObliviousDoHConfigContents structure 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 Section 7 of [HPKE]. The fields in this structure are as follows:
An ObliviousDoHConfigContents structure 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 Section 7 of [HPKE]. The fields in this structure are as follows:
kem_id:
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.
クライアントは、サポートしていないKEMを使用しているキーを持つObliviousDoHConfig構造を無視しなければなりません。
kdf_id:
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.
public_keyに対応するHPKE鍵導出関数（KDF）識別子。クライアントは、サポートしていないKDFを使用するキーを持つObliviousDoHConfig構造を無視する必要があります。
aead_id:
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に対応するHPKE認証付き暗号化と関連データ（AEAD）識別子。クライアントは、サポートしていないAEADを使用するキーを持つObliviousDoHConfig構造を無視する必要があります。
public_key:
公開鍵:
The HPKE public key used by the Client to encrypt Oblivious DoH queries.
クライアントが使用するHPKE公開鍵は、Oblivious DoHクエリを暗号化するために使用されます。
This section includes encoding and wire format details for Oblivious DoH, as well as routines for encrypting and decrypting encoded values.
このセクションには、Oblivious DoHのエンコーディングとワイヤーフォーマットの詳細、およびエンコードされた値を暗号化および復号化するための手順が含まれています。
There are two types of Oblivious DoH messages: Queries (0x01) and Responses (0x02). Both messages carry the following information:
Oblivious DoHメッセージには、クエリ（0x01）とレスポンス（0x02）の2種類があります。両方のメッセージには、以下の情報が含まれています。
1. A DNS message, which is either a Query or Response, depending on context.
1. コンテキストによって、クエリまたはレスポンスであるDNSメッセージ。
2. Padding of arbitrary length, which MUST contain all zeros.
2. 任意の長さのパディングで、すべてのゼロを含む必要があります。
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.
QueryとResponseメッセージの両方がObliviousDoHMessagePlaintext形式を使用します。
ObliviousDoHMessagePlaintext ObliviousDoHQuery;
ObliviousDoHMessagePlaintext ObliviousDoHResponse;
An encrypted ObliviousDoHMessagePlaintext parameter is carried in an ObliviousDoHMessage message, encoded as follows:
ObliviousDoHMessageメッセージには、暗号化されたObliviousDoHMessagePlaintextパラメータが次のようにエンコードされて含まれています。
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:
The ObliviousDoHMessage構造体には、次のフィールドが含まれています。
message_type:
message_type:
A one-byte identifier for the type of message. Query messages use message_type 0x01, and Response messages use message_type 0x02.
メッセージの種類を示す1バイトの識別子。クエリメッセージはmessage_type 0x01を使用し、レスポンスメッセージはmessage_type 0x02を使用します。
key_id:
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.
対応するObliviousDoHConfigContentsキーの識別子。これは、configがObliviousDoHConfigContents構造体であり、Extract、Expand、およびNhがconfig.kdf_idに対応するHPKE暗号スイートKDFで指定されている場合に、Expand(Extract("", config), "odoh key id", Nh)として計算されます。
encrypted_message:
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.)
暗号化されたメッセージは、無自覚なターゲット（クエリメッセージの場合）またはクライアント（レスポンスメッセージの場合）向けです。実装は、このフィールドのサイズに制限を課すことができます。 (たとえば、DNSクエリは実際には2^16-1のサイズ制限に達しません。)
The contents of ObliviousDoHMessage.encrypted_message depend on ObliviousDoHMessage.message_type. In particular, ObliviousDoHMessage.encrypted_message is an encryption of an ObliviousDoHQuery message if the message is a Query and an encryption of ObliviousDoHResponse if the message is a Response.
ObliviousDoHMessage.encrypted_messageの内容は、ObliviousDoHMessage.message_typeに依存します。特に、ObliviousDoHMessage.encrypted_messageは、メッセージがQueryの場合はObliviousDoHQueryメッセージの暗号化であり、メッセージがResponseの場合はObliviousDoHResponseの暗号化です。
Clients use the following utility functions for encrypting a Query and decrypting a Response as described in Section 7.
クライアントは、セクション7で説明されているように、クエリの暗号化とレスポンスの復号化に以下のユーティリティ関数を使用します。
* encrypt_query_body: Encrypt an Oblivious DoH query.
* encrypt_query_body: 情報を暗号化する。
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.
* decrypt_response_body: 忘却 DoH レスポンスを復号化します。
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
The derive_secrets function is described below.
derive_secrets 関数は以下のように記述されています。
Targets use the following utility functions in processing queries and producing responses as described in Section 8.
ターゲットは、セクション8で説明されているように、クエリの処理と応答の生成に次のユーティリティ関数を使用します。
* setup_query_context: Set up an HPKE context used for decrypting an Oblivious DoH query.
* setup_query_context: Oblivious DoH クエリを復号化するために使用される HPKE コンテキストを設定します。
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.
* decrypt_query_body: 意識のない DoH クエリを復号化します。
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.
* derive_secrets: Oblivious DoH レスポンスを暗号化するために使用される鍵生成素材を導出します。
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
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.
random(N) 関数は、エントロピーの良いソースから N 個の暗号的に安全なランダムバイトを返します [RFC4086]。max(A, B) 関数は、A > B の場合は A を返し、それ以外の場合は B を返します。
* encrypt_response_body: Encrypt an Oblivious DoH response.
* encrypt_response_body: 意識のない DoH レスポンスを暗号化します。
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
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:
MをDNSメッセージ（クエリ）とし、クライアントがOblivious DoHで保護したいとする。ObliviousDoHConfigContents構成を持つOblivious TargetにMを解決するためのOblivious DoHクエリを送信する際、クライアントは以下の手順を実行する。
1. Creates an ObliviousDoHQuery structure, carrying the message M and padding, to produce Q_plain.
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.
2. config.public_keyをデシリアライズして、public key pkR（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.
3. Q_encrypted = encrypt_query_body(pkR、key_id、Q_plain)として暗号化メッセージを計算します。ここで、key_idはセクション6で計算されたものです。また、len(key_id)はkey_idの長さを2バイトの符号なし整数として出力します。
4. Outputs an ObliviousDoHMessage message Q, where Q.message_type = 0x01, Q.key_id carries key_id, and Q.encrypted_message = Q_encrypted.
4. Q.message_type = 0x01、Q.key_id が key_id を運び、Q.encrypted_message = Q_encrypted を持つ ObliviousDoHMessage メッセージ Q を出力します。
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.
クライアントは、セクション4.1に従ってプロキシにQを送信します。クライアントが応答Rを受信すると、セクション8で指定されたように暗号化されたRを復号化するためにdecrypt_response_bodyを使用します（R.key_idをnonceとして使用）。クライアントは、R_plain.dns_messageを使用する前に、R_plain.padding（すべてゼロ）を検証する必要があります。
Targets that receive a Query message Q decrypt and process it as follows:
QueryメッセージQを受信するターゲットは、それを復号化して処理します。
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.
1. Q.key_idに基づいてObliviousDoHConfigContents情報を調べてください。そのようなキーが存在しない場合、ターゲットはクエリを破棄してもよく、その場合はプロキシに401（認証が必要）の応答を返さなければなりません。それ以外の場合は、この公開鍵に対応する秘密鍵、または試験的な復号化のために選択された秘密鍵skRを使用してください。
2. Compute context = setup_query_context(skR, Q.key_id, Q.encrypted_message).
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).
3. 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.
4. エラーが返されず、Q_plain.padding が有効（すべてゼロ）である場合、必要に応じて Q_plain.dns_message を解決し、DNS メッセージ M を生成します。それ以外の場合、エラーが返されたかパディングが無効である場合は、プロキシに 400（クライアントエラー）の応答を返します。
5. Create an ObliviousDoHResponseBody structure, carrying the message M and padding, to produce R_plain.
5. ObliviousDoHResponseBody構造体を作成し、メッセージMとパディングを含めて、R_plainを生成します。
6. Create a fresh nonce resp_nonce = random(max(Nn, Nk)).
6. 新しいナンスを作成します。resp_nonce = random(max(Nn, Nk))。
7. Compute aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce).
7. 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.
8. R_encrypted = encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce)を計算します。暗号化に使用されるkey_idフィールドは、クライアントが同じ秘密を導出するためにresp_nonceを持っています。また、Seal関数はHPKE AEADに関連付けられた関数です。
9. Output an ObliviousDoHMessage message R, where R.message_type = 0x02, R.key_id = resp_nonce, and R.encrypted_message = R_encrypted.
9. R.message_type = 0x02、R.key_id = resp_nonce、およびR.encrypted_message = R_encrypted である ObliviousDoHMessage メッセージ R を出力します。
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.
ターゲットは、プロキシに対して2xx（成功）の応答Rを送信します。プロキシは、メッセージRを変更せずにクライアントに転送し、クライアントの元のHTTPリクエストに対するHTTP応答として返します。エラーが発生した場合（2xx以外のステータスコード）、プロキシはターゲットのエラーをクライアントに転送します。
Oblivious DoH uses HPKE for public key encryption [HPKE]. In the absence of an application profile standard specifying otherwise, a compliant Oblivious DoH implementation MUST support the following HPKE cipher suite:
Oblivious DoHは公開鍵暗号化のためにHPKEを使用します。それ以外の場合、準拠するOblivious DoHの実装は、次のHPKE暗号スイートをサポートする必要があります。
KEM:
KEM:
DHKEM(X25519, HKDF-SHA256) (see [HPKE], Section 7.1)
DHKEM（X25519、HKDF-SHA256）（[HPKE]、セクション7.1を参照）
KDF:
KDF:
HKDF-SHA256 (see [HPKE], Section 7.2)
HKDF-SHA256（[HPKE]、セクション7.2を参照）
AEAD:
AEAD:
AES-128-GCM (see [HPKE], Section 7.3)
AES-128-GCM（[HPKE]、セクション7.3を参照）
This document describes an experimental protocol built on DoH. The purpose of this experiment is to assess deployment configuration viability and related performance impacts on DNS resolution by measuring key performance indicators such as resolution latency. Experiment participants will test various parameters affecting service operation and performance, including mechanisms for discovery and configuration of DoH Proxies and Targets, as well as performance implications of connection reuse and pools where appropriate. The results of this experiment will be used to influence future protocol design and deployment efforts related to Oblivious DoH, such as Oblivious HTTP [OHTP]. Implementations of DoH that are not involved in the experiment 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.
この文書は、DoHをベースに構築された実験プロトコルについて説明しています。この実験の目的は、解決の遅延などの主要なパフォーマンス指標を測定することにより、展開構成の実行可能性と関連するパフォーマンスへの影響を評価することです。実験参加者は、DoHプロキシとターゲットの発見と構成に影響を与えるさまざまなパラメータをテストし、適切な場合には接続再利用とプールのパフォーマンスへの影響も検討します。この実験の結果は、Oblivious DoHに関連する将来のプロトコル設計と展開の取り組みに影響を与えるために使用されます。実験に関与していないDoHの実装は、このプロトコルを認識せず、実験に参加しません。Oblivious DoHの使用が広範囲になることが予想され、この実験が長期間にわたるものであると予想されています。
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, and one Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker [Dolev-Yao] that can observe all network activity and can adaptively compromise either P or T, but not C1 or C2. Note that compromising both 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 to arbitrarily many Clients, Proxies, and Targets, with the constraints that (1) not all Targets and Proxies are simultaneously compromised and (2) 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.)
Oblivious DoHは、真のクエリの起源とその内容の知識をクライアントのみに知らせることを目指しています。簡略化されたモデルとして、2つのクライアントC1とC2、1つのプロキシP、および1つのターゲットTが存在するケースを考えてください。Oblivious DoHは、すべてのネットワークアクティビティを観察し、PまたはTのいずれかを適応的に妥協させることができる拡張されたDolev-Yaoスタイルの攻撃者[Dolev-Yao]を想定していますが、C1またはC2を妥協させることはできません。PとTの両方を妥協させることは、実際にはこれら2つの当事者間の共謀に等しいことに注意してください。一旦妥協されると、攻撃者はすべてのセッション情報と秘密鍵素材にアクセスできます。（これは、任意の数のクライアント、プロキシ、およびターゲットに一般化され、（1）すべてのターゲットとプロキシが同時に妥協されるわけではなく、（2）少なくとも2つのクライアントが妥協されないようにする制約があります。）攻撃者は、IPアドレスなどのクライアントを識別する情報をターゲットに送信することを禁止されています。（これにより、攻撃者は簡単にクエリを対応するクライアントにリンクすることができます。）
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 observe the subsequent connection from a Client, learning its identity in the process. Such attacks are out of scope for this model.)
このモデルでは、C1とC2はそれぞれOblivious DoHクエリQ1とQ2をPを介してTに送信し、Tは回答A1とA2を提供します。 攻撃者は、C1を(Q1、A1)およびC2を(Q2、A2)にリンクさせることを目指しています。 攻撃者は、追加の相互作用なしにこのリンクを可能にすることができれば成功です。（たとえば、Tが侵害されている場合、それは制御するエンティティに対応するDNS回答を返し、その後の接続を観察してクライアントのアイデンティティを学習することができます。 このような攻撃は、このモデルの対象外です。）
Oblivious DoH security prevents such linkability. Informally, this means:
Oblivious DoHセキュリティにより、そのようなリンク可能性が防がれます。非公式には、これは次のような意味です：
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.
1. クエリと回答は、対応する応答キーとHPKEキー材料を所持しているクライアントとターゲットのみが知っています。特に、プロキシは無知なクエリの発信元と宛先を知っていますが、平文クエリは知りません。同様に、ターゲットは無知なクエリの発信元であるプロキシと平文クエリのみを知っています。平文クエリの内容と宛先を知っているのはクライアントだけです。
2. Target resolvers cannot link queries from the same Client in the absence of unique per-Client keys.
2. ターゲットリゾルバーは、クライアントごとの一意のキーがない場合、同じクライアントからのクエリをリンクすることができません。
Traffic analysis mitigations are outside the scope of this document. In particular, this document does not prescribe padding lengths for ObliviousDoHQuery and ObliviousDoHResponse messages. Implementations SHOULD follow the guidance in [RFC8467] for choosing padding length.
このドキュメントの範囲外にあるトラフィック解析の緩和策。特に、このドキュメントでは、ObliviousDoHQueryおよびObliviousDoHResponseメッセージのパディング長を指定していません。実装は、パディング長を選択する際に[RFC8467]のガイダンスに従うべきです。
Oblivious DoH security does not depend on Proxy and Target indistinguishability. Specifically, an on-path attacker could determine whether a connection to a specific endpoint is used for oblivious or direct DoH queries. However, this has no effect on the confidentiality goals listed above.
Oblivious DoHのセキュリティは、プロキシとターゲットの区別に依存しません。具体的には、経路上の攻撃者は特定のエンドポイントへの接続が忘却的または直接のDoHクエリに使用されているかを判断できます。ただし、これは上記の機密性の目標に影響を与えません。
Malicious Clients (or Proxies) can send bogus Oblivious DoH queries to Targets as a Denial-of-Service (DoS) attack. Target servers can 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 can throttle specific Clients in response to these errors. In general, however, Targets trust Proxies to not overwhelm the Target, and it is expected that Proxies implement either some form of rate limiting or client authentication to limit abuse; see Section 11.3.
悪意のあるクライアント（またはプロキシ）は、ターゲットに対して偽のOblivious DoHクエリを送信して、サービス拒否（DoS）攻撃を行うことができます。ターゲットサーバーは、そのような事態が発生した場合、処理リクエストを制限することができます。さらに、ターゲットは復号化失敗時に明示的なエラーを提供するため、つまり、暗号文の復号化に失敗した場合や平文のDNSメッセージが不正な場合、プロキシはこれらのエラーに応じて特定のクライアントの処理を制限することができます。ただし、一般的には、ターゲットはプロキシがターゲットを圧倒しないことを信頼しており、プロキシが乱用を制限するためにいくつかの形式のレート制限またはクライアント認証を実装することが期待されています。詳細は11.3節を参照してください。
Malicious Targets or Proxies can 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 noted above, malicious Targets and Proxies are out of scope for the threat model.
悪意のあるターゲットやプロキシは、Oblivious DoHクエリに対する虚偽の回答を送信する可能性があります。応答の復号に失敗した場合、プロキシまたはターゲットのいずれかが不正行為をしている可能性があります。クライアントは、そのような失敗が発生した場合、これらのサーバーのいずれかまたは両方の使用を停止することを選択できます。ただし、前述のように、悪意のあるターゲットやプロキシは脅威モデルの対象外です。
Proxies are free to enforce any forwarding policy they desire for Clients. For example, they can choose to only forward requests to known or otherwise trusted Targets.
プロキシはクライアントに対して望む転送ポリシーを自由に強制することができます。例えば、彼らは既知または信頼できるターゲットにのみリクエストを転送することを選択することができます。
Proxies that do not reuse connections to Targets for many Clients may allow Targets to link individual queries to unknown Targets. To mitigate this linkability vector, it is RECOMMENDED that Proxies pool and reuse connections to Targets. Note that this benefits performance as well as privacy, since queries do not incur any delay that might otherwise result from Proxy-to-Target connection establishment.
クライアントに対して接続を再利用しないプロキシは、ターゲットが個々のクエリを未知のターゲットにリンクさせる可能性があります。このリンク可能性ベクトルを軽減するために、プロキシがターゲットへの接続をプールして再利用することが推奨されています。クエリがプロキシからターゲットへの接続確立から生じるかもしれない遅延を引き起こさないため、これはパフォーマンスだけでなくプライバシーにも利益があります。
Depending on the deployment scenario, Proxies and Targets might 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 ought to 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 response codes due to Client key mismatch; see Section 4.3.
ターゲットが使用する前に、プロキシがHTTPまたはアプリケーションレイヤーで認証を必要とする場合は、クライアントのクエリをターゲットに転送しようとする前に行う必要があります。これにより、プロキシが認証の失敗による401（権限なし）応答コードと、クライアントキーの不一致による401応答コードを区別できるようになります。セクション4.3を参照してください。
This document makes changes to the "Media Types" registry. The changes are described in the following subsection.
この文書は「メディアタイプ」レジストリに変更を加えます。変更内容は次のサブセクションで説明されています。
This document registers a new media type, "application/oblivious-dns-message".
このドキュメントは、新しいメディアタイプ「application/oblivious-dns-message」を登録します。
Type name:
入力をそのまま出力します。
application
アプリケーション
Subtype name:
サブタイプ名:
oblivious-dns-message
oblivious-dns-message
Required parameters:
必須パラメータ:
N/A
N/A
Optional parameters:
オプションパラメータ:
N/A
N/A
Encoding considerations:
エンコーディングに関する考慮事項:
This is a binary format, containing encrypted DNS requests and responses encoded as ObliviousDoHMessage values, as defined in Section 6.1.
これは、セクション6.1で定義されたObliviousDoHMessage値としてエンコードされた暗号化されたDNSリクエストとレスポンスを含むバイナリ形式です。
Security considerations:
セキュリティに関する考慮事項:
See this document. The content is an encrypted DNS message, and not executable code.
このドキュメントを見てください。内容は暗号化されたDNSメッセージであり、実行可能なコードではありません。
Interoperability considerations:
相互運用性に関する考慮事項:
This document specifies the format of conforming messages and the interpretation thereof; see Section 6.1.
この文書は、適合メッセージの形式とその解釈を指定しています。セクション6.1を参照してください。
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.
このメディアタイプは、DNS over HTTPSを使用する際にDNSクエリを隠したいクライアントが使用することを意図しています。
Additional information:
追加情報:
N/A
N/A
Person and email address to contact for further information:
さらなる情報を得るための担当者とメールアドレス：
See the Authors' Addresses section.
著者の住所欄をご覧ください。
Intended usage:
使用目的:
COMMON
共通
Restrictions on usage:
使用制限:
N/A
N/A
Author:
著者:
Tommy Pauly (tpauly@apple.com)
Tommy Pauly（tpauly@apple.com）
Change controller:
コントローラーを変更します。
IETF
IETF
Provisional registration? (standards tree only):
仮登録？（標準ツリーのみ）:
No
No
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/info/rfc9180>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/info/rfc6570>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms
for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467,
October 2018, <https://www.rfc-editor.org/info/rfc8467>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[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>.
[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,
"Oblivious DNS - Strong Privacy for DNS Queries", Work in
Progress, Internet-Draft, draft-annee-dprive-oblivious-
dns-00, 2 July 2018,
<https://datatracker.ietf.org/doc/html/draft-annee-dprive-
oblivious-dns-00>.
[OHTP] Thomson, M. and C.A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-01, 15
February 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-ohai-ohttp-01>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/info/rfc7239>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.
Using DoH over anonymizing proxy services such as Tor can also achieve the desired goal of separating query origins from their contents. However, there are several reasons why such systems are undesirable as contrasted with Oblivious DoH:
DoHを匿名化プロキシサービス（Torなど）を介して使用することで、クエリの発信元と内容を分離するという目的も達成できます。ただし、そのようなシステムがOblivious DoHと比較して望ましくない理由がいくつかあります。
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.
1. Torは一般的な接続レベルの匿名システムであり、個々のDNSクエリをプロキシするために高い遅延コストとプロトコルの複雑さを負担します。一方、Oblivious DoHはDoH上に構築された軽量なプロトコルであり、アプリケーションレイヤープロキシとして実装され、プライバシーを強化する必要があるユーザーにデフォルトモードとして有効にできます。
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.
2. Oblivious DoHは、1ホッププロキシとして、クライアントのクエリ相関を軽減するために接続のないプロキシを奨励します。一方、Torのようなマルチホップシステムは、エンドツーエンドで安全な接続（TLS）を頻繁に実行するため、DoHサーバーは同じ接続上でクエリを追跡できます。クエリごとに新しいDoH接続を使用すると、接続設定時間に無視できないペナルティが発生します。
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.
この作品はOblivious DNS [OBLIVIOUS-DNS] に触発されています。その文書のすべての著者に感謝します。Nafeez Ahamed、Elliot Briggs、Marwan Fayed、Jonathan Hoyland、Frederic Jacobs、Tommy Jensen、Erik Nygren、Paul Schmitt、Brian Swander、Peter Wu には、フィードバックと入力に感謝します。
Eric Kinnear
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: ekinnear@apple.com
Patrick McManus
Fastly
Email: mcmanus@ducksong.com
Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: tpauly@apple.com
Tanya Verma
Cloudflare
101 Townsend St
San Francisco, California 94107
United States of America
Email: vermatanyax@gmail.com
Christopher A. Wood
Cloudflare
101 Townsend St
San Francisco, California 94107
United States of America
Email: caw@heapingbits.net