[要約] RFC 9458 は、暗号化されたHTTPメッセージを転送するためのプロトコルであり、クライアントが複数のリクエストをオリジンサーバーに送信する際に、サーバーがそれらのリクエストをクライアントにリンクしたり同一クライアントからのものと特定したりできないようにすることを目的としています。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 9458 Mozilla
Category: Standards Track C. A. Wood
ISSN: 2070-1721 Cloudflare
January 2024
This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages.
このドキュメントは、暗号化されたHTTPメッセージを転送するためのプロトコルであるOblivious HTTPについて説明しています。Oblivious HTTPは、クライアントがオリジンサーバーに複数のリクエストを行うことを可能にし、そのサーバーがそれらのリクエストをクライアントにリンクしたり、同じクライアントから来たリクエストとして識別したりすることができないようにします。メッセージを転送するノードに対しては限られた信頼しか置かれません。
This is an Internet Standards Track document.
これはインターネット標準トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はInternet Engineering Task Force（IETF）の製品です。IETFコミュニティの合意を表しています。公開レビューを受け、Internet Engineering Steering Group（IESG）によって出版が承認されました。Internet Standardsに関する詳細情報は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/rfc9458.
この文書の現在の状況、誤植、フィードバック方法に関する情報は、https://www.rfc-editor.org/info/rfc9458 で入手できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なBCP 78およびIETF文書に関連するIETF Trustの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらの文書を注意深く確認してください。これらは、この文書に関するあなたの権利と制限を説明しています。この文書から抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているように、Revised BSDライセンスのテキストを含める必要があり、Revised BSDライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Overview
2.1. Applicability
2.2. Conventions and Definitions
3. Key Configuration
3.1. Key Configuration Encoding
3.2. Key Configuration Media Type
4. HPKE Encapsulation
4.1. Request Format
4.2. Response Format
4.3. Encapsulation of Requests
4.4. Encapsulation of Responses
4.5. Request and Response Media Types
4.6. Repurposing the Encapsulation Format
5. HTTP Usage
5.1. Informational Responses
5.2. Errors
5.3. Signaling Key Configuration Problems
6. Security Considerations
6.1. Client Responsibilities
6.2. Relay Responsibilities
6.2.1. Differential Treatment
6.2.2. Denial of Service
6.2.3. Traffic Analysis
6.3. Server Responsibilities
6.4. Key Management
6.5. Replay Attacks
6.5.1. Use of Date for Anti-replay
6.5.2. Correcting Clock Differences
6.6. Forward Secrecy
6.7. Post-Compromise Security
6.8. Client Clock Exposure
6.9. Media Type Security
6.10. Separate Gateway and Target
7. Privacy Considerations
8. Operational and Deployment Considerations
8.1. Performance Overhead
8.2. Resource Mappings
8.3. Network Management
9. IANA Considerations
9.1. application/ohttp-keys Media Type
9.2. message/ohttp-req Media Type
9.3. message/ohttp-res Media Type
9.4. Registration of "date" Problem Type
9.5. Registration of "ohttp-key" Problem Type
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Complete Example of a Request and Response
Acknowledgments
Authors' Addresses
HTTP requests reveal information about client identities to servers. While the actual content of the request message is under the control of the client, other information that is more difficult to control can still be used to identify the client.
HTTPリクエストは、クライアントのアイデンティティに関する情報をサーバーに明らかにします。リクエストメッセージの実際の内容はクライアントの制御下にありますが、クライアントを特定するのに使用される他の情報は、より制御が難しいものでもあります。
Even where an IP address is not directly associated with an individual, the requests made from it can be correlated over time to assemble a profile of client behavior. In particular, connection reuse improves performance but provides servers with the ability to link requests that share a connection.
IPアドレスが直接個人に関連付けられていない場合でも、それからのリクエストは時間の経過とともに相関関係を持たせ、クライアントの行動のプロファイルを組み立てることができます。特に、接続の再利用はパフォーマンスを向上させますが、サーバーには接続を共有するリクエストをリンクする能力を提供します。
In particular, the source IP address of the underlying connection reveals identifying information that the client has only limited control over. While client-configured HTTP proxies can provide a degree of protection against IP address tracking, they present an unfortunate trade-off: if they are used without TLS, the contents of communication are revealed to the proxy; if they are used with TLS, a new connection needs to be used for each request to ensure that the origin server cannot use the connection as a way to correlate requests, incurring significant performance overheads.
特に、基礎となる接続のソースIPアドレスは、クライアントが制御できる情報を限定的に明らかにします。クライアントが設定したHTTPプロキシを使用すると、IPアドレスの追跡に対する一定の保護を提供できますが、不運なトレードオフが発生します。TLSなしで使用すると、通信内容がプロキシに公開されます。TLSを使用すると、リクエストごとに新しい接続を使用する必要があり、オリジンサーバーがリクエストを関連付ける手段として接続を使用できないようにするために、大幅なパフォーマンスオーバーヘッドが発生します。
To overcome these limitations, this document defines Oblivious HTTP, a protocol for encrypting and sending HTTP messages from a client to a gateway. This uses a trusted relay service in a manner that mitigates the use of metadata such as IP address and connection information for client identification, with reasonable performance characteristics. This document describes:
これらの制限を克服するために、この文書では、クライアントからゲートウェイにHTTPメッセージを暗号化して送信するためのプロトコルであるOblivious HTTPを定義します。これは、IPアドレスや接続情報などのメタデータの使用を軽減し、合理的なパフォーマンス特性を持つ信頼できるリレーサービスを使用します。この文書では、以下の内容が記載されています。
1. an algorithm for encapsulating binary HTTP messages [BINARY] using Hybrid Public Key Encryption (HPKE) [HPKE] to protect their contents,
1. バイナリHTTPメッセージを保護するためにHybrid Public Key Encryption（HPKE）を使用するアルゴリズム
2. a method for forwarding Encapsulated Requests between Clients and an Oblivious Gateway Resource through a trusted Oblivious Relay Resource using HTTP, and
2. クライアントと無関心なゲートウェイリソースの間でカプセル化されたリクエストを転送するための方法を、信頼された無関心なリレーリソースを介してHTTPを使用しています。
3. requirements for how the Oblivious Gateway Resource handles Encapsulated Requests and produces Encapsulated Responses for the Client.
3. クライアント向けにカプセル化されたリクエストを処理し、カプセル化されたレスポンスを生成する方法に関する Oblivious Gateway リソースの要件。
The combination of encapsulation and relaying ensures that Oblivious Gateway Resource never sees the Client's IP address and that the Oblivious Relay Resource never sees plaintext HTTP message content.
カプセル化と中継の組み合わせにより、Oblivious Gateway ResourceはクライアントのIPアドレスを見ることがなく、Oblivious Relay Resourceは平文のHTTPメッセージの内容を見ることがありません。
Oblivious HTTP allows connection reuse between the Client and Oblivious Relay Resource, as well as between that relay and the Oblivious Gateway Resource, so this scheme represents a performance improvement over using just one request in each connection. With limited trust placed in the Oblivious Relay Resource (see Section 6), Clients are assured that requests are not uniquely attributed to them or linked to other requests.
Oblivious HTTPは、クライアントとOblivious Relay Resourceの間、およびそのリレーとOblivious Gateway Resourceの間で接続の再利用を可能にし、このスキームは1つの接続ごとに1つのリクエストを使用するよりもパフォーマンスが向上します。Oblivious Relay Resourceに対する信頼が限られているため（セクション6を参照）、クライアントはリクエストが自分に固有に帰属されたり他のリクエストと関連付けられたりしないことを保証されます。
An Oblivious HTTP Client must initially know the following:
An Oblivious HTTP Client must initially know the following:
* The identity of an Oblivious Gateway Resource. This might include some information about what Target Resources the Oblivious Gateway Resource supports.
* Oblivious Gateway Resourceの識別情報。これには、Oblivious Gateway ResourceがサポートするTarget Resourcesに関する情報が含まれる場合があります。
* The details of an HPKE public key for the Oblivious Gateway Resource, including an identifier for that key and the HPKE algorithms that are used with that key.
* Oblivious Gateway Resource用のHPKE公開鍵の詳細、その鍵の識別子、およびその鍵で使用されるHPKEアルゴリズム。
* The identity of an Oblivious Relay Resource that will accept relay requests carrying an Encapsulated Request as its content and forward the content in these requests to a particular Oblivious Gateway Resource. Oblivious HTTP uses a one-to-one mapping between Oblivious Relay and Gateway Resources; see Section 8.2 for more details.
* Oblivious Relay Resourceというアイデンティティは、そのコンテンツとしてEncapsulated Requestを持つリレーリクエストを受け入れ、これらのリクエストのコンテンツを特定のOblivious Gateway Resourceに転送します。Oblivious HTTPは、Oblivious RelayとGateway Resourceの間で一対一のマッピングを使用します。詳細については、セクション8.2を参照してください。
This information allows the Client to send HTTP requests to the Oblivious Gateway Resource for forwarding to a Target Resource. The Oblivious Gateway Resource does not learn the Client's IP address or any other identifying information that might be revealed from the Client at the transport layer, nor does the Oblivious Gateway Resource learn which of the requests it receives are from the same Client.
この情報により、クライアントはHTTPリクエストを忘却ゲートウェイリソースに送信し、ターゲットリソースに転送することができます。忘却ゲートウェイリソースは、クライアントのIPアドレスやその他の識別情報を学習しません。また、忘却ゲートウェイリソースは、受信したリクエストのうちどれが同じクライアントからのものかも学習しません。
.------------------------------.
+---------+ +----------+ | +----------+ +----------+ |
| Client | | Relay | | | Gateway | | Target | |
| | | Resource | | | Resource | | Resource | |
+----+----+ +----+-----+ | +-----+----+ +----+-----+ |
| | `-------|--------------|-------'
| Relay | | |
| Request | | |
| [+ Encapsulated | | |
| Request ] | | |
+---------------->| Gateway | |
| | Request | |
| | [+ Encapsulated | |
| | Request ] | |
| +------------------->| Request |
| | +------------->|
| | | |
| | | Response |
| | Gateway |<-------------+
| | Response | |
| | [+ Encapsulated | |
| | Response ] | |
| Relay |<-------------------+ |
| Response | | |
| [+ Encapsulated | | |
| Response ] | | |
|<----------------+ | |
| | | |
Figure 1: Overview of Oblivious HTTP
図1：Oblivious HTTPの概要
In order to forward a request for a Target Resource to the Oblivious Gateway Resource, the following steps occur, as shown in Figure 1:
ターゲットリソースへのリクエストを忘却ゲートウェイリソースに転送するためには、図1に示すように、以下の手順が発生します。
1. The Client constructs an HTTP request for a Target Resource.
1. クライアントはターゲットリソース向けのHTTPリクエストを構築します。
2. The Client encodes the HTTP request in a binary HTTP message and then encapsulates that message using HPKE and the process from Section 4.3.
2. クライアントは、HTTPリクエストをバイナリHTTPメッセージにエンコードし、そのメッセージをHPKEとセクション4.3のプロセスを使用してカプセル化します。
3. The Client sends a POST request to the Oblivious Relay Resource with the Encapsulated Request as the content of that message.
3. クライアントは、忘却リレーリソースに対して、そのメッセージの内容としてカプセル化されたリクエストを含むPOSTリクエストを送信します。
4. The Oblivious Relay Resource forwards this request to the Oblivious Gateway Resource.
4. The Oblivious Relay Resource forwards this request to the Oblivious Gateway Resource.
5. The Oblivious Gateway Resource receives this request and removes the HPKE protection to obtain an HTTP request.
5. The Oblivious Gateway Resourceはこのリクエストを受け取り、HPKE保護を解除してHTTPリクエストを取得します。
The Oblivious Gateway Resource then handles the HTTP request. This typically involves making an HTTP request using the content of the Encapsulated Request. Once the Oblivious Gateway Resource has an HTTP response for this request, the following steps occur to return this response to the Client:
忘却ゲートウェイリソースは、その後、HTTPリクエストを処理します。通常、カプセル化されたリクエストの内容を使用してHTTPリクエストを行います。忘却ゲートウェイリソースがこのリクエストに対するHTTPレスポンスを持っているとき、次の手順がクライアントにこのレスポンスを返すために発生します。
1. The Oblivious Gateway Resource encapsulates the HTTP response following the process in Section 4.4 and sends this in response to the request from the Oblivious Relay Resource.
1. Oblivious Gateway Resourceは、セクション4.4のプロセスに続くHTTPレスポンスをカプセル化し、Oblivious Relay Resourceからのリクエストに応答として送信します。
2. The Oblivious Relay Resource forwards this response to the Client.
2. The Oblivious Relay Resourceはこの応答をクライアントに転送します。
3. The Client removes the encapsulation to obtain the response to the original request.
3. クライアントはカプセル化を解除して、元のリクエストに対する応答を取得します。
This interaction provides authentication and confidentiality protection between the Client and the Oblivious Gateway, but importantly not between the Client and the Target Resource. While the Target Resource is a distinct HTTP resource from the Oblivious Gateway Resource, they are both logically under the control of the Oblivious Gateway, since the Oblivious Gateway Resource can unilaterally dictate the responses returned from the Target Resource to the Client. This arrangement is shown in Figure 1.
このインタラクションは、クライアントと忘却ゲートウェイの間で認証と機密保護を提供しますが、重要なのはクライアントとターゲットリソースの間ではありません。 ターゲットリソースは忘却ゲートウェイリソースとは異なるHTTPリソースですが、忘却ゲートウェイの管理下にあると論理的に見なされます。なぜなら、忘却ゲートウェイリソースは、ターゲットリソースからクライアントに返される応答を一方的に指示できるからです。この配置は図1に示されています。
Oblivious HTTP has limited applicability. Importantly, it requires explicit support from a willing Oblivious Relay Resource and Oblivious Gateway Resource, thereby limiting the use of Oblivious HTTP for generic applications; see Section 6.3 for more information.
Oblivious HTTPは限られた適用範囲しか持ちません。重要なことは、Oblivious HTTPを一般的なアプリケーションに使用することを制限するために、協力的なOblivious Relay ResourceとOblivious Gateway Resourceからの明示的なサポートが必要です。詳細については、セクション6.3を参照してください。
Many uses of HTTP benefit from being able to carry state between requests, such as with cookies [COOKIES], authentication (Section 11 of [HTTP]), or even alternative services [RFC7838]. Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests.
HTTPの多くの用途は、クッキー[COOKIES]、認証([HTTP]のセクション11)、または別のサービス[RFC7838]など、リクエスト間で状態を保持できることから利益を得ています。忘却HTTPは、リクエスト間で状態を保持しないアプリケーションにのみ有用な、トランスポート層でのリンケージを除去します。
Oblivious HTTP is primarily useful where the privacy risks associated with possible stateful treatment of requests are sufficiently large that the cost of deploying this protocol can be justified. Oblivious HTTP is simpler and less costly than more robust systems, like Prio [PRIO] or Tor [DMS2004], which can provide stronger guarantees at higher operational costs.
Oblivious HTTPは、リクエストの状態に関連するプライバシーのリスクが十分に大きい場合に主に有用です。このプロトコルを展開するコストが正当化されるほどです。Oblivious HTTPは、Prio [PRIO]やTor [DMS2004]などのより堅牢なシステムよりもシンプルでコストが低く、運用コストが高いがより強力な保証を提供できます。
Oblivious HTTP is more costly than a direct connection to a server. Some costs, like those involved with connection setup, can be amortized, but there are several ways in which Oblivious HTTP is more expensive than a direct request:
Oblivious HTTPは、サーバーへの直接接続よりもコストが高くなります。接続設定に関連するコストなどは分割できますが、Oblivious HTTPが直接リクエストよりも高価であるいくつかの方法があります。
* Each request requires at least two regular HTTP requests, which could increase latency.
* 各リクエストには少なくとも2つの通常のHTTPリクエストが必要であり、これによりレイテンシが増加する可能性があります。
* Each request is expanded in size with additional HTTP fields, encryption-related metadata, and Authenticated Encryption with Associated Data (AEAD) expansion.
* 各リクエストは、追加のHTTPフィールド、暗号化関連のメタデータ、および認証付き暗号化と関連データ（AEAD）の拡張とともにサイズが拡大します。
* Deriving cryptographic keys and applying them for request and response protection takes non-negligible computational resources.
* 暗号鍵を導出し、リクエストとレスポンスの保護に適用するには無視できない計算リソースが必要です。
Examples of where preventing the linking of requests might justify these costs include:
リクエストのリンクを防止することがこれらのコストを正当化する例は次のとおりです：
DNS queries:
DNS クエリ:
DNS queries made to a recursive resolver reveal information about the requester, particularly if linked to other queries.
再帰リゾルバに対して行われたDNSクエリは、特に他のクエリにリンクされている場合、リクエスターに関する情報を明らかにします。
Telemetry submission:
テレメトリーの提出:
Applications that submit reports about their usage to their developers might use Oblivious HTTP for some types of moderately sensitive data.
アプリケーションは、使用状況に関するレポートを開発者に提出する場合、一部の比較的機密性の高いデータに対してOblivious HTTPを使用するかもしれません。
These are examples of requests where there is information in a request that -- if it were connected to the identity of the user -- might allow a server to learn something about that user even if the identity of the user were pseudonymous. Other examples include submitting anonymous surveys, making search queries, or requesting location-specific content (such as retrieving tiles of a map display).
これらは、ユーザーの身元に関連付けられた情報が含まれているリクエストの例です。ユーザーの身元が擬似的であっても、サーバーがそのユーザーについて何かを学ぶことができる可能性があります。匿名のアンケートの提出、検索クエリの作成、または位置固有のコンテンツのリクエスト（地図表示のタイルの取得など）などの他の例もあります。
In addition to these limitations, Section 6 describes operational constraints that are necessary to realize the goals of the protocol.
これらの制約に加えて、セクション6では、プロトコルの目標を実現するために必要な運用上の制約が記載されています。
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 uses terminology from [HTTP] and defines several terms as follows:
この文書は、[HTTP] から用語を使用し、以下のようにいくつかの用語を定義します。
Client:
クライアント：
A Client originates Oblivious HTTP requests. A Client is also an HTTP client in two ways: for the Target Resource and for the Oblivious Relay Resource. However, when referring to the HTTP definition of client (Section 3.3 of [HTTP]), the term "HTTP client" is used; see Section 5.
クライアントは忘却HTTPリクエストを発信します。クライアントは、ターゲットリソースと忘却リレーリソースの両方に対してHTTPクライアントでもあります。ただし、HTTPのクライアントの定義（[HTTP]のセクション3.3）を参照すると、「HTTPクライアント」という用語が使用されます。セクション5を参照してください。
Encapsulated Request:
カプセル化されたリクエスト:
An HTTP request that is encapsulated in an HPKE-encrypted message; see Section 4.3.
HPKEで暗号化されたHTTPリクエストをカプセル化したメッセージ。セクション4.3を参照してください。
Encapsulated Response:
カプセル化された応答:
An HTTP response that is encapsulated in an HPKE-encrypted message; see Section 4.4.
HPKEで暗号化されたHTTPレスポンスを含むメッセージ。セクション4.4を参照してください。
Oblivious Relay Resource:
Oblivious Relay Resource:
An intermediary that forwards Encapsulated Requests and Responses between Clients and a single Oblivious Gateway Resource. In context, this can be referred to simply as a "relay".
クライアントと単一の忘却ゲートウェイリソース間でカプセル化されたリクエストとレスポンスを転送する中間者。文脈では、これを単に「リレー」と呼ぶことができます。
Oblivious Gateway Resource:
Oblivious Gateway Resource:
A resource that can receive an Encapsulated Request, extract the contents of that request, forward it to a Target Resource, receive a response, encapsulate that response, and then return the resulting Encapsulated Response. In context, this can be referred to simply as a "gateway".
Encapsulated Requestを受け取り、そのリクエストの内容を抽出し、Target Resourceに転送し、レスポンスを受け取り、そのレスポンスをカプセル化して、結果のEncapsulated Responseを返すリソース。文脈において、これは単純に「ゲートウェイ」と呼ばれることがあります。
Target Resource:
ターゲットリソース:
The resource that is the target of an Encapsulated Request. This resource logically handles only regular HTTP requests and responses, so it might be ignorant of the use of Oblivious HTTP to reach it.
Encapsulated Requestの対象となるリソース。このリソースは通常のHTTPリクエストとレスポンスのみを論理的に処理するため、それに到達するためにOblivious HTTPを使用することに無知かもしれません。
This document includes pseudocode that uses the functions and conventions defined in [HPKE].
この文書には、[HPKE] で定義された関数と規約を使用する疑似コードが含まれています。
Encoding an integer to a sequence of bytes in network byte order is described using the function encode(n, v), where n is the number of bytes and v is the integer value. ASCII [ASCII] encoding of a string s is indicated using the function encode_str(s).
整数をネットワークバイト順にバイトのシーケンスにエンコードする方法は、関数encode(n, v)を使用して説明されます。ここで、nはバイト数、vは整数値です。文字列sのASCII [ASCII]エンコーディングは、関数encode_str(s)を使用して示されます。
Formats are described using notation from Section 1.3 of [QUIC]. An extension to that notation expresses the number of bits in a field using a simple mathematical function.
フォーマットは、[QUIC]のセクション1.3の表記法を使用して説明されます。その表記法の拡張では、フィールド内のビット数を単純な数学関数を使って表現します。
A Client needs to acquire information about the key configuration of the Oblivious Gateway Resource in order to send Encapsulated Requests. In order to ensure that Clients do not encapsulate messages that other entities can intercept, the key configuration MUST be authenticated and have integrity protection.
クライアントは、忘却ゲートウェイリソースのキー構成に関する情報を取得する必要があります。これにより、カプセル化されたリクエストを送信できます。クライアントが他のエンティティが傍受できるメッセージをカプセル化しないようにするために、キー構成は認証され、整合性保護されている必要があります。
This document does not define how that acquisition occurs. However, in order to help facilitate interoperability, it does specify a format for the keys. This ensures that different Client implementations can be configured in the same way and also enables advertising key configurations in a consistent format. This format might be used, for example, with HTTPS, as part of a system for configuring or discovering key configurations. However, note that such a system needs to consider the potential for key configuration to be used to compromise Client privacy; see Section 7.
この文書は、その取得がどのように行われるかを定義していません。ただし、相互運用性を促進するために、キーの形式を指定しています。これにより、異なるクライアントの実装が同じ方法で構成されることが保証され、また広告キー構成を一貫した形式で可能にします。この形式は、たとえばHTTPSと共に使用され、キー構成を構成または発見するシステムの一部として使用されるかもしれません。ただし、このようなシステムは、クライアントのプライバシーを危険にさらす可能性を考慮する必要があります。セクション7を参照してください。
A Client might have multiple key configurations to select from when encapsulating a request. Clients are responsible for selecting a preferred key configuration from those it supports. Clients need to consider both the Key Encapsulation Method (KEM) and the combinations of the Key Derivation Function (KDF) and AEAD in this decision.
クライアントは、リクエストをカプセル化する際に選択肢として複数のキー構成を持つ可能性があります。クライアントは、サポートされている中から好ましいキー構成を選択する責任があります。クライアントは、この決定において、キーのカプセル化方法（KEM）とキー導出関数（KDF）およびAEADの組み合わせを考慮する必要があります。
A single key configuration consists of a key identifier, a public key, an identifier for the KEM that the public key uses, and a set of HPKE symmetric algorithms. Each symmetric algorithm consists of an identifier for a KDF and an identifier for an AEAD.
単一のキー構成は、キー識別子、公開鍵、公開鍵が使用するKEMの識別子、および一連のHPKE対称アルゴリズムで構成されます。各対称アルゴリズムには、KDFの識別子とAEADの識別子が含まれます。
Figure 2 shows a single key configuration.
図2は単一のキー構成を示しています。
HPKE Symmetric Algorithms {
HPKE KDF ID (16),
HPKE AEAD ID (16),
}
Key Config {
Key Identifier (8),
HPKE KEM ID (16),
HPKE Public Key (Npk * 8),
HPKE Symmetric Algorithms Length (16) = 4..65532,
HPKE Symmetric Algorithms (32) ...,
}
Figure 2: A Single Key Configuration
図2：単一キー構成
That is, a key configuration consists of the following fields:
それは、キー構成は次のフィールドで構成されています。
Key Identifier:
キー識別子:
An 8-bit value that identifies the key used by the Oblivious Gateway Resource.
Oblivious Gateway Resource が使用するキーを識別する 8 ビット値。
HPKE KEM ID:
HPKE KEM ID:
A 16-bit value that identifies the KEM used for the identified key as defined in Section 7.1 of [HPKE] or the "HPKE KEM Identifiers" registry <https://www.iana.org/assignments/hpke>.
[HPKE]のセクション7.1で定義されている識別されたキーに使用されるKEMを識別する16ビット値、または「HPKE KEM Identifiers」レジストリ<https://www.iana.org/assignments/hpke>。
HPKE Public Key:
HPKE 公開鍵:
The public key used by the gateway. The length of the public key is Npk, which is determined by the choice of HPKE KEM as defined in Section 4 of [HPKE].
ゲートウェイで使用される公開鍵。公開鍵の長さはNpkであり、これは[HPKE]のセクション4で定義されたHPKE KEMの選択によって決まります。
HPKE Symmetric Algorithms Length:
HPKE対称アルゴリズムの長さ:
A 16-bit integer in network byte order that encodes the length, in bytes, of the HPKE Symmetric Algorithms field that follows.
後続のHPKE対称アルゴリズムフィールドの長さをバイト単位でエンコードする、ネットワーク バイト オーダーの 16 ビット整数。
HPKE Symmetric Algorithms:
HPKE対称アルゴリズム:
One or more pairs of identifiers for the different combinations of HPKE KDF and AEAD that the Oblivious Gateway Resource supports:
Oblivious Gateway Resource がサポートする HPKE KDF と AEAD の異なる組み合わせの識別子の 1 つ以上:
HPKE KDF ID:
HPKE KDF ID:
A 16-bit HPKE KDF identifier as defined in Section 7.2 of [HPKE] or the "HPKE KDF Identifiers" registry <https://www.iana.org/assignments/hpke>.
[HPKE]のセクション7.2で定義されている16ビットのHPKE KDF識別子、または「HPKE KDF Identifiers」レジストリ <https://www.iana.org/assignments/hpke>。
HPKE AEAD ID:
HPKE AEAD ID:
A 16-bit HPKE AEAD identifier as defined in Section 7.3 of [HPKE] or the "HPKE AEAD Identifiers" registry <https://www.iana.org/assignments/hpke>.
[HPKE]のセクション7.3で定義されている16ビットのHPKE AEAD識別子、または「HPKE AEAD Identifiers」レジストリ <https://www.iana.org/assignments/hpke>。
The "application/ohttp-keys" format is a media type that identifies a serialized collection of key configurations. The content of this media type comprises one or more key configuration encodings (see Section 3.1). Each encoded configuration is prefixed with a 2-byte integer in network byte order that indicates the length of the key configuration in bytes. The length-prefixed encodings are concatenated to form a list. See Section 9.1 for a definition of the media type.
"application/ohttp-keys"形式は、キー構成のシリアル化されたコレクションを識別するメディアタイプです。このメディアタイプの内容は、1つ以上のキー構成エンコーディングで構成されています（セクション3.1を参照）。各エンコードされた構成は、バイト数で表されるネットワークバイトオーダーの2バイト整数で先頭に付加されます。長さが先頭に付加されたエンコーディングは、リストを形成するために連結されます。メディアタイプの定義については、セクション9.1を参照してください。
Evolution of the key configuration format is supported through the definition of new formats that are identified by new media types.
キー構成形式の進化は、新しいメディアタイプによって識別される新しい形式の定義を通じてサポートされています。
A Client that receives an "application/ohttp-keys" object with encoding errors might be able to recover one or more key configurations. Differences in how key configurations are recovered might be exploited to segregate Clients, so Clients MUST discard incorrectly encoded key configuration collections.
「application/ohttp-keys」オブジェクトを受信したクライアントは、エンコードエラーを回復できる可能性があります。キー構成が回復される方法の違いを悪用してクライアントを分離することができるため、クライアントは誤ってエンコードされたキー構成コレクションを破棄しなければなりません。
This document defines how a binary-encoded HTTP message [BINARY] is encapsulated using HPKE [HPKE]. Separate media types are defined to distinguish request and response messages:
このドキュメントは、バイナリエンコードされたHTTPメッセージ[BINARY]がHPKE[HPKE]を使用してカプセル化される方法を定義します。リクエストとレスポンスメッセージを区別するために、別々のメディアタイプが定義されています。
* An Encapsulated Request format defined in Section 4.1 is identified by the "message/ohttp-req" media type (Section 9.2).
* セクション4.1で定義されたカプセル化リクエスト形式は、「message/ohttp-req」メディアタイプ（セクション9.2）によって識別されます。
* An Encapsulated Response format defined in Section 4.2 is identified by the "message/ohttp-res" media type (Section 9.3).
* セクション4.2で定義されたカプセル化された応答形式は、「message/ohttp-res」メディアタイプ（セクション9.3）によって識別されます。
Alternative encapsulations or message formats are indicated using the media type; see Sections 4.5 and 4.6.
代替カプセル化またはメッセージ形式は、メディアタイプを使用して示されます。セクション4.5および4.6を参照してください。
A message in "message/ohttp-req" format protects a binary HTTP request message; see Figure 3.
"message/ohttp-req"形式のメッセージは、バイナリHTTPリクエストメッセージを保護します。図3を参照してください。
Request {
Binary HTTP Message (..),
}
Figure 3: Plaintext Request Structure
図3：平文リクエスト構造
This plaintext Request structure is encapsulated into a message in "message/ohttp-req" form by generating an Encapsulated Request. An Encapsulated Request comprises a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated KEM shared secret (or enc); and an HPKE-protected binary HTTP request message.
このプレーンテキストのリクエスト構造は、Encapsulated Requestを生成することで、"message/ohttp-req"形式のメッセージにカプセル化されます。 Encapsulated Requestには、キー識別子、選択したKEM、KDF、およびAEADのHPKEパラメータ、カプセル化されたKEM共有秘密（またはenc）、HPKEで保護されたバイナリHTTPリクエストメッセージが含まれます。
An Encapsulated Request is shown in Figure 4. Section 4.3 describes the process for constructing and processing an Encapsulated Request.
図4にはカプセル化されたリクエストが示されています。セクション4.3では、カプセル化されたリクエストを構築および処理するプロセスが説明されています。
Encapsulated Request {
Key Identifier (8),
HPKE KEM ID (16),
HPKE KDF ID (16),
HPKE AEAD ID (16),
Encapsulated KEM Shared Secret (8 * Nenc),
HPKE-Protected Request (..),
}
Figure 4: Encapsulated Request
図4：カプセル化されたリクエスト
That is, an Encapsulated Request comprises a Key Identifier, an HPKE KEM ID, an HPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared Secret, and an HPKE-Protected Request. The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE AEAD ID fields are defined in Section 3.1. The Encapsulated KEM Shared Secret is the output of the Encap() function for the KEM, which is Nenc bytes in length, as defined in Section 4 of [HPKE].
それは、カプセル化されたリクエストがキー識別子、HPKE KEM ID、HPKE KDF ID、HPKE AEAD ID、カプセル化されたKEM共有秘密、およびHPKE-保護されたリクエストを含むことを意味します。キー識別子、HPKE KEM ID、HPKE KDF ID、およびHPKE AEAD IDフィールドは、セクション3.1で定義されています。カプセル化されたKEM共有秘密は、[HPKE]のセクション4で定義されているように、KEMのEncap()関数の出力であり、長さがNencバイトです。
A message in "message/ohttp-res" format protects a binary HTTP response message; see Figure 5.
"message/ohttp-res"形式のメッセージは、バイナリHTTPレスポンスメッセージを保護します。図5を参照してください。
Response {
Binary HTTP Message (..),
}
Figure 5: Plaintext Response Structure
図5：平文応答構造
This plaintext Response structure is encapsulated into a message in "message/ohttp-res" form by generating an Encapsulated Response. An Encapsulated Response comprises a nonce and the AEAD-protected binary HTTP response message.
このプレーンテキスト応答構造は、エンカプセルされた応答を生成することで、"message/ohttp-res"形式のメッセージにカプセル化されます。エンカプセルされた応答には、ナンスとAEADで保護されたバイナリHTTP応答メッセージが含まれます。
An Encapsulated Response is shown in Figure 6. Section 4.4 describes the process for constructing and processing an Encapsulated Response.
図6にはカプセル化された応答が示されています。セクション4.4では、カプセル化された応答を構築および処理するプロセスが説明されています。
Encapsulated Response {
Nonce (8 * max(Nn, Nk)),
AEAD-Protected Response (..),
}
Figure 6: Encapsulated Response
図6：カプセル化された応答
That is, an Encapsulated Response contains a Nonce and an AEAD-Protected Response. The Nonce field is either Nn or Nk bytes long, whichever is larger. The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in Section 7.3 of [HPKE] or the "HPKE AEAD Identifiers" IANA registry <https://www.iana.org/assignments/hpke>. Nn and Nk refer to the size of the AEAD nonce and key, respectively, in bytes.
これは、カプセル化されたレスポンスにはNonceとAEADで保護されたレスポンスが含まれています。 Nonceフィールドは、NnまたはNkバイトのいずれかが長いです。 NnおよびNkの値は、HPKEで使用されるAEADのパラメータに対応しており、これは[HPKE]のセクション7.3で定義されています。 NnおよびNkは、それぞれAEADのノンスとキーのサイズをバイト単位で指します。
Clients encapsulate a request, identified as request, using values from a key configuration:
クライアントは、キー構成からの値を使用して、リクエストとして識別される要求をカプセル化します。
* the key identifier from the configuration (key_id) with the corresponding KEM identified by kem_id,
* 構成からのキー識別子（key_id）と、kem_idによって識別される対応するKEM、
* the public key from the configuration (pkR), and
* 設定からの公開鍵（pkR）と
* a combination of KDF (identified by kdf_id) and AEAD (identified by aead_id) that the Client selects from those in the key configuration.
* クライアントがキー構成内から選択するKDF（kdf_idで識別される）とAEAD（aead_idで識別される）の組み合わせ。
The Client then constructs an Encapsulated Request, enc_request, from a binary-encoded HTTP request [BINARY] (request) as follows:
クライアントは、バイナリエンコードされたHTTPリクエスト（リクエスト）から、enc_requestというカプセル化されたリクエストを構築します。
1. Construct a message header (hdr) by concatenating the values of key_id, kem_id, kdf_id, and aead_id as one 8-bit integer and three 16-bit integers, respectively, each in network byte order.
1. key_id、kem_id、kdf_id、およびaead_idの値を、それぞれネットワークバイトオーダーで1つの8ビット整数と3つの16ビット整数として連結して、メッセージヘッダー（hdr）を構築します。
2. Build a sequence of bytes (info) by concatenating the ASCII-encoded string "message/bhttp request", a zero byte, and the header. Note: Section 4.6 discusses how alternative message formats might use a different info value.
2. ASCIIエンコードされた文字列 "message/bhttp request"、ゼロバイト、およびヘッダーを連結して、バイトのシーケンス（情報）を構築します。注：セクション4.6では、代替メッセージ形式が異なる情報値を使用する方法について説明しています。
3. Create a sending HPKE context by invoking SetupBaseS() (Section 5.1.1 of [HPKE]) with the public key of the receiver pkR and info. This yields the context sctxt and an encapsulation key enc.
3. 受信者の公開鍵pkRと情報を使用して、SetupBaseS()（[HPKE]のセクション5.1.1）を呼び出すことで、送信用のHPKEコンテキストを作成します。これにより、コンテキストsctxtとカプセル化キーencが生成されます。
4. Encrypt request by invoking the Seal() method on sctxt (Section 5.2 of [HPKE]) with empty associated data aad, yielding ciphertext ct.
4. sctxtにSeal()メソッドを呼び出してリクエストを暗号化し、空の関連データaadを使用して、暗号文ctを生成します。
5. Concatenate the values of hdr, enc, and ct. This yields an Encapsulated Request (enc_request).
5. hdr、enc、およびctの値を連結します。これにより、Encapsulated Request（enc_request）が生成されます。
Note that enc is of fixed length, so there is no ambiguity in parsing this structure.
enc は固定長なので、この構造を解析する際に曖昧さはありません。
In pseudocode, this procedure is as follows:
この手続きの擬似コードは次のようになります。
hdr = concat(encode(1, key_id),
encode(2, kem_id),
encode(2, kdf_id),
encode(2, aead_id))
info = concat(encode_str("message/bhttp request"),
encode(1, 0),
hdr)
enc, sctxt = SetupBaseS(pkR, info)
ct = sctxt.Seal("", request)
enc_request = concat(hdr, enc, ct)
An Oblivious Gateway Resource decrypts an Encapsulated Request by reversing this process. To decapsulate an Encapsulated Request, enc_request:
An Oblivious Gateway Resourceは、このプロセスを逆にしてEncapsulated Requestを復号化します。Encapsulated Requestを解凍するには、enc_request:
1. Parse enc_request into key_id, kem_id, kdf_id, aead_id, enc, and ct (indicated using the function parse() in pseudocode). The Oblivious Gateway Resource is then able to find the HPKE private key, skR, corresponding to key_id.
1. enc_requestをkey_id、kem_id、kdf_id、aead_id、enc、およびctに解析します（疑似コードのparse()関数を使用して示されます）。その後、Oblivious Gateway Resourceは、key_idに対応するHPKEプライベートキーskRを見つけることができます。
a. If key_id does not identify a key matching the type of kem_id, the Oblivious Gateway Resource returns an error.
a. key_id が kem_id のタイプに一致するキーを識別しない場合、Oblivious Gateway リソースはエラーを返します。
b. If kdf_id and aead_id identify a combination of KDF and AEAD that the Oblivious Gateway Resource is unwilling to use with skR, the Oblivious Gateway Resource returns an error.
b. kdf_idとaead_idがOblivious Gateway ResourceがskRと一緒に使用したくないKDFとAEADの組み合わせを識別する場合、Oblivious Gateway Resourceはエラーを返します。
2. Build a sequence of bytes (info) by concatenating the ASCII-encoded string "message/bhttp request"; a zero byte; key_id as an 8-bit integer; plus kem_id, kdf_id, and aead_id as three 16-bit integers.
2. "message/bhttp request"というASCIIエンコードされた文字列に、ゼロバイト、8ビット整数のkey_id、および3つの16ビット整数のkem_id、kdf_id、aead_idを連結して、バイトのシーケンス（info）を構築します。
3. Create a receiving HPKE context, rctxt, by invoking SetupBaseR() (Section 5.1.1 of [HPKE]) with skR, enc, and info.
3. SetupBaseR()（[HPKE]のセクション5.1.1）を使用して、skR、enc、およびinfoを指定して、受信用のHPKEコンテキストrctxtを作成します。
4. Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of [HPKE]), with an empty associated data aad, yielding request or an error on failure. If decryption fails, the Oblivious Gateway Resource returns an error.
4. rctxtのOpen()メソッドを呼び出して、空の関連データaadでctを復号化し、失敗した場合はrequestまたはエラーを返します。復号化に失敗した場合、Oblivious Gateway Resourceはエラーを返します。
In pseudocode, this procedure is as follows:
この手続きの擬似コードは次のようになります。
key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
info = concat(encode_str("message/bhttp request"),
encode(1, 0),
encode(1, key_id),
encode(2, kem_id),
encode(2, kdf_id),
encode(2, aead_id))
rctxt = SetupBaseR(enc, skR, info)
request, error = rctxt.Open("", ct)
The Oblivious Gateway Resource retains the HPKE context, rctxt, so that it can encapsulate a response.
Oblivious Gateway リソースは、応答をカプセル化できるように HPKE コンテキスト rctxt を保持します。
Oblivious Gateway Resources generate an Encapsulated Response (enc_response) from a binary-encoded HTTP response [BINARY] (response). The Oblivious Gateway Resource uses the HPKE receiver context (rctxt) as the HPKE context (context) as follows:
Oblivious Gateway Resourcesは、バイナリエンコードされたHTTPレスポンス（response）からEncapsulated Response（enc_response）を生成します。Oblivious Gateway Resourceは、HPKE受信者コンテキスト（rctxt）をHPKEコンテキスト（context）として使用します。
1. Export a secret (secret) from context, using the string "message/ bhttp response" as the exporter_context parameter to context.Export; see Section 5.3 of [HPKE]. The length of this secret is max(Nn, Nk), where Nn and Nk are the length of the AEAD key and nonce that are associated with context. Note: Section 4.6 discusses how alternative message formats might use a different context value.
1. コンテキストから秘密（secret）をエクスポートし、context.Exportにエクスポーター・コンテキスト・パラメーターとして文字列「message/bhttp response」を使用します。この秘密の長さは、NnとNkがコンテキストに関連付けられているAEAD鍵とノンスの長さであるmax(Nn, Nk)です。注：セクション4.6では、代替メッセージ形式が異なるコンテキスト値を使用する方法について説明しています。
2. Generate a random value of length max(Nn, Nk) bytes, called response_nonce.
2. response_nonce と呼ばれる長さが max(Nn、Nk) バイトのランダムな値を生成します。
3. Extract a pseudorandom key (prk) using the Extract function provided by the KDF algorithm associated with context. The ikm input to this function is secret; the salt input is the concatenation of enc (from enc_request) and response_nonce.
3. コンテキストに関連するKDFアルゴリズムで提供されるExtract関数を使用して、疑似乱数鍵（prk）を抽出します。この関数へのikm入力は秘密です。salt入力はenc（enc_requestから）とresponse_nonceの連結です。
4. Use the Expand function provided by the same KDF to create an AEAD key, key, of length Nk -- the length of the keys used by the AEAD associated with context. Generating aead_key uses a label of "key".
4. 同じKDFが提供するExpand関数を使用して、コンテキストに関連付けられたAEADで使用されるキーの長さであるNkの長さのAEADキーkeyを作成します。 aead_keyの生成には、ラベルが「key」を使用します。
5. Use the same Expand function to create a nonce, nonce, of length Nn -- the length of the nonce used by the AEAD. Generating aead_nonce uses a label of "nonce".
5. 同じExpand関数を使用して、AEADで使用されるnonceの長さであるNnの長さのnonce、nonceを作成します。 aead_nonceを生成するには、ラベルを「nonce」とします。
6. Encrypt response, passing the AEAD function Seal the values of aead_key, aead_nonce, an empty aad, and a pt input of response. This yields ct.
6. 応答を暗号化するために、AEAD関数を使用して、aead_key、aead_nonce、空のaad、および応答のpt入力をシールしてください。これによりctが生成されます。
7. Concatenate response_nonce and ct, yielding an Encapsulated Response, enc_response. Note that response_nonce is of fixed length, so there is no ambiguity in parsing either response_nonce or ct.
7. response_nonceとctを連結して、Encapsulated Responseであるenc_responseを生成します。response_nonceは固定長なので、response_nonceやctを解析する際に曖昧さはありません。
In pseudocode, this procedure is as follows:
この手続きの擬似コードは次のようになります。
secret = context.Export("message/bhttp response", max(Nn, Nk))
response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce)
prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk)
aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct)
Clients decrypt an Encapsulated Response by reversing this process. That is, Clients first parse enc_response into response_nonce and ct. Then, they follow the same process to derive values for aead_key and aead_nonce, using their sending HPKE context, sctxt, as the HPKE context, context.
クライアントは、このプロセスを逆にしてカプセル化されたレスポンスを復号化します。つまり、クライアントはまずenc_responseをresponse_nonceとctに解析します。その後、送信HPKEコンテキストsctxtをHPKEコンテキストcontextとして使用して、aead_keyとaead_nonceの値を導出するために同じプロセスに従います。
The Client uses these values to decrypt ct using the AEAD function Open. Decrypting might produce an error, as follows:
クライアントは、これらの値を使用して、AEAD 関数 Open を使用して ct を復号化します。 復号化中にエラーが発生する可能性があります。
response, error = Open(aead_key, aead_nonce, "", ct)
Media types are used to identify Encapsulated Requests and Responses; see Sections 9.2 and 9.3 for definitions of these media types.
メディアタイプは、カプセル化されたリクエストとレスポンスを識別するために使用されます。これらのメディアタイプの定義については、セクション9.2および9.3を参照してください。
Evolution of the format of Encapsulated Requests and Responses is supported through the definition of new formats that are identified by new media types. New media types might be defined to use a similar encapsulation with a different HTTP message format than in [BINARY]; see Section 4.6 for guidance on reusing this encapsulation method. Alternatively, a new encapsulation method might be defined.
Encapsulated Requests and Responsesの形式の進化は、新しいメディアタイプによって識別される新しい形式の定義を通じてサポートされます。新しいメディアタイプは、[BINARY]とは異なるHTTPメッセージ形式を使用するように定義されるかもしれません。このカプセル化方法を再利用するためのガイダンスについては、セクション4.6を参照してください。また、新しいカプセル化方法が定義されるかもしれません。
The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message [BINARY]. The Client and Oblivious Gateway Resource agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively.
Oblivious HTTPリクエストとレスポンスの暗号化されたペイロードはバイナリHTTPメッセージ[BINARY]です。クライアントとOblivious Gatewayリソースは、リクエストとレスポンスの暗号化のために、それぞれHPKE情報文字列とHPKEエクスポートコンテキスト文字列でメディアタイプ"message/bhttp"を指定することで、この暗号化されたペイロードのタイプに同意します。
Future specifications may repurpose the encapsulation mechanism described in this document. This requires that the specification define a new media type. The encapsulation process for that content type can follow the same process, using new constant strings for the HPKE info and exporter context inputs.
将来の仕様では、この文書で説明されているカプセル化メカニズムを再利用する可能性があります。これには、仕様が新しいメディアタイプを定義する必要があります。そのコンテンツタイプのカプセル化プロセスは、同じプロセスに従い、HPKE情報とエクスポーターコンテキストの入力に新しい定数文字列を使用できます。
For example, a future specification might encapsulate DNS messages, which use the "application/dns-message" media type [RFC8484]. In creating a new, encrypted media types, specifications might define the use of string "application/dns-message request" (plus a zero byte and the header for the full value) for request encryption and the string "application/dns-message response" for response encryption.
例えば、将来の仕様では、"application/dns-message" メディアタイプ[RFC8484]を使用する DNS メッセージをカプセル化するかもしれません。新しい暗号化メディアタイプを作成する際、仕様では、リクエスト暗号化に "application/dns-message request"（ゼロバイトと完全な値のヘッダーを追加）を使用し、レスポンス暗号化には "application/dns-message response" を使用するかもしれません。
A Client interacts with the Oblivious Relay Resource by constructing an Encapsulated Request. This Encapsulated Request is included as the content of a POST request to the Oblivious Relay Resource. This request only needs those fields necessary to carry the Encapsulated Request: a method of POST, a target URI of the Oblivious Relay Resource, a header field containing the content type (see Section 9.2), and the Encapsulated Request as the request content. In the request to the Oblivious Relay Resource, Clients MAY include additional fields. However, additional fields MUST be independent of the Encapsulated Request and MUST be fields that the Oblivious Relay Resource will remove before forwarding the Encapsulated Request towards the target, such as the Connection or Proxy-Authorization header fields [HTTP].
クライアントは、エンカプセレートリクエストを構築して忘却リレーリソースとやり取りします。このエンカプセレートリクエストは、POSTリクエストのコンテンツとして忘却リレーリソースに含まれます。このリクエストには、POSTメソッド、忘却リレーリソースのターゲットURI、コンテンツタイプを含むヘッダーフィールド（セクション9.2を参照）、およびリクエストコンテンツとしてのエンカプセレートリクエストが必要です。クライアントは、忘却リレーリソースへのリクエストに追加のフィールドを含めることができます。ただし、追加のフィールドはエンカプセレートリクエストと独立しており、忘却リレーリソースがターゲットに転送する前に削除するフィールドでなければなりません。例えば、ConnectionやProxy-Authorizationのヘッダーフィールドなどです。
The Client role in this protocol acts as an HTTP client both with respect to the Oblivious Relay Resource and the Target Resource. The request, which the Client makes to the Target Resource, diverges from typical HTTP assumptions about the use of a connection (see Section 3.3 of [HTTP]) in that the request and response are encrypted rather than sent over a connection. The Oblivious Relay Resource and the Oblivious Gateway Resource also act as HTTP clients toward the Oblivious Gateway Resource and Target Resource, respectively.
このプロトコルにおけるクライアントの役割は、Oblivious Relay ResourceとTarget Resourceの両方に対してHTTPクライアントとして機能します。クライアントがTarget Resourceに対して行うリクエストは、通常のHTTPの接続に関する仮定とは異なり、リクエストとレスポンスが接続経由ではなく暗号化されて送信される点に異なります。Oblivious Relay ResourceとOblivious Gateway Resourceも、それぞれOblivious Gateway ResourceとTarget Resourceに対してHTTPクライアントとして機能します。
In order to achieve the privacy and security goals of the protocol, a Client also needs to observe the guidance in Section 6.1.
プロトコルのプライバシーとセキュリティの目標を達成するために、クライアントはセクション6.1のガイダンスに従う必要があります。
The Oblivious Relay Resource interacts with the Oblivious Gateway Resource as an HTTP client by constructing a request using the same restrictions as the Client request, except that the target URI is the Oblivious Gateway Resource. The content of this request is copied from the Client. An Oblivious Relay Resource MAY reject requests that are obviously invalid, such as a request with no content. The Oblivious Relay Resource MUST NOT add information to the request without the Client being aware of the type of information that might be added; see Section 6.2 for more information on relay responsibilities.
Oblivious Relay Resourceは、Oblivious Gateway ResourceとHTTPクライアントとしてやり取りし、クライアントリクエストと同じ制限を使用してリクエストを構築しますが、対象URIはOblivious Gateway Resourceです。このリクエストの内容はクライアントからコピーされます。Oblivious Relay Resourceは、明らかに無効なリクエスト（コンテンツのないリクエストなど）を拒否する場合があります。Oblivious Relay Resourceは、クライアントが追加される可能性のある情報の種類を認識していない場合に、リクエストに情報を追加してはいけません。リレーの責任に関する詳細については、セクション6.2を参照してください。
When a response is received from the Oblivious Gateway Resource, the Oblivious Relay Resource forwards the response according to the rules of an HTTP proxy; see Section 7.6 of [HTTP]. In case of timeout or error, the Oblivious Relay Resource can generate a response with an appropriate status code.
忘却ゲートウェイリソースからの応答を受信した場合、忘却リレーリソースはHTTPプロキシの規則に従って応答を転送します。タイムアウトやエラーの場合、忘却リレーリソースは適切なステータスコードを持つ応答を生成できます。
In order to achieve the privacy and security goals of the protocol, an Oblivious Relay Resource also needs to observe the guidance in Section 6.2.
プロトコルのプライバシーとセキュリティの目標を達成するために、Oblivious Relay Resourceもセクション6.2のガイダンスに従う必要があります。
An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see Section 7.6 of [HTTP]). The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors that do not relate to processing the contents of the Encapsulated Request; see Section 5.2.
忘れられたゲートウェイリソースは、ターゲットリソースへのリクエストのゲートウェイとして機能します（[HTTP]のセクション7.6を参照）。唯一の例外は、応答で転送する可能性のある情報は、カプセル化されている必要があるということです。ただし、カプセル化されたリクエストの内容の処理に関係しないエラーに対応する場合は除きます。セクション5.2を参照してください。
An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the Encapsulated Response. Like the request from the Client, this response MUST only contain those fields necessary to carry the Encapsulated Response: a 200 status code, a header field indicating the content type, and the Encapsulated Response as the response content. As with requests, additional fields MAY be used to convey information that does not reveal information about the Encapsulated Response.
オブリビアス・ゲートウェイ・リソースは、ターゲット・リソースからの応答を受信した場合、カプセル化された応答を含む単一の200応答を送信します。クライアントからのリクエストと同様に、この応答にはカプセル化された応答を運ぶために必要なフィールドのみを含める必要があります：200ステータスコード、コンテンツタイプを示すヘッダーフィールド、および応答コンテンツとしてのカプセル化された応答。リクエストと同様に、カプセル化された応答に関する情報を明らかにしない情報を伝達するために追加のフィールドを使用することができます。
An Oblivious Gateway Resource that does not receive a response can itself generate a response with an appropriate error status code (such as 504 (Gateway Timeout); see Section 15.6.5 of [HTTP]), which is then encapsulated in the same way as a successful response.
応答を受信しない無自覚なゲートウェイリソースは、適切なエラーステータスコード（たとえば504（ゲートウェイタイムアウト）; [HTTP]のセクション15.6.5を参照）を生成することができ、その後、成功した応答と同じ方法でカプセル化されます。
In order to achieve the privacy and security goals of the protocol, an Oblivious Gateway Resource also needs to observe the guidance in Section 6.3.
プロトコルのプライバシーとセキュリティの目標を達成するために、Oblivious Gateway Resourceもセクション6.3のガイダンスに従う必要があります。
This encapsulation does not permit progressive processing of responses. Though the binary HTTP response format does support the inclusion of informational (1xx) status codes, the AEAD encapsulation cannot be removed until the entire message is received.
このカプセル化は、応答の逐次処理を許可しません。バイナリHTTP応答形式は情報 (1xx) ステータスコードの含まれることをサポートしていますが、AEADカプセル化はメッセージ全体が受信されるまで削除できません。
In particular, the Expect header field with 100-continue (see Section 10.1.1 of [HTTP]) cannot be used. Clients MUST NOT construct a request that includes a 100-continue expectation; the Oblivious Gateway Resource MUST generate an error if a 100-continue expectation is received.
特に、100-continueを伴うExpectヘッダーフィールド（[HTTP]のセクション10.1.1を参照）は使用できません。クライアントは、100-continueの期待を含むリクエストを構築してはなりません。Oblivious Gateway Resourceは、100-continueの期待が受信された場合にエラーを生成する必要があります。
A server that receives an invalid message for any reason MUST generate an HTTP response with a 4xx status code.
サーバーが何らかの理由で無効なメッセージを受信した場合、4xxステータスコードを持つHTTPレスポンスを生成する必要があります。
Errors detected by the Oblivious Relay Resource and errors detected by the Oblivious Gateway Resource before removing protection (including being unable to remove encapsulation for any reason) result in the status code being sent without protection in response to the POST request made to that resource.
Oblivious Relay Resource および Oblivious Gateway Resource によって検出されたエラーは、保護を解除する前に発生した場合、そのリソースに対する POST リクエストへの応答として保護なしでステータスコードが送信されます。
Errors detected by the Oblivious Gateway Resource after successfully removing encapsulation and errors detected by the Target Resource MUST be sent in an Encapsulated Response. This might be because the Encapsulated Request is malformed or the Target Resource does not produce a response. In either case, the Oblivious Gateway Resource can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see Sections 15.5.1 and 15.6.5 of [HTTP], respectively). This response is encapsulated in the same way as a successful response.
成功裏にカプセル化を削除した後にOblivious Gateway Resourceによって検出されたエラーと、Target Resourceによって検出されたエラーは、カプセル化された応答で送信する必要があります。これは、カプセル化されたリクエストが不正であるか、Target Resourceが応答を生成しないためかもしれません。いずれの場合も、Oblivious Gateway Resourceは適切なエラーステータスコード（たとえば400（Bad Request）または504（Gateway Timeout）など、それぞれ[HTTP]の15.5.1節および15.6.5節を参照）を持つ応答を生成できます。この応答は、成功した応答と同じ方法でカプセル化されます。
Errors in the encapsulation of requests mean that responses cannot be encapsulated. This includes cases where the key configuration is incorrect or outdated. The Oblivious Gateway Resource can generate and send a response with a 4xx status code to the Oblivious Relay Resource. This response MAY be forwarded to the Client or treated by the Oblivious Relay Resource as a failure. If a Client receives a response that is not an Encapsulated Response, this could indicate that the Client configuration used to construct the request is incorrect or out of date.
リクエストのカプセル化にエラーがあると、レスポンスをカプセル化できません。これには、キー構成が正しくないか古い場合も含まれます。忘却ゲートウェイリソースは、忘却リレーリソースに4xxステータスコードを持つレスポンスを生成して送信できます。このレスポンスはクライアントに転送されるか、忘却リレーリソースによって失敗として扱われる可能性があります。クライアントがカプセル化されたレスポンスでないレスポンスを受信した場合、それはリクエストを構築するために使用されたクライアント構成が正しくないか古いことを示している可能性があります。
The problem type [PROBLEM] of "https://iana.org/assignments/http-problem-types#ohttp-key" is defined in this section. An Oblivious Gateway Resource MAY use this problem type in a response to indicate that an Encapsulated Request used an outdated or incorrect key configuration.
"https://iana.org/assignments/http-problem-types#ohttp-key"の問題タイプ[PROBLEM]は、このセクションで定義されています。忘れられたゲートウェイリソースは、エンカプセレートされたリクエストが古いまたは間違ったキー構成を使用したことを示すために、この問題タイプを応答で使用する場合があります。
Figure 7 shows an example response in HTTP/1.1 format.
図7は、HTTP/1.1形式での応答の例を示しています。
HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json
Content-Length: 106
{"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
"title": "key identifier unknown"}
Figure 7: Example Rejection of Key Configuration
図7：キー構成の拒否の例
As this response cannot be encrypted, it might not reach the Client. A Client cannot rely on the Oblivious Gateway Resource using this problem type. A Client might also be configured to disregard responses that are not encapsulated on the basis that they might be subject to observation or modification by an Oblivious Relay Resource. A Client might manage the risk of an outdated key configuration using a heuristic approach whereby it periodically refreshes its key configuration if it receives a response with an error status code that has not been encapsulated.
この応答は暗号化できないため、クライアントに届かない可能性があります。この問題タイプを使用してOblivious Gatewayリソースに依存することはできません。クライアントは、Oblivious Relayリソースによる観察や変更の対象となる可能性があるため、カプセル化されていない応答を無視するように構成されている場合があります。クライアントは、期限切れのキー構成のリスクを管理するために、エラーステータスコードを含まない応答を定期的に受信した場合、ヒューリスティックアプローチを使用してキー構成を更新するかもしれません。
In this design, a Client wishes to make a request to an Oblivious Gateway Resource that is forwarded to a Target Resource. The Client wishes to make this request without linking that request with either of the following:
この設計では、クライアントは忘却ゲートウェイリソースにリクエストを送り、それがターゲットリソースに転送されることを希望しています。クライアントは、このリクエストを次のいずれかと関連付けずに行いたいと考えています。
* The identity at the network and transport layer of the Client (that is, the Client IP address and TCP or UDP port number the Client uses to create a connection).
* クライアントのネットワークおよびトランスポート層の識別情報（つまり、クライアントが接続を作成する際に使用するクライアントのIPアドレスとTCPまたはUDPポート番号）。
* Any other request the Client might have made in the past or might make in the future.
* クライアントが過去に行った要求や将来行うかもしれない要求。
In order to ensure this, the Client selects a relay (that serves the Oblivious Relay Resource) that it trusts will protect this information by forwarding the Encapsulated Request and Response without passing it to the server (that serves the Oblivious Gateway Resource).
クライアントは、信頼できるリレー（Oblivious Relay Resourceを提供する）を選択し、その情報を保護するために、カプセル化されたリクエストとレスポンスをサーバー（Oblivious Gateway Resourceを提供する）に渡さずに転送することを確認するために、これを行います。
In this section, a deployment where there are three entities is considered:
このセクションでは、3つのエンティティが存在する展開が考慮されています。
* A Client makes requests and receives responses.
* クライアントはリクエストを行い、レスポンスを受け取ります。
* A relay operates the Oblivious Relay Resource.
* リレーは忘却リレーリソースを操作します。
* A server operates both the Oblivious Gateway Resource and the Target Resource.
* サーバーは、忘却ゲートウェイリソースとターゲットリソースの両方を運用しています。
Section 6.10 discusses the security implications for a case where different servers operate the Oblivious Gateway Resource and Target Resource.
セクション6.10では、異なるサーバーがOblivious Gateway ResourceとTarget Resourceを操作する場合のセキュリティ上の考慮事項について説明しています。
Requests from the Client to Oblivious Relay Resource and from Oblivious Relay Resource to Oblivious Gateway Resource MUST use HTTPS in order to provide unlinkability in the presence of a network observer.
クライアントから無関心中継リソースへのリクエストと、無関心中継リソースから無関心ゲートウェイリソースへのリクエストは、ネットワーク監視者の存在下での非リンク可能性を提供するためにHTTPSを使用する必要があります。
To achieve the stated privacy goals, the Oblivious Relay Resource cannot be operated by the same entity as the Oblivious Gateway Resource. However, colocation of the Oblivious Gateway Resource and Target Resource simplifies the interactions between those resources without affecting Client privacy.
述べられたプライバシー目標を達成するために、Oblivious Relay リソースは Oblivious Gateway リソースと同じエンティティによって運用されてはなりません。ただし、Oblivious Gateway リソースと Target リソースの共有は、それらのリソース間の相互作用を簡素化する一方で、クライアントのプライバシーに影響を与えません。
As a consequence of this configuration, Oblivious HTTP prevents linkability described above. Informally, this means:
この構成の結果として、Oblivious HTTPは上述のリンク可能性を防ぎます。簡単に言うと、これは次のことを意味します：
1. Requests and responses are known only to Clients and Oblivious Gateway Resources. In particular, the Oblivious Relay Resource knows the origin and destination of an Encapsulated Request and Response, yet it does not know the decrypted contents. Likewise, Oblivious Gateway Resources learn only the Oblivious Relay Resource and the decrypted request. No entity other than the Client can see the plaintext request and response and can attribute them to the Client.
1. リクエストとレスポンスは、クライアントと無自覚なゲートウェイリソースだけが知っています。特に、無自覚なリレーリソースは、カプセル化されたリクエストとレスポンスの出所と宛先を知っていますが、復号化された内容は知りません。同様に、無自覚なゲートウェイリソースは、無自覚なリレーリソースと復号化されたリクエストだけを知ります。クライアント以外のエンティティは、平文のリクエストとレスポンスを見ることはできず、それらをクライアントに帰属させることはできません。
2. Oblivious Gateway Resources, and therefore Target Resources, cannot link requests from the same Client in the absence of unique per-Client keys.
2. Oblivious Gateway Resources、およびそれによってターゲットリソースは、ユニークなクライアントごとのキーがない場合、同じクライアントからのリクエストをリンクすることはできません。
Traffic analysis that might affect these properties is outside the scope of this document; see Section 6.2.3.
これらの特性に影響を与える可能性のあるトラフィック分析は、この文書の範囲外です。セクション6.2.3を参照してください。
A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS].
Oblivious HTTPの形式的な分析は、[OHTTP-ANALYSIS]にあります。
Because Clients do not authenticate the Target Resource when using Oblivious HTTP, Clients MUST have some mechanism to authorize an Oblivious Gateway Resource for use with a Target Resource. One possible means of authorization is an allowlist. This ensures that Oblivious Gateway Resources are not misused to forward traffic to arbitrary Target Resources. Section 6.3 describes similar responsibilities that apply to Oblivious Gateway Resources.
クライアントが忘却HTTPを使用する際、クライアントはターゲットリソースを認証しないため、クライアントはターゲットリソースと使用するための忘却ゲートウェイリソースを承認するためのメカニズムを持っている必要があります。承認の1つの可能な手段は許可リストです。これにより、忘却ゲートウェイリソースが任意のターゲットリソースにトラフィックを転送することがないようにします。セクション6.3では、忘却ゲートウェイリソースに適用される同様の責任について説明しています。
Clients MUST ensure that the key configuration they select for generating Encapsulated Requests is integrity protected and authenticated so that it can be attributed to the Oblivious Gateway Resource; see Section 3.
クライアントは、生成されたカプセル化リクエストのキー構成が整合性保護され、認証されていることを確認する必要があります。これにより、それを忘却ゲートウェイリソースに帰属させることができます。セクション3を参照してください。
Since Clients connect directly to the Oblivious Relay Resource instead of the Target Resource, application configurations wherein Clients make policy decisions about target connections, e.g., to apply certificate pinning, are incompatible with Oblivious HTTP. In such cases, alternative technologies such as HTTP CONNECT (Section 9.3.6 of [HTTP]) can be used. Applications could implement related policies on key configurations and relay connections, though these might not provide the same properties as policies enforced directly on target connections. Instead, when this difference is relevant, applications can connect directly to the target at the cost of either privacy or performance.
クライアントは、ターゲットリソースではなく忘却リレーリソースに直接接続するため、クライアントがターゲット接続についてポリシー決定を行うアプリケーション構成は、忘却HTTPと互換性がありません。このような場合、代替技術としてHTTP CONNECT（[HTTP]のセクション9.3.6）などが使用されることがあります。アプリケーションは、キー構成やリレーコネクションに関連するポリシーを実装することができますが、これらはターゲット接続に直接適用されるポリシーと同じ特性を提供しない可能性があります。代わりに、この違いが関連する場合、アプリケーションはプライバシーまたはパフォーマンスのコストを払って、直接ターゲットに接続することができます。
Clients cannot carry connection-level state between requests as they only establish direct connections to the relay responsible for the Oblivious Relay Resource. However, the content of requests might be used by a server to correlate requests. Cookies [COOKIES] are the most obvious feature that might be used to correlate requests, but any identity information and authentication credentials might have the same effect. Clients also need to treat information learned from responses with similar care when constructing subsequent requests, which includes the identity of resources.
クライアントは、Oblivious Relay Resource に対応するリレーに直接接続を確立するため、リクエスト間で接続レベルの状態を保持することはできません。ただし、リクエストの内容はサーバーによってリクエストを関連付けるために使用される可能性があります。Cookies [COOKIES] はリクエストを関連付けるために使用される可能性が最も高い機能ですが、任意のアイデンティティ情報や認証資格情報も同じ効果を持つ可能性があります。クライアントは、後続のリクエストを構築する際に、レスポンスから得られた情報を同様の注意を払って扱う必要があります。これにはリソースのアイデンティティも含まれます。
Clients MUST generate a new HPKE context for every request, using a good source of entropy [RANDOM] for generating keys. Key reuse not only risks requests being linked but also could expose request and response contents to the relay.
クライアントは、リクエストごとに新しいHPKEコンテキストを生成する必要があります。キーを生成するためには、良質なエントロピー[RANDOM]を使用してください。キーの再利用は、リクエストが関連付けられるリスクだけでなく、リクエストとレスポンスの内容がリレーに公開される可能性もあります。
The request the Client sends to the Oblivious Relay Resource only requires minimal information; see Section 5. The request that carries the Encapsulated Request and that is sent to the Oblivious Relay Resource MUST NOT include identifying information unless the Client can trust that this information is removed by the relay. A Client MAY include information only for the Oblivious Relay Resource in header fields identified by the Connection header field if it trusts the relay to remove these, as required by Section 7.6.1 of [HTTP]. The Client needs to trust that the relay does not replicate the source addressing information in the request it forwards.
クライアントが忘却リレーリソースに送信するリクエストには、最小限の情報しか必要ありません。エンカプセレートされたリクエストを含むリクエストは、クライアントがその情報がリレーによって削除されることを信頼できる場合を除き、識別情報を含んではなりません。クライアントは、[HTTP]のセクション7.6.1で要求されているように、リレーがこれらを削除することを信頼できる場合にのみ、Connectionヘッダーフィールドで忘却リレーリソースのための情報を含めることができます。クライアントは、リクエストで転送されるソースアドレッシング情報をリレーが複製しないことを信頼する必要があります。
Clients rely on the Oblivious Relay Resource to forward Encapsulated Requests and Responses. However, the relay can only refuse to forward messages; it cannot inspect or modify the contents of Encapsulated Requests or Responses.
クライアントは、忘却リレーリソースに依存して、カプセル化されたリクエストとレスポンスを転送します。ただし、リレーはメッセージの転送を拒否するだけであり、カプセル化されたリクエストやレスポンスの内容を検査または変更することはできません。
The relay that serves the Oblivious Relay Resource has a very simple function to perform. For each request it receives, it makes a request of the Oblivious Gateway Resource that includes the same content. When it receives a response, it sends a response to the Client that includes the content of the response from the Oblivious Gateway Resource.
Oblivious Relay Resourceを提供するリレーには、実行する非常に単純な機能があります。受け取った各リクエストに対して、同じ内容を含むOblivious Gateway Resourceにリクエストを行います。応答を受け取ると、Oblivious Gateway Resourceからの応答の内容を含むクライアントに応答を送信します。
When forwarding a request, the relay MUST follow the forwarding rules in Section 7.6 of [HTTP]. A generic HTTP intermediary implementation is suitable for the purposes of serving an Oblivious Relay Resource, but additional care is needed to ensure that Client privacy is maintained.
リクエストを転送する際、リレーは[HTTP]のセクション7.6の転送ルールに従う必要があります。忘却リレーリソースを提供するために一般的なHTTP中継実装が適していますが、クライアントのプライバシーが保持されるように追加の注意が必要です。
Firstly, a generic implementation will forward unknown fields. For Oblivious HTTP, an Oblivious Relay Resource SHOULD NOT forward unknown fields. Though Clients are not expected to include fields that might contain identifying information, removing unknown fields removes this privacy risk.
最初に、一般的な実装は未知のフィールドを転送します。Oblivious HTTPの場合、Oblivious Relay Resourceは未知のフィールドを転送すべきではありません。クライアントが識別情報を含む可能性のあるフィールドを含めることは想定されていませんが、未知のフィールドを削除することでこのプライバシーのリスクを取り除くことができます。
Secondly, generic implementations are often configured to augment requests with information about the Client, such as the Via field or the Forwarded field [FORWARDED]. A relay MUST NOT add information when forwarding requests that might be used to identify Clients, except for information that a Client is aware of; see Section 6.2.1.
第二に、一般的な実装は、クライアントに関する情報をリクエストに追加するように構成されることがよくあります。ただし、リレーは、クライアントを特定するために使用される可能性のある情報を追加してはいけません。クライアントが認識している情報を除いては。セクション6.2.1を参照してください。
Finally, a relay can also generate responses, though it is assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD); therefore, it is also assumed that it cannot generate an Encapsulated Response.
最終的に、リレーは応答を生成することもできますが、リクエストの内容を調べることはできないと仮定されています（キー識別子、KDF、およびAEADの選択を観察することを除く）。したがって、カプセル化された応答を生成することはできないとも仮定されています。
A relay MAY add information to requests if the Client is aware of the nature of the information that could be added. Any addition MUST NOT include information that uniquely and permanently identifies the Client, including any pseudonymous identifier. Information added by the relay -- beyond what is already revealed through Encapsulated Requests from Clients -- can reduce the size of the anonymity set of Clients at a gateway.
リレーは、クライアントが追加される情報の性質を認識している場合に、リクエストに情報を追加することができます。追加される情報には、クライアントを一意かつ永続的に識別する情報は含めてはいけません。リレーによって追加される情報は、クライアントの匿名性セットのサイズを減少させる可能性があります。
A Client does not need to be aware of the exact value added for each request but needs to know the range of possible values the relay might use. How a Client might learn about added information is not defined in this document.
クライアントは、各リクエストごとの正確な付加価値を把握する必要はありませんが、リレーが使用する可能性のある値の範囲を知る必要があります。クライアントが追加情報をどのように学ぶかは、この文書では定義されていません。
Moreover, relays MAY apply differential treatment to Clients that engage in abusive behavior, e.g., by sending too many requests in comparison to other Clients, or as a response to rate limits signaled from the gateway. Any such differential treatment can reveal information to the gateway that would not be revealed otherwise and therefore reduce the size of the anonymity set of Clients using a gateway. For example, if a relay chooses to rate limit or block an abusive Client, this means that any Client requests that are not treated this way are known to be non-abusive by the gateway. Clients need to consider the likelihood of such differential treatment and the privacy risks when using a relay.
さらに、リレーは、他のクライアントと比較して過剰なリクエストを送信するなどの乱用行為を行うクライアントに対して差別的な取り扱いを適用する可能性があります。また、ゲートウェイからのレート制限に対する応答としても差別的な取り扱いが行われることがあります。このような差別的な取り扱いは、通常では明らかにされない情報をゲートウェイに示す可能性があり、その結果、ゲートウェイを使用するクライアントの匿名性セットのサイズが減少することがあります。たとえば、リレーが乱用クライアントに対してレート制限やブロックを選択した場合、このことは、このような取り扱いを受けていない他のクライアントリクエストがゲートウェイによって非乱用であると認識されることを意味します。クライアントは、リレーを使用する際に、このような差別的な取り扱いやプライバシーのリスクを考慮する必要があります。
Some patterns of abuse cannot be detected without access to the request that is made to the target. This means that only the gateway or the target is in a position to identify abuse. A gateway MAY send signals toward the relay to provide feedback about specific requests. For example, a gateway could respond differently to requests it cannot decapsulate, as mentioned in Section 5.2. A relay that acts on this feedback could -- either inadvertently or by design -- lead to Client deanonymization.
一部の虐待のパターンは、ターゲットに対するリクエストへのアクセスなしには検出できません。これは、ゲートウェイまたはターゲットだけが虐待を特定できる立場にあることを意味します。ゲートウェイは、特定のリクエストに関するフィードバックをリレーに送信することができます。たとえば、5.2節で言及されているように、ゲートウェイは、デカプセル化できないリクエストに異なる応答を返すことがあります。このフィードバックに基づいて行動するリレーは、クライアントの匿名性の解除を意図せずにもたらす可能性があります。
As there are privacy benefits from having a large rate of requests forwarded by the same relay (see Section 6.2.3), servers that operate the Oblivious Gateway Resource might need an arrangement with Oblivious Relay Resources. This arrangement might be necessary to prevent having the large volume of requests being classified as an attack by the server.
同じリレーによって転送されるリクエストの割合が大きいと、プライバシーの利点があります（セクション6.2.3を参照）。Oblivious Gateway Resourceを運用するサーバーは、Oblivious Relay Resourcesとの取り決めが必要になるかもしれません。この取り決めは、サーバーによる攻撃として分類されることを防ぐために必要かもしれません。
If a server accepts a larger volume of requests from a relay, it needs to trust that the relay does not allow abusive levels of request volumes from Clients. That is, if a server allows requests from the relay to be exempt from rate limits, the server might want to ensure that the relay applies a rate-limiting policy that is acceptable to the server.
サーバーがリレーからのリクエストの大量受け入れを許可する場合、サーバーはリレーがクライアントからのリクエストの過剰な量を許可しないことを信頼する必要があります。つまり、サーバーがリレーからのリクエストをレート制限の対象外とする場合、サーバーはリレーがサーバーに受け入れられるレート制限ポリシーを適用していることを確認したいと思うかもしれません。
Servers that enter into an agreement with a relay that enables a higher request rate might choose to authenticate the relay to enable the higher rate.
リクエスト率を高めるリレーと契約を結ぶサーバーは、高い率を可能にするためにリレーを認証することを選択するかもしれません。
Using HTTPS protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a relay. However, using HTTPS does not prevent traffic analysis by such network observers.
HTTPSを使用すると、リクエストの対象となるリソースに関する情報が保護され、中継点の両側のメッセージを簡単に関連付けることができなくなります。ただし、HTTPSを使用しても、そのようなネットワーク監視者によるトラフィック解析を防ぐことはできません。
The time at which Encapsulated Request or Response messages are sent can reveal information to a network observer. Though messages exchanged between the Oblivious Relay Resource and the Oblivious Gateway Resource might be sent in a single connection, traffic analysis could be used to match messages that are forwarded by the relay.
Encapsulated RequestまたはResponseメッセージが送信される時間は、ネットワークの観察者に情報を明らかにする可能性があります。Oblivious Relay ResourceとOblivious Gateway Resource間で交換されるメッセージは、1つの接続で送信されるかもしれませんが、トラフィック分析を使用してリレーによって転送されるメッセージを一致させることができます。
A relay could, as part of its function, delay requests before forwarding them. Delays might increase the anonymity set into which each request is attributed. Any delay also increases the time that a Client waits for a response, so delays SHOULD only be added with the consent -- or at least awareness -- of Clients.
リレーは、その機能の一部として、リクエストを転送する前に遅延させることがあります。遅延は、各リクエストが帰属される匿名性セットを増やす可能性があります。遅延はクライアントが応答を待つ時間も増やすため、遅延はクライアントの同意または少なくとも認識の下でのみ追加すべきです。
A relay that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.
大量の取引を転送するリレーは、一致させる必要があるメッセージのセットを提供することで、より良いプライバシーを提供できます。
Traffic analysis is not restricted to network observers. A malicious Oblivious Relay Resource could use traffic analysis to learn information about otherwise encrypted requests and responses relayed between Clients and gateways. An Oblivious Relay Resource terminates TLS connections from Clients, so they see message boundaries. This privileged position allows for richer feature extraction from encrypted data, which might improve traffic analysis.
Traffic analysisはネットワークの観察者に限定されていません。悪意のあるOblivious Relay Resourceは、クライアントとゲートウェイ間で中継される通常は暗号化されたリクエストとレスポンスに関する情報を学ぶために、Traffic analysisを使用する可能性があります。Oblivious Relay Resourceは、クライアントからのTLS接続を終了するため、メッセージの境界を見ることができます。この特権的な位置は、暗号化されたデータからより豊富な特徴抽出を可能にし、Traffic analysisを向上させる可能性があります。
Clients and Oblivious Gateway Resources can use padding to reduce the effectiveness of traffic analysis. Padding is a capability provided by binary HTTP messages; see Section 3.8 of [BINARY]. If the encapsulation method described in this document is used to protect a different message type (see Section 4.6), that message format might need to include padding support. Oblivious Relay Resources can also use padding for the same reason but need to operate at the HTTP layer since they cannot manipulate binary HTTP messages; for example, see Section 10.7 of [HTTP/2] or Section 10.7 of [HTTP/3]).
クライアントと無自覚なゲートウェイリソースは、トラフィック解析の効果を低減するためにパディングを使用できます。パディングはバイナリHTTPメッセージによって提供される機能です。このドキュメントで説明されているカプセル化メソッドが異なるメッセージタイプを保護するために使用される場合、そのメッセージ形式にはパディングサポートが必要になるかもしれません。無自覚なリレーリソースも同じ理由でパディングを使用できますが、バイナリHTTPメッセージを操作することができないため、HTTPレイヤーで動作する必要があります。
The Oblivious Gateway Resource can be operated by a different entity than the Target Resource. However, this means that the Client needs to trust the Oblivious Gateway Resource not to modify requests or responses. This analysis concerns itself with a deployment scenario where a single server provides both the Oblivious Gateway Resource and Target Resource.
忘却ゲートウェイリソースは、ターゲットリソースとは異なるエンティティによって運用される可能性があります。ただし、これはクライアントが忘却ゲートウェイリソースがリクエストやレスポンスを変更しないことを信頼する必要があることを意味します。この分析は、忘却ゲートウェイリソースとターゲットリソースの両方を提供する単一のサーバーが展開されているシナリオに関わります。
A server that operates both Oblivious Gateway and Target Resources is responsible for removing request encryption, generating a response to the Encapsulated Request, and encrypting the response.
Oblivious GatewayとTarget Resourcesの両方を操作するサーバーは、リクエストの暗号化を解除し、Encapsulated Requestに対する応答を生成し、応答を暗号化する責任があります。
Servers should account for traffic analysis based on response size or generation time. Techniques such as padding or timing delays can help protect against such attacks; see Section 6.2.3.
サーバーは、応答サイズや生成時間に基づくトラフィック解析を考慮すべきです。パディングやタイミングの遅延などの技術を使用することで、そのような攻撃に対して保護することができます。セクション6.2.3を参照してください。
If separate entities provide the Oblivious Gateway Resource and Target Resource, these entities might need an arrangement similar to that between server and relay for managing denial of service; see Section 6.2.2. Moreover, the Oblivious Gateway Resource SHOULD have some mechanism to ensure that the Oblivious Gateway Resource is not misused as a relay for HTTP messages to an arbitrary Target Resource, such as an allowlist.
別々のエンティティがOblivious GatewayリソースとTargetリソースを提供する場合、これらのエンティティは、サーバーとリレーの間の管理を行うための類似した取り決めが必要になる可能性があります。さらに、Oblivious Gatewayリソースは、HTTPメッセージを任意のTargetリソースに中継されないようにするメカニズムを持つべきです。例えば、allowlistなどが考えられます。
Non-secure requests -- such as those with the "http" scheme as opposed to the "https" scheme -- SHOULD NOT be used if the Oblivious Gateway and Target Resources are not on the same origin. If messages are forwarded between these resources without the protections afforded by HTTPS, they could be inspected or modified by a network attacker. Note that a request could be forwarded without protection if the two resources share an origin.
安全でないリクエスト（"http"スキームではなく"https"スキーム）は、Oblivious GatewayとTarget Resourcesが同じオリジンでない場合には使用すべきではありません。HTTPSによる保護がない状態でこれらのリソース間でメッセージが転送されると、ネットワーク攻撃者によって検査または変更される可能性があります。2つのリソースが同じオリジンを共有している場合、保護なしにリクエストが転送される可能性があることに注意してください。
An Oblivious Gateway Resource needs to have a plan for replacing keys. This might include regular replacement of keys, which can be assigned new key identifiers. If an Oblivious Gateway Resource receives a request that contains a key identifier that it does not understand or that corresponds to a key that has been replaced, the server can respond with an HTTP 422 (Unprocessable Content) status code.
Oblivious Gatewayリソースは、キーの置き換え計画を持つ必要があります。これには、新しいキー識別子が割り当てられることが含まれる場合があります。Oblivious Gatewayリソースが理解できないキー識別子を含むリクエストを受信した場合、または置き換えられたキーに対応するキー識別子を含むリクエストを受信した場合、サーバーはHTTP 422（処理できないコンテンツ）ステータスコードで応答することができます。
A server can also use a 422 status code if the server has a key that corresponds to the key identifier, but the Encapsulated Request cannot be successfully decrypted using the key.
サーバーは、キー識別子に対応するキーを持っているが、そのキーを使用してカプセル化されたリクエストを正常に復号化できない場合、422ステータスコードも使用できます。
A server MUST ensure that the HPKE keys it uses are not valid for any other protocol that uses HPKE with the "message/bhttp request" label. Designers of protocols that reuse this encryption format, especially new versions of this protocol, can ensure key diversity by choosing a different label in their use of HPKE. The "message/bhttp response" label was chosen for symmetry only as it provides key diversity only within the HPKE context created using the "message/bhttp request" label; see Section 4.6.
サーバーは、使用するHPKEキーが、"message/bhttp request"ラベルを使用する他のプロトコルに対して有効でないことを確認する必要があります。この暗号化形式を再利用するプロトコルの設計者は、特にこのプロトコルの新しいバージョンにおいて、HPKEの使用において異なるラベルを選択することでキーの多様性を確保できます。"message/bhttp response"ラベルは、対称性のために選択されただけであり、"message/bhttp request"ラベルを使用して作成されたHPKEコンテキスト内でのみキーの多様性を提供します。セクション4.6を参照してください。
A server is responsible for either rejecting replayed requests or ensuring that the effect of replays does not adversely affect Clients or resources.
サーバーは、再生されたリクエストを拒否するか、再生の影響がクライアントやリソースに悪影響を与えないようにする責任があります。
Encapsulated Requests can be copied and replayed by the Oblivious Relay Resource. The threat model for Oblivious HTTP allows the possibility that an Oblivious Relay Resource might replay requests. Furthermore, if a Client sends an Encapsulated Request in TLS early data (see Section 8 of [TLS] and [RFC8470]), a network-based adversary might be able to cause the request to be replayed. In both cases, the effect of a replay attack and the mitigations that might be employed are similar to TLS early data.
Encapsulated Requests can be copied and replayed by the Oblivious Relay Resource. The threat model for Oblivious HTTP allows the possibility that an Oblivious Relay Resource might replay requests. Furthermore, if a Client sends an Encapsulated Request in TLS early data (see Section 8 of [TLS] and [RFC8470]), a network-based adversary might be able to cause the request to be replayed. In both cases, the effect of a replay attack and the mitigations that might be employed are similar to TLS early data.
It is the responsibility of the application that uses Oblivious HTTP to either reject replayed requests or ensure that replayed requests have no adverse effect on their operation. This section describes some approaches that are universally applicable and suggestions for more targeted techniques.
Oblivious HTTPを使用するアプリケーションは、再生されたリクエストを拒否するか、再生されたリクエストが操作に悪影響を与えないようにする責任があります。このセクションでは、普遍的に適用可能なアプローチと、よりターゲットとなるテクニックの提案について説明します。
A Client or Oblivious Relay Resource MUST NOT automatically attempt to retry a failed request unless it receives a positive signal indicating that the request was not processed or forwarded. The HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of [HTTP/2]), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of [HTTP/3]), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred. HTTP/1.1 [HTTP/1.1] provides no equivalent signal. Connection failures or interruptions are not sufficient signals that no processing occurred.
クライアントまたは無自覚なリレーリソースは、リクエストが処理または転送されなかったことを示す肯定的なシグナルを受信するまで、失敗したリクエストを自動的に再試行してはなりません。HTTP/2のREFUSED_STREAMエラーコード（[HTTP/2]の8.1.4節）、HTTP/3のH3_REQUEST_REJECTEDエラーコード（[HTTP/3]の8.1節）、またはプロトコルバージョンに関係なく低い識別子を持つGOAWAYフレームは、いずれも処理が行われなかったことを示す十分なシグナルです。HTTP/1.1には同等のシグナルがありません。接続の失敗や中断は、処理が行われなかったことを示す十分なシグナルではありません。
The anti-replay mechanisms described in Section 8 of [TLS] are generally applicable to Oblivious HTTP requests. The encapsulated keying material (or enc) can be used in place of a nonce to uniquely identify a request. This value is a high-entropy value that is freshly generated for every request, so two valid requests will have different values with overwhelming probability.
[TLS]のセクション8に記載されているアンチリプレイメカニズムは、Obilivious HTTPリクエストに一般的に適用されます。カプセル化された鍵素材（またはenc）は、リクエストを一意に識別するためにノンスの代わりに使用できます。この値は、リクエストごとに新しく生成される高エントロピー値であり、2つの有効なリクエストは圧倒的な確率で異なる値を持ちます。
The mechanism used in TLS for managing differences in Client and server clocks cannot be used as it depends on being able to observe previous interactions. Oblivious HTTP explicitly prevents such linkability.
TLSで使用されるクライアントとサーバーの時計の違いを管理するためのメカニズムは、以前のやり取りを観察できることに依存しているため使用できません。Oblivious HTTPは、そのようなリンク性を明示的に防止します。
The considerations in [RFC8470] as they relate to managing the risk of replay also apply, though there is no option to delay the processing of a request.
[RFC8470]に関連するリプレイのリスクを管理する際の考慮事項も適用されますが、リクエストの処理を遅延させるオプションはありません。
Limiting requests to those with safe methods might not be satisfactory for some applications, particularly those that involve the submission of data to a server. The use of idempotent methods might be of some use in managing replay risk, though it is important to recognize that different idempotent requests can be combined to be not idempotent.
安全なメソッドを使用するリクエストに制限をかけることは、特にデータをサーバーに送信するアプリケーションにとって満足できるものではないかもしれません。再生リスクを管理するために、冪等性のメソッドの使用が役立つ場合がありますが、異なる冪等なリクエストが組み合わされて冪等でなくなることを認識することが重要です。
Even without replay prevention, the server-chosen response_nonce field ensures that responses have unique AEAD keys and nonces even when requests are replayed.
再生防止がなくても、サーバーが選択したresponse_nonceフィールドにより、リクエストが再生された場合でも、レスポンスには一意のAEADキーとnonceが保証されます。
Clients SHOULD include a Date header field in Encapsulated Requests, unless the Client has prior knowledge that indicates that the Oblivious Gateway Resource does not use Date for anti-replay purposes.
クライアントは、忘却ゲートウェイリソースが再生防止のために日付を使用しないことを示す事前の知識がある場合を除き、カプセル化されたリクエストに日付ヘッダーフィールドを含める必要があります。
Though HTTP requests often do not include a Date header field, the value of this field might be used by a server to limit the amount of requests it needs to track if it needs to prevent replay attacks.
HTTPリクエストにはしばしばDateヘッダーフィールドが含まれていませんが、このフィールドの値は、サーバーがリプレイ攻撃を防ぐ必要がある場合に、追跡する必要があるリクエストの量を制限するために使用される可能性があります。
An Oblivious Gateway Resource can maintain state for requests for a small window of time over which it wishes to accept requests. The Oblivious Gateway Resource can store all requests it processes within this window. Storing just the enc field of a request, which should be unique to each request, is sufficient. The Oblivious Gateway Resource can reject any request that is the same as one that was previously answered within that time window or if the Date header field from the decrypted request is outside of the current time window.
Oblivious Gateway Resourceは、リクエストの状態を一定時間保持し、その間にリクエストを受け入れることができます。Oblivious Gateway Resourceは、このウィンドウ内で処理されたすべてのリクエストを保存できます。リクエストのencフィールドのみを保存することが十分です。このencフィールドは、各リクエストごとに一意である必要があります。Oblivious Gateway Resourceは、その時間ウィンドウ内で以前に回答されたリクエストと同じもの、または復号化されたリクエストのDateヘッダーフィールドが現在の時間ウィンドウの外にある場合、リクエストを拒否することができます。
Oblivious Gateway Resources might need to allow for the time it takes requests to arrive from the Client, with a time window that is large enough to allow for differences in clocks. Insufficient tolerance of time differences could result in valid requests being unnecessarily rejected. Beyond allowing for multiple round-trip times -- to account for retransmission -- network delays are unlikely to be significant in determining the size of the window, unless all potential Clients are known to have excellent timekeeping. A specific window size might need to be determined experimentally.
Oblivious Gateway Resourcesは、クライアントからのリクエストが到着する時間を考慮する必要があるかもしれません。時計の違いを考慮するための十分な時間枠が必要です。時間の違いに対する十分な許容度がないと、有効なリクエストが不必要に拒否される可能性があります。再送信を考慮するために複数のラウンドトリップ時間を許可することを超えて、ネットワークの遅延は、すべての潜在的なクライアントが優れた時計を持っていると知られていない限り、ウィンドウのサイズを決定する上で重要ではない可能性があります。特定のウィンドウサイズは実験的に決定する必要があるかもしれません。
Oblivious Gateway Resources MUST NOT treat the time window as secret information. An attacker can actively probe with different values for the Date field to determine the time window over which the server will accept responses.
Oblivious Gateway Resourcesは、時間枠を秘密情報として扱ってはなりません。攻撃者は、Dateフィールドの異なる値で積極的に探査することで、サーバーが応答を受け入れる時間枠を特定できます。
An Oblivious Gateway Resource can reject requests that contain a Date value that is outside of its active window with a 400 series status code. The problem type [PROBLEM] of "https://iana.org/assignments/ http-problem-types#date" is defined to allow the server to signal that the Date value in the request was unacceptable.
Oblivious Gatewayリソースは、アクティブウィンドウ外のDate値を含むリクエストを400シリーズのステータスコードで拒否することができます。問題タイプ[PROBLEM]の"https://iana.org/assignments/http-problem-types#date"は、サーバーがリクエスト内のDate値が受け入れられないことを示すために定義されています。
Figure 8 shows an example response in HTTP/1.1 format.
図8は、HTTP/1.1形式での例の応答を示しています。
HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json
Content-Length: 128
{"type":"https://iana.org/assignments/http-problem-types#date",
"title": "date field in request outside of acceptable range"}
Figure 8: Example Rejection of Request Date Field
図8：リクエスト日付フィールドの拒否例
Disagreements about time are unlikely if both Client and Oblivious Gateway Resource have a good source of time; see [NTP]. However, clock differences are known to be commonplace; see Section 7.1 of [CLOCKSKEW].
時間に関する意見の相違は、クライアントと無関心なゲートウェイリソースの両方が良い時間源を持っている場合には起こりにくいです。ただし、時計の違いは一般的であることが知られています。
Including a Date header field in the response allows the Client to correct clock errors by retrying the same request using the value of the Date field provided by the Oblivious Gateway Resource. The value of the Date field can be copied if the response is fresh, with an adjustment based on the Age field otherwise; see Section 4.2 of [HTTP-CACHING]. When retrying a request, the Client MUST create a fresh encryption of the modified request, using a new HPKE context.
レスポンスにDateヘッダーフィールドを含めることで、クライアントは時計の誤差を修正することができます。同じリクエストを再試行する際に、Oblivious Gateway Resourceが提供するDateフィールドの値を使用します。レスポンスが新鮮な場合は、Dateフィールドの値をコピーし、それ以外の場合はAgeフィールドに基づいて調整します。リクエストを再試行する際、クライアントは新しいHPKEコンテキストを使用して変更されたリクエストの新鮮な暗号化を作成する必要があります。
+---------+ +-------------------+ +----------+
| Client | | Relay and Gateway | | Target |
| | | Resources | | Resource |
+----+----+ +----+-----------+--+ +----+-----+
| | | |
| | | |
| Request | | |
+============================>+------------->|
| | | |
| | | 400 Response |
| | | + Date |
|<============================+<-------------+
| | | |
| Request | | |
| + Updated Date | | |
+============================>+------------->|
| | | |
Figure 9: Retrying with an Updated Date Field
図9：更新された日付フィールドで再試行
Retrying immediately allows the Oblivious Gateway Resource to measure the round-trip time to the Client. The observed delay might reveal something about the location of the Client. Clients could delay retries to add some uncertainty to any observed delay.
直ちに再試行することで、忘却ゲートウェイリソースはクライアントへの往復時間を測定できます。観測された遅延は、クライアントの位置について何かを示すかもしれません。クライアントは再試行を遅らせることで、観測された遅延に不確実性を加えることができます。
Intermediaries can sometimes rewrite the Date field when forwarding responses. This might cause problems if the Oblivious Gateway Resource and intermediary clocks differ by enough to cause the retry to be rejected. Therefore, Clients MUST NOT retry a request with an adjusted date more than once.
中間者は、応答を転送する際に時刻フィールドを書き換えることがあります。これにより、応答ゲートウェイリソースと中間者の時計が十分に異なる場合、再試行が拒否される可能性があります。したがって、クライアントは調整された日付でのリクエストを1回を超えて再試行してはなりません。
Oblivious Gateway Resources that condition their responses on the Date header field SHOULD either ensure that intermediaries do not cache responses (by including a Cache-Control directive of no-store) or designate the response as conditional on the value of the Date request header field (by including the token "date" in a Vary header field).
日付ヘッダーフィールドに応じて応答を条件付ける Oblivious Gateway リソースは、中継者が応答をキャッシュしないようにするか（no-store キャッシュ制御ディレクティブを含めることで）、または応答を Date リクエストヘッダーフィールドの値に応じて条件付けるように指定するべきです（Vary ヘッダーフィールドに "date" トークンを含めることで）。
Clients MUST NOT use the date provided by the Oblivious Gateway Resource for any other purpose, including future requests to any resource. Any request that uses information provided by the Oblivious Gateway Resource might be correlated using that information.
クライアントは、忘却ゲートウェイリソースから提供された日付を、将来のリクエストを含む他の目的に使用してはなりません。忘却ゲートウェイリソースが提供する情報を使用するリクエストは、その情報を使用して相関付けられる可能性があります。
This document does not provide forward secrecy for either requests or responses during the lifetime of the key configuration. A measure of forward secrecy can be provided by generating a new key configuration then deleting the old keys after a suitable period.
この文書は、キー構成の寿命中にリクエストまたはレスポンスのいずれにも先進的な秘匿性を提供しません。先進的な秘匿性の一定の程度は、新しいキー構成を生成し、適切な期間後に古いキーを削除することで提供できます。
This design does not provide post-compromise security for responses.
このデザインは、応答に対するポストコンプロマイズセキュリティを提供しません。
A Client only needs to retain keying material that might be used to compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a Client compromise.
クライアントは、応答の機密性と整合性を危険にさらす可能性のあるキー素材のみを保持する必要があります。その応答が消費されるまで、クライアントの危険に関連するリスクは無視できるレベルです。
A server retains a secret key that might be used to remove protection from messages over much longer periods. A server compromise that provided access to the Oblivious Gateway Resource secret key could allow an attacker to recover the plaintext of all requests sent toward affected keys and all of the responses that were generated.
サーバーは、メッセージの保護を解除するために使用されるかもしれない秘密鍵を保持しています。Oblivious Gateway Resourceの秘密鍵にアクセスできるサーバーの侵害は、影響を受けた鍵に向かって送信されたすべてのリクエストの平文と生成されたすべての応答を攻撃者が回復する可能性があります。
Even if server keys are compromised, an adversary cannot access messages exchanged by the Client with the Oblivious Relay Resource as messages are protected by TLS. Use of a compromised key also requires that the Oblivious Relay Resource cooperate with the attacker or that the attacker is able to compromise these TLS connections.
サーバーキーが侵害されても、クライアントと忘却リレーリソース間で交換されるメッセージにアクセスすることはできません。メッセージはTLSによって保護されています。侵害されたキーの使用には、忘却リレーリソースが攻撃者と協力するか、攻撃者がこれらのTLS接続を侵害する必要があります。
The total number of messages affected by server key compromise can be limited by regular rotation of server keys.
サーバーキーの犯罪によって影響を受けるメッセージの総数は、サーバーキーの定期的なローテーションによって制限できます。
Including a Date field in requests reveals some information about the Client clock. This might be used to fingerprint Clients [UWT] or to identify Clients that are vulnerable to attacks that depend on incorrect clocks.
リクエストに日付フィールドを含めると、クライアントの時計に関する情報が明らかになります。これは、クライアントを識別したり、誤った時計に依存する攻撃に対して脆弱なクライアントを特定するために使用される可能性があります。
Clients can randomize the value that they provide for Date to obscure the true value of their clock and reduce the chance of linking requests over time. However, this increases the risk that their request is rejected as outside the acceptable window.
クライアントは、提供する日付の値をランダム化して、自分の時計の真の値を隠し、時間の経過とともにリクエストをリンクさせる可能性を減らすことができます。ただし、これにより、リクエストが許容範囲外であるとして拒否されるリスクが高まります。
The key configuration media type defined in Section 3.2 represents keying material. The content of this media type is not active (see Section 4.6 of [RFC6838]), but it governs how a Client might interact with an Oblivious Gateway Resource. The security implications of processing it are described in Section 6.1; privacy implications are described in Section 7.
セクション3.2で定義されたキー構成メディアタイプは、キー材料を表します。このメディアタイプの内容はアクティブではありませんが、クライアントが忘却ゲートウェイリソースとやり取りする方法を規定します。それを処理する際のセキュリティ上の考慮事項はセクション6.1に記載されており、プライバシー上の考慮事項はセクション7に記載されています。
The security implications of handling the message media types defined in Section 4.5 is covered in other parts of this section in more detail. However, these message media types are also encrypted encapsulations of HTTP requests and responses.
Section 4.5 で定義されたメッセージメディアタイプの取り扱いに関するセキュリティ上の考慮事項は、このセクションの他の部分で詳細に説明されています。ただし、これらのメッセージメディアタイプは、HTTPリクエストとレスポンスの暗号化されたカプセル化でもあります。
HTTP messages contain content, which can use any media type. In particular, requests are processed by an Oblivious Target Resource, which -- as an HTTP resource -- defines how content is processed; see Section 3.1 of [HTTP]. HTTP clients can also use resource identity and response content to determine how content is processed. Consequently, the security considerations of Section 17 of [HTTP] also apply to the handling of the content of these media types.
HTTPメッセージには、任意のメディアタイプを使用できるコンテンツが含まれています。特に、リクエストはHTTPリソースとして処理されるOblivious Target Resourceによって処理され、コンテンツがどのように処理されるかが定義されます。HTTPクライアントは、リソースの識別子と応答コンテンツも使用して、コンテンツがどのように処理されるかを判断できます。したがって、これらのメディアタイプのコンテンツの取り扱いには、[HTTP]のセクション17のセキュリティに関する考慮事項も適用されます。
This document generally assumes that the same entity operates the Oblivious Gateway Resource and the Target Resource. However, as the Oblivious Gateway Resource performs generic HTTP processing, the use of forwarding cannot be completely precluded.
この文書は、通常、忘却ゲートウェイリソースとターゲットリソースを同じエンティティが運用していると仮定しています。ただし、忘却ゲートウェイリソースが一般的なHTTP処理を実行するため、転送の使用を完全に排除することはできません。
The scheme specified in the Encapsulated Request determines the security requirements for any protocol that is used between the Oblivious Gateway and Target Resources. Using HTTPS is RECOMMENDED; see Section 6.3.
Encapsulated Requestで指定されたスキームは、Oblivious GatewayとTarget Resourcesの間で使用されるプロトコルのセキュリティ要件を決定します。HTTPSの使用が推奨されています。セクション6.3を参照してください。
A Target Resource that is operated on a different server from the Oblivious Gateway Resource is an ordinary HTTP resource. A Target Resource can privilege requests that are forwarded by a given Oblivious Gateway Resource if it trusts the operator of the Oblivious Gateway Resource to only forward requests that meet the expectations of the Target Resource. Otherwise, the Target Resource treats requests from an Oblivious Gateway Resource no differently than any other HTTP client.
Oblivious Gateway Resource とは異なるサーバーで運用されている Target Resource は通常の HTTP リソースです。Target Resource は、Oblivious Gateway Resource が期待に合ったリクエストのみを転送することを信頼している場合、そのリクエストに特権を与えることができます。それ以外の場合、Target Resource は Oblivious Gateway Resource からのリクエストを他のどの HTTP クライアントと同様に扱います。
For instance, an Oblivious Gateway Resource might -- possibly with the help of Oblivious Relay Resources -- be trusted not to forward an excessive volume of requests. This might allow the Target Resource to accept a greater volume of requests from that Oblivious Gateway Resource relative to other HTTP clients.
例えば、Oblivious Gateway Resourceは、おそらくOblivious Relay Resourcesの助けを借りて、過剰なリクエストを転送しないことが信頼されるかもしれません。これにより、Target Resourceは、他のHTTPクライアントに比べて、そのOblivious Gateway Resourceからのリクエストの量を受け入れることができるかもしれません。
An Oblivious Gateway Resource could implement policies that improve the ability of the Target Resource to implement policy exemptions, such as only forwarding requests toward specific Target Resources according to an allowlist; see Section 6.3.
An Oblivious Gateway Resourceは、ターゲットリソースがポリシー例外を実装する能力を向上させるポリシーを実装できます。たとえば、ホワイトリストに従って特定のターゲットリソースにのみリクエストを転送するなどのポリシー例外を実装できます。セクション6.3を参照してください。
One goal of this design is that independent Client requests are only linkable by their content. However, the choice of Client configuration might be used to correlate requests. A Client configuration includes the Oblivious Relay Resource URI, the Oblivious Gateway key configuration, and the Oblivious Gateway Resource URI. A configuration is active if Clients can successfully use it for interacting with a target.
このデザインの目標の1つは、独立したクライアントリクエストがそのコンテンツによってのみリンク可能であることです。ただし、クライアント構成の選択はリクエストを関連付けるために使用される可能性があります。クライアント構成には、Oblivious Relay Resource URI、Oblivious Gateway key configuration、Oblivious Gateway Resource URIが含まれます。構成がアクティブである場合、クライアントはそれを正常に使用してターゲットとやり取りできます。
Oblivious Relay and Gateway Resources can identify when requests use the same configuration by matching the key identifier from the key configuration or the Oblivious Gateway Resource URI. The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator. If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on active configurations that clients use.
Oblivious RelayとGatewayリソースは、リクエストが同じ構成を使用していることを識別できます。キー構成またはOblivious GatewayリソースURIからキー識別子を一致させることによって。Oblivious Gatewayリソースは、同じオペレーターによって実行されるOblivious Relayリソースを使用するリクエストを関連付けるために、リクエストのソースアドレスを使用するかもしれません。Oblivious Gatewayリソースが試行復号を使用することを許可する場合、クライアントが使用するアクティブな構成に基づいて、リクエストをさらに小さなグループに分割できます。
Each active Client configuration partitions the Client anonymity set. In practice, it is infeasible to reduce the number of active configurations to one. Enabling diversity in choice of Oblivious Relay Resource naturally increases the number of active configurations. More than one configuration might need to be active to allow for key rotation and server maintenance.
各アクティブクライアント構成は、クライアントの匿名性セットを分割します。実際には、アクティブな構成の数を1つに減らすことは不可能です。Oblivious Relay Resourceの選択肢の多様性を有効にすると、アクティブな構成の数が自然に増加します。キーのローテーションやサーバーメンテナンスを許可するためには、1つ以上の構成がアクティブである必要があるかもしれません。
Client privacy depends on having each configuration used by many other Clients. It is critical to prevent the use of unique Client configurations, which might be used to track individual Clients, but it is also important to avoid creating small groupings of Clients that might weaken privacy protections.
クライアントのプライバシーは、他の多くのクライアントが使用する各構成に依存しています。個々のクライアントを追跡するために使用されるかもしれない独自のクライアント構成の使用を防ぐことが重要ですが、プライバシー保護を弱める可能性のある小さなクライアントグループを作成することも避けることが重要です。
A specific method for a Client to acquire configurations is not included in this specification. Applications using this design MUST provide accommodations to mitigate tracking using Client configurations. [CONSISTENCY] provides options for ensuring that Client configurations are consistent between Clients.
この仕様には、クライアントが構成を取得するための特定の方法は含まれていません。この設計を使用するアプリケーションは、クライアント構成を使用したトラッキングを軽減するための対応策を提供する必要があります。[CONSISTENCY]は、クライアント構成がクライアント間で一貫していることを確認するためのオプションを提供します。
The content of requests or responses, if used in forming new requests, can be used to correlate requests. This includes obvious methods of linking requests, like cookies [COOKIES], but it also includes any information in either message that might affect how subsequent requests are formulated. For example, [FIELDING] describes how interactions that are individually stateless can be used to build a stateful system when a Client acts on the content of a response.
リクエストまたはレスポンスの内容は、新しいリクエストを形成する際に使用される場合、リクエストを関連付けるために使用できます。これには、クッキーなどの明らかなリクエストのリンク方法が含まれますが、それだけでなく、後続のリクエストがどのように形成されるかに影響を与える可能性のあるメッセージの情報も含まれます。たとえば、[FIELDING]は、個々に状態を持たない相互作用が、クライアントがレスポンスの内容に基づいて行動するときに状態を持つシステムを構築する方法を説明しています。
This section discusses various operational and deployment considerations.
このセクションでは、さまざまな運用および展開に関する考慮事項について説明します。
Using Oblivious HTTP adds both cryptographic overhead and latency to requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between Clients and servers avoids adding significant additional delay due to network topology. A study of a similar system [ODOH-PETS] found that deploying proxies close to servers was most effective in minimizing additional latency.
Oblivious HTTPを使用すると、単純なHTTPリクエスト-レスポンスのやり取りに比べて、暗号化のオーバーヘッドとレイテンシが追加されます。クライアントとサーバーの間にあるパス上にリレーサービスを展開することで、ネットワークトポロジによる追加の遅延を最小限に抑えることができます。類似システムの研究[ODOH-PETS]では、サーバーに近いプロキシを展開することが追加のレイテンシを最小限に抑えるのに最も効果的であることがわかりました。
This protocol assumes a fixed, one-to-one mapping between the Oblivious Relay Resource and the Oblivious Gateway Resource. This means that any Encapsulated Request sent to the Oblivious Relay Resource will always be forwarded to the Oblivious Gateway Resource. This constraint was imposed to simplify relay configuration and mitigate against the Oblivious Relay Resource being used as a generic relay for unknown Oblivious Gateway Resources. The relay will only forward for Oblivious Gateway Resources that it has explicitly configured and allowed.
このプロトコルは、Oblivious Relay リソースと Oblivious Gateway リソースの間に固定の一対一のマッピングがあると仮定しています。これは、Oblivious Relay リソースに送信された任意のカプセル化リクエストが常に Oblivious Gateway リソースに転送されることを意味します。この制約は、リレーの構成を簡素化し、未知の Oblivious Gateway リソースに対して汎用リレーとして使用されることを防ぐために課されました。リレーは、明示的に構成され許可された Oblivious Gateway リソースにのみ転送します。
It is possible for a server to be configured with multiple Oblivious Relay Resources, each for a different Oblivious Gateway Resource as needed. If the goal is to support a large number of Oblivious Gateway Resources, Clients might be provided with a URI template [TEMPLATE], from which multiple Oblivious Relay Resources could be constructed.
サーバーは、必要に応じて異なるOblivious Gateway Resource用に複数のOblivious Relay Resourceを構成することが可能です。大量のOblivious Gateway Resourceをサポートすることが目標である場合、クライアントにはURIテンプレート[TEMPLATE]が提供され、複数のOblivious Relay Resourceを構築することができます。
Oblivious HTTP might be incompatible with network interception regimes, such as those that rely on configuring Clients with trust anchors and intercepting TLS connections. While TLS might be intercepted successfully, interception middlebox devices might not receive updates that would allow Oblivious HTTP to be correctly identified using the media types defined in Sections 9.2 and 9.3.
Oblivious HTTPは、信頼アンカーを設定してTLS接続を傍受するようなネットワーク傍受体制と互換性がない可能性があります。TLSは傍受されるかもしれませんが、傍受中継ボックスデバイスは、9.2節および9.3節で定義されたメディアタイプを使用してOblivious HTTPを正しく識別するための更新を受け取らないかもしれません。
Oblivious HTTP has a simple key management design that is not trivially altered to enable interception by intermediaries. Clients that are configured to enable interception might choose to disable Oblivious HTTP in order to ensure that content is accessible to middleboxes.
Oblivious HTTPは、中間者による傍受を可能にするように簡単に変更されないシンプルなキー管理設計を持っています。傍受を有効にするように構成されたクライアントは、コンテンツがミドルボックスからアクセス可能であることを確認するためにOblivious HTTPを無効にすることを選択するかもしれません。
IANA has registered the following media types in the "Media Types" registry at <https://iana.org/assignments/media-types>, following the procedures of [RFC6838]: "application/ohttp-keys" (Section 9.1), "message/ohttp-req" (Section 9.2), and "message/ohttp-res" (Section 9.3).
IANAは、[RFC6838]の手順に従い、「Media Types」レジストリに次のメディアタイプを登録しました：「application/ohttp-keys」（セクション9.1）、 「message/ohttp-req」（セクション9.2）、および「message/ohttp-res」（セクション9.3）。
IANA has added the following types to the "HTTP Problem Types" registry at <https://iana.org/assignments/http-problem-types>: "date" (Section 9.4) and "ohttp-key" (Section 9.5).
IANAは、次のタイプを「HTTP Problem Types」レジストリに追加しました：<https://iana.org/assignments/http-problem-types>："date"（セクション9.4）および"ohttp-key"（セクション9.5）。
The "application/ohttp-keys" media type identifies a key configuration used by Oblivious HTTP.
"application/ohttp-keys" メディアタイプは、Oblivious HTTP で使用されるキー構成を識別します。
Type name:
入力をそのまま出力します。
application
アプリケーション
Subtype name:
サブタイプ名:
ohttp-keys
ohttp-keys
Required parameters:
必須パラメータ:
N/A
N/A
Optional parameters:
オプションパラメータ:
N/A
N/A
Encoding considerations:
エンコーディングの考慮事項:
"binary"
バイナリ
Security considerations:
セキュリティに関する考慮事項:
See Section 6.9
セクション6.9を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
N/A
Published specification:
公開された仕様書:
RFC 9458
RFC 9458
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
This type identifies a key configuration as used by Oblivious HTTP and applications that use Oblivious HTTP.
このタイプは、Oblivious HTTPおよびOblivious HTTPを使用するアプリケーションで使用されるキー構成を識別します。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
N/A
Additional information:
追加情報:
Magic number(s):
マジックナンバー:
N/A
N/A
Deprecated alias names for this type:
このタイプの非推奨なエイリアス名:
N/A
N/A
File extension(s):
ファイルの拡張子:
N/A
N/A
Macintosh file type code(s):
Macintosh ファイルタイプコード:
N/A
N/A
Person and email address to contact for further information:
さらなる情報を得るための担当者とメールアドレス：
See Authors' Addresses section
著者の住所欄をご覧ください。
Intended usage:
使用目的:
COMMON
共通
Restrictions on usage:
使用制限:
N/A
N/A
Author:
著者
See Authors' Addresses section
著者の住所欄をご覧ください。
Change controller:
コントローラーを変更します。
IETF
IETF
The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in Section 4.3.
"message/ohttp-req"は暗号化されたバイナリHTTPリクエストを識別します。これはセクション4.3で定義されたバイナリ形式です。
Type name:
入力をそのまま出力します。
message
メッセージ
Subtype name:
サブタイプ名:
ohttp-req
ohttp-req
Required parameters:
必須パラメータ:
N/A
N/A
Optional parameters:
オプションパラメータ:
N/A
N/A
Encoding considerations:
エンコーディングの考慮事項:
"binary"
バイナリ
Security considerations:
セキュリティに関する考慮事項:
See Section 6.9
セクション6.9を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
N/A
Published specification:
公開された仕様書:
RFC 9458
RFC 9458
Applications that use this media type:
このメディアタイプを使用するアプリケーション:
Oblivious HTTP and applications that use Oblivious HTTP use this media type to identify encapsulated binary HTTP requests.
Oblivious HTTPおよびOblivious HTTPを使用するアプリケーションは、カプセル化されたバイナリHTTPリクエストを識別するためにこのメディアタイプを使用します。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
N/A
Additional information:
追加情報:
Magic number(s):
マジックナンバー:
N/A
N/A
Deprecated alias names for this type:
このタイプの非推奨なエイリアス名:
N/A
N/A
File extension(s):
ファイルの拡張子:
N/A
N/A
Macintosh file type code(s):
Macintosh ファイルタイプコード:
N/A
N/A
Person and email address to contact for further information:
さらなる情報を得るための担当者とメールアドレス：
See Authors' Addresses section
著者の連絡先欄をご覧ください。
Intended usage:
使用目的:
COMMON
共通
Restrictions on usage:
使用制限:
N/A
N/A
Author:
著者
See Authors' Addresses section
著者の住所欄をご覧ください。
Change controller:
コントローラーを変更します。
IETF
IETF
The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in Section 4.4.
"message/ohttp-res"は暗号化されたバイナリHTTPレスポンスを識別します。これはセクション4.4で定義されたバイナリ形式です。
Type name:
名前を入力してください。
message
メッセージ
Subtype name:
サブタイプ名:
ohttp-res
ohttp-res
Required parameters:
必須パラメータ:
N/A
N/A
Optional parameters:
オプションパラメータ:
N/A
N/A
Encoding considerations:
エンコーディングの考慮事項:
"binary"
バイナリ
Security considerations:
セキュリティに関する考慮事項:
See Section 6.9
セクション6.9を参照してください。
Interoperability considerations:
相互運用性に関する考慮事項:
N/A
N/A
Published specification:
公開された仕様書:
RFC 9458
RFC 9458
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Oblivious HTTP and applications that use Oblivious HTTP use this media type to identify encapsulated binary HTTP responses.
Oblivious HTTPおよびOblivious HTTPを使用するアプリケーションは、このメディアタイプを使用してカプセル化されたバイナリHTTPレスポンスを識別します。
Fragment identifier considerations:
フラグメント識別子の考慮事項:
N/A
N/A
Additional information:
追加情報:
Magic number(s):
マジックナンバー:
N/A
N/A
Deprecated alias names for this type:
このタイプの非推奨なエイリアス名:
N/A
N/A
File extension(s):
ファイルの拡張子:
N/A
N/A
Macintosh file type code(s):
Macintosh ファイルタイプコード:
N/A
N/A
Person and email address to contact for further information:
さらなる情報を得るための連絡先とメールアドレス：
See Authors' Addresses section
著者の住所欄をご覧ください。
Intended usage:
使用目的:
COMMON
共通
Restrictions on usage:
使用制限:
N/A
N/A
Author:
著者
See Authors' Addresses section
著者の住所欄をご覧ください。
Change controller:
コントローラーを変更します。
IETF
IETF
IANA has added a new entry in the "HTTP Problem Types" registry established by [PROBLEM].
IANAは、[PROBLEM]によって設立された「HTTP Problem Types」レジストリに新しいエントリを追加しました。
Type URI:
URIを入力してください。
https://iana.org/assignments/http-problem-types#date
https://iana.org/assignments/http-problem-types#date
Title:
タイトル:
Date Not Acceptable
日付は受け入れられません。
Recommended HTTP Status Code:
推奨されるHTTPステータスコード:
400
400
Reference:
参照:
Section 6.5.2 of RFC 9458
RFC 9458のセクション6.5.2
IANA has added a new entry in the "HTTP Problem Types" registry established by [PROBLEM].
IANAは、[PROBLEM]によって設立された「HTTP Problem Types」レジストリに新しいエントリを追加しました。
Type URI:
URIを入力してください。
https://iana.org/assignments/http-problem-types#ohttp-key
https://iana.org/assignments/http-problem-types#ohttp-key
Title:
タイトル:
Oblivious HTTP key configuration not acceptable
Oblivious HTTPキーの構成は受け入れられません。
Recommended HTTP Status Code:
推奨されるHTTPステータスコード:
400
400
Reference:
参照:
Section 5.3 of RFC 9458
RFC 9458のセクション5.3
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[BINARY] Thomson, M. and C. A. Wood, "Binary Representation of HTTP
Messages", RFC 9292, DOI 10.17487/RFC9292, August 2022,
<https://www.rfc-editor.org/info/rfc9292>.
[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>.
[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[PROBLEM] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/info/rfc9457>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[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>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[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>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>.
[TLS] 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>.
[CLOCKSKEW]
Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R.,
Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz,
"Where the Wild Warnings Are: Root Causes of Chrome HTTPS
Certificate Errors", Proceedings of the 2017 ACM SIGSAC
Conference on Computer and Communications Security,
DOI 10.1145/3133956.3134007, October 2017,
<https://doi.org/10.1145/3133956.3134007>.
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-ietf-privacypass-key-consistency-01,
10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-key-consistency-01>.
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", May 2004,
<https://svn.torproject.org/svn/projects/design-paper/tor-
design.html>.
[FIELDING] Fielding, R. T., "Architectural Styles and the Design of
Network-based Software Architectures", January 2000,
<https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>.
[FORWARDED]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/info/rfc7239>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/info/rfc9230>.
[ODOH-PETS]
Singanamalla, S., Chunhapanya, S., Hoyland, J., Vavruša,
M., Verma, T., Wu, P., Fayed, M., Heimerl, K., Sullivan,
N., and C. A. Wood, "Oblivious DNS over HTTPS (ODoH): A
Practical Privacy Enhancement to DNS", PoPETS Proceedings
Volume 2021, Issue 4, pp. 575-592, DOI 10.2478/popets-
2021-0085, January 2021,
<https://www.petsymposium.org/2021/files/papers/issue4/
popets-2021-0085.pdf>.
[OHTTP-ANALYSIS]
Hoyland, J., "Tamarin Model of Oblivious HTTP", commit
6824eee, October 2022,
<https://github.com/cloudflare/ohttp-analysis>.
[PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust,
and Scalable Computation of Aggregate Statistics", March
2017, <https://crypto.stanford.edu/prio/paper.pdf>.
[RANDOM] 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>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[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>.
[TEMPLATE] 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>.
[UWT] Nottingham, M., "Unsanctioned Web Tracking", W3C TAG
Finding, July 2015,
<https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>.
[X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
A single request and response exchange is shown here. Binary values (key configuration, secret keys, the content of messages, and intermediate values) are shown in hexadecimal. The request and response here are minimal; the purpose of this example is to show the cryptographic operations. In this example, the Client is configured with the Oblivious Relay Resource URI of https://proxy.example.org/request.example.net/proxy, and the proxy is configured to map requests to this URI to the Oblivious Gateway Resource URI https://example.com/oblivious/request. The Target Resource URI, i.e., the resource the Client ultimately wishes to query, is https://example.com.
ここには、1つのリクエストとレスポンスのやり取りが表示されています。バイナリ値（キー構成、秘密鍵、メッセージの内容、中間値）は16進数で表示されています。ここでのリクエストとレスポンスは最小限です。この例の目的は暗号操作を示すことです。この例では、クライアントはhttps://proxy.example.org/request.example.net/proxyのOblivious RelayリソースURIで構成されており、プロキシはこのURIへのリクエストをhttps://example.com/oblivious/requestのOblivious GatewayリソースURIにマッピングするように構成されています。つまり、クライアントが最終的にクエリしたいリソースURIはhttps://example.comです。
To begin the process, the Oblivious Gateway Resource generates a key pair. In this example, the server chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 key pair [X25519]. The X25519 secret key is:
プロセスを開始するために、Oblivious Gateway リソースはキーペアを生成します。この例では、サーバーはDHKEM(X25519, HKDF-SHA256)を選択し、X25519キーペア[X25519]を生成します。X25519の秘密鍵は次の通りです：
3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
The Oblivious Gateway Resource constructs a key configuration that includes the corresponding public key as follows:
The Oblivious Gateway Resource constructs a key configuration that includes the corresponding public key as follows:
01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
79815500080001000100010003
This key configuration is somehow obtained by the Client. Then, when a Client wishes to send an HTTP GET request to the target https://example.com, it constructs the following binary HTTP message:
このキー構成はクライアントによって何らかの方法で取得されます。その後、クライアントがターゲットのhttps://example.com にHTTP GETリクエストを送信したい場合、次のバイナリHTTPメッセージを構築します。
00034745540568747470730b6578616d706c652e636f6d012f
The Client then reads the Oblivious Gateway Resource key configuration and selects a mutually supported KDF and AEAD. In this example, the Client selects HKDF-SHA256 and AES-128-GCM. The Client then generates an HPKE sending context that uses the server public key. This context is constructed from the following ephemeral secret key:
クライアントは、忘却ゲートウェイリソースキーの構成を読み取り、相互にサポートされるKDFとAEADを選択します。この例では、クライアントはHKDF-SHA256とAES-128-GCMを選択します。クライアントは次に、サーバーの公開鍵を使用するHPKE送信コンテキストを生成します。このコンテキストは、次の一時秘密鍵から構築されます：
bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
The corresponding public key is:
対応する公開鍵は：
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
The context is created with an info parameter of:
文脈は、infoパラメーターを使用して作成されます。
6d6573736167652f626874747020726571756573740001002000010001
Applying the Seal operation from the HPKE context produces an encrypted message, allowing the Client to construct the following Encapsulated Request:
HPKEコンテキストからシール操作を適用すると、暗号化されたメッセージが生成され、クライアントが次のカプセル化リクエストを構築できるようになります。
010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
5e7d86b83dd440b2c0185204b4d63525
The Client then sends this to the Oblivious Relay Resource in a POST request, which might look like the following HTTP/1.1 request:
クライアントは、これをPOSTリクエストで忘却リレーリソースに送信します。次のようなHTTP/1.1リクエストになる可能性があります。
POST /request.example.net/proxy HTTP/1.1
Host: proxy.example.org
Content-Type: message/ohttp-req
Content-Length: 78
<content is the Encapsulated Request above>
The Oblivious Relay Resource receives this request and forwards it to the Oblivious Gateway Resource, which might look like:
The Oblivious Relay Resourceはこのリクエストを受け取り、それをOblivious Gateway Resourceに転送します。これは次のように見えるかもしれません：
POST /oblivious/request HTTP/1.1
Host: example.com
Content-Type: message/ohttp-req
Content-Length: 78
<content is the Encapsulated Request above>
The Oblivious Gateway Resource receives this request, selects the key it generated previously using the key identifier from the message, and decrypts the message. As this request is directed to the same server, the Oblivious Gateway Resource does not need to initiate an HTTP request to the Target Resource. The request can be served directly by the Target Resource, which generates a minimal response (consisting of just a 200 status code) as follows:
Oblivious Gateway Resourceは、このリクエストを受信し、メッセージからキー識別子を使用して以前に生成したキーを選択し、メッセージを復号化します。このリクエストが同じサーバーに向けられているため、Oblivious Gateway ResourceはTarget ResourceにHTTPリクエストを開始する必要はありません。リクエストはTarget Resourceによって直接処理され、次のような最小限の応答（200ステータスコードのみで構成される）が生成されます。
0140c8
The response is constructed by exporting a secret from the HPKE context:
応答は、HPKEコンテキストから秘密をエクスポートして構築されます。
62d87a6ba569ee81014c2641f52bea36
The key derivation for the Encapsulated Response uses both the encapsulated KEM key from the request and a randomly selected nonce. This produces a salt of:
Encapsulated Responseの鍵導出には、リクエストからのカプセル化されたKEM鍵とランダムに選択されたnonceが使用されます。これにより、次のようなsaltが生成されます：
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
c789e7151fcba46158ca84b04464910d
The salt and secret are both passed to the Extract function of the selected KDF (HKDF-SHA256) to produce a pseudorandom key of:
選択されたKDF（HKDF-SHA256）のExtract関数には、塩と秘密が両方渡され、疑似ランダムキーが生成されます。
979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db
The pseudorandom key is used with the Expand function of the KDF and an info field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):
疑似乱数鍵は、KDFのExpand関数と"key"の情報フィールドと一緒に使用され、選択されたAEAD（AES-128-GCM）のための16バイトの鍵を生成します。
5d0172a080e428b16d298c4ea0db620d
With the same KDF and pseudorandom key, an info field of "nonce" is used to generate a 12-byte nonce:
同じKDFと擬似乱数鍵を使用して、「nonce」という情報フィールドを使用して12バイトのnonceを生成します。
f6bf1aeb88d6df87007fa263
The AEAD Seal() function is then used to encrypt the response, which is added to the randomized nonce value to produce the Encapsulated Response:
AEAD Seal() 関数は、応答を暗号化するために使用され、ランダム化されたナンス値に追加されて、カプセル化された応答を生成します。
c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
857fbd
The Oblivious Gateway Resource constructs a response with the same content:
The Oblivious Gateway Resource constructs a response with the same content:
HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store
Content-Type: message/ohttp-res
Content-Length: 38
<content is the Encapsulated Response>
The same response might then be generated by the Oblivious Relay Resource, which might change as little as the Date header. The Client is then able to use the HPKE context it created and the nonce from the Encapsulated Response to construct the AEAD key and nonce and decrypt the response.
同じ応答は、忘却リレーリソースによって生成される可能性があり、Dateヘッダーだけが少し変更されるかもしれません。クライアントは、作成したHPKEコンテキストとEncapsulated Responseからのnonceを使用して、AEADキーとnonceを構築し、応答を復号化することができます。
This design is based on a design for Oblivious DNS (queries) over HTTPS (DoH), described in [ODOH]. David Benjamin, Mark Nottingham, and Eric Rescorla made technical contributions. The authors also thank Ralph Giles, Lucas Pardue, and Tommy Pauly for invaluable assistance.
このデザインは、[ODOH]で説明されているOblivious DNS（クエリ）over HTTPS（DoH）のデザインに基づいています。David Benjamin、Mark Nottingham、Eric Rescorlaが技術的な貢献をしました。著者はまた、Ralph Giles、Lucas Pardue、Tommy Paulyに貴重な支援を感謝します。
Martin Thomson
Mozilla
Email: mt@lowentropy.net
Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net