[要約] この文書は、プライバシー分割の原則について説明しており、ユーザーのアイデンティティをユーザーデータから分離することでプライバシーを向上させる手段として、データと通信を複数の当事者に選択的に広げる方法を説明しています。プロトコル間の相互作用を通じてどのデータとメタデータが明らかにされるかを分割するためのプロトコルの新しいパターン、共通の用語、およびそのようなモデルを分析する方法について説明しています。
Internet Architecture Board (IAB) M. Kühlewind
Request for Comments: 9614
Category: Informational T. Pauly
ISSN: 2070-1721
C. A. Wood
July 2024
This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve privacy by separating user identity from user data. This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models.
このドキュメントでは、ユーザーのアイデンティティをユーザーデータから分離することでプライバシーを向上させる手段として、データと通信を複数の当事者に選択的に分散させるプライバシーパーティショニングの原則について説明します。このドキュメントでは、プロトコルの相互作用を通じてどのデータやメタデータが明らかにされるかを分割するためのプロトコルにおける新たなパターンについて説明し、一般的な用語を提供し、そのようなモデルを分析する方法について論じます。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは Internet Standards Track の仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Architecture Board (IAB) の成果物であり、IAB が恒久的な記録として提供する価値があると判断した情報を表しています。これは Internet Architecture Board (IAB) のコンセンサスを表しています。IAB によって公開が承認されたドキュメントは、いかなるレベルのインターネット標準の候補にもなりません。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/rfc9614.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9614 で入手できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2024 IETF Trust および文書の著者として特定された人物。All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78 および IETF ドキュメントに関連する IETF トラストの法的規定（https://trustee.ietf.org/license-info）の、このドキュメントの発行日において有効なものの対象となります。これらのドキュメントは、このドキュメントに関する権利と制限について説明しているため、注意深く確認してください。
1. Introduction
2. Privacy Partitioning
2.1. Privacy Contexts
2.2. Context Separation
2.3. Approaches to Partitioning
3. A Survey of Protocols Using Partitioning
3.1. CONNECT Proxying and MASQUE
3.2. Oblivious HTTP and DNS
3.3. Privacy Pass
3.4. Privacy Preserving Measurement
4. Applying Privacy Partitioning
4.1. User-Identifying Information
4.2. Selecting Client Identifiers
4.3. Incorrect or Incomplete Partitioning
4.4. Selecting Information within a Context
5. Limits of Privacy Partitioning
5.1. Violations by Collusion
5.2. Violations by Insufficient or Incorrect Partitioning
5.2.1. Violations from Application Information
5.2.2. Violations from Network Information
5.2.3. Violations from Side Channels
5.2.4. Identifying Partitions
6. Partitioning Impacts
7. Security Considerations
8. IANA Considerations
9. Informative References
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses
Protocols such as TLS and IPsec provide a secure (authenticated and encrypted) channel between two endpoints over which endpoints transfer information. Encryption and authentication of data in transit are necessary to protect information from being seen or modified by parties other than the intended protocol participants. As such, this kind of security is necessary for ensuring that information transferred over these channels remains private.
TLS や IPsec などのプロトコルは、エンドポイントが情報を転送する 2 つのエンドポイント間で安全な（認証および暗号化された）チャネルを提供します。転送中のデータの暗号化と認証は、意図したプロトコル参加者以外の当事者によって情報が見られたり変更されたりしないように保護するために必要です。そのため、この種のセキュリティは、これらのチャネルを介して転送される情報のプライバシーを維持するために必要です。
However, a secure channel between two endpoints is insufficient for the privacy of the endpoints themselves. In recent years, privacy requirements have expanded beyond the need to protect data in transit between two endpoints. Some examples of this expansion include:
しかし、2 つのエンドポイント間のセキュアなチャネルだけでは、エンドポイント自体のプライバシーには不十分です。近年、プライバシー要件は、2 つのエンドポイント間の転送中のデータを保護する必要性を超えて拡大しています。この拡張のいくつかの例は次のとおりです。
* A user accessing a service on a website might not consent to reveal their location, but if that service is able to observe the client's IP address, it can learn something about the user's location. This is problematic for privacy since the service can link user data to the user's location.
* ウェブサイト上のサービスにアクセスするユーザーは、自分の位置情報を明らかにすることに同意していないかもしれませんが、そのサービスがクライアントの IP アドレスを観測できる場合、ユーザーの位置情報について何かを知ることができます。サービスはユーザーデータをユーザーの位置情報に紐付けることができるため、これはプライバシー上の問題となります。
* A user might want to be able to access content for which they are authorized, such as a news article; but the news service might track which users access which articles, even if the user doesn't want their activity to be tracked. This is problematic for privacy since the service can link user activity to the user's account.
* ユーザーは、ニュース記事など、アクセス権限のあるコンテンツにアクセスしたいと考えるかもしれませんが、ユーザーが自分のアクティビティを追跡されたくない場合でも、ニュースサービスはどのユーザーがどの記事にアクセスしたかを追跡する可能性があります。サービスはユーザーのアクティビティをユーザーのアカウントに紐付けることができるため、これはプライバシー上の問題となります。
* A client device might need to upload metrics to an aggregation service and in doing so allow the service to attribute the specific metrics contributions to that client device. This is problematic for privacy since the service can link client contributions to the specific client.
* クライアントデバイスは、メトリクスを集約サービスにアップロードする必要がある場合がありますが、そうすることで、サービスが特定のメトリクスの提供元をそのクライアントデバイスに特定できるようになる可能性があります。サービスはクライアントからの提供データを特定のクライアントに紐付けることができるため、これはプライバシー上の問題となります。
The commonality in these examples is that clients want to interact with or use a service without exposing too much user-specific or identifying information to that service. In particular, separating the user-specific identity information from user-specific data is necessary for privacy. Thus, in order to protect user privacy, it is important to keep identity (who) and data (what) separate.
これらの例の共通点は、クライアントがユーザー固有情報や識別情報をそのサービスに過度に公開することなく、サービスと対話したり、サービスを利用したりしたいということです。特に、ユーザー固有の識別情報をユーザー固有のデータから分離することは、プライバシーにとって必要です。したがって、ユーザーのプライバシーを保護するためには、アイデンティティ（誰が）とデータ（何を）を分離しておくことが重要です。
This document defines "privacy partitioning," sometimes also referred to as the "decoupling principle" [DECOUPLING], as the general technique used to separate the data and metadata visible to various parties in network communication, with the aim of improving user privacy. Although privacy partitioning cannot guarantee there is no link between user-specific identity and user-specific data, when applied properly it helps ensure that user privacy violations become more technically difficult to achieve over time.
このドキュメントでは、「分離の原則 (decoupling principle)」[DECOUPLING] とも呼ばれる「プライバシーパーティショニング」を、ユーザーのプライバシーを向上させることを目的として、ネットワーク通信においてさまざまな当事者に見えるデータとメタデータを分離するために使用される一般的な手法として定義します。プライバシーパーティショニングは、ユーザー固有のアイデンティティとユーザー固有のデータの間にリンクがないことを保証することはできませんが、適切に適用されれば、ユーザーのプライバシー侵害を技術的に達成することをより困難にするのに役立ちます。
Several IETF working groups are working on protocols or systems that adhere to the principle of privacy partitioning, including Oblivious HTTP Application Intermediation (OHAI), Multiplexed Application Substrate over QUIC Encryption (MASQUE), Privacy Pass, and Privacy Preserving Measurement (PPM). This document summarizes work in those groups and describes a framework for thinking about the resulting privacy posture of different endpoints in practice.
いくつかの IETF ワーキンググループは、Oblivious HTTP Application Intermediation (OHAI)、Multiplexed Application Substrate over QUIC Encryption (MASQUE)、Privacy Pass、Privacy Preserving Measurement (PPM) など、プライバシーパーティショニングの原則に従うプロトコルやシステムに取り組んでいます。このドキュメントは、これらのグループでの作業を要約し、実際のさまざまなエンドポイントのプライバシー姿勢について考えるためのフレームワークを説明しています。
Privacy partitioning is particularly relevant as a tool for data minimization, which is described in Section 6.1 of [RFC6973]. [RFC6973] provides guidance for privacy considerations in Internet protocols, along with a set of questions on how to evaluate the data minimization of a protocol in Section 7.1 of [RFC6973]. Protocols that employ privacy partitioning ought to consider the questions in that section when evaluating their design, particularly with regard to how identifiers and data can be correlated by protocol participants and observers in each context that has been partitioned. Privacy partitioning can also be used as a way to separate identity providers from relying parties (see Section 6.1.4 of [RFC6973]), as in the case of Privacy Pass (see Section 3.3).
プライバシーパーティショニングは、[RFC6973] のセクション 6.1 で説明されているデータ最小化のツールとして特に関連しています。[RFC6973] は、[RFC6973] のセクション 7.1 におけるプロトコルのデータ最小化を評価する方法に関する一連の質問とともに、インターネットプロトコルにおけるプライバシーの考慮事項に関するガイダンスを提供します。プライバシーパーティショニングを採用するプロトコルは、特に分割された各コンテキストにおいてプロトコルの参加者や観測者が識別子とデータをどのように紐付けることができるかに関して、設計を評価する際にそのセクションの質問を考慮すべきです。プライバシーパーティショニングは、Privacy Pass の場合（セクション 3.3 を参照）のように、ID プロバイダーを Relying Party から分離する方法として使用することもできます（[RFC6973] のセクション 6.1.4 を参照）。
Privacy partitioning is not a panacea; applying it well requires holistic analysis of the system in question to determine whether or not partitioning as a tool, and as implemented, offers meaningful privacy improvements. See Section 5 for more information.
プライバシーパーティショニングは万能薬ではありません。これを適切に適用するには、ツールとしてのパーティショニング、およびその実装が有意義なプライバシーの改善を提供するかどうかを判断するために、対象となるシステムの全体的な分析が必要です。詳細については、セクション 5 を参照してください。
For the purposes of user privacy, this document focuses on user-specific information. This might include any identifying information that is specific to a user, such as their email address or IP address, or any data about the user, such as their date of birth. Informally, the goal of privacy partitioning is to ensure that each party in a system beyond the user themselves only has access to one type of user-specific information.
ユーザープライバシーの目的のために、このドキュメントはユーザー固有の情報に焦点を当てています。これには、電子メールアドレスや IP アドレスなど、ユーザーに固有の識別情報、または生年月日などのユーザーに関するデータが含まれる場合があります。非公式には、プライバシーパーティショニングの目標は、ユーザー自身以外のシステム内の各当事者が、1 種類のユーザー固有情報にのみアクセスできるようにすることです。
This is a simple application of the principle of least privilege, wherein every party in a system only has access to the minimum amount of information needed to fulfill their function. Privacy partitioning advocates for this minimization by ensuring that protocols, applications, and systems only reveal user-specific information to parties that need access to the information for their intended purpose.
これは、システム内のすべての当事者がその機能を果たすために必要な最小限の情報にのみアクセスできるようにするという、最小特権の原則の単純な適用です。プライバシーパーティショニングは、プロトコル、アプリケーション、およびシステムが、意図した目的のために情報にアクセスする必要がある当事者にのみユーザー固有情報を明らかにすることを保証することにより、この最小化を推奨します。
Put simply, privacy partitioning aims to separate _who_ someone is from _what_ they do. In the rest of this section, we describe how privacy partitioning can be used to achieve this goal.
簡単に言えば、プライバシーパーティショニングは、「誰か (who)」を「何をしているか (what)」から分離することを目的としています。このセクションの残りの部分では、この目標を達成するためにプライバシーパーティショニングを使用する方法について説明します。
Each piece of user-specific information exists within some context, where a context is abstractly defined as a set of data, metadata, and the entities that share access to that information. In order to prevent the correlation of user-specific information across contexts, partitions need to ensure that any single entity (other than the client itself) does not participate in more than one context where the information is visible.
ユーザー固有の各情報は、あるコンテキストの中に存在します。コンテキストは、データ、メタデータ、およびその情報へのアクセスを共有するエンティティのセットとして抽象的に定義されます。コンテキスト間でユーザー固有の情報の紐付けを防ぐために、パーティションは、単一のエンティティ（クライアント自体以外）が、その情報が見える複数のコンテキストに参加しないようにする必要があります。
[RFC6973] discusses the importance of identifiers in reducing correlation as a way of improving privacy:
[RFC6973] は、プライバシーを向上させる方法として、相関 (correlation) を減らす際の識別子の重要性について論じています。
Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined....
相関 (Correlation) とは、個人に関連するさまざまな情報の組み合わせ、または組み合わせることでそのような特性を持つようになる情報の組み合わせのことです...
Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing individuals' activities to be tracked and combined over time....
相関は識別と密接に関連しています。インターネットプロトコルは、個人の活動を時間の経過とともに追跡して組み合わせることを可能にすることで、相関を促進できます...
Pseudonymity is strengthened when less personal data can be linked to the pseudonym; when the same pseudonym is used less often and across fewer contexts; and when independently chosen pseudonyms are more frequently used for new actions (making them, from an observer's or attacker's perspective, unlinkable).
仮名にリンクできる個人データが少ない場合、同じ仮名が使用される頻度が低く、使用されるコンテキストが少ない場合、そして新しいアクションに対して独立して選択された仮名がより頻繁に使用される場合（観測者や攻撃者の視点からリンク不可能にする）、仮名性は強化されます。
Context separation is foundational to privacy partitioning and reducing correlation. As an example, consider an unencrypted HTTP session over TCP, wherein the context includes both the content of the transaction as well as any metadata from the transport and IP headers; and the participants include the client, routers, other network middleboxes, intermediaries, and the server. Middleboxes or intermediaries might simply forward traffic or might terminate the traffic at any layer (such as terminating the TCP connection from the client and creating another TCP connection to the server). Regardless of how the middlebox interacts with the traffic, for the purposes of privacy partitioning, it is able to observe all of the data in the context.
コンテキストの分離は、プライバシーパーティショニングと相関の削減の基礎です。例として、TCP を介した暗号化されていない HTTP セッションを考えてみましょう。コンテキストには、トランザクションの内容と、トランスポートおよび IP ヘッダーからのメタデータの両方が含まれます。参加者には、クライアント、ルーター、その他のネットワークミドルボックス、仲介者、およびサーバーが含まれます。ミドルボックスや仲介者は、単にトラフィックを転送する場合もあれば、任意のレイヤーでトラフィックを終端する場合もあります（クライアントからの TCP 接続を終端し、サーバーへの別の TCP 接続を作成するなど）。ミドルボックスがトラフィックとどのように相互作用するかに関わらず、プライバシーパーティショニングの観点からは、ミドルボックスはそのコンテキスト内のすべてのデータを観測できることになります。
+-------------------------------------------------------------------+
| Context A |
| +--------+ +-----------+ +--------+ |
| | +------HTTP------+ +--------------+ | |
| | Client | | Middlebox | | Server | |
| | +------TCP-------+ +--------------+ | |
| +--------+ flow +-----------+ +--------+ |
| |
+-------------------------------------------------------------------+
Figure 1: Diagram of a Basic Unencrypted Client-to-Server Connection with Middleboxes
図1：ミドルボックスを含む、基本的な暗号化されていないクライアント・サーバー接続の図
Adding TLS encryption to the HTTP session is a simple partitioning technique that splits the previous context into two separate contexts. The content of the transaction is now only visible to the client, TLS-terminating intermediaries, and server, while the metadata in transport and IP headers remain in the original context. In this scenario, without any further partitioning, the entities that participate in both contexts can allow the data in both contexts to be correlated.
HTTP セッションに TLS 暗号化を追加することは、以前のコンテキストを 2 つの別々のコンテキストに分割する単純なパーティショニング手法です。トランザクションのコンテンツは、クライアント、TLS を終端する仲介者、およびサーバーにのみ見えるようになりましたが、トランスポートおよび IP ヘッダーのメタデータは元のコンテキストに残ります。このシナリオでは、それ以上のパーティショニングを行わない限り、両方のコンテキストに参加するエンティティは、両方のコンテキストのデータを紐付けることができます。
+-------------------------------------------------------------------+
| Context A |
| +--------+ +--------+ |
| | | | | |
| | Client +-------------------HTTPS-------------------+ Server | |
| | | | | |
| +--------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Context B |
| +--------+ +-----------+ +--------+ |
| | | | | | | |
| | Client +-------TCP------+ Middlebox +--------------+ Server | |
| | | flow | | | | |
| +--------+ +-----------+ +--------+ |
| |
+-------------------------------------------------------------------+
Figure 2: Diagram of How Adding Encryption Splits the Context into Two
図2：暗号化の追加によりコンテキストが 2 つに分割される様子の図
Another way to create a partition is to simply use separate connections. For example, to split two separate HTTP requests from one another, a client could issue the requests on separate TCP connections, each on a different network and at different times, and avoid including obvious identifiers like HTTP cookies across the requests.
パーティションを作成する別の方法は、単純に個別の接続を使用することです。たとえば、2 つの個別の HTTP リクエストを互いに分割するために、クライアントは、それぞれ異なるネットワークと異なる時間に、個別の TCP 接続でリクエストを発行し、リクエスト間で HTTP Cookie などの明白な識別子を含めることを避けることができます。
+-------------------------------------------------------------------+
| Context A |
| +--------+ +-----------+ +--------+ |
| | | IP A | | | | |
| | Client +-------TCP------+ Middlebox +--------------+ Server | |
| | | flow A | A | | | |
| +--------+ +-----------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Context B |
| +--------+ +-----------+ +--------+ |
| | | IP B | | | | |
| | Client +-------TCP------+ Middlebox +--------------+ Server | |
| | | flow B | B | | | |
| +--------+ +-----------+ +--------+ |
| |
+-------------------------------------------------------------------+
Figure 3: Diagram of Making Separate Connections to Generate Separate Contexts
図3：個別のコンテキストを生成するために個別の接続を作成する図
Using separate connections to create separate contexts can reduce or eliminate the ability of specific parties to correlate activity across contexts. However, any identifier at any layer that is common across different contexts can be used as a way to correlate activity. Beyond IP addresses, many other factors can be used together to create a fingerprint of a specific device (such as Media Access Control (MAC) addresses, device properties, software properties and behavior, application state, etc.).
個別の接続を使用して個別のコンテキストを作成すると、特定の当事者がコンテキスト間でアクティビティを紐付ける能力を低下または排除できます。ただし、さまざまなコンテキストで共通する任意のレイヤーの識別子は、アクティビティを紐付ける方法として使用できます。IP アドレス以外にも、特定のデバイスのフィンガープリントを作成するために、他の多くの要素（メディアアクセス制御 (MAC) アドレス、デバイスのプロパティ、ソフトウェアのプロパティと動作、アプリケーションの状態など）を組み合わせて使用できます。
In order to define and analyze how various partitioning techniques work, the boundaries of what is being partitioned need to be established. This is the role of context separation. In particular, in order to prevent the correlation of user-specific information across contexts, partitions need to ensure that any single entity (other than the client itself) does not participate in contexts where both identifiers are visible.
さまざまなパーティショニング技術がどのように機能するかを定義および分析するには、分割されているものの境界を確立する必要があります。これがコンテキスト分離の役割です。特に、コンテキスト間でユーザー固有の情報の紐付けを防ぐために、パーティションは、単一のエンティティ（クライアント自体以外）が両方の識別子が見えるコンテキストに参加しないことを確認する必要があります。
Context separation can be achieved in different ways, for example, over time, across network paths, based on (en)coding, etc. The privacy-oriented protocols described in this document generally involve more complex partitioning, but the techniques to partition communication contexts still employ the same techniques:
コンテキスト分離は、たとえば、（エン）コーディングなどに基づいて、ネットワークパス全体や時間の経過とともに、さまざまな方法で達成できます。このドキュメントで説明するプライバシー指向のプロトコルは、一般により複雑なパーティショニングを伴いますが、通信コンテキストを分割する技術は依然として同じ手法を採用しています。
* Cryptographic protection, such as the use of encryption to specific parties, allows partitioning of contexts between different parties (those with the ability to remove cryptographic protections, and those without).
* 特定の当事者への暗号化の使用などの暗号化保護により、さまざまな当事者（暗号化保護を解除する能力があるものとないもの）間のコンテキストを分割することができます。
* Connection separation across time or space to allow partitioning of contexts for different application transactions over the network.
* ネットワーク上のさまざまなアプリケーショントランザクションのコンテキストを分割するための、時間的または空間的な接続の分離。
These techniques are frequently used in conjunction for context separation. For example, encrypting an HTTP exchange using TLS between the client and TLS-terminating server might prevent a network middlebox that sees a client IP address from seeing the user account identifier, but it doesn't prevent the TLS-terminating server from observing both identifiers and correlating them. As such, preventing correlation requires separating contexts, such as by using proxying to conceal a client's IP address that would otherwise be used as an identifier.
これらの手法は、コンテキスト分離のために頻繁に組み合わせて使用されます。たとえば、クライアントと TLS 終端サーバーの間で TLS を使用して HTTP 交換を暗号化すると、クライアント IP アドレスを見るネットワークミドルボックスがユーザーアカウント識別子を見るのを防ぐことができますが、TLS 終端サーバーが両方の識別子を観測し、それらを紐付けることを防ぐことはできません。そのため、紐付けを防ぐには、プロキシを使用して、識別子として使用される可能性のあるクライアントの IP アドレスを隠すなど、コンテキストを分離する必要があります。
While all of the partitioning protocols described in this document create separate contexts using cryptographic protection and/or connection separation, each one has a unique approach that results in different sets of contexts. Since many of these protocols are new, it is yet to be seen how each approach will be used at scale across the Internet and what new models will emerge in the future.
このドキュメントで説明されているすべてのパーティショニングプロトコルは、暗号化保護および/または接続分離を使用して個別のコンテキストを作成しますが、それぞれに異なるコンテキストセットをもたらす独自のアプローチがあります。これらのプロトコルの多くは新しいため、各アプローチがインターネット全体で大規模にどのように使用されるか、そして将来どのような新しいモデルが出現するかはまだわかりません。
There are multiple factors that lead to a diversity in approaches to partitioning, including:
パーティショニングへのアプローチの多様性につながる複数の要因があります。これには以下が含まれます。
* Adding privacy partitioning to existing protocol ecosystems places requirements and constraints on how contexts are constructed. CONNECT-style proxying is intended to work with servers that are unaware of privacy contexts, requiring more intermediaries to provide strong separation guarantees. On the other hand, Oblivious HTTP assumes servers that cooperate with context separation and, thus, reduces the overall number of elements in the solution.
* 既存のプロトコルエコシステムにプライバシーパーティショニングを追加すると、コンテキストの構築方法に要件と制約が課されます。CONNECT スタイルのプロキシは、プライバシーコンテキストを認識しないサーバーと連携することを意図しており、強力な分離保証を提供するためにより多くの仲介者を必要とします。一方、Oblivious HTTP は、コンテキスト分離に協力するサーバーを想定しているため、ソリューション内の要素の総数を削減します。
* Whether or not information exchange needs to happen bidirectionally in an interactive fashion determines how contexts can be separated. Some use cases, like metrics collection for PPM, can occur whereby information only flows from clients to servers and can function even when clients are no longer connected. Privacy Pass is an example of a case that can be either interactive or not, depending on whether tokens can be cached and reused. CONNECT-style proxying and Oblivious HTTP often require bidirectional and interactive communication.
* 情報交換がインタラクティブな方法で双方向に行われる必要があるかどうかによって、コンテキストをどのように分離できるかが決まります。PPM のメトリクス収集などの一部のユースケースでは、情報はクライアントからサーバーへのみ流れ、クライアントが接続されなくなった後でも機能する場合があります。Privacy Pass は、トークンをキャッシュして再利用できるかどうかに応じて、インタラクティブにも非インタラクティブにもなり得るケースの例です。CONNECT スタイルのプロキシと Oblivious HTTP は、多くの場合、双方向かつインタラクティブな通信を必要とします。
* The degree to which contexts need to be partitioned depends in part on the client's threat models and level of trust in various protocol participants. For example, in Oblivious HTTP, clients allow relays to learn that clients are accessing a particular application-specific gateway. If clients do not trust relays with this information, they can instead use a multi-hop CONNECT-style proxy approach wherein no single party learns whether specific clients are accessing a specific application. This is the default trust model for systems like Tor, where multiple hops are used to drive down the probability of privacy violations due to collusion or related attacks.
* コンテキストをどの程度分割する必要があるかは、クライアントの脅威モデルと、さまざまなプロトコル参加者に対する信頼レベルに部分的に依存します。たとえば、Oblivious HTTP では、クライアントは、クライアントが特定のアプリケーション固有のゲートウェイにアクセスしていることをリレーが知ることを許可します。クライアントがこの情報に関してリレーを信頼しない場合は、代わりにマルチホップ CONNECT スタイルのプロキシアプローチを使用できます。この場合、特定のクライアントが特定のアプリケーションにアクセスしているかどうかを単一の当事者が知ることはありません。これは Tor のようなシステムのデフォルトの信頼モデルであり、複数のホップを使用して、共謀や関連する攻撃によるプライバシー違反の確率を低減します。
The following section discusses current on-going work in the IETF that is applying privacy partitioning.
次のセクションでは、プライバシーパーティショニングを適用している IETF での現在の進行中の作業について説明します。
When using encryption on the connection between the client and the proxy, HTTP forward proxies provide privacy partitioning by separating a connection into multiple segments. When connections to targets via the proxy themselves are encrypted, the proxy cannot see the end-to-end content. HTTP has historically supported forward proxying for TCP-like streams via the CONNECT method. More recently, the Multiplexed Application Substrate over QUIC Encryption (MASQUE) Working Group has developed protocols to similarly proxy UDP [CONNECT-UDP] and IP packets [CONNECT-IP] based on tunneling.
クライアントとプロキシ間の接続で暗号化を使用する場合、HTTP フォワードプロキシは、接続を複数のセグメントに分離することにより、プライバシーパーティショニングを提供します。プロキシ自体を介してターゲットへの接続が暗号化されている場合、プロキシはエンドツーエンドのコンテンツを見ることができません。HTTP は、CONNECT メソッドを介して TCP のようなストリームのフォワードプロキシを歴史的にサポートしてきました。最近では、Multiplexed Application Substrate over QUIC Encryption (MASQUE) ワーキンググループが、トンネリングに基づいて UDP [CONNECT-UDP] および IP パケット [CONNECT-IP] を同様にプロキシするためのプロトコルを開発しました。
In a single-proxy setup, there is a tunnel connection between the client and proxy and an end-to-end connection that is tunneled between the client and target. This setup, as shown in Figure 4, partitions communication into:
単一プロキシのセットアップでは、クライアントとプロキシの間にトンネル接続があり、クライアントとターゲットの間にトンネルが付けられたエンドツーエンドの接続があります。図4に示すように、このセットアップは、通信を次のように分割します。
* a Client-to-Target encrypted context, which contains the end-to-end content within the TLS session to the target, such as HTTP content;
* HTTP コンテンツなど、ターゲットへの TLS セッション内のエンドツーエンドコンテンツを含む Client-to-Target 暗号化コンテキスト。
* a Client-to-Target proxied context, which is the end-to-end data exchanged with the target that is also visible to the proxy, such as a TLS session;
* TLS セッションなど、プロキシにも見えるターゲットと交換されるエンドツーエンドのデータである Client-to-Target プロキシコンテキスト。
* a Client-to-Proxy context, which contains the transport metadata between the client and the target, and the request to the proxy to open a connection to the target; and
* クライアントとターゲットの間のトランスポートメタデータと、ターゲットへの接続を開くプロキシへの要求を含む Client-to-Proxy コンテキスト。そして
* a Proxy-to-Target context, which for TCP and UDP proxying contains any packet header information that is added or modified by the proxy, e.g., the IP and TCP/UDP headers.
* TCP および UDP プロキシの場合、プロキシによって追加または変更されるパケットヘッダー情報（IP および TCP/UDP ヘッダーなど）を含む Proxy-to-Target コンテキスト。
+-------------------------------------------------------------------+
| Client-to-Target Encrypted Context |
| +--------+ +--------+ |
| | | | | |
| | Client +------------------HTTPS--------------------+ Target | |
| | | content | | |
| +--------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Client-to-Target Proxied Context |
| +--------+ +-----------+ +--------+ |
| | | | | | | |
| | Client +----Proxied-----+ Proxy +--------------+ Target | |
| | | TLS flow | | | | |
| +--------+ +-----------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Client-to-Proxy Context |
| +--------+ +-----------+ |
| | | | | |
| | Client +---Transport----+ Proxy | |
| | | flow | | |
| +--------+ +-----------+ |
| |
+-------------------------------------------------------------------+
| Proxy-to-Target Context |
| +-----------+ +--------+ |
| | | | | |
| | Proxy +--Transport---+ Target | |
| | | flow | | |
| +-----------+ +--------+ |
| |
+-------------------------------------------------------------------+
Figure 4: Diagram of One-Hop Proxy Contexts
図4：ワンホッププロキシコンテキストの図
Using two (or more) proxies provides better privacy partitioning. In particular, with two proxies, each proxy sees the Client metadata but not the Target, the Target but not the Client metadata, or neither.
2 つ（またはそれ以上）のプロキシを使用すると、プライバシーパーティショニングが向上します。特に、2 つのプロキシを使用すると、各プロキシはクライアントメタデータを見るがターゲットは見ない、ターゲットを見るがクライアントメタデータは見ない、あるいはそのどちらも見ない、という状態になります。
In addition to the contexts described above for the single proxy case, the two-hop proxy case shown in Figure 5 changes the contexts in several ways:
単一のプロキシケースについて上記のコンテキストに加えて、図 5 に示す 2 ホッププロキシケースは、いくつかの方法でコンテキストを変更します。
* the Client-to-Target proxied context only includes the second proxy (referred to here as "Proxy B");
* Client-to-Target プロキシコンテキストには、2 番目のプロキシ（ここでは「Proxy B」と呼びます）のみが含まれます。
* a new Client-to-Proxy B context is added, which is the TLS session from the client to Proxy B that is also visible to the first proxy (referred to here as "Proxy A");
* 新しい Client-to-Proxy B コンテキストが追加されます。これは、クライアントから Proxy B への TLS セッションであり、最初のプロキシ（ここでは「Proxy A」と呼びます）にも見えます。
* the contexts that see transport data only (TCP or UDP over IP) are separated out into three separate contexts, a Client-to-Proxy A context, a Proxy A-to-Proxy B context, and a Proxy B-to-Target context.
* トランスポートデータのみ（TCP または UDP over IP）を見るコンテキストは、3 つの別々のコンテキスト、Client-to-Proxy A コンテキスト、Proxy A-to-Proxy B コンテキスト、および Proxy B-to-Target コンテキストに分離されます。
+-------------------------------------------------------------------+
| Client-to-Target Encrypted Context |
| +--------+ +--------+ |
| | | | | |
| | Client +------------------HTTPS--------------------+ Target | |
| | | content | | |
| +--------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Client-to-Target Proxied Context |
| +--------+ +-------+ +--------+ |
| | | | | | | |
| | Client +----------Proxied----------+ Proxy +-------+ Target | |
| | | TLS flow | B | | | |
| +--------+ +-------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Client-to-Proxy B Context |
| +--------+ +-------+ +-------+ |
| | | | | | | |
| | Client +---------+ Proxy +---------+ Proxy | |
| | | | A | | B | |
| +--------+ +-------+ +-------+ |
| |
+-------------------------------------------------------------------+
| Client-to-Proxy A Context |
| +--------+ +-------+ |
| | | | | |
| | Client +---------+ Proxy | |
| | | | A | |
| +--------+ +-------+ |
| |
+-------------------------------------------------------------------+
| Proxy A-to-Proxy B Context |
| +-------+ +-------+ |
| | | | | |
| | Proxy +---------+ Proxy | |
| | A | | B | |
| +-------+ +-------+ |
| |
+-------------------------------------------------------------------+
| Proxy B-to-Target Context |
| +-------+ +--------+ |
| | | | | |
| | Proxy +-------+ Target | |
| | B | | | |
| +-------+ +--------+ |
| |
+-------------------------------------------------------------------+
Figure 5: Diagram of Two-Hop Proxy Contexts
図5：2ホッププロキシコンテキストの図
Forward proxying, such as the modes of proxying in the protocols developed in MASQUE, uses both encryption (via TLS) and separation of connections (via proxy hops that see only the next hop) to achieve privacy partitioning.
MASQUE で開発されたプロトコルにおけるプロキシモードのようなフォワードプロキシは、プライバシーパーティショニングを実現するために、暗号化（TLS 経由）と接続の分離（次のホップしか見えないプロキシホップ経由）の両方を使用します。
Oblivious HTTP [OHTTP], developed in the Oblivious HTTP Application Intermediation (OHAI) Working Group, adds per-message encryption to HTTP exchanges through a relay system. Clients send requests through an Oblivious Relay, which cannot read message contents, to an Oblivious Gateway, which can decrypt the messages but cannot communicate directly with the client or observe client metadata like an IP address. Oblivious HTTP relies on Hybrid Public Key Encryption [HPKE] to perform encryption.
Oblivious HTTP Application Intermediation (OHAI) ワーキンググループで開発された Oblivious HTTP [OHTTP] は、リレーシステムを通じて HTTP 交換にメッセージごとの暗号化を追加します。クライアントは、メッセージの内容を読み取ることができない Oblivious Relay を介して、Oblivious Gateway にリクエストを送信します。Oblivious Gateway はメッセージを復号できますが、クライアントと直接通信したり、IP アドレスなどのクライアントメタデータを観測したりすることはできません。Oblivious HTTP は、暗号化を実行するために Hybrid Public Key Encryption [HPKE] に依存しています。
Oblivious HTTP uses both encryption and separation of connections to achieve privacy partitioning.
Oblivious HTTP は、暗号化と接続の分離の両方を使用して、プライバシーパーティショニングを実現します。
* End-to-end messages are encrypted between the Client and Gateway. The content of these inner messages are visible to the Client, Gateway, and Target. This is the Client-to-Target context.
* エンドツーエンドのメッセージは、クライアントとゲートウェイの間で暗号化されます。これらの内側のメッセージの内容は、クライアント、ゲートウェイ、およびターゲットに見えます。これは Client-to-Target コンテキストです。
* The encrypted messages exchanged between the Client and Gateway are visible to the Relay, but the Relay cannot decrypt the messages. This is the Client-to-Gateway context.
* クライアントとゲートウェイの間で交換される暗号化されたメッセージはリレーに見えますが、リレーはメッセージを復号することはできません。これは Client-to-Gateway コンテキストです。
* The transport (such as TCP and TLS) connections between the Client, Relay, and Gateway form two separate contexts: a Client-to-Relay context and a Relay-to-Gateway context. It is important to note that the Relay-to-Gateway connection can be a single connection, even if the Relay has many separate Clients. This provides better anonymity by making the pseudonym presented by the Relay to be shared across many Clients.
* クライアント、リレー、ゲートウェイ間のトランスポート（TCP や TLS など）接続は、Client-to-Relay コンテキストと Relay-to-Gateway コンテキストという 2 つの別々のコンテキストを形成します。リレーが多数の個別のクライアントを抱えている場合でも、Relay-to-Gateway 接続は単一の接続になり得ることに注意することが重要です。これにより、リレーによって提示される仮名が多数のクライアント間で共有されることになり、より高い匿名性が提供されます。
+-------------------------------------------------------------------+
| Client-to-Target Context |
| +--------+ +---------+ +--------+ |
| | | | | | | |
| | Client +---------------------------+ Gateway +-----+ Target | |
| | | | | | | |
| +--------+ +---------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Client-to-Gateway Context |
| +--------+ +-------+ +---------+ |
| | | | | | | |
| | Client +---------+ Relay +---------+ Gateway | |
| | | | | | | |
| +--------+ +-------+ +---------+ |
| |
+-------------------------------------------------------------------+
| Client-to-Relay Context |
| +--------+ +-------+ |
| | | | | |
| | Client +---------+ Relay | |
| | | | | |
| +--------+ +-------+ |
| |
+-------------------------------------------------------------------+
| Relay-to-Gateway Context |
| +-------+ +---------+ |
| | | | | |
| + Relay +---------+ Gateway | |
| | | | | |
| +-------+ +---------+ |
| |
+-------------------------------------------------------------------+
Figure 6: Diagram of Oblivious HTTP Contexts
図6：Oblivious HTTP コンテキストの図
Oblivious DNS over HTTPS (ODoH) [ODOH] applies the same principle as Oblivious HTTP but operates on DNS messages only. As a precursor to the more generalized Oblivious HTTP, it relies on the same HPKE cryptographic primitives and can be analyzed in the same way.
Oblivious DNS over HTTPS (ODoH) [ODOH] は、Oblivious HTTP と同じ原則を適用しますが、DNS メッセージのみで動作します。より一般化された Oblivious HTTP の前身として、同じ HPKE 暗号プリミティブに依存しており、同じ方法で分析できます。
Privacy Pass is an architecture [RFC9576] and a set of protocols being developed in the Privacy Pass Working Group that allows clients to present proof of verification in an anonymous and unlinkable fashion via tokens. These tokens were originally designed as a way to prove that a client had solved a CAPTCHA, but they can be applied to other types of user or device attestation checks as well. In Privacy Pass, clients interact with an attester and issuer for the purposes of issuing a token, and clients then interact with an origin server to redeem said token.
Privacy Pass は、アーキテクチャ [RFC9576] であり、Privacy Pass ワーキンググループで開発されている一連のプロトコルです。これにより、クライアントはトークンを介して匿名かつリンク不可能な方法で検証の証明を提示できます。これらのトークンはもともと、クライアントが CAPTCHA を解決したことを証明する方法として設計されていましたが、他のタイプのユーザーまたはデバイスの証明チェックにも適用できます。Privacy Pass では、クライアントはトークンを発行する目的で Attester および Issuer と対話し、その後、クライアントはオリジンサーバーと対話してそのトークンを利用 (redeem) します。
In Privacy Pass, privacy partitioning is achieved with cryptographic protection (in the form of blind signature protocols or similar) and separation of connections across two contexts: a "redemption context" between clients and origins (servers that request and receive tokens), and an "issuance context" between clients, attestation servers, and token issuance servers. The cryptographic protection ensures that information revealed during the issuance context is separated from information revealed during the redemption context.
Privacy Pass では、プライバシーパーティショニングは、暗号化保護（ブラインド署名プロトコルなどの形式で）と 2 つのコンテキストにわたる接続の分離によって達成されます。クライアントとオリジン（トークンを要求および受信するサーバー）間の「償還コンテキスト (redemption context)」、およびクライアント、Attestation サーバー、トークン発行サーバー間の「発行コンテキスト (issuance context)」です。暗号化保護により、発行コンテキスト中に明らかにされた情報が、償還コンテキスト中に明らかにされた情報から分離されます。
+-------------------------------------------------------------------+
| Redemption Context |
| +--------+ +--------+ |
| | | | | |
| | Origin +---------+ Client | |
| | | | | |
| +--------+ +--------+ |
| |
+-------------------------------------------------------------------+
| Issuance Context |
| +--------+ +----------+ +--------+ |
| | | | | | | |
| | Client +------+ Attester +------+ Issuer | |
| | | | | | | |
| +--------+ +----------+ +--------+ |
| |
+-------------------------------------------------------------------+
Figure 7: Diagram of Contexts in Privacy Pass
図7：プライバシーパスのコンテキストの図
Since the redemption context and issuance context are separate connections that involve separate entities, they can also be further decoupled by running those parts of the protocols at different times. Clients can fetch tokens through the issuance context early and cache the tokens for later use in redemption contexts. This can aid in partitioning identifiers and data.
償還コンテキストと発行コンテキストは、個別のエンティティを含む個別の接続であるため、プロトコルのそれらの部分を異なる時期に実行することでさらに分離することもできます。クライアントは、発行コンテキストを通じて事前にトークンを取得し、後の償還コンテキストで使用するためにトークンをキャッシュできます。これは、識別子とデータの分割に役立ちます。
[RFC9576] describes different deployment models for which entities operate origins, attesters, and issuers; in some models, they are all separate entities, and in others they can be operated by the same entity. The model impacts the effectiveness of partitioning, and some models (such as when all three are operated by the same entity) only provide effective partitioning when the timing of connections on the two contexts are not correlated and when the client uses different identifiers (such as different IP addresses) on each context.
[RFC9576] は、エンティティがオリジン、Attester、および Issuer を運用するさまざまな展開モデルを説明しています。一部のモデルでは、それらはすべて別個のエンティティであり、他のモデルでは同じエンティティによって運用される可能性があります。モデルはパーティショニングの有効性に影響を与え、一部のモデル（3 つすべてが同じエンティティによって運用されている場合など）は、2 つのコンテキストでの接続のタイミングが相関しておらず、クライアントが各コンテキストで異なる識別子（異なる IP アドレスなど）を使用する場合にのみ、効果的なパーティショニングを提供します。
The Privacy Preserving Measurement (PPM) Working Group is chartered to develop protocols and systems that help a data aggregation or collection server (or multiple non-colluding servers) compute aggregate values without learning the value of any one client's individual measurement. The Distributed Aggregation Protocol (DAP) is the primary working item of the group.
Privacy Preserving Measurement (PPM) ワーキンググループは、データ集約または収集サーバー（または複数の共謀しないサーバー）が、いずれかのクライアントの個々の測定値を知ることなく集約値を計算するのに役立つプロトコルとシステムを開発するために設立されました。Distributed Aggregation Protocol (DAP) は、このグループの主要な作業項目です。
At a high level, DAP uses a combination of cryptographic protection (in the form of secret sharing amongst non-colluding servers) to establish two contexts:
高レベルでは、DAP は、暗号化保護（共謀しないサーバー間での秘密分散の形式）の組み合わせを使用して、2 つのコンテキストを確立します。
* an "upload context" between clients and non-colluding aggregation servers (in which the servers are separated into "Helper" and "Leader" roles) wherein aggregation servers possibly learn client identity but nothing about their individual measurement reports; and
* クライアントと共謀しない集約サーバー（サーバーは「Helper」と「Leader」の役割に分かれています）間の「アップロードコンテキスト」。ここでは、集約サーバーはクライアントのアイデンティティを知る可能性がありますが、個々の測定レポートについては何も知りません。そして
* a "collect context" wherein a collector learns aggregate measurement results and nothing about individual client data.
* コレクターが集計された測定結果を知るものの、個々のクライアントデータについては何も知らない「収集コンテキスト (collect context)」。
+-------------------------------------+--------------------+
| Upload Context | Collect Context |
| +------------+ | |
| +----->| Helper | | |
| +--------+ | +------------+ | |
| | +---+ ^ | +-----------+ |
| | Client | | | | Collector | |
| | +---+ v | +-----+-----+ |
| +--------+ | +------------+ | | |
| +----->| Leader |<-----------+ |
| +------------+ | |
+-------------------------------------+--------------------+
Figure 8: Diagram of Contexts in DAP
図8：DAPのコンテキストの図
Applying privacy partitioning to an existing or new system or protocol requires the following steps:
プライバシーパーティショニングを既存または新しいシステムまたはプロトコルに適用するには、次の手順が必要です。
1. Identify the types of information used or exposed in a system or protocol, some of which can be used to identify a user or correlate to other contexts.
1. システムまたはプロトコルで使用または公開されている情報の種類を特定します。その一部は、ユーザーを識別したり、他のコンテキストと紐付けたりするために使用できる可能性があります。
2. Partition data to minimize the amount of user-identifying or correlatable information in any given context to only include what is necessary for that context and prevent the sharing of data across contexts wherever possible.
2. データを分割し、特定のコンテキストにおけるユーザー識別情報や紐付け可能な情報の量を、そのコンテキストに必要なものだけに最小化し、可能な限りコンテキスト間でのデータ共有を防ぎます。
The most impactful types of information to partition are (a) user-identifying information, such as user identifiers (including account names or IP addresses) that can be linked and (b) non-user-identifying information (including content a user generates or accesses), which can be often sensitive when combined with a user identifier.
分割すべき最も影響力のある情報の種類は、(a) リンク可能なユーザー識別子（アカウント名や IP アドレスを含む）などのユーザー識別情報、および (b) 非ユーザー識別情報（ユーザーが生成またはアクセスするコンテンツを含む）です。後者はユーザー識別子と組み合わされると、多くの場合センシティブな情報となります。
In this section, we discuss considerations for partitioning these types of information.
このセクションでは、これらのタイプの情報を分割するための考慮事項について説明します。
User data can itself be user-identifying, in which case it should be treated as an identifier. For example, Oblivious DoH and Oblivious HTTP partition the client IP address and client request data into separate contexts, thereby ensuring that no entity beyond the client can observe both. Collusion across contexts could reverse this partitioning and cause non-user-identifying information to become user-identifying information. For example, in CONNECT proxy systems that use QUIC, the QUIC connection ID is inherently non-user-identifying since it is generated randomly (Section 5.1 of [QUIC]). However, if combined with another context that has user-identifying information such as the client IP address, the QUIC connection ID can become user-identifying information.
ユーザーデータ自体がユーザー識別情報となる場合があり、その場合は識別子として扱う必要があります。たとえば、Oblivious DoH と Oblivious HTTP は、クライアント IP アドレスとクライアントリクエストデータを別々のコンテキストに分割し、それによってクライアント以外のエンティティがその両方を観測できないようにします。コンテキスト間での共謀は、このパーティショニングを覆し、非ユーザー識別情報をユーザー識別情報に変えてしまう可能性があります。たとえば、QUIC を使用する CONNECT プロキシシステムでは、QUIC 接続 ID はランダムに生成されるため、本質的に非ユーザー識別情報です（[QUIC] のセクション 5.1）。ただし、クライアント IP アドレスなどのユーザー識別情報を持つ別のコンテキストと組み合わせると、QUIC 接続 ID はユーザー識別情報になり得ます。
Some information is innate to client user-agents, including details of the network location and implementation of protocols in hardware and software. This information can be used to construct user-identifying information, which is a process sometimes referred to as "fingerprinting". Depending on the application and system constraints, users may not be able to prevent fingerprinting in privacy contexts. As a result, fingerprinting information, when combined with non-user-identifying user data, could turn that otherwise innocuous user data into user-identifying information.
一部の情報は、ネットワークの場所の詳細やハードウェアとソフトウェアにおけるプロトコルの実装など、クライアントのユーザーエージェントに固有のものです。この情報は、ユーザー識別情報を構築するために使用でき、このプロセスは「フィンガープリント」と呼ばれることがあります。アプリケーションとシステムの制約によっては、ユーザーはプライバシーコンテキストでのフィンガープリントを防ぐことができない場合があります。その結果、フィンガープリント情報は、非ユーザー識別ユーザーデータと組み合わされると、それ自体は無害なユーザーデータをユーザー識別情報に変えてしまう可能性があります。
The selection of client identifiers used in the contexts used for privacy partitioning has a large impact on the effectiveness of partitioning. Identifier selection can either undermine or improve the value of partitioning. Generally, each context involves some form of client identifier, which might be directly associated with a client identity but can also be a pseudonym or a random one-time identifier.
プライバシーパーティショニングに使用されるコンテキストでのクライアント識別子の選択は、パーティショニングの有効性に大きな影響を与えます。識別子の選択は、パーティショニングの価値を損なうこともあれば、高めることもあります。一般に、各コンテキストには何らかの形のクライアント識別子が含まれます。これはクライアントのアイデンティティに直接関連付けられている場合もあれば、仮名やランダムなワンタイム識別子である場合もあります。
Using the same client identifier across multiple contexts can partly or wholly undermine the effectiveness of partitioning by allowing the various contexts to be linked back to the same client. For example, if a client uses proxies as described in Section 3.1 to separate connections but uses the same email address to authenticate to two servers in different contexts, those actions can be linked back to the same client. While this does not undermine all of the partitioning achieved through proxying (the contexts along the network path still cannot correlate the client identity and what servers are being accessed), the overall effect of partitioning is diminished.
複数のコンテキストで同じクライアント識別子を使用すると、さまざまなコンテキストを同じクライアントに紐付けられるようにしてしまい、パーティショニングの有効性を部分的または完全に損なう可能性があります。たとえば、セクション 3.1 で説明されているようにプロキシを使用して接続を分離していても、異なるコンテキストにある 2 つのサーバーへの認証に同じメールアドレスを使用する場合、それらのアクションは同じクライアントに紐付けることができます。これは、プロキシを通じて達成されるパーティショニングのすべてを損なうわけではありませんが（ネットワークパス上のコンテキストは、依然としてクライアントのアイデンティティとアクセス先のサーバーを紐付けることはできません）、パーティショニングの全体的な効果は減少します。
When possible, using per-context unique client identifiers provides better partitioning properties. For example, a client can use a unique email address as an account identifier with each different server it needs to log into. The same approach can apply across many layers, as seen with per-network MAC address randomization [RANDOM-MAC], use of multiple temporary IP addresses across connections and over time [RFC8981], and use of unique per-subscription identifiers for HTTP Web Push [RFC8030].
可能であれば、コンテキストごとに一意のクライアント識別子を使用すると、より良いパーティショニング特性が得られます。たとえば、クライアントは、ログインする必要があるサーバーごとに、アカウント識別子として一意のメールアドレスを使用できます。ネットワークごとの MAC アドレスのランダム化 [RANDOM-MAC]、接続間および時間経過に伴う複数の一時的な IP アドレスの使用 [RFC8981]、HTTP Web Push [RFC8030] におけるサブスクリプションごとの一意な識別子の使用に見られるように、同じアプローチを多くのレイヤーに適用できます。
Privacy partitioning can be applied incorrectly or incompletely. Contexts may contain more user-identifying information than desired, or some information in a context may be more user-identifying than intended. Moreover, splitting user-identifying information over multiple contexts has to be done with care, as creating more contexts can increase the number of entities that need to be trusted to not collude. Nevertheless, partitions can help improve the client's privacy posture when applied carefully.
プライバシーパーティショニングは、誤ってまたは不完全に適用される可能性があります。コンテキストには、望ましいよりも多くのユーザー識別情報が含まれる場合や、コンテキスト内の一部の情報が意図したよりもユーザー識別性が高い場合があります。さらに、より多くのコンテキストを作成することは、共謀しないと信頼しなければならないエンティティの数を増やす可能性があるため、ユーザー識別情報を複数のコンテキストに分割することは慎重に行う必要があります。それにもかかわらず、慎重に適用すれば、パーティションはクライアントのプライバシー姿勢を改善するのに役立ちます。
Evaluating and qualifying the resulting privacy of a system or protocol that applies privacy partitioning depends on the contexts that exist and the types of user-identifying information in each context. Such evaluation is helpful for identifying ways in which systems or protocols can improve their privacy posture. For example, consider DNS over HTTPS [DOH], which produces a single context that contains both the client IP address and client query. One application of privacy partitioning results in ODoH, which produces two contexts, one with the client IP address and the other with the client query.
プライバシーパーティショニングを適用するシステムまたはプロトコルの結果として生じるプライバシーを評価および認定することは、存在するコンテキストと各コンテキストにおけるユーザー識別情報の種類に依存します。このような評価は、システムまたはプロトコルがプライバシー姿勢を改善できる方法を特定するのに役立ちます。たとえば、クライアント IP アドレスとクライアントクエリの両方を含む単一のコンテキストを生成する DNS over HTTPS [DOH] を考えてみましょう。プライバシーパーティショニングの適用例の 1 つが ODoH であり、これは 2 つのコンテキスト（一方はクライアント IP アドレスを含み、もう一方はクライアントクエリを含む）を生成します。
Recognizing potential applications of privacy partitioning requires identifying the contexts in use, the information exposed in a context, and the intent of information exposed in a context. Unfortunately, determining what information to include in a given context is a non-trivial task. In principle, the information contained in a context should be fit for purpose. As such, new systems or protocols developed should aim to ensure that all information exposed in a context serves as few purposes as possible. Designing with this principle from the start helps mitigate issues that arise if users of the system or protocol inadvertently ossify on the information available in contexts. Legacy systems that have ossified on information available in contexts may be difficult to change in practice. As an example, many existing anti-abuse systems depend on some client identifier, such as the client IP address, coupled with client data to provide value. Partitioning contexts in these systems such that they no longer determine the client identity requires new solutions to the anti-abuse problem.
プライバシーパーティショニングの潜在的な適用可能性を認識するには、使用中のコンテキスト、コンテキストで公開される情報、およびコンテキストで公開される情報の意図を特定する必要があります。残念ながら、特定のコンテキストにどの情報を含めるかを決定することは、容易なタスクではありません。原則として、コンテキストに含まれる情報は目的に適合している必要があります。そのため、開発される新しいシステムまたはプロトコルは、コンテキストで公開されるすべての情報が可能な限り少ない目的を果たすようにすることを目指すべきです。最初からこの原則に基づいて設計することは、システムやプロトコルのユーザーがコンテキストで利用可能な情報に不注意に依存し固定化 (ossify) してしまう場合に生じる問題を軽減するのに役立ちます。コンテキストで利用可能な情報に固定化してしまったレガシーシステムは、実際には変更が難しい場合があります。例として、多くの既存の不正行為防止システムは、クライアント IP アドレスなどのクライアント識別子とクライアントデータを組み合わせて価値を提供することに依存しています。これらのシステムにおいて、もはやクライアントのアイデンティティを特定できないようにコンテキストを分割するには、不正行為防止の問題に対する新しいソリューションが必要になります。
Privacy partitioning aims to increase user privacy, though, as stated, it is merely one of possibly many architectural tools that help manage privacy risks. Understanding the limits of its benefits requires a more comprehensive analysis of the system in question. Such analysis also helps determine whether or not the tool has been applied correctly. In particular, the value of privacy partitioning depends on numerous factors, including, though not limited to, the following:
プライバシーパーティショニングはユーザーのプライバシーを向上させることを目的としていますが、前述のように、これはプライバシーリスクの管理に役立つ可能性のある多くのアーキテクチャツールの 1 つにすぎません。その利点の限界を理解するには、対象となるシステムのより包括的な分析が必要です。このような分析は、ツールが正しく適用されているかどうかを判断するのにも役立ちます。特に、プライバシーパーティショニングの価値は、以下を含む（ただしこれらに限定されない）多くの要因に依存します。
* non-collusion across contexts and
* コンテキスト間での非共謀、および
* the type of information exposed in each context.
* 各コンテキストで公開される情報のタイプ。
We elaborate on each in the following sections.
次のセクションでそれぞれについて詳しく説明します。
Privacy partitions ensure that only the client, i.e., the entity that is responsible for partitioning, can independently link all user-specific information. No other entity individually knows how to link all the user-specific information as long as they do not collude with each other across contexts. Thus, non-collusion is a fundamental requirement for privacy partitioning to offer meaningful privacy for end users. In particular, the trust relationships that users have with different parties affect the resulting impact on the user's privacy.
プライバシーパーティションにより、クライアント、つまりパーティショニングを担当するエンティティのみが、すべてのユーザー固有情報を独立してリンクできるようになります。他のどのエンティティも、コンテキスト間で互いに共謀しない限り、すべてのユーザー固有情報をリンクする方法を単独で知ることはありません。したがって、非共謀は、プライバシーパーティショニングがエンドユーザーに有意義なプライバシーを提供するための基本的な要件です。特に、ユーザーが異なる当事者と持つ信頼関係は、結果として生じるユーザーのプライバシーへの影響を左右します。
As an example, consider Oblivious HTTP (OHTTP), wherein the Oblivious Relay knows the client identity but not the client data, and the Oblivious Gateway knows the client data but not the client identity. If the Oblivious Relay and Gateway collude, they can link client identity and data together for each request and response transaction by simply observing requests in transit.
例として、Oblivious HTTP (OHTTP) を考えます。ここでは、Oblivious Relay はクライアントのアイデンティティを知っていますがクライアントデータは知らず、Oblivious Gateway はクライアントデータを知っていますがクライアントのアイデンティティは知りません。もし Oblivious Relay と Gateway が共謀すれば、転送中のリクエストを単に観測するだけで、各リクエストとレスポンスのトランザクションについてクライアントのアイデンティティとデータを紐付けることができます。
It is not currently possible to guarantee with technical protocol measures that two entities are not colluding. Even if two entities do not collude directly, if both entities reveal information to other parties, it will not be possible to guarantee that the information won't be combined. However, there are some mitigations that can be applied to reduce the risk of collusion happening in practice:
現在、2 つのエンティティが共謀していないことを技術的なプロトコル対策で保証することは不可能です。2 つのエンティティが直接共謀しない場合でも、両方のエンティティが他の当事者に情報を公開する場合、情報が組み合わされないことを保証することはできません。ただし、実際に発生する共謀のリスクを減らすために適用できるいくつかの緩和策があります。
* Policy and contractual agreements between entities involved in partitioning to disallow logging or sharing of data, along with auditing to validate that the policies are being followed. For cases where logging is required (such as for service operation), such logged data should be minimized and anonymized to prevent it from being useful for collusion.
* データのロギングまたは共有を禁止するための、パーティショニングに関与するエンティティ間のポリシーおよび契約上の合意、ならびにポリシーが遵守されていることを検証するための監査。ロギングが必要な場合（サービス運用など）、そのようなログデータは、共謀に利用されるのを防ぐために最小化および匿名化されるべきです。
* Protocol requirements to make collusion or data sharing more difficult.
* 共謀またはデータ共有をより困難にするためのプロトコル要件。
* Adding more partitions and contexts to make it increasingly difficult to collude with enough parties to recover identities.
* パーティションとコンテキストを追加し、アイデンティティを復元するために十分な数の当事者と共謀することをますます困難にする。
Insufficient or incorrect application of privacy partitioning can lessen or negate benefits to users. In particular, it is possible to apply partitioning in a way that is either insufficient or incorrect for meaningful privacy. For example, partitioning at one layer in the stack can fail to account for linkable information at different layers in the stack. Privacy violations can stem from partitioning failures in a multitude of ways, some of which are described in the following sections.
プライバシーパーティショニングの不十分または誤った適用は、ユーザーへの利益を減少または無効にする可能性があります。特に、有意義なプライバシーにとって不十分または不正確な方法でパーティショニングを適用してしまう可能性があります。たとえば、スタックのあるレイヤーでのパーティショニングは、スタックの異なるレイヤーにあるリンク可能な情報を考慮できていない可能性があります。プライバシー侵害は、さまざまな形でのパーティショニングの失敗に起因する可能性があり、その一部を以下のセクションで説明します。
Partitioning at the network layer can be insufficient when the application layer fails to properly partition. As an example, consider OHTTP used for the purposes of hiding client-identifying information for a browser telemetry system. It is entirely possible for reports in such a telemetry system to contain both client-specific telemetry data, such as information about their specific browser instance, as well as client-identifying information, such as the client's email address, location, or IP address. Even though OHTTP separates the client IP address from the server via a relay, the server can still learn this directly from the client's telemetry report.
ネットワークレイヤーでのパーティショニングは、アプリケーションレイヤーが適切にパーティショニングを行わない場合、不十分になる可能性があります。例として、ブラウザテレメトリシステムにおいてクライアント識別情報を隠すために使用される OHTTP を考えてみましょう。このようなテレメトリシステムのレポートには、特定のブラウザインスタンスに関する情報などのクライアント固有のテレメトリデータと、クライアントの電子メールアドレス、場所、IP アドレスなどのクライアント識別情報の両方が含まれる可能性が十分にあります。OHTTP はリレーを介してクライアント IP アドレスをサーバーから分離しますが、サーバーはクライアントのテレメトリレポートから直接これを知ることができます。
It is also possible to inadequately partition at the network layer. As an example, consider both TLS Encrypted Client Hello (ECH) [TLS-ESNI] and VPNs. ECH uses cryptographic protection (encryption) to hide information from unauthorized parties, but both clients and servers (two entities) can link user-specific data to a user-specific identifier (IP address). Similarly, while VPNs hide identifiers from end servers, the VPN server can still see the identifiers of both the client and server. Applying privacy partitioning would advocate for at least two additional entities to avoid revealing both identity (who) and user actions (what) from each involved party.
ネットワークレイヤーでのパーティショニングが不十分になる可能性もあります。例として、TLS Encrypted Client Hello (ECH) [TLS-ESNI] と VPN の両方を考えてみましょう。ECH は暗号化保護（暗号化）を使用して権限のない当事者から情報を隠しますが、クライアントとサーバー（2 つのエンティティ）の両方がユーザー固有データをユーザー固有識別子（IP アドレス）に紐付けることができます。同様に、VPN はエンドサーバーから識別子を隠しますが、VPN サーバーは依然としてクライアントとサーバーの両方の識別子を見ることができます。プライバシーパーティショニングを適用する場合、関与する各当事者に対してアイデンティティ（誰が）とユーザーアクション（何を）の両方が明らかになるのを避けるために、少なくとも 2 つの追加エンティティの使用が推奨されます。
Beyond the information that is intentionally revealed by applying privacy partitioning, it is also possible for the information to be unintentionally revealed through side channels. For example, in the two-hop proxy arrangement described in Section 3.1, Proxy A sees and proxies TLS data between the client and Proxy B. While it does not directly learn information that Proxy B sees, it does learn information through metadata, such as the timing and size of encrypted data being proxied. Traffic analysis could be exploited to learn more information from such metadata, including, in some cases, application data that Proxy A was never meant to see. Although privacy partitioning does not obviate such attacks, it does increase the cost necessary to carry them out in practice. See Section 7 for more discussion on this topic.
プライバシーパーティショニングを適用することで意図的に明らかにされる情報以外に、サイドチャネルを通じて情報が意図せず明らかになる可能性もあります。たとえば、セクション 3.1 で説明した 2 ホッププロキシの構成では、Proxy A はクライアントと Proxy B の間の TLS データを見てプロキシします。Proxy A は Proxy B が見る情報を直接知ることはありませんが、プロキシされる暗号化データのタイミングやサイズなどのメタデータを通じて情報を知ることになります。トラフィック分析を悪用して、そのようなメタデータからより多くの情報を知ることが可能であり、場合によっては、Proxy A が決して見ることを意図されていなかったアプリケーションデータが含まれることもあります。プライバシーパーティショニングはそのような攻撃を排除するものではありませんが、実際にそれらを実行するために必要なコストを増大させます。このトピックの詳細については、セクション 7 を参照してください。
While straightforward violations of user privacy that stem from insufficient partitioning may seem straightforward to mitigate, it remains an open problem to rigorously determine what information needs to be partitioned for meaningful privacy and to implement it in a way that achieves the desired properties. In essence, it is difficult to determine whether a certain set of information reveals "too much" about a specific user, and it is similarly challenging to determine whether or not an implementation of partitioning works as intended. There is ample evidence of data being assumed "private" or "anonymous" but, in hindsight, winds up revealing too much information such that it allows one to link back to individual clients; see [DataSetReconstruction] and [CensusReconstruction] for more examples of this in the real world.
不十分なパーティショニングに起因するユーザープライバシーの単純な侵害は、軽減するのが簡単に思えるかもしれませんが、有意義なプライバシーのためにどの情報を分割する必要があるかを厳密に決定し、望ましい特性を達成する方法でそれを実装することは、依然として未解決の問題です。本質的に、特定の情報セットが特定のユーザーについて「多すぎる」情報を明らかにしているかどうかを判断することは困難であり、パーティショニングの実装が意図したとおりに機能しているかどうかを判断することも同様に困難です。データが「プライベート」または「匿名」であると想定されていたものの、後になってみれば、個々のクライアントに紐付けられるほど多くの情報を明らかにしていたという十分な証拠があります。現実世界におけるこの例については、[DataSetReconstruction] および [CensusReconstruction] を参照してください。
Applying privacy partitioning to communication protocols leads to a substantial change in communication patterns. For example, instead of sending traffic directly to a service, essentially all user traffic is routed through a set of intermediaries, possibly adding more end-to-end round trips in the process (depending on the system and protocol). This has a number of practical implications, described below.
プライバシーパーティショニングを通信プロトコルに適用すると、通信パターンが大幅に変化します。たとえば、トラフィックをサービスに直接送信する代わりに、基本的にすべてのユーザートラフィックは一連の仲介者を介してルーティングされ、プロセスにエンドツーエンドのラウンドトリップが追加される可能性があります（システムとプロトコルによって異なります）。これには、以下で説明する多くの実際的な影響があります。
1. Service operational or management challenges: Information that is usually passively observed in the network or metadata that has been unintentionally revealed to the service provider will no longer be available; for example, this can impact existing security procedures such as application rate limiting or DDoS mitigation. Current network management techniques deployed often rely on information that is exposed by typical traffic that lacks guarantees or accuracy.
1. サービスの運用または管理の課題：通常ネットワーク内で受動的に観測される情報や、サービスプロバイダーに意図せず明らかにされていたメタデータは、もはや利用できなくなります。たとえば、これはアプリケーションレート制限や DDoS 緩和などの既存のセキュリティ手順に影響を与える可能性があります。現在展開されているネットワーク管理手法は、保証や正確性を欠く典型的なトラフィックによって公開される情報に依存していることがよくあります。
Privacy partitioning provides an opportunity for improvements in these management techniques by enabling active exchange of information with each entity in a privacy-preserving way and requesting exactly the information needed for a specific task or function rather than relying on information derived from a limited set of unintentionally revealed information that cannot be guaranteed to be available and may be removed in the future.
プライバシーパーティショニングは、プライバシーを保護する方法で各エンティティとの積極的な情報交換を可能にし、利用可能性が保証されず将来削除される可能性のある、意図せず明らかにされた限られた情報のセットから派生した情報に依存するのではなく、特定のタスクまたは機能に必要な情報だけを正確に要求することにより、これらの管理手法を改善する機会を提供します。
2. Varying performance effects and costs: Depending on how context separation is done, privacy partitioning may affect application performance. As an example, Privacy Pass introduces an entire end-to-end round trip to issue a token before it can be redeemed, thereby decreasing performance. In contrast, while systems like CONNECT proxying may seem like they would reduce performance, oftentimes the highly optimized nature of proxy-to-proxy paths leads to improved performance.
2. パフォーマンスへの影響とコストの変化：コンテキスト分離の方法によっては、プライバシーパーティショニングがアプリケーションのパフォーマンスに影響を与える可能性があります。例として、Privacy Pass は、トークンを利用する前にトークンを発行するためにエンドツーエンドのラウンドトリップ全体を導入するため、パフォーマンスが低下します。対照的に、CONNECT プロキシのようなシステムはパフォーマンスを低下させるように見えるかもしれませんが、多くの場合、プロキシからプロキシへのパスの高度に最適化された性質により、パフォーマンスが向上します。
Reduced performance can be a reason that protocols and deployments will not apply privacy partitioning. For example, HTTPS connection reuse (Section 9.1.1 of [HTTP2]) allows clients to use an existing HTTPS session created for one origin to interact with different origins (provided that the original origin is authoritative for these alternative origins). Reusing connections saves the cost of connection establishment but means that the server can now link the client's activity with these two or more origins together. Applying privacy partitioning would prevent this, but typically at the cost of performance.
パフォーマンスの低下は、プロトコルや展開がプライバシーパーティショニングを適用しない理由になる可能性があります。たとえば、HTTPS 接続の再利用（[HTTP2] のセクション 9.1.1）により、クライアントは 1 つのオリジンに対して作成された既存の HTTPS セッションを使用して、異なるオリジンと対話できるようになります（元のオリジンがこれらの代替オリジンに対して権威がある場合）。接続を再利用すると接続確立のコストは節約されますが、サーバーがクライアントのこれら 2 つ以上のオリジンでのアクティビティを紐付けできるようになることを意味します。プライバシーパーティショニングを適用するとこれは防止されますが、通常はパフォーマンスが犠牲になります。
In general, while performance and privacy trade-offs are often cast as a zero-sum game, in practice this is often not the case. The relationship between privacy and performance varies depending on a number of related factors, such as application characteristics, network path properties, and so on.
一般に、パフォーマンスとプライバシーのトレードオフはしばしばゼロサムゲームとして扱われますが、実際にはそうではないことがよくあります。プライバシーとパフォーマンスの関係は、アプリケーションの特性、ネットワークパスの特性など、多くの関連要因によって異なります。
3. Increased attack surface: Even in the event that information is adequately partitioned across non-colluding parties, the resulting effects on the end user may not always be positive. For example, using OHTTP as a basis for illustration, consider a hypothetical scenario where the Oblivious Gateway has an implementation flaw that causes all of its decrypt requests to be inappropriately logged in a public or otherwise compromised location. Moreover, assume that the Target Resource for which these requests are destined does not have such an implementation flaw. Applications that use OHTTP with this flawed Oblivious Gateway to interact with the Target Resource risk their user request information being made public, albeit in a way that is decoupled from user identifying information, whereas applications that do not use OHTTP to interact with the Target Resource do not risk this type of disclosure.
3. 攻撃対象領域 (Attack Surface) の拡大：情報が共謀しない当事者間で適切に分割されている場合でも、エンドユーザーへの影響が常に肯定的であるとは限りません。たとえば、OHTTP を例にとると、Oblivious Gateway に実装上の欠陥があり、すべての復号リクエストが公開された場所や侵害された場所に不適切にログ記録されてしまうという仮想的なシナリオを考えてみましょう。さらに、これらのリクエストの宛先であるターゲットリソースには、そのような実装上の欠陥がないと仮定します。この欠陥のある Oblivious Gateway を使用してターゲットリソースと対話する OHTTP アプリケーションは、ユーザー識別情報からは切り離されているとはいえ、ユーザーのリクエスト情報が公開されるリスクを負います。一方、OHTTP を使用せずにターゲットリソースと対話するアプリケーションは、この種の漏洩リスクを負いません。
4. Centralization: Depending on the protocol and system, as well as the desired privacy properties, the use of partitioning may inherently force centralization to a selected set of trusted participants. As an example, the impact of OHTTP on end-user privacy generally increases proportionally to the number of users that exist behind a given Oblivious Relay. That is, the probability of an Oblivious Gateway determining the client associated with a request forwarded through an Oblivious Relay decreases as the number of possible clients behind the Oblivious Relay increases. This trade-off encourages the centralization of the Oblivious Relays.
4. 集中化：プロトコルやシステム、および望まれるプライバシー特性によっては、パーティショニングの使用が、選択された信頼できる参加者のセットへの集中化を本質的に強制する場合があります。例として、エンドユーザーのプライバシーに対する OHTTP の影響は、一般に、特定の Oblivious Relay の背後に存在するユーザーの数に比例して増大します。つまり、Oblivious Relay の背後にいる可能性のあるクライアントの数が増えるにつれて、Oblivious Relay を介して転送されたリクエストに関連付けられたクライアントを Oblivious Gateway が特定できる確率は低下します。このトレードオフは、Oblivious Relay の集中化を促進します。
Section 5 discusses some of the limitations of privacy partitioning in practice and advocates for holistic analysis to understand the extent to which privacy partitioning offers meaningful privacy improvements. Applied correctly, partitioning helps improve an end-user's privacy posture, thereby making violations harder to do via technical, social, or policy means. For example, side channels such as traffic analysis [FINGERPINT] or timing analysis are still possible and can allow an unauthorized entity to learn information about a context they are not a participant of. Proposed mitigations for these types of attacks, e.g., padding application traffic or generating fake traffic, can be very expensive and are therefore not typically applied in practice. Nevertheless, privacy partitioning moves the threat vector from one that has direct access to user-specific information to one that requires more effort, e.g., computational resources, to violate end-user privacy.
セクション 5 では、実際的なプライバシーパーティショニングの制限のいくつかについて論じ、プライバシーパーティショニングがどの程度有意義なプライバシーの改善を提供するかを理解するための包括的な分析を推奨しています。正しく適用されれば、パーティショニングはエンドユーザーのプライバシー姿勢を改善するのに役立ち、それにより、技術的、社会的、または政策的手段による侵害をより困難にします。たとえば、トラフィック分析 [FINGERPINT] やタイミング分析などのサイドチャネルは依然として可能であり、権限のないエンティティが、自身が参加していないコンテキストに関する情報を知ることを可能にします。これらのタイプの攻撃に対して提案されている緩和策（アプリケーショントラフィックのパディングや偽のトラフィックの生成など）は、非常にコストがかかる可能性があるため、通常は実際には適用されません。それにもかかわらず、プライバシーパーティショニングは、脅威ベクトルを、ユーザー固有情報に直接アクセスできるものから、エンドユーザーのプライバシーを侵害するためにより多くの労力（計算リソースなど）を必要とするものへと変化させます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[CensusReconstruction]
United States Consensus Bureau, "The Census Bureau's
Simulated Reconstruction-Abetted Re-identification Attack
on the 2010 Census", May 2021,
<https://www.census.gov/data/academy/webinars/2021/
disclosure-avoidance-series/simulated-reconstruction-
abetted-re-identification-attack-on-the-2010-census.html>.
[CONNECT-IP]
Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
RFC 9484, DOI 10.17487/RFC9484, October 2023,
<https://www.rfc-editor.org/info/rfc9484>.
[CONNECT-UDP]
Schinazi, D. and L. Pardue, "HTTP Datagrams and the
Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
2022, <https://www.rfc-editor.org/info/rfc9297>.
[DataSetReconstruction]
Narayanan, A. and V. Shmatikov, "Robust De-anonymization
of Large Sparse Datasets", IEEE Symposium on Security and
Privacy, DOI 10.1109/sp.2008.33, May 2008,
<https://doi.org/10.1109/sp.2008.33>.
[DECOUPLING]
Schmitt, P., Iyengar, J., Wood, C., and B. Raghavan, "The
decoupling principle: a practical privacy framework",
Proceedings of the 21st ACM Workshop on Hot Topics in
Networks, DOI 10.1145/3563766.3564112, November 2022,
<https://doi.org/10.1145/3563766.3564112>.
[DOH] 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>.
[FINGERPINT]
Goldberg, I., Wang, T., and C. A. Wood, "Network-Based
Website Fingerprinting", Work in Progress, Internet-Draft,
draft-irtf-pearg-website-fingerprinting-01, 8 September
2020, <https://datatracker.ietf.org/doc/html/draft-irtf-
pearg-website-fingerprinting-01>.
[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>.
[HTTP2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[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>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
DOI 10.17487/RFC9458, January 2024,
<https://www.rfc-editor.org/info/rfc9458>.
[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>.
[RANDOM-MAC]
Zuniga, JC., Bernardos, CJ., Ed., and A. Andersdotter,
"Randomized and Changing MAC Address state of affairs",
Work in Progress, Internet-Draft, draft-ietf-madinas-mac-
address-randomization-12, 28 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-madinas-
mac-address-randomization-12>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016,
<https://www.rfc-editor.org/info/rfc8030>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/info/rfc8981>.
[RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June
2024, <https://www.rfc-editor.org/info/rfc9576>.
[TLS-ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-18, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-18>.
Internet Architecture Board members at the time this document was approved for publication were:
このドキュメントが公開承認された時点の Internet Architecture Board メンバーは以下の通りです。
Dhruv Dhody
Dhruv Dhody
Lars Eggert
Lars Eggert
Wes Hardaker
Wes Hardaker
Cullen Jennings
Cullen Jennings
Mallory Knodel
Mallory Knodel
Suresh Krishnan
Suresh Krishnan
Mirja Kühlewind
Mirja Kühlewind
Tommy Pauly
Tommy Pauly
Alvaro Retana
Alvaro Retana
David Schinazi
David Schinazi
Christopher A. Wood
Christopher A. Wood
Qin Wu
Qin Wu
Jiankang Yao
Jiankang Yao
We would like to thank Martin Thomson, Eliot Lear, Mark Nottingham, Niels ten Oever, Vittorio Bertola, Antoine Fressancourt, Cullen Jennings, and Dhruv Dhody for their reviews and feedback.
Martin Thomson、Eliot Lear、Mark Nottingham、Niels ten Oever、Vittorio Bertola、Antoine Fressancourt、Cullen Jennings、および Dhruv Dhody のレビューとフィードバックに感謝します。
Mirja Kühlewind
Email: mirja.kuehlewind@ericsson.com
Tommy Pauly
Email: tpauly@apple.com
Christopher A. Wood
Email: caw@heapingbits.net