rfc9614.original   rfc9614.txt 
Network Working Group M. Kühlewind Internet Architecture Board (IAB) M. Kühlewind
Internet-Draft Ericsson Research Request for Comments: 9614
Intended status: Informational T. Pauly Category: Informational T. Pauly
Expires: 14 July 2024 Apple ISSN: 2070-1721
C. A. Wood C. A. Wood
Cloudflare July 2024
11 January 2024
Partitioning as an Architecture for Privacy Partitioning as an Architecture for Privacy
draft-iab-privacy-partitioning-05
Abstract Abstract
This document describes the principle of privacy partitioning, which This document describes the principle of privacy partitioning, which
selectively spreads data and communication across multiple parties as selectively spreads data and communication across multiple parties as
a means to improve privacy by separating user identity from user a means to improve privacy by separating user identity from user
data. This document describes emerging patterns in protocols to data. This document describes emerging patterns in protocols to
partition what data and metadata is revealed through protocol partition what data and metadata is revealed through protocol
interactions, provides common terminology, and discusses how to interactions, provides common terminology, and discusses how to
analyze such models. analyze such models.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Internet Architecture
Board Internet Engineering Task Force mailing list (iab@iab.org),
which is archived at .
Source for this draft and an issue tracker can be found at
https://github.com/intarchboard/draft-obliviousness.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Architecture Board (IAB)
Task Force (IETF). Note that other groups may also distribute and represents information that the IAB has deemed valuable to
working documents as Internet-Drafts. The list of current Internet- provide for permanent record. It represents the consensus of the
Drafts is at https://datatracker.ietf.org/drafts/current/. 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-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9614.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 July 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Privacy Partitioning . . . . . . . . . . . . . . . . . . . . 4 2. Privacy Partitioning
2.1. Privacy Contexts . . . . . . . . . . . . . . . . . . . . 5 2.1. Privacy Contexts
2.2. Context Separation . . . . . . . . . . . . . . . . . . . 7 2.2. Context Separation
2.3. Approaches to Partitioning . . . . . . . . . . . . . . . 8 2.3. Approaches to Partitioning
3. A Survey of Protocols using Partitioning . . . . . . . . . . 9 3. A Survey of Protocols Using Partitioning
3.1. CONNECT Proxying and MASQUE . . . . . . . . . . . . . . . 9 3.1. CONNECT Proxying and MASQUE
3.2. Oblivious HTTP and DNS . . . . . . . . . . . . . . . . . 12 3.2. Oblivious HTTP and DNS
3.3. Privacy Pass . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Privacy Pass
3.4. Privacy Preserving Measurement . . . . . . . . . . . . . 15 3.4. Privacy Preserving Measurement
4. Applying Privacy Partitioning . . . . . . . . . . . . . . . . 16 4. Applying Privacy Partitioning
4.1. User-Identifying Information . . . . . . . . . . . . . . 16 4.1. User-Identifying Information
4.2. Selecting Client Identifiers . . . . . . . . . . . . . . 17 4.2. Selecting Client Identifiers
4.3. Incorrect or Incomplete Partitioning . . . . . . . . . . 18 4.3. Incorrect or Incomplete Partitioning
4.4. Selecting Information Within a Context . . . . . . . . . 18 4.4. Selecting Information within a Context
5. Limits of Privacy Partitioning . . . . . . . . . . . . . . . 19 5. Limits of Privacy Partitioning
5.1. Violations by Collusion . . . . . . . . . . . . . . . . . 19 5.1. Violations by Collusion
5.2. Violations by Insufficient or Incorrect Partitioning . . 20 5.2. Violations by Insufficient or Incorrect Partitioning
5.2.1. Violations from Application Information . . . . . . . 20 5.2.1. Violations from Application Information
5.2.2. Violations from Network Information . . . . . . . . . 20 5.2.2. Violations from Network Information
5.2.3. Violations from Side Channels . . . . . . . . . . . . 21 5.2.3. Violations from Side Channels
5.2.4. Identifying Partitions . . . . . . . . . . . . . . . 21 5.2.4. Identifying Partitions
6. Partitioning Impacts . . . . . . . . . . . . . . . . . . . . 21 6. Partitioning Impacts
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations
9. Informative References . . . . . . . . . . . . . . . . . . . 23 9. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 IAB Members at the Time of Approval
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
Protocols such as TLS and IPsec provide a secure (authenticated and Protocols such as TLS and IPsec provide a secure (authenticated and
encrypted) channel between two endpoints over which endpoints encrypted) channel between two endpoints over which endpoints
transfer information. Encryption and authentication of data in transfer information. Encryption and authentication of data in
transit are necessary to protect information from being seen or transit are necessary to protect information from being seen or
modified by parties other than the intended protocol participants. modified by parties other than the intended protocol participants.
As such, this kind of security is necessary for ensuring that As such, this kind of security is necessary for ensuring that
information transferred over these channels remains private. information transferred over these channels remains private.
skipping to change at page 3, line 27 skipping to change at line 103
requirements have expanded beyond the need to protect data in transit requirements have expanded beyond the need to protect data in transit
between two endpoints. Some examples of this expansion include: between two endpoints. Some examples of this expansion include:
* A user accessing a service on a website might not consent to * A user accessing a service on a website might not consent to
reveal their location, but if that service is able to observe the reveal their location, but if that service is able to observe the
client's IP address, it can learn something about the user's client's IP address, it can learn something about the user's
location. This is problematic for privacy since the service can location. This is problematic for privacy since the service can
link user data to the user's location. link user data to the user's location.
* A user might want to be able to access content for which they are * A user might want to be able to access content for which they are
authorized, such as a news article, without needing to have which authorized, such as a news article; but the news service might
specific articles they read on their account being recorded. This track which users access which articles, even if the user doesn't
is problematic for privacy since the service can link user want their activity to be tracked. This is problematic for
activity to the user's account. privacy since the service can link user activity to the user's
account.
* A client device that needs to upload metrics to an aggregation * A client device might need to upload metrics to an aggregation
service might want to be able to contribute data to the system service and in doing so allow the service to attribute the
without having their specific contributions attributed to them. specific metrics contributions to that client device. This is
This is problematic for privacy since the service can link client problematic for privacy since the service can link client
contributions to the specific client. contributions to the specific client.
The commonality in these examples is that clients want to interact The commonality in these examples is that clients want to interact
with or use a service without exposing too much user-specific or with or use a service without exposing too much user-specific or
identifying information to that service. In particular, separating identifying information to that service. In particular, separating
the user-specific identity information from user-specific data is the user-specific identity information from user-specific data is
necessary for privacy. Thus, in order to protect user privacy, it is necessary for privacy. Thus, in order to protect user privacy, it is
important to keep identity (who) and data (what) separate. important to keep identity (who) and data (what) separate.
This document defines "privacy partitioning," sometimes also referred This document defines "privacy partitioning," sometimes also referred
skipping to change at page 4, line 10 skipping to change at line 136
privacy. Although privacy partitioning cannot guarantee there is no privacy. Although privacy partitioning cannot guarantee there is no
link between user-specific identity and user-specific data, when link between user-specific identity and user-specific data, when
applied properly it helps ensure that user privacy violations become applied properly it helps ensure that user privacy violations become
more technically difficult to achieve over time. more technically difficult to achieve over time.
Several IETF working groups are working on protocols or systems that Several IETF working groups are working on protocols or systems that
adhere to the principle of privacy partitioning, including Oblivious adhere to the principle of privacy partitioning, including Oblivious
HTTP Application Intermediation (OHAI), Multiplexed Application HTTP Application Intermediation (OHAI), Multiplexed Application
Substrate over QUIC Encryption (MASQUE), Privacy Pass, and Privacy Substrate over QUIC Encryption (MASQUE), Privacy Pass, and Privacy
Preserving Measurement (PPM). This document summarizes work in those Preserving Measurement (PPM). This document summarizes work in those
groups and describes a framework for reasoning about the resulting groups and describes a framework for thinking about the resulting
privacy posture of different endpoints in practice. privacy posture of different endpoints in practice.
Privacy partitioning is particularly relevant as a tool for data Privacy partitioning is particularly relevant as a tool for data
minimization, which is described in Section 6.1 of [RFC6973]. minimization, which is described in Section 6.1 of [RFC6973].
[RFC6973] provides guidance for privacy considerations in Internet [RFC6973] provides guidance for privacy considerations in Internet
protocols, along with a set of questions on how to evaluate the data protocols, along with a set of questions on how to evaluate the data
minimization of a protocol in Section 7.1 of [RFC6973]. Protocols minimization of a protocol in Section 7.1 of [RFC6973]. Protocols
that employ privacy partitioning ought to consider the questions in that employ privacy partitioning ought to consider the questions in
that section when evaluating their design, particularly with regard that section when evaluating their design, particularly with regard
to how identifiers and data can be correlated by protocol to how identifiers and data can be correlated by protocol
participants and observers in each context that has been partitioned. participants and observers in each context that has been partitioned.
Privacy partitioning can also be used as a way to separate identity Privacy partitioning can also be used as a way to separate identity
providers from relying parties (see Section 6.1.4 of [RFC6973]), as providers from relying parties (see Section 6.1.4 of [RFC6973]), as
in the case of Privacy Pass (see Section Section 3.3). in the case of Privacy Pass (see Section 3.3).
Privacy partitioning is not a panacea; applying it well requires Privacy partitioning is not a panacea; applying it well requires
holistic analysis of the system in question to determine whether or holistic analysis of the system in question to determine whether or
not partitioning as a tool, and as implemented, offers meaningful not partitioning as a tool, and as implemented, offers meaningful
privacy improvements. See Section 5 for more information. privacy improvements. See Section 5 for more information.
2. Privacy Partitioning 2. Privacy Partitioning
For the purposes of user privacy, this document focuses on user- For the purposes of user privacy, this document focuses on user-
specific information. This might include any identifying information specific information. This might include any identifying information
that is specific to a user, such as their email address or IP that is specific to a user, such as their email address or IP
address, or data about the user, such as their date of birth. address, or any data about the user, such as their date of birth.
Informally, the goal of privacy partitioning is to ensure that each Informally, the goal of privacy partitioning is to ensure that each
party in a system beyond the user themselves only have access to one party in a system beyond the user themselves only has access to one
type of user-specific information. type of user-specific information.
This is a simple application of the principle of least privilege, This is a simple application of the principle of least privilege,
wherein every party in a system only has access to the minimum amount wherein every party in a system only has access to the minimum amount
of information needed to fulfill their function. Privacy of information needed to fulfill their function. Privacy
partitioning advocates for this minimization by ensuring that partitioning advocates for this minimization by ensuring that
protocols, applications, and systems only reveal user-specific protocols, applications, and systems only reveal user-specific
information to parties that need access to the information for their information to parties that need access to the information for their
intended purpose. intended purpose.
skipping to change at page 5, line 20 skipping to change at line 194
prevent the correlation of user-specific information across contexts, prevent the correlation of user-specific information across contexts,
partitions need to ensure that any single entity (other than the partitions need to ensure that any single entity (other than the
client itself) does not participate in more than one context where client itself) does not participate in more than one context where
the information is visible. the information is visible.
[RFC6973] discusses the importance of identifiers in reducing [RFC6973] discusses the importance of identifiers in reducing
correlation as a way of improving privacy: correlation as a way of improving privacy:
| Correlation is the combination of various pieces of information | Correlation is the combination of various pieces of information
| related to an individual or that obtain that characteristic when | related to an individual or that obtain that characteristic when
| combined... Correlation is closely related to identification. | combined....
| Internet protocols can facilitate correlation by allowing |
| individuals' activities to be tracked and combined over time. | 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 | Pseudonymity is strengthened when less personal data can be linked
| to the pseudonym; when the same pseudonym is used less often and | to the pseudonym; when the same pseudonym is used less often and
| across fewer contexts; and when independently chosen pseudonyms | across fewer contexts; and when independently chosen pseudonyms
| are more frequently used for new actions (making them, from an | are more frequently used for new actions (making them, from an
| observer's or attacker's perspective, unlinkable). | observer's or attacker's perspective, unlinkable).
Context separation is foundational to privacy partitioning and Context separation is foundational to privacy partitioning and
reducing correlation. As an example, consider an unencrypted HTTP reducing correlation. As an example, consider an unencrypted HTTP
session over TCP, wherein the context includes both the content of session over TCP, wherein the context includes both the content of
the transaction as well as any metadata from the transport and IP the transaction as well as any metadata from the transport and IP
headers; and the participants include the client, routers, other headers; and the participants include the client, routers, other
network middleboxes, intermediaries, and server. Middlboxes or network middleboxes, intermediaries, and the server. Middleboxes or
intermediaries might simply forward traffic, or might terminate the intermediaries might simply forward traffic or might terminate the
traffic at any layer (such as terminating the TCP connection from the traffic at any layer (such as terminating the TCP connection from the
client and creating another TCP connection to the server). client and creating another TCP connection to the server).
Regardless of how the middlebox interacts with the traffic, for the Regardless of how the middlebox interacts with the traffic, for the
purposes of privacy partitioning, it is able to observe all of the purposes of privacy partitioning, it is able to observe all of the
data in the context. data in the context.
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Context A | | Context A |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | +------HTTP------+ +--------------+ | | | | +------HTTP------+ +--------------+ | |
| | Client | | Middlebox | | Server | | | | Client | | Middlebox | | Server | |
| | +------TCP-------+ +--------------+ | | | | +------TCP-------+ +--------------+ | |
| +--------+ flow +-----------+ +--------+ | | +--------+ flow +-----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 1: Diagram of a basic unencrypted client-to-server
connection with middleboxes Figure 1: Diagram of a Basic Unencrypted Client-to-Server
Connection with Middleboxes
Adding TLS encryption to the HTTP session is a simple partitioning Adding TLS encryption to the HTTP session is a simple partitioning
technique that splits the previous context into two separate technique that splits the previous context into two separate
contexts: the content of the transaction is now only visible to the contexts. The content of the transaction is now only visible to the
client, TLS-terminating intermediaries, and server; while the client, TLS-terminating intermediaries, and server, while the
metadata in transport and IP headers remain in the original context. metadata in transport and IP headers remain in the original context.
In this scenario, without any further partitioning, the entities that In this scenario, without any further partitioning, the entities that
participate in both contexts can allow the data in both contexts to participate in both contexts can allow the data in both contexts to
be correlated. be correlated.
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Context A | | Context A |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | | | | | |
| | Client +-------------------HTTPS-------------------+ Server | | | | Client +-------------------HTTPS-------------------+ Server | |
skipping to change at page 6, line 34 skipping to change at line 259
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Context B | | Context B |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | | | | | | | | | | | | | | |
| | Client +-------TCP------+ Middlebox +--------------+ Server | | | | Client +-------TCP------+ Middlebox +--------------+ Server | |
| | | flow | | | | | | | | flow | | | | |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 2: Diagram of how adding encryption splits the context Figure 2: Diagram of How Adding Encryption Splits the Context
into two into Two
Another way to create a partition is to simply use separate Another way to create a partition is to simply use separate
connections. For example, to split two separate HTTP requests from connections. For example, to split two separate HTTP requests from
one another, a client could issue the requests on separate TCP one another, a client could issue the requests on separate TCP
connections, each on a different network, and at different times; and connections, each on a different network and at different times, and
avoid including obvious identifiers like HTTP cookies across the avoid including obvious identifiers like HTTP cookies across the
requests. requests.
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Context A | | Context A |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | | IP A | | | | | | | | IP A | | | | |
| | Client +-------TCP------+ Middlebox +--------------+ Server | | | | Client +-------TCP------+ Middlebox +--------------+ Server | |
| | | flow A | A | | | | | | | flow A | A | | | |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
skipping to change at page 7, line 23 skipping to change at line 287
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Context B | | Context B |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | | IP B | | | | | | | | IP B | | | | |
| | Client +-------TCP------+ Middlebox +--------------+ Server | | | | Client +-------TCP------+ Middlebox +--------------+ Server | |
| | | flow B | B | | | | | | | flow B | B | | | |
| +--------+ +-----------+ +--------+ | | +--------+ +-----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 3: Diagram of making separate connections to generate Figure 3: Diagram of Making Separate Connections to Generate
separate contexts Separate Contexts
Using separate connections to create separate contexts can reduce or Using separate connections to create separate contexts can reduce or
eliminate the ability of specific parties to correlate activity eliminate the ability of specific parties to correlate activity
across contexts. However, any identifier at any layer that is common across contexts. However, any identifier at any layer that is common
across different contexts can be used as a way to correlate activity. across different contexts can be used as a way to correlate activity.
Beyond IP addresses, many other factors can be used together to Beyond IP addresses, many other factors can be used together to
create a fingerprint of a specific device (such as MAC addresses, create a fingerprint of a specific device (such as Media Access
device properties, software properties and behavior, application Control (MAC) addresses, device properties, software properties and
state, etc). behavior, application state, etc.).
2.2. Context Separation 2.2. Context Separation
In order to define and analyze how various partitioning techniques In order to define and analyze how various partitioning techniques
work, the boundaries of what is being partitioned need to be work, the boundaries of what is being partitioned need to be
established. This is the role of context separation. In particular, established. This is the role of context separation. In particular,
in order to prevent the correlation of user-specific information in order to prevent the correlation of user-specific information
across contexts, partitions need to ensure that any single entity across contexts, partitions need to ensure that any single entity
(other than the client itself) does not participate in contexts where (other than the client itself) does not participate in contexts where
both identifiers are visible. both identifiers are visible.
Context separation can be achieved in different ways, for example, Context separation can be achieved in different ways, for example,
over time, across network paths, based on (en)coding, etc. The over time, across network paths, based on (en)coding, etc. The
privacy-oriented protocols described in this document generally privacy-oriented protocols described in this document generally
involve more complex partitioning, but the techniques to partition involve more complex partitioning, but the techniques to partition
communication contexts still employ the same techniques: communication contexts still employ the same techniques:
1. Cryptographic protection, such as the use of encryption to * Cryptographic protection, such as the use of encryption to
specific parties, allows partitioning of contexts between specific parties, allows partitioning of contexts between
different parties (those with the ability to remove cryptographic different parties (those with the ability to remove cryptographic
protections, and those without). protections, and those without).
2. Connection separation across time or space to allow partitioning * Connection separation across time or space to allow partitioning
of contexts for different application transactions over the of contexts for different application transactions over the
network. network.
These techniques are frequently used in conjunction for context These techniques are frequently used in conjunction for context
separation. For example, encrypting an HTTP exchange using TLS separation. For example, encrypting an HTTP exchange using TLS
between client and TLS-terminating server might prevent a network between the client and TLS-terminating server might prevent a network
middlebox that sees a client IP address from seeing the user account middlebox that sees a client IP address from seeing the user account
identifier, but it doesn't prevent the TLS-terminating server from identifier, but it doesn't prevent the TLS-terminating server from
observing both identifiers and correlating them. As such, preventing observing both identifiers and correlating them. As such, preventing
correlation requires separating contexts, such as by using proxying correlation requires separating contexts, such as by using proxying
to conceal a client's IP address that would otherwise be used as an to conceal a client's IP address that would otherwise be used as an
identifier. identifier.
2.3. Approaches to Partitioning 2.3. Approaches to Partitioning
While all of the partitioning protocols described in this document While all of the partitioning protocols described in this document
create separate contexts using cryptographic protection and/or create separate contexts using cryptographic protection and/or
connection separation, each one has a unique approach that results in connection separation, each one has a unique approach that results in
different sets of contexts. Since many of these protocols are new, 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 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. the Internet and what new models will emerge in the future.
There are multiple factors that lead to a diversity in approaches to There are multiple factors that lead to a diversity in approaches to
partitioning, including: partitioning, including:
* Adding privacy partitioning to existing protocol ecosystems places * Adding privacy partitioning to existing protocol ecosystems places
requirements and constraints on how contexts are constructed. requirements and constraints on how contexts are constructed.
CONNECT-style proxying is intended to work with servers that are CONNECT-style proxying is intended to work with servers that are
unaware of privacy contexts, requiring more intermediaries to unaware of privacy contexts, requiring more intermediaries to
provide strong separation guarantees. Oblivious HTTP, on the provide strong separation guarantees. On the other hand,
other hand, assumes servers that cooperate with context Oblivious HTTP assumes servers that cooperate with context
separation, and thus reduces the overall number of elements in the separation and, thus, reduces the overall number of elements in
solution. the solution.
* Whether or not information exchange needs to happen * Whether or not information exchange needs to happen
bidirectionally in an interactive fashion determines how contexts bidirectionally in an interactive fashion determines how contexts
can be separated. Some use cases, like metrics collection for can be separated. Some use cases, like metrics collection for
PPM, can occur with information flowing only from clients to PPM, can occur whereby information only flows from clients to
servers, and can function even when clients are no longer servers and can function even when clients are no longer
connected. Privacy Pass is an example of a case that can be connected. Privacy Pass is an example of a case that can be
either interactive or not, depending on whether tokens can be either interactive or not, depending on whether tokens can be
cached and reused. CONNECT-style proxying and Oblivious HTTP cached and reused. CONNECT-style proxying and Oblivious HTTP
often requires bidirectional and interactive communication. often require bidirectional and interactive communication.
* The degree to which contexts need to be partitioned depends in * The degree to which contexts need to be partitioned depends in
part on the client's threat models and level of trust in various part on the client's threat models and level of trust in various
protocol participants. For example, in Oblivious HTTP, clients protocol participants. For example, in Oblivious HTTP, clients
allow relays to learn that clients are accessing a particular allow relays to learn that clients are accessing a particular
application-specific gateway. If clients do not trust relays with application-specific gateway. If clients do not trust relays with
this information, they can instead use a multi-hop CONNECT-style this information, they can instead use a multi-hop CONNECT-style
proxy approach wherein no single party learns whether specific proxy approach wherein no single party learns whether specific
clients are accessing a specific application. This is the default clients are accessing a specific application. This is the default
trust model for systems like Tor, where multiple hops are used to trust model for systems like Tor, where multiple hops are used to
drive down the probability of privacy violations due to collusion drive down the probability of privacy violations due to collusion
or related attacks. or related attacks.
3. A Survey of Protocols using Partitioning 3. A Survey of Protocols Using Partitioning
The following section discusses current on-going work in the IETF The following section discusses current on-going work in the IETF
that is applying privacy partitioning. that is applying privacy partitioning.
3.1. CONNECT Proxying and MASQUE 3.1. CONNECT Proxying and MASQUE
HTTP forward proxies, when using encryption on the connection between When using encryption on the connection between the client and the
the client and the proxy, provide privacy partitioning by separating proxy, HTTP forward proxies provide privacy partitioning by
a connection into multiple segments. When connections to targets via separating a connection into multiple segments. When connections to
the proxy themselves are encrypted, the proxy cannot see the end-to- targets via the proxy themselves are encrypted, the proxy cannot see
end content. HTTP has historically supported forward proxying for the end-to-end content. HTTP has historically supported forward
TCP-like streams via the CONNECT method. More recently, the proxying for TCP-like streams via the CONNECT method. More recently,
Multiplexed Application Substrate over QUIC Encryption (MASQUE) the Multiplexed Application Substrate over QUIC Encryption (MASQUE)
working group has developed protocols to similarly proxy UDP Working Group has developed protocols to similarly proxy UDP
[CONNECT-UDP] and IP packets [CONNECT-IP] based on tunneling. [CONNECT-UDP] and IP packets [CONNECT-IP] based on tunneling.
In a single-proxy setup, there is a tunnel connection between the In a single-proxy setup, there is a tunnel connection between the
client and proxy and an end-to-end connection that is tunnelled client and proxy and an end-to-end connection that is tunneled
between the client and target. This setup, as shown in the figure between the client and target. This setup, as shown in Figure 4,
below, partitions communication into: partitions communication into:
* a Client-to-Target encrypted context, which contains the end-to- * a Client-to-Target encrypted context, which contains the end-to-
end content within the TLS session to the target, such as HTTP end content within the TLS session to the target, such as HTTP
content; content;
* a Client-to-Target proxied context, which is the end-to-end data * a Client-to-Target proxied context, which is the end-to-end data
to the target that is also visible to the proxy, such as a TLS exchanged with the target that is also visible to the proxy, such
session; as a TLS session;
* a Client-to-Proxy context, which contains the transport metadata * a Client-to-Proxy context, which contains the transport metadata
between the client and the target, and the request to the proxy to between the client and the target, and the request to the proxy to
open a connection to the target; open a connection to the target; and
* and a Proxy-to-Target context, which for TCP and UDP proxying * a Proxy-to-Target context, which for TCP and UDP proxying contains
contains any packet header information that is added or modified any packet header information that is added or modified by the
by the proxy, e.g., the IP and TCP/UDP headers. proxy, e.g., the IP and TCP/UDP headers.
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Client-to-Target Encrypted Context | | Client-to-Target Encrypted Context |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | | | | | | | | | |
| | Client +------------------HTTPS--------------------+ Target | | | | Client +------------------HTTPS--------------------+ Target | |
| | | content | | | | | | content | | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
skipping to change at page 10, line 51 skipping to change at line 449
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Proxy-to-Target Context | | Proxy-to-Target Context |
| +-----------+ +--------+ | | +-----------+ +--------+ |
| | | | | | | | | | | |
| | Proxy +--Transport---+ Target | | | | Proxy +--Transport---+ Target | |
| | | flow | | | | | | flow | | |
| +-----------+ +--------+ | | +-----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 4: Diagram of one-hop proxy contexts Figure 4: Diagram of One-Hop Proxy Contexts
Using two (or more) proxies provides better privacy partitioning. In Using two (or more) proxies provides better privacy partitioning. In
particular, with two proxies, each proxy sees the Client metadata, particular, with two proxies, each proxy sees the Client metadata but
but not the Target; the Target, but not the Client metadata; or not the Target, the Target but not the Client metadata, or neither.
neither.
In addition to the contexts described above for the single proxy In addition to the contexts described above for the single proxy
case, the two-hop proxy case shown in the figure below changes the case, the two-hop proxy case shown in Figure 5 changes the contexts
contexts in several ways: in several ways:
* the Client-to-Target proxied context only includes the second * the Client-to-Target proxied context only includes the second
proxy (referred to here as "Proxy B"); proxy (referred to here as "Proxy B");
* a new Client-to-Proxy B context is added, which is the TLS session * 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 from the client to Proxy B that is also visible to the first proxy
(referred to here as "Proxy A"); (referred to here as "Proxy A");
* the contexts that see transport data only (TCP or UDP over IP) are * the contexts that see transport data only (TCP or UDP over IP) are
separated out into three separate contexts, a Client-to-Proxy A separated out into three separate contexts, a Client-to-Proxy A
skipping to change at page 12, line 27 skipping to change at line 521
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Proxy B-to-Target Context | | Proxy B-to-Target Context |
| +-------+ +--------+ | | +-------+ +--------+ |
| | | | | | | | | | | |
| | Proxy +-------+ Target | | | | Proxy +-------+ Target | |
| | B | | | | | | B | | | |
| +-------+ +--------+ | | +-------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 5: Diagram of two-hop proxy contexts Figure 5: Diagram of Two-Hop Proxy Contexts
Forward proxying, such as the protocols developed in MASQUE, uses Forward proxying, such as the modes of proxying in the protocols
both encryption (via TLS) and separation of connections (via proxy developed in MASQUE, uses both encryption (via TLS) and separation of
hops that see only the next hop) to achieve privacy partitioning. connections (via proxy hops that see only the next hop) to achieve
privacy partitioning.
3.2. Oblivious HTTP and DNS 3.2. Oblivious HTTP and DNS
Oblivious HTTP [OHTTP], developed in the Oblivious HTTP Application Oblivious HTTP [OHTTP], developed in the Oblivious HTTP Application
Intermediation (OHAI) working group, adds per-message encryption to Intermediation (OHAI) Working Group, adds per-message encryption to
HTTP exchanges through a relay system. Clients send requests through HTTP exchanges through a relay system. Clients send requests through
an Oblivious Relay, which cannot read message contents, to an an Oblivious Relay, which cannot read message contents, to an
Oblivious Gateway, which can decrypt the messages but cannot Oblivious Gateway, which can decrypt the messages but cannot
communicate directly with the client or observe client metadata like communicate directly with the client or observe client metadata like
IP address. Oblivious HTTP relies on Hybrid Public Key Encryption an IP address. Oblivious HTTP relies on Hybrid Public Key Encryption
[HPKE] to perform encryption. [HPKE] to perform encryption.
Oblivious HTTP uses both encryption and separation of connections to Oblivious HTTP uses both encryption and separation of connections to
achieve privacy partitioning. achieve privacy partitioning.
* End-to-end messages are encrypted between the Client and Gateway. * End-to-end messages are encrypted between the Client and Gateway.
The content of these inner messages are visible to the Client, The content of these inner messages are visible to the Client,
Gateway, and Target. This is the Client-to-Target context. Gateway, and Target. This is the Client-to-Target context.
* The encrypted messages exchanged between the Client and Gateway * The encrypted messages exchanged between the Client and Gateway
skipping to change at page 13, line 51 skipping to change at line 592
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Relay-to-Gateway Context | | Relay-to-Gateway Context |
| +-------+ +---------+ | | +-------+ +---------+ |
| | | | | | | | | | | |
| + Relay +---------+ Gateway | | | + Relay +---------+ Gateway | |
| | | | | | | | | | | |
| +-------+ +---------+ | | +-------+ +---------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 6: Diagram of Oblivious HTTP contexts Figure 6: Diagram of Oblivious HTTP Contexts
Oblivious DNS over HTTPS [ODOH] applies the same principle as Oblivious DNS over HTTPS (ODoH) [ODOH] applies the same principle as
Oblivious HTTP, but operates on DNS messages only. As a precursor to Oblivious HTTP but operates on DNS messages only. As a precursor to
the more generalized Oblivious HTTP, it relies on the same HPKE the more generalized Oblivious HTTP, it relies on the same HPKE
cryptographic primitives, and can be analyzed in the same way. cryptographic primitives and can be analyzed in the same way.
3.3. Privacy Pass 3.3. Privacy Pass
Privacy Pass is an architecture [PRIVACYPASS] and a set of protocols Privacy Pass is an architecture [RFC9576] and a set of protocols
being developed in the Privacy Pass working group that allows clients being developed in the Privacy Pass Working Group that allows clients
to present proof of verification in an anonymous and unlinkable to present proof of verification in an anonymous and unlinkable
fashion, via tokens. These tokens originally were designed as a way fashion via tokens. These tokens were originally designed as a way
to prove that a client had solved a CAPTCHA, but can be applied to to prove that a client had solved a CAPTCHA, but they can be applied
other types of user or device attestation checks as well. In Privacy to other types of user or device attestation checks as well. In
Pass, clients interact with an attester and issuer for the purposes Privacy Pass, clients interact with an attester and issuer for the
of issuing a token, and clients then interact with an origin server purposes of issuing a token, and clients then interact with an origin
to redeem said token. server to redeem said token.
In Privacy Pass, privacy partitioning is achieved with cryptographic In Privacy Pass, privacy partitioning is achieved with cryptographic
protection (in the form of blind signature protocols or similar) and protection (in the form of blind signature protocols or similar) and
separation of connections across two contexts: a "redemption context" separation of connections across two contexts: a "redemption context"
between clients and origins (servers that request and receive between clients and origins (servers that request and receive
tokens), and an "issuance context" between clients, attestation tokens), and an "issuance context" between clients, attestation
servers, and token issuance servers. The cryptographic protection servers, and token issuance servers. The cryptographic protection
ensures that information revealed during the issuance context is ensures that information revealed during the issuance context is
separated from information revealed during the redemption context. separated from information revealed during the redemption context.
skipping to change at page 14, line 49 skipping to change at line 638
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| Issuance Context | | Issuance Context |
| +--------+ +----------+ +--------+ | | +--------+ +----------+ +--------+ |
| | | | | | | | | | | | | | | |
| | Client +------+ Attester +------+ Issuer | | | | Client +------+ Attester +------+ Issuer | |
| | | | | | | | | | | | | | | |
| +--------+ +----------+ +--------+ | | +--------+ +----------+ +--------+ |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 7: Diagram of contexts in Privacy Pass Figure 7: Diagram of Contexts in Privacy Pass
Since the redemption context and issuance context are separate Since the redemption context and issuance context are separate
connections that involve separate entities, they can also be further connections that involve separate entities, they can also be further
decoupled by running those parts of the protocols at different times. decoupled by running those parts of the protocols at different times.
Clients can fetch tokens through the issuance context early, and Clients can fetch tokens through the issuance context early and cache
cache the tokens to later use in redemption contexts. This can aid the tokens for later use in redemption contexts. This can aid in
in partitioning identifiers and data. partitioning identifiers and data.
[PRIVACYPASS] describes different deployment models for which [RFC9576] describes different deployment models for which entities
entities operate origins, attesters, and issuers; in some models, operate origins, attesters, and issuers; in some models, they are all
they are all separate entities, but in others, they can be operated separate entities, and in others they can be operated by the same
by the same entity. The model impacts the effectiveness of entity. The model impacts the effectiveness of partitioning, and
partitioning, and some models (such as when all three are operated by some models (such as when all three are operated by the same entity)
the same entity) only provide effective partitioning when the timing only provide effective partitioning when the timing of connections on
of connections on the two contexts are not correlated, and when the the two contexts are not correlated and when the client uses
client uses different identifiers (such as different IP addresses) on different identifiers (such as different IP addresses) on each
each context. context.
3.4. Privacy Preserving Measurement 3.4. Privacy Preserving Measurement
The Privacy Preserving Measurement (PPM) working group is chartered The Privacy Preserving Measurement (PPM) Working Group is chartered
to develop protocols and systems that help a data aggregation or to develop protocols and systems that help a data aggregation or
collection server (or multiple, non-colluding servers) compute collection server (or multiple non-colluding servers) compute
aggregate values without learning the value of any one client's aggregate values without learning the value of any one client's
individual measurement. Distributed Aggregation Protocol (DAP) is individual measurement. The Distributed Aggregation Protocol (DAP)
the primary working item of the group. is the primary working item of the group.
At a high level, DAP uses a combination of cryptographic protection At a high level, DAP uses a combination of cryptographic protection
(in the form of secret sharing amongst non-colluding servers) to (in the form of secret sharing amongst non-colluding servers) to
establish two contexts: an "upload context" between clients and non- establish two contexts:
colluding aggregation servers (in which the servers are separated
into "Helper" and "Leader" roles) wherein aggregation servers * an "upload context" between clients and non-colluding aggregation
possibly learn client identity but nothing about their individual servers (in which the servers are separated into "Helper" and
measurement reports, and a "collect context" wherein a collector "Leader" roles) wherein aggregation servers possibly learn client
learns aggregate measurement results and nothing about individual identity but nothing about their individual measurement reports;
client data. and
* a "collect context" wherein a collector learns aggregate
measurement results and nothing about individual client data.
+-------------------------------------+--------------------+ +-------------------------------------+--------------------+
| Upload Context | Collect Context | | Upload Context | Collect Context |
| +------------+ | | | +------------+ | |
| +----->| Helper | | | | +----->| Helper | | |
| +--------+ | +------------+ | | | +--------+ | +------------+ | |
| | +---+ ^ | +-----------+ | | | +---+ ^ | +-----------+ |
| | Client | | | | Collector | | | | Client | | | | Collector | |
| | +---+ v | +-----+-----+ | | | +---+ v | +-----+-----+ |
| +--------+ | +------------+ | | | | +--------+ | +------------+ | | |
| +----->| Leader |<-----------+ | | +----->| Leader |<-----------+ |
| +------------+ | | | +------------+ | |
+-------------------------------------+--------------------+ +-------------------------------------+--------------------+
Figure 8: Diagram of contexts in DAP
Figure 8: Diagram of Contexts in DAP
4. Applying Privacy Partitioning 4. Applying Privacy Partitioning
Applying privacy partitioning to an existing or new system or Applying privacy partitioning to an existing or new system or
protocol requires the following steps: protocol requires the following steps:
1. Identify the types of information used or exposed in a system or 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 protocol, some of which can be used to identify a user or
correlate to other contexts. correlate to other contexts.
2. Partition data to minimize the amount of user-identifying or 2. Partition data to minimize the amount of user-identifying or
correlatable information in any given context to only include correlatable information in any given context to only include
what is necessary for that context, and prevent the sharing of what is necessary for that context and prevent the sharing of
data across contexts wherever possible. data across contexts wherever possible.
The most impactful types of information to partition are (a) user- The most impactful types of information to partition are (a) user-
identifying information, such as user identifiers (including account identifying information, such as user identifiers (including account
names or IP addresses) that can be linked and (b) non-user- names or IP addresses) that can be linked and (b) non-user-
identifying information (including content a user generates or identifying information (including content a user generates or
accesses), which can be often sensitive when combined with a user accesses), which can be often sensitive when combined with a user
identifier. identifier.
In this section, we discuss considerations for partitioning these In this section, we discuss considerations for partitioning these
types of information. types of information.
4.1. User-Identifying Information 4.1. User-Identifying Information
User data can itself be user-identifying, in which case it should be User data can itself be user-identifying, in which case it should be
treated as an identifier. For example, Oblivious DoH and Oblivious treated as an identifier. For example, Oblivious DoH and Oblivious
HTTP partition the client IP address and client request data into HTTP partition the client IP address and client request data into
separate contexts, thereby ensuring that no entity beyond the client separate contexts, thereby ensuring that no entity beyond the client
can observe both. Collusion across contexts could reverse this can observe both. Collusion across contexts could reverse this
partitioning, but can also promote non-user-identifying information partitioning and cause non-user-identifying information to become
to user-identifying. For example, in CONNECT proxy systems that use user-identifying information. For example, in CONNECT proxy systems
QUIC, the QUIC connection ID is inherently non-user-identifying since that use QUIC, the QUIC connection ID is inherently non-user-
it is generated randomly ([QUIC], Section 5.1). However, if combined identifying since it is generated randomly (Section 5.1 of [QUIC]).
with another context that has user-identifying information such as However, if combined with another context that has user-identifying
the client IP address, the QUIC connection ID can become user- information such as the client IP address, the QUIC connection ID can
identifying information. become user-identifying information.
Some information is innate to client user-agents, including details Some information is innate to client user-agents, including details
of implementation of protocols in hardware and software, and network of the network location and implementation of protocols in hardware
location. This information can be used to construct user-identifying and software. This information can be used to construct user-
information, which is a process sometimes referred to as identifying information, which is a process sometimes referred to as
fingerprinting. Depending on the application and system constraints, "fingerprinting". Depending on the application and system
users may not be able to prevent fingerprinting in privacy contexts. constraints, users may not be able to prevent fingerprinting in
As a result, fingerprinting information, when combined with non-user- privacy contexts. As a result, fingerprinting information, when
identifying user data, could promote user data to user-identifying combined with non-user-identifying user data, could turn that
information. otherwise innocuous user data into user-identifying information.
4.2. Selecting Client Identifiers 4.2. Selecting Client Identifiers
The selection of client identifiers used in the contexts used for The selection of client identifiers used in the contexts used for
privacy partitioning has a large impact on the effectiveness of privacy partitioning has a large impact on the effectiveness of
partitioning. Identifier selection can either undermine or improve partitioning. Identifier selection can either undermine or improve
the value of partitioning. Generally, each context involves some the value of partitioning. Generally, each context involves some
form of client identifier, which might be directly associated with a form of client identifier, which might be directly associated with a
client identity, but can also be a pseudonym or a random one-time client identity but can also be a pseudonym or a random one-time
identifier. identifier.
Using the same client identifier across multiple contexts can partly Using the same client identifier across multiple contexts can partly
or wholly undermine the effectiveness of partitioning, by allowing or wholly undermine the effectiveness of partitioning by allowing the
the various contexts to be linked back to the same client. For various contexts to be linked back to the same client. For example,
example, if a client uses proxies as described in Section 3.1 to if a client uses proxies as described in Section 3.1 to separate
separate connections, but uses the same email address to authenticate connections but uses the same email address to authenticate to two
to two servers in different contexts, those actions can be linked servers in different contexts, those actions can be linked back to
back to the same client. While this does not undermine all of the the same client. While this does not undermine all of the
partitioning achieved through proxying (the contexts along the partitioning achieved through proxying (the contexts along the
network path still cannot correlate the client identity and what network path still cannot correlate the client identity and what
servers are being accessed), the overall effect of partitioning is servers are being accessed), the overall effect of partitioning is
diminished. diminished.
When possible, using per-context unique client identifiers provides When possible, using per-context unique client identifiers provides
better partitioning properties. For example, a client can use a better partitioning properties. For example, a client can use a
unique email address as an account identifier with each different unique email address as an account identifier with each different
server it needs to log into. The same approach can apply across many server it needs to log into. The same approach can apply across many
layers, as seen with per-network MAC address randomization layers, as seen with per-network MAC address randomization
[I-D.ietf-madinas-mac-address-randomization], use of multiple [RANDOM-MAC], use of multiple temporary IP addresses across
temporary IP addresses across connections and over time [RFC8981], connections and over time [RFC8981], and use of unique per-
and use of unique per-subscription identifiers for HTTP Web Push subscription identifiers for HTTP Web Push [RFC8030].
[RFC8030].
4.3. Incorrect or Incomplete Partitioning 4.3. Incorrect or Incomplete Partitioning
Privacy partitioning can be applied incorrectly or incompletely. Privacy partitioning can be applied incorrectly or incompletely.
Contexts may contain more user-identifying information than desired, Contexts may contain more user-identifying information than desired,
or some information in a context may be more user-identifying than or some information in a context may be more user-identifying than
intended. Moreover, splitting user-identifying information over intended. Moreover, splitting user-identifying information over
multiple contexts has to be done with care, as creating more contexts 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 can increase the number of entities that need to be trusted to not
collude. Nevertheless, partitions can help improve the client's collude. Nevertheless, partitions can help improve the client's
privacy posture when applied carefully. privacy posture when applied carefully.
Evaluating and qualifying the resulting privacy of a system or Evaluating and qualifying the resulting privacy of a system or
protocol that applies privacy partitioning depends on the contexts protocol that applies privacy partitioning depends on the contexts
that exist and the types of user-identifying information in each that exist and the types of user-identifying information in each
context. Such evaluation is helpful for identifying ways in which context. Such evaluation is helpful for identifying ways in which
systems or protocols can improve their privacy posture. For example, systems or protocols can improve their privacy posture. For example,
consider DNS-over-HTTPS [DOH], which produces a single context which consider DNS over HTTPS [DOH], which produces a single context that
contains both the client IP address and client query. One contains both the client IP address and client query. One
application of privacy partitioning results in ODoH, which produces application of privacy partitioning results in ODoH, which produces
two contexts, one with the client IP address and the other with the two contexts, one with the client IP address and the other with the
client query. client query.
4.4. Selecting Information Within a Context 4.4. Selecting Information within a Context
Recognizing potential applications of privacy partitioning requires Recognizing potential applications of privacy partitioning requires
identifying the contexts in use, the information exposed in a identifying the contexts in use, the information exposed in a
context, and the intent of information exposed in a context. context, and the intent of information exposed in a context.
Unfortunately, determining what information to include in a given Unfortunately, determining what information to include in a given
context is a non-trivial task. In principle, the information context is a non-trivial task. In principle, the information
contained in a context should be fit for purpose. As such, new contained in a context should be fit for purpose. As such, new
systems or protocols developed should aim to ensure that all systems or protocols developed should aim to ensure that all
information exposed in a context serves as few purposes as possible. information exposed in a context serves as few purposes as possible.
Designing with this principle from the start helps mitigate issues Designing with this principle from the start helps mitigate issues
that arise if users of the system or protocol inadvertently ossify on that arise if users of the system or protocol inadvertently ossify on
the information available in contexts. Legacy systems that have the information available in contexts. Legacy systems that have
ossified on information available in contexts may be difficult to ossified on information available in contexts may be difficult to
change in practice. As an example, many existing anti-abuse systems change in practice. As an example, many existing anti-abuse systems
depend on some client identifier such as client IP address, coupled depend on some client identifier, such as the client IP address,
with client data, to provide value. Partitioning contexts in these coupled with client data to provide value. Partitioning contexts in
systems such that they no longer determine the client identity these systems such that they no longer determine the client identity
requires new solutions to the anti-abuse problem. requires new solutions to the anti-abuse problem.
5. Limits of Privacy Partitioning 5. Limits of Privacy Partitioning
Privacy partitioning aims to increase user privacy, though as stated, Privacy partitioning aims to increase user privacy, though, as
it is merely one of possibly many architectural tools that help stated, it is merely one of possibly many architectural tools that
manage privacy risks. Understanding the limits of its benefits help manage privacy risks. Understanding the limits of its benefits
requires a more comprehensive analysis of the system in question. requires a more comprehensive analysis of the system in question.
Such analysis also helps determine whether or not the tool has been Such analysis also helps determine whether or not the tool has been
applied correctly. In particular, the value of privacy partitioning applied correctly. In particular, the value of privacy partitioning
depends on numerous factors, including, though not limited to: depends on numerous factors, including, though not limited to, the
following:
* Non-collusion across contexts; and * non-collusion across contexts and
* The type of information exposed in each context. * the type of information exposed in each context.
We elaborate on each below. We elaborate on each in the following sections.
5.1. Violations by Collusion 5.1. Violations by Collusion
Privacy partitions ensure that only the client, i.e., the entity Privacy partitions ensure that only the client, i.e., the entity that
which is responsible for partitioning, can independently link all is responsible for partitioning, can independently link all user-
user-specific information. No other entity individually knows how to specific information. No other entity individually knows how to link
link all the user-specific information as long as they do not collude all the user-specific information as long as they do not collude with
with each other across contexts. Thus, non-collusion is a each other across contexts. Thus, non-collusion is a fundamental
fundamental requirement for privacy partitioning to offer meaningful requirement for privacy partitioning to offer meaningful privacy for
privacy for end-users. In particular, the trust relationships that end users. In particular, the trust relationships that users have
users have with different parties affect the resulting impact on the with different parties affect the resulting impact on the user's
user's privacy. privacy.
As an example, consider OHTTP, wherein the Oblivious Relay knows the As an example, consider Oblivious HTTP (OHTTP), wherein the Oblivious
client identity but not the client data, and the Oblivious Gateway Relay knows the client identity but not the client data, and the
knows the client data but not the client identity. If the Oblivious Oblivious Gateway knows the client data but not the client identity.
Relay and Gateway collude, they can link client identity and data If the Oblivious Relay and Gateway collude, they can link client
together for each request and response transaction by simply identity and data together for each request and response transaction
observing requests in transit. by simply observing requests in transit.
It is not currently possible to guarantee with technical protocol It is not currently possible to guarantee with technical protocol
measures that two entities are not colluding. Even if two entities measures that two entities are not colluding. Even if two entities
do not collude directly, if both entities reveal information to other do not collude directly, if both entities reveal information to other
parties, it will not be possible to guarantee that the information parties, it will not be possible to guarantee that the information
won't be combined. However, there are some mitigations that can be won't be combined. However, there are some mitigations that can be
applied to reduce the risk of collusion happening in practice: applied to reduce the risk of collusion happening in practice:
* Policy and contractual agreements between entities involved in * Policy and contractual agreements between entities involved in
partitioning to disallow logging or sharing of data, along with partitioning to disallow logging or sharing of data, along with
auditing to validate that the policies are being followed. For auditing to validate that the policies are being followed. For
cases where logging is required (such as for service operation), cases where logging is required (such as for service operation),
such logged data should be minimized and anonymized to prevent it such logged data should be minimized and anonymized to prevent it
from being useful for collusion. from being useful for collusion.
* Protocol requirements to make collusion or data sharing more * Protocol requirements to make collusion or data sharing more
difficult. difficult.
* Adding more partitions and contexts, to make it increasingly * Adding more partitions and contexts to make it increasingly
difficult to collude with enough parties to recover identities. difficult to collude with enough parties to recover identities.
5.2. Violations by Insufficient or Incorrect Partitioning 5.2. Violations by Insufficient or Incorrect Partitioning
Insufficient or incorrect application of privacy partitioning can Insufficient or incorrect application of privacy partitioning can
lessen or negate benefits to users. In particular, it is possible to lessen or negate benefits to users. In particular, it is possible to
apply partitioning in a way that is either insufficient or incorrect apply partitioning in a way that is either insufficient or incorrect
for meaningful privacy. For example, partitioning at one layer in for meaningful privacy. For example, partitioning at one layer in
the stack can fail to account for linkable information at different the stack can fail to account for linkable information at different
layers in the stack. Privacy violations can stem from partitioning layers in the stack. Privacy violations can stem from partitioning
failures in a multitude of ways, some of which are described below. failures in a multitude of ways, some of which are described in the
following sections.
5.2.1. Violations from Application Information 5.2.1. Violations from Application Information
Partitioning at the network layer can be insufficient when the Partitioning at the network layer can be insufficient when the
application layer fails to properly partition. As an example, application layer fails to properly partition. As an example,
consider OHTTP used for the purposes of hiding client-identifying consider OHTTP used for the purposes of hiding client-identifying
information for a browser telemetry system. It is entirely possible information for a browser telemetry system. It is entirely possible
for reports in such a telemetry system to contain both client- for reports in such a telemetry system to contain both client-
specific telemetry data, such as information about their specific specific telemetry data, such as information about their specific
browser instance, as well as client-identifying information, such as browser instance, as well as client-identifying information, such as
the client's email address, location, or IP address. Even though the client's email address, location, or IP address. Even though
OHTTP separates the client IP address from the server via a relay, OHTTP separates the client IP address from the server via a relay,
the server can still learn this directly from the client's telemetry the server can still learn this directly from the client's telemetry
report. report.
5.2.2. Violations from Network Information 5.2.2. Violations from Network Information
It is also possible to inadequately partition at the network layer. It is also possible to inadequately partition at the network layer.
As an example, consider both TLS Encrypted Client Hello (ECH) As an example, consider both TLS Encrypted Client Hello (ECH)
[I-D.ietf-tls-esni] and VPNs. ECH uses cryptographic protection [TLS-ESNI] and VPNs. ECH uses cryptographic protection (encryption)
(encryption) to hide information from unauthorized parties, but both to hide information from unauthorized parties, but both clients and
clients and servers (two entities) can link user-specific data to servers (two entities) can link user-specific data to a user-specific
user-specific identifier (IP address). Similarly, while VPNs hide identifier (IP address). Similarly, while VPNs hide identifiers from
identifiers from end servers, the VPN server can still see the end servers, the VPN server can still see the identifiers of both the
identifiers of both the client and server. Applying privacy client and server. Applying privacy partitioning would advocate for
partitioning would advocate for at least two additional entities to at least two additional entities to avoid revealing both identity
avoid revealing both identity (who) and user actions (what) from each (who) and user actions (what) from each involved party.
involved party.
5.2.3. Violations from Side Channels 5.2.3. Violations from Side Channels
Beyond the information that is intentionally revealed by applying Beyond the information that is intentionally revealed by applying
privacy partitioning, it is also possible for the information to be privacy partitioning, it is also possible for the information to be
unintentionally revealed through side channels. For example, in the unintentionally revealed through side channels. For example, in the
two-hop proxy arrangement described in Section 3.1, Proxy A sees and 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 proxies TLS data between the client and Proxy B. While it does not
directly learn information that Proxy B sees, it does learn directly learn information that Proxy B sees, it does learn
information through metadata, such as the timing and size of information through metadata, such as the timing and size of
skipping to change at page 21, line 26 skipping to change at line 931
application data that Proxy A was never meant to see. Although application data that Proxy A was never meant to see. Although
privacy partitioning does not obviate such attacks, it does increase privacy partitioning does not obviate such attacks, it does increase
the cost necessary to carry them out in practice. See Section 7 for the cost necessary to carry them out in practice. See Section 7 for
more discussion on this topic. more discussion on this topic.
5.2.4. Identifying Partitions 5.2.4. Identifying Partitions
While straightforward violations of user privacy that stem from While straightforward violations of user privacy that stem from
insufficient partitioning may seem straightforward to mitigate, it insufficient partitioning may seem straightforward to mitigate, it
remains an open problem to rigorously determine what information remains an open problem to rigorously determine what information
needs to be partitioned for meaningful privacy, and to implement it needs to be partitioned for meaningful privacy and to implement it in
in a way that achieves the desired properties. In essence, it is a way that achieves the desired properties. In essence, it is
difficult to determine whether a certain set of information reveals difficult to determine whether a certain set of information reveals
"too much" about a specific user, and it is similarly challenging to "too much" about a specific user, and it is similarly challenging to
determine whether or not an implementation of partitioning works as determine whether or not an implementation of partitioning works as
intended. There is ample evidence of data being assumed "private" or intended. There is ample evidence of data being assumed "private" or
"anonymous" but, in hindsight, winds up revealing too much "anonymous" but, in hindsight, winds up revealing too much
information such that it allows one to link back to individual information such that it allows one to link back to individual
clients; see [DataSetReconstruction] and [CensusReconstruction] for clients; see [DataSetReconstruction] and [CensusReconstruction] for
more examples of this in the real world. more examples of this in the real world.
6. Partitioning Impacts 6. Partitioning Impacts
Applying privacy partitioning to communication protocols leads to a Applying privacy partitioning to communication protocols leads to a
substantial change in communication patterns. For example, instead substantial change in communication patterns. For example, instead
of sending traffic directly to a service, essentially all user of sending traffic directly to a service, essentially all user
traffic is routed through a set of intermediaries, possibly adding traffic is routed through a set of intermediaries, possibly adding
more end-to-end round trips in the process (depending on the system more end-to-end round trips in the process (depending on the system
and protocol). This has a number of practical implications, and protocol). This has a number of practical implications,
described below. described below.
1. Service operational or management challenges. Information that 1. Service operational or management challenges: Information that is
is traditionally passively observed in the network or metadata usually passively observed in the network or metadata that has
that has been unintentionally revealed to the service provider been unintentionally revealed to the service provider will no
cannot be used anymore for e.g., existing security procedures longer be available; for example, this can impact existing
such as application rate limiting or DDoS mitigation. However, security procedures such as application rate limiting or DDoS
network management techniques deployed at present often rely on mitigation. Current network management techniques deployed often
information that is exposed by most traffic but without any rely on information that is exposed by typical traffic that lacks
guarantees that the information is accurate. guarantees or accuracy.
Privacy partitioning provides an opportunity for improvements in Privacy partitioning provides an opportunity for improvements in
these management techniques by enabling active exchange of these management techniques by enabling active exchange of
information with each entity in a privacy-preserving way and information with each entity in a privacy-preserving way and
requesting exactly the information needed for a specific task or requesting exactly the information needed for a specific task or
function rather than relying on the assumption that are derived function rather than relying on information derived from a
from a limited set of unintentionally revealed information which limited set of unintentionally revealed information that cannot
cannot be guaranteed to be present and may disappear at any time be guaranteed to be available and may be removed in the future.
in future.
2. Varying performance effects and costs. Depending on how context 2. Varying performance effects and costs: Depending on how context
separation is done, privacy partitioning may affect application separation is done, privacy partitioning may affect application
performance. As an example, Privacy Pass introduces an entire performance. As an example, Privacy Pass introduces an entire
end-to-end round trip to issue a token before it can be redeemed, end-to-end round trip to issue a token before it can be redeemed,
thereby decreasing performance. In contrast, while systems like thereby decreasing performance. In contrast, while systems like
CONNECT proxying may seem like they would regress performance, CONNECT proxying may seem like they would reduce performance,
oftentimes the highly optimized nature of proxy-to-proxy paths oftentimes the highly optimized nature of proxy-to-proxy paths
leads to improved performance. leads to improved performance.
Performance may also push back against the desire to apply Reduced performance can be a reason that protocols and
privacy partitioning. For example, HTTPS connection reuse deployments will not apply privacy partitioning. For example,
[HTTP2], Section 9.1.1 allows clients to use an existing HTTPS HTTPS connection reuse (Section 9.1.1 of [HTTP2]) allows clients
session created for one origin to interact with different origins to use an existing HTTPS session created for one origin to
(provided the original origin is authoritative for these interact with different origins (provided that the original
alternative origins). Reusing connections saves the cost of origin is authoritative for these alternative origins). Reusing
connection establishment, but means that the server can now link connections saves the cost of connection establishment but means
the client's activity with these two or more origins together. that the server can now link the client's activity with these two
Applying privacy partitioning would prevent this, while typically or more origins together. Applying privacy partitioning would
at the cost of less performance. prevent this, but typically at the cost of performance.
In general, while performance and privacy tradeoffs are often In general, while performance and privacy trade-offs are often
cast as a zero-sum game, in practice this is often not the case. cast as a zero-sum game, in practice this is often not the case.
The relationship between privacy and performance varies depending The relationship between privacy and performance varies depending
on a number of related factors, such as application on a number of related factors, such as application
characteristics, network path properties, and so on. characteristics, network path properties, and so on.
3. Increased attack surface. Even in the event that information is 3. Increased attack surface: Even in the event that information is
adequately partitioned across non-colluding parties, the adequately partitioned across non-colluding parties, the
resulting effects on the end-user may not always be positive. resulting effects on the end user may not always be positive.
For example, using OHTTP as a basis for illustration, consider a For example, using OHTTP as a basis for illustration, consider a
hypothetical scenario where the Oblivious Gateway has an hypothetical scenario where the Oblivious Gateway has an
implementation flaw that causes all of its decrypt requests to be implementation flaw that causes all of its decrypt requests to be
inappropriately logged to a public or otherwise compromised inappropriately logged in a public or otherwise compromised
location. Moreover, assume that the Target Resource for which location. Moreover, assume that the Target Resource for which
these requests are destined does not have such an implementation these requests are destined does not have such an implementation
flaw. Applications which use OHTTP with this flawed Oblivious flaw. Applications that use OHTTP with this flawed Oblivious
Gateway to interact with the Target Resource risk their user Gateway to interact with the Target Resource risk their user
request information being made public, albeit in a way that is request information being made public, albeit in a way that is
decoupled from user identifying information, whereas applications decoupled from user identifying information, whereas applications
that do not use OHTTP to interact with the Target Resource do not that do not use OHTTP to interact with the Target Resource do not
risk this type of disclosure. risk this type of disclosure.
4. Centralization. Depending on the protocol and system, as well as 4. Centralization: Depending on the protocol and system, as well as
the desired privacy properties, the use of partitioning may the desired privacy properties, the use of partitioning may
inherently force centralization to a selected set of trusted inherently force centralization to a selected set of trusted
participants. As an example, the impact of OHTTP on end-user participants. As an example, the impact of OHTTP on end-user
privacy generally increases proportionally to the number of users privacy generally increases proportionally to the number of users
that exist behind a given Oblivious Relay. That is, the that exist behind a given Oblivious Relay. That is, the
probability of an Oblivious Gateway determining the client probability of an Oblivious Gateway determining the client
associated with a request forwarded through an Oblivious Relay associated with a request forwarded through an Oblivious Relay
decreases as the number of possible clients behind the Oblivious decreases as the number of possible clients behind the Oblivious
Relay increases. This tradeoff encourages the centralization of Relay increases. This trade-off encourages the centralization of
the Oblivious Relays. the Oblivious Relays.
7. Security Considerations 7. Security Considerations
Section 5 discusses some of the limitations of privacy partitioning Section 5 discusses some of the limitations of privacy partitioning
in practice, and advocates for holistic analysis to understand the in practice and advocates for holistic analysis to understand the
extent to which privacy partitioning offers meaningful privacy extent to which privacy partitioning offers meaningful privacy
improvements. Applied correctly, partitioning helps improve an end- improvements. Applied correctly, partitioning helps improve an end-
user's privacy posture, thereby making violations harder to do via user's privacy posture, thereby making violations harder to do via
technical, social, or policy means. For example, side channels such technical, social, or policy means. For example, side channels such
as traffic analysis [I-D.irtf-pearg-website-fingerprinting] or timing as traffic analysis [FINGERPINT] or timing analysis are still
analysis are still possible and can allow an unauthorized entity to possible and can allow an unauthorized entity to learn information
learn information about a context they are not a participant of. about a context they are not a participant of. Proposed mitigations
Proposed mitigations for these types of attacks, e.g., padding for these types of attacks, e.g., padding application traffic or
application traffic or generating fake traffic, can be very expensive generating fake traffic, can be very expensive and are therefore not
and are therefore not typically applied in practice. Nevertheless, typically applied in practice. Nevertheless, privacy partitioning
privacy partitioning moves the threat vector from one that has direct moves the threat vector from one that has direct access to user-
access to user-specific information to one which requires more specific information to one that requires more effort, e.g.,
effort, e.g., computational resources, to violate end-user privacy. computational resources, to violate end-user privacy.
8. IANA Considerations 8. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
9. Informative References 9. Informative References
[CensusReconstruction] [CensusReconstruction]
"The Census Bureau's Simulated Reconstruction-Abetted Re- United States Consensus Bureau, "The Census Bureau's
identification Attack on the 2010 Census", n.d., Simulated Reconstruction-Abetted Re-identification Attack
on the 2010 Census", May 2021,
<https://www.census.gov/data/academy/webinars/2021/ <https://www.census.gov/data/academy/webinars/2021/
disclosure-avoidance-series/simulated-reconstruction- disclosure-avoidance-series/simulated-reconstruction-
abetted-re-identification-attack-on-the-2010-census.html>. abetted-re-identification-attack-on-the-2010-census.html>.
[CONNECT-IP] [CONNECT-IP]
Pauly, T., Schinazi, D., Chernyakhovsky, A., Kühlewind, Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
M., and M. Westerlund, "Proxying IP in HTTP", Work in Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
Progress, Internet-Draft, draft-ietf-masque-connect-ip-13, RFC 9484, DOI 10.17487/RFC9484, October 2023,
28 April 2023, <https://datatracker.ietf.org/doc/html/ <https://www.rfc-editor.org/info/rfc9484>.
draft-ietf-masque-connect-ip-13>.
[CONNECT-UDP] [CONNECT-UDP]
Schinazi, D. and L. Pardue, "HTTP Datagrams and the Schinazi, D. and L. Pardue, "HTTP Datagrams and the
Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August Capsule Protocol", RFC 9297, DOI 10.17487/RFC9297, August
2022, <https://www.rfc-editor.org/rfc/rfc9297>. 2022, <https://www.rfc-editor.org/info/rfc9297>.
[DataSetReconstruction] [DataSetReconstruction]
Narayanan, A. and V. Shmatikov, "Robust De-anonymization Narayanan, A. and V. Shmatikov, "Robust De-anonymization
of Large Sparse Datasets", IEEE, 2008 IEEE Symposium on of Large Sparse Datasets", IEEE Symposium on Security and
Security and Privacy (sp 2008), DOI 10.1109/sp.2008.33, Privacy, DOI 10.1109/sp.2008.33, May 2008,
May 2008, <https://doi.org/10.1109/sp.2008.33>. <https://doi.org/10.1109/sp.2008.33>.
[DECOUPLING] [DECOUPLING]
Schmitt, P., Iyengar, J., Wood, C., and B. Raghavan, "The Schmitt, P., Iyengar, J., Wood, C., and B. Raghavan, "The
decoupling principle: a practical privacy framework", ACM, decoupling principle: a practical privacy framework",
Proceedings of the 21st ACM Workshop on Hot Topics Proceedings of the 21st ACM Workshop on Hot Topics in
in Networks, DOI 10.1145/3563766.3564112, November 2022, Networks, DOI 10.1145/3563766.3564112, November 2022,
<https://doi.org/10.1145/3563766.3564112>. <https://doi.org/10.1145/3563766.3564112>.
[DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[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/rfc/rfc9180>.
[HTTP2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>.
[I-D.ietf-madinas-mac-address-randomization]
Zúñiga, J. C., Bernardos, C. J., and A. Andersdotter,
"Randomized and Changing MAC Address state of affairs",
Work in Progress, Internet-Draft, draft-ietf-madinas-mac-
address-randomization-10, 11 January 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-madinas-
mac-address-randomization-10>.
[I-D.ietf-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-17, 9 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
esni-17>.
[I-D.irtf-pearg-website-fingerprinting] [FINGERPINT]
Goldberg, I., Wang, T., and C. A. Wood, "Network-Based Goldberg, I., Wang, T., and C. A. Wood, "Network-Based
Website Fingerprinting", Work in Progress, Internet-Draft, Website Fingerprinting", Work in Progress, Internet-Draft,
draft-irtf-pearg-website-fingerprinting-01, 8 September draft-irtf-pearg-website-fingerprinting-01, 8 September
2020, <https://datatracker.ietf.org/doc/html/draft-irtf- 2020, <https://datatracker.ietf.org/doc/html/draft-irtf-
pearg-website-fingerprinting-01>. 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. [ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230, Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022, DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/rfc/rfc9230>. <https://www.rfc-editor.org/info/rfc9230>.
[OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in
Progress, Internet-Draft, draft-ietf-ohai-ohttp-10, 25
August 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-ohai-ohttp-10>.
[PRIVACYPASS] [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458,
Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy DOI 10.17487/RFC9458, January 2024,
Pass Architecture", Work in Progress, Internet-Draft, <https://www.rfc-editor.org/info/rfc9458>.
draft-ietf-privacypass-architecture-16, 25 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-
privacypass-architecture-16>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <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., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic
Event Delivery Using HTTP Push", RFC 8030, Event Delivery Using HTTP Push", RFC 8030,
DOI 10.17487/RFC8030, December 2016, DOI 10.17487/RFC8030, December 2016,
<https://www.rfc-editor.org/rfc/rfc8030>. <https://www.rfc-editor.org/info/rfc8030>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, [RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves,
"Temporary Address Extensions for Stateless Address "Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6", RFC 8981, Autoconfiguration in IPv6", RFC 8981,
DOI 10.17487/RFC8981, February 2021, DOI 10.17487/RFC8981, February 2021,
<https://www.rfc-editor.org/rfc/rfc8981>. <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>.
IAB Members at the Time of Approval
Internet Architecture Board members at the time this document was
approved for publication were:
Dhruv Dhody
Lars Eggert
Wes Hardaker
Cullen Jennings
Mallory Knodel
Suresh Krishnan
Mirja Kühlewind
Tommy Pauly
Alvaro Retana
David Schinazi
Christopher Wood
Qin Wu
Jiankang Yao
Acknowledgments Acknowledgments
We would like to thank Martin Thomson, Eliot Lear, Mark Nottingham, We would like to thank Martin Thomson, Eliot Lear, Mark Nottingham,
Niels ten Oever, Vittorio Bertola, Antoine Fressancourt, Cullen Niels ten Oever, Vittorio Bertola, Antoine Fressancourt, Cullen
Jennings, and Dhruv Dhody for their reviews and feedback. Jennings, and Dhruv Dhody for their reviews and feedback.
Authors' Addresses Authors' Addresses
Mirja Kühlewind Mirja Kühlewind
Ericsson Research
Email: mirja.kuehlewind@ericsson.com Email: mirja.kuehlewind@ericsson.com
Tommy Pauly Tommy Pauly
Apple
Email: tpauly@apple.com Email: tpauly@apple.com
Christopher A. Wood Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net Email: caw@heapingbits.net
 End of changes. 107 change blocks. 
339 lines changed or deleted 346 lines changed or added

This html diff was produced by rfcdiff 1.48.