RFC 9614

Partitioning as an Architecture for Privacy

📅 published July 2024, from ietf

Partitioning as an Architecture for Privacy 🎀

Series: Internet Architecture Board (IAB) 🏛️ RFC number: 9614 Authors: M. Kühlewind, T. Pauly, and C. A. Wood 💕 Category: Informational 📚 ISSN: 2070-1721 Date: July 2024 🗓️ Obsoletes / Updates: the header doesn't list either one, so this RFC doesn't obsolete or update anything 🙅‍♀️

Abstract ✨

okay so this doc is all about privacy partitioning 🦋 The idea is to spread your data and your communication across several parties on purpose, so that who you are gets separated from what your data is. It's giving "don't let one party see everything" energy 👑 The doc walks through the patterns popping up in newer protocols that partition what data and metadata gets revealed during protocol interactions. It also gives everyone a shared vocabulary and talks about how to analyze these setups 🧠

Status of This Memo 🌸

Not a standards-track spec, sorry bestie 🙈 It's published purely for information.

This doc is a product of the Internet Architecture Board (IAB). The IAB decided it's valuable enough to keep on the permanent record, and it reflects the IAB's consensus. Anything the IAB approves for publication can't be a candidate for any level of Internet Standard, see Section 2 of RFC 7841 🫶

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9614 🔗

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this doc was published. Please read these carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents 🧚

1.  Introduction
2.  Privacy Partitioning
  2.1.  Privacy Contexts
  2.2.  Context Separation
  2.3.  Approaches to Partitioning
3.  A Survey of Protocols Using Partitioning
  3.1.  CONNECT Proxying and MASQUE
  3.2.  Oblivious HTTP and DNS
  3.3.  Privacy Pass
  3.4.  Privacy Preserving Measurement
4.  Applying Privacy Partitioning
  4.1.  User-Identifying Information
  4.2.  Selecting Client Identifiers
  4.3.  Incorrect or Incomplete Partitioning
  4.4.  Selecting Information within a Context
5.  Limits of Privacy Partitioning
  5.1.  Violations by Collusion
  5.2.  Violations by Insufficient or Incorrect Partitioning
    5.2.1.  Violations from Application Information
    5.2.2.  Violations from Network Information
    5.2.3.  Violations from Side Channels
    5.2.4.  Identifying Partitions
6.  Partitioning Impacts
7.  Security Considerations
8.  IANA Considerations
9.  Informative References
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses

1. Introduction ✨

okay so protocols like TLS and IPsec give you a secure channel between two endpoints, meaning it's authenticated and encrypted, so the info you send gets passed along safely 🔐 Encryption and authentication in transit are a must so that nobody other than the intended protocol participants can see or change your info. This kind of security is what keeps the information sent over these channels private 💖

BUT 😭 a secure channel between two endpoints is NOT enough for the privacy of the endpoints themselves. Privacy needs have grown way past just protecting data in transit between two endpoints. A few examples of this glow-up:

  • A user visits a website service and doesn't consent to share their location, but if that service can see the client's IP address, it can learn something about where the user is. That's a privacy problem, because the service can link user data to the user's location 📍
  • A user wants to read content they're allowed to access, like a news article. The news service might still track which users read which articles, even when the user doesn't want their activity tracked. That's a privacy problem, because the service can link user activity to the user's account 📰
  • A client device might need to upload metrics to an aggregation service, and doing so lets the service attribute those specific metric contributions to that device. That's a privacy problem, because the service can link client contributions to the specific client 📊

The common thread is that clients want to use a service without giving it too much user-specific or identifying info. Specifically, keeping user-specific identity info separate from user-specific data is necessary for privacy. So to protect user privacy, it's really important to keep identity (who) and data (what) apart 🫶

This doc defines "privacy partitioning" 🧩 (sometimes also called the "decoupling principle" [DECOUPLING]). It's the general technique for separating the data and metadata that different parties can see during network communication, with the goal of improving user privacy. Privacy partitioning can't guarantee there's no link between user-specific identity and user-specific data. But when it's applied properly, it helps make privacy violations more technically difficult to pull off over time 🛡️

Several IETF working groups are building protocols and systems that follow the privacy partitioning principle, including Oblivious HTTP Application Intermediation (OHAI), Multiplexed Application Substrate over QUIC Encryption (MASQUE), Privacy Pass, and Privacy Preserving Measurement (PPM). This doc summarizes what those groups are doing and offers a framework for thinking about the resulting privacy posture of different endpoints in practice 🌈

Privacy partitioning is especially useful as a tool for data minimization, which is described in Section 6.1 of [RFC6973]. [RFC6973] gives guidance on privacy considerations for Internet protocols, and it includes a set of questions for evaluating a protocol's data minimization in Section 7.1 of [RFC6973]. Protocols that use privacy partitioning ought to work through the questions in that section when evaluating their design. They should pay special attention to how identifiers and data can be correlated by protocol participants and observers in each partitioned context 🔍 Privacy partitioning can also separate identity providers from relying parties (see Section 6.1.4 of [RFC6973]), like in the case of Privacy Pass (see Section 3.3) 🎟️

Heads up though: privacy partitioning is NOT a panacea 🙅‍♀️ Applying it well means doing a holistic analysis of the system in question to figure out whether partitioning, both as a tool and as actually implemented, gives you meaningful privacy improvements. See Section 5 for more 💅

2. Privacy Partitioning 🦋

For user privacy, this doc focuses on user-specific information. That can include any identifying info specific to a user, like their email address or IP address, or any data about the user, like their date of birth 🎂 Basically, the goal of privacy partitioning is to make sure every party in a system, other than the user themselves, only has access to one type of user-specific information 🎯

This is a straightforward use of the principle of least privilege. Every party in the system only gets the minimum amount of info it needs to do its job. Privacy partitioning pushes for this minimization by making sure protocols, applications, and systems only reveal user-specific info to the parties that actually need it for their intended purpose 🌸

Put simply, privacy partitioning is all about separating who someone is from what they do 💖 In the rest of this section, we'll go over how privacy partitioning can get that done ✨

2.1. Privacy Contexts ✨

okay so bestie, every bit of user-specific info lives inside some context 🫧. A context is basically a bubble: a pile of data, the metadata riding along with it, and all the entities that can see it. To stop user info from getting linked across bubbles, partitions have to make sure that any single entity (other than the client itself) does not hang out in more than one bubble where that info is visible 🙈

[RFC6973] explains why identifiers matter for cutting down on correlation, which is a big privacy win 💜

Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined.... Correlation is closely related to identification. Internet protocols can facilitate correlation by allowing individuals' activities to be tracked and combined over time.... Pseudonymity is strengthened when less personal data can be linked to the pseudonym; when the same pseudonym is used less often and across fewer contexts; and when independently chosen pseudonyms are more frequently used for new actions (making them, from an observer's or attacker's perspective, unlinkable).

Context separation is the foundation of privacy partitioning and of reducing correlation 🌸 Let's look at an unencrypted HTTP session over TCP. Its context includes the content of the transaction plus any metadata from the transport and IP headers 📦 The participants are the client, routers, other network middleboxes, intermediaries, and the server. Middleboxes or intermediaries might just forward traffic, or they might terminate it at any layer (like ending the TCP connection from the client and opening a brand new TCP connection to the server). Either way, for privacy partitioning, they can see all of the data in the context 👀

   +-------------------------------------------------------------------+
   | Context A                                                         |
   |  +--------+                +-----------+              +--------+  |
   |  |        +------HTTP------+           +--------------+        |  |
   |  | Client |                | Middlebox |              | Server |  |
   |  |        +------TCP-------+           +--------------+        |  |
   |  +--------+      flow      +-----------+              +--------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

         Figure 1: Diagram of a Basic Unencrypted Client-to-Server
                        Connection with Middleboxes

Adding TLS encryption to the HTTP session is a simple partitioning trick that splits the one context into two separate contexts 🦋 Now the content of the transaction is only visible to the client, TLS-terminating intermediaries, and the server, while the metadata in the transport and IP headers stays in the original context. Here's the catch: without any further partitioning, the entities that sit in both contexts can still correlate the data across them 😭

   +-------------------------------------------------------------------+
   | Context A                                                         |
   |  +--------+                                           +--------+  |
   |  |        |                                           |        |  |
   |  | Client +-------------------HTTPS-------------------+ Server |  |
   |  |        |                                           |        |  |
   |  +--------+                                           +--------+  |
   |                                                                   |
   +-------------------------------------------------------------------+
   | Context B                                                         |
   |  +--------+                +-----------+              +--------+  |
   |  |        |                |           |              |        |  |
   |  | Client +-------TCP------+ Middlebox +--------------+ Server |  |
   |  |        |       flow     |           |              |        |  |
   |  +--------+                +-----------+              +--------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

       Figure 2: Diagram of How Adding Encryption Splits the Context
                                  into Two

Another way to make a partition is to just use separate connections 🧚 For example, to split two separate HTTP requests from each other, a client could send the requests on separate TCP connections, each on a different network and at different times, and avoid including obvious identifiers like HTTP cookies across the requests 🍓

   +-------------------------------------------------------------------+
   | Context A                                                         |
   |  +--------+                +-----------+              +--------+  |
   |  |        | IP A           |           |              |        |  |
   |  | Client +-------TCP------+ Middlebox +--------------+ Server |  |
   |  |        |      flow A    |     A     |              |        |  |
   |  +--------+                +-----------+              +--------+  |
   |                                                                   |
   +-------------------------------------------------------------------+
   | Context B                                                         |
   |  +--------+                +-----------+              +--------+  |
   |  |        | IP B           |           |              |        |  |
   |  | Client +-------TCP------+ Middlebox +--------------+ Server |  |
   |  |        |      flow B    |     B     |              |        |  |
   |  +--------+                +-----------+              +--------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

        Figure 3: Diagram of Making Separate Connections to Generate
                             Separate Contexts

Using separate connections to create separate contexts can reduce or eliminate the ability of specific parties to correlate activity across contexts 💅 BUT (and this is important, bestie) any identifier at any layer that is common across different contexts can still be used to correlate activity 🚨 Beyond IP addresses, lots of other factors can be combined into a fingerprint of a specific device, like Media Access Control (MAC) addresses, device properties, software properties and behavior, application state, etc. 🔍

2.2. Context Separation 🌈

To define and analyze how the various partitioning techniques work, we first need to pin down the boundaries of what is being partitioned 📏 That's the job of context separation. Specifically, to stop user-specific info from being correlated across contexts, partitions need to make sure that any single entity (other than the client itself) does not participate in contexts where both identifiers are visible 🫶

Context separation can be achieved in different ways, for example over time, across network paths, or based on (en)coding, etc. ⭐ The privacy-oriented protocols described in this document usually involve more complex partitioning, but they still use the same underlying techniques to partition communication contexts:

  • Cryptographic protection, such as the use of encryption to specific parties, allows partitioning of contexts between different parties (those with the ability to remove cryptographic protections, and those without).
  • Connection separation across time or space to allow partitioning of contexts for different application transactions over the network.

These techniques are often used together for context separation 🧩 For example, encrypting an HTTP exchange with TLS between the client and a TLS-terminating server might stop a network middlebox that sees a client IP address from seeing the user account identifier. BUT it doesn't stop the TLS-terminating server from observing both identifiers and correlating them 😬 So, preventing correlation takes actual context separation, like using proxying to hide a client's IP address that would otherwise be used as an identifier 🎭

2.3. Approaches to Partitioning 💖

All of the partitioning protocols described in this document create separate contexts using cryptographic protection and/or connection separation 🔐 But each one has its own unique approach that results in a different set of contexts. Since many of these protocols are brand new, we'll have to wait and see how each approach gets used at scale across the Internet and what new models pop up in the future 🔮

There are several factors that lead to this diversity in approaches to partitioning, including:

  • Adding privacy partitioning to existing protocol ecosystems places requirements and constraints on how contexts are constructed. CONNECT-style proxying is meant to work with servers that are unaware of privacy contexts, which means it needs more intermediaries to provide strong separation guarantees 🏗️ On the other hand, Oblivious HTTP assumes servers that cooperate with context separation and, thus, reduces the overall number of elements in the solution 🌟
  • Whether or not information exchange needs to happen bidirectionally in an interactive fashion determines how contexts can be separated 🔄 Some use cases, like metrics collection for PPM, can happen where information only flows from clients to servers, and they can work even when clients are no longer connected 📤 Privacy Pass is an example of a case that can be either interactive or not, depending on whether tokens can be cached and reused 🎟️ CONNECT-style proxying and Oblivious HTTP often require bidirectional and interactive communication 💬
  • The degree to which contexts need to be partitioned depends in part on the client's threat models and level of trust in various protocol participants 🕵️‍♀️ For example, in Oblivious HTTP, clients allow relays to learn that they are accessing a particular application-specific gateway. If clients don't trust relays with this information, they can instead use a multi-hop CONNECT-style proxy approach where no single party learns whether specific clients are accessing a specific application 🧅 This is the default trust model for systems like Tor, where multiple hops are used to drive down the probability of privacy violations due to collusion or related attacks 👑

3. A Survey of Protocols Using Partitioning 🦋

The following section discusses current ongoing work in the IETF that is applying privacy partitioning 🌸

3.1. CONNECT Proxying and MASQUE 🎀

Okay so bestie, forward proxies are lowkey the MVPs of privacy partitioning ✨. When the connection between the client and the proxy is encrypted, the proxy gets split into segments, and each segment only knows so much. If the connections to targets through the proxy are encrypted too, the proxy can't read the end-to-end content. 🙈 HTTP has been doing forward proxying for TCP-like streams with the CONNECT method for a long time. More recently, the Multiplexed Application Substrate over QUIC Encryption (MASQUE) Working Group has been cooking up protocols that proxy UDP [CONNECT-UDP] and IP packets [CONNECT-IP] using tunneling. It's giving main character energy 💅

In a single-proxy setup, there's a tunnel connection between the client and the proxy, and then an end-to-end connection that gets tunneled between the client and the target. As shown in Figure 4, this splits the communication into four contexts:

  • a Client-to-Target encrypted context, which holds the end-to-end content inside the TLS session to the target, like HTTP content 🔐;
  • a Client-to-Target proxied context, which is the end-to-end data exchanged with the target that the proxy can also see, like a TLS session 👀;
  • a Client-to-Proxy context, which holds the transport metadata between the client and the target, plus the request asking the proxy to open a connection to the target 📨; and
  • a Proxy-to-Target context, which, for TCP and UDP proxying, holds any packet header info that the proxy adds or changes, e.g., the IP and TCP/UDP headers 🧩.
+-------------------------------------------------------------------+
| Client-to-Target Encrypted Context                                |
|  +--------+                                           +--------+  |
|  |        |                                           |        |  |
|  | Client +------------------HTTPS--------------------+ Target |  |
|  |        |                 content                   |        |  |
|  +--------+                                           +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Target Proxied Context                                  |
|  +--------+                +-----------+              +--------+  |
|  |        |                |           |              |        |  |
|  | Client +----Proxied-----+   Proxy   +--------------+ Target |  |
|  |        |    TLS flow    |           |              |        |  |
|  +--------+                +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Proxy Context                                           |
|  +--------+                +-----------+                          |
|  |        |                |           |                          |
|  | Client +---Transport----+   Proxy   |                          |
|  |        |     flow       |           |                          |
|  +--------+                +-----------+                          |
|                                                                   |
+-------------------------------------------------------------------+
| Proxy-to-Target Context                                           |
|                            +-----------+              +--------+  |
|                            |           |              |        |  |
|                            |   Proxy   +--Transport---+ Target |  |
|                            |           |    flow      |        |  |
|                            +-----------+              +--------+  |
|                                                                   |
+-------------------------------------------------------------------+

                Figure 4: Diagram of One-Hop Proxy Contexts

Using two (or more) proxies gives you even better privacy partitioning ✨🦋. Specifically, with two proxies, each proxy sees either the Client metadata but not the Target, the Target but not the Client metadata, or neither. Iconic 👑

On top of the contexts we just covered for the single proxy case, the two-hop proxy case in Figure 5 changes the contexts in a few ways:

  • the Client-to-Target proxied context only includes the second proxy (called "Proxy B" here) 🌸;
  • a new Client-to-Proxy B context gets added, which is the TLS session from the client to Proxy B that the first proxy (called "Proxy A" here) can also see 🫶; and
  • the contexts that only see transport data (TCP or UDP over IP) get split into three separate contexts: a Client-to-Proxy A context, a Proxy A-to-Proxy B context, and a Proxy B-to-Target context 💜.
+-------------------------------------------------------------------+
| Client-to-Target Encrypted Context                                |
|  +--------+                                           +--------+  |
|  |        |                                           |        |  |
|  | Client +------------------HTTPS--------------------+ Target |  |
|  |        |                 content                   |        |  |
|  +--------+                                           +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Target Proxied Context                                  |
|  +--------+                           +-------+       +--------+  |
|  |        |                           |       |       |        |  |
|  | Client +----------Proxied----------+ Proxy +-------+ Target |  |
|  |        |          TLS flow         |   B   |       |        |  |
|  +--------+                           +-------+       +--------+  |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Proxy B Context                                         |
|  +--------+         +-------+         +-------+                   |
|  |        |         |       |         |       |                   |
|  | Client +---------+ Proxy +---------+ Proxy |                   |
|  |        |         |   A   |         |   B   |                   |
|  +--------+         +-------+         +-------+                   |
|                                                                   |
+-------------------------------------------------------------------+
| Client-to-Proxy A Context                                         |
|  +--------+         +-------+                                     |
|  |        |         |       |                                     |
|  | Client +---------+ Proxy |                                     |
|  |        |         |   A   |                                     |
|  +--------+         +-------+                                     |
|                                                                   |
+-------------------------------------------------------------------+
| Proxy A-to-Proxy B Context                                        |
|                     +-------+         +-------+                   |
|                     |       |         |       |                   |
|                     | Proxy +---------+ Proxy |                   |
|                     |   A   |         |   B   |                   |
|                     +-------+         +-------+                   |
|                                                                   |
+-------------------------------------------------------------------+
| Proxy B-to-Target Context                                         |
|                                       +-------+       +--------+  |
|                                       |       |       |        |  |
|                                       | Proxy +-------+ Target |  |
|                                       |   B   |       |        |  |
|                                       +-------+       +--------+  |
|                                                                   |
+-------------------------------------------------------------------+

                Figure 5: Diagram of Two-Hop Proxy Contexts

Forward proxying, like the modes of proxying in the MASQUE protocols, uses both encryption (via TLS) and separate connections (via proxy hops that only see the next hop) to get privacy partitioning. It's a whole team effort, and I'm obsessed 🧚💖

3.2. Oblivious HTTP and DNS 🦋

okay so Oblivious HTTP [OHTTP] is giving total privacy realness 💜 It was developed in the Oblivious HTTP Application Intermediation (OHAI) Working Group, and it adds per-message encryption to HTTP exchanges through a relay system 🔐. Clients send requests through an Oblivious Relay, which cannot read the message contents 🙈, on the way to an Oblivious Gateway. The Gateway can decrypt the messages, but it can't talk to the client directly or see client metadata like an IP address 💅. Under the hood, Oblivious HTTP relies on Hybrid Public Key Encryption [HPKE] to do the encryption ✨.

Oblivious HTTP uses both encryption and separation of connections to get its privacy partitioning, and it's honestly so clever 🧚

  • End-to-end messages are encrypted between the Client and Gateway. The content of these inner messages is visible to the Client, Gateway, and Target. This is the Client-to-Target context.
  • The encrypted messages exchanged between the Client and Gateway are visible to the Relay, but the Relay cannot decrypt them. This is the Client-to-Gateway context.
  • The transport connections (such as TCP and TLS) between the Client, Relay, and Gateway form two separate contexts: a Client-to-Relay context and a Relay-to-Gateway context. It's important to note that the Relay-to-Gateway connection can be a single connection, even if the Relay has many separate Clients. This gives better anonymity, because the pseudonym the Relay shows is shared across lots of Clients 🌸
   +-------------------------------------------------------------------+
   | Client-to-Target Context                                          |
   |  +--------+                           +---------+     +--------+  |
   |  |        |                           |         |     |        |  |
   |  | Client +---------------------------+ Gateway +-----+ Target |  |
   |  |        |                           |         |     |        |  |
   |  +--------+                           +---------+     +--------+  |
   |                                                                   |
   +-------------------------------------------------------------------+
   | Client-to-Gateway Context                                         |
   |  +--------+         +-------+         +---------+                 |
   |  |        |         |       |         |         |                 |
   |  | Client +---------+ Relay +---------+ Gateway |                 |
   |  |        |         |       |         |         |                 |
   |  +--------+         +-------+         +---------+                 |
   |                                                                   |
   +-------------------------------------------------------------------+
   | Client-to-Relay Context                                           |
   |  +--------+         +-------+                                     |
   |  |        |         |       |                                     |
   |  | Client +---------+ Relay |                                     |
   |  |        |         |       |                                     |
   |  +--------+         +-------+                                     |
   |                                                                   |
   +-------------------------------------------------------------------+
   | Relay-to-Gateway Context                                          |
   |                     +-------+         +---------+                 |
   |                     |       |         |         |                 |
   |                     + Relay +---------+ Gateway |                 |
   |                     |       |         |         |                 |
   |                     +-------+         +---------+                 |
   |                                                                   |
   +-------------------------------------------------------------------+

Figure 6: Diagram of Oblivious HTTP Contexts

Oblivious DNS over HTTPS (ODoH) [ODOH] uses the same principle as Oblivious HTTP, but it only works on DNS messages 🌐 It's kind of a precursor to the more generalized Oblivious HTTP, so it relies on the same HPKE cryptographic primitives and can be analyzed in the same way 💖

3.3. Privacy Pass 🎀

Okay, Privacy Pass is an architecture [RFC9576] and a set of protocols being developed in the Privacy Pass Working Group 🧁 It lets clients prove they've been verified in a way that's anonymous and unlinkable, using tokens 🔑 These tokens were first designed to prove a client had solved a CAPTCHA, but they can be used for other kinds of user or device attestation checks too. In Privacy Pass, clients talk to an attester and an issuer to get a token issued, and then they talk to an origin server to redeem that token 💫

In Privacy Pass, privacy partitioning comes from cryptographic protection (blind signature protocols or something similar) plus separation of connections across two contexts: a "redemption context" between clients and origins (servers that request and receive tokens), and an "issuance context" between clients, attestation servers, and token issuance servers. The cryptographic protection makes sure that what gets revealed during the issuance context stays separate from what gets revealed during the redemption context 🦋

   +-------------------------------------------------------------------+
   | Redemption Context                                                |
   |  +--------+         +--------+                                    |
   |  |        |         |        |                                    |
   |  | Origin +---------+ Client |                                    |
   |  |        |         |        |                                    |
   |  +--------+         +--------+                                    |
   |                                                                   |
   +-------------------------------------------------------------------+
   | Issuance Context                                                  |
   |                     +--------+      +----------+      +--------+  |
   |                     |        |      |          |      |        |  |
   |                     | Client +------+ Attester +------+ Issuer |  |
   |                     |        |      |          |      |        |  |
   |                     +--------+      +----------+      +--------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

Figure 7: Diagram of Contexts in Privacy Pass

Since the redemption context and issuance context are separate connections involving separate entities, you can decouple them even further by running those parts of the protocols at different times ⏰ Clients can fetch tokens through the issuance context early and cache them for later use in redemption contexts. This can help partition identifiers and data, which is such a smart move 🧠✨

[RFC9576] describes different deployment models for which entities operate origins, attesters, and issuers. In some models they're all separate entities, and in others the same entity can run them all. The model affects how well partitioning works 👀 Some models (like when all three are run by the same entity) only give effective partitioning when the timing of connections on the two contexts isn't correlated and when the client uses different identifiers (such as different IP addresses) on each context. Be careful with that one, bestie 🙈

3.4. Privacy Preserving Measurement 📊

The Privacy Preserving Measurement (PPM) Working Group is chartered to develop protocols and systems that help a data aggregation or collection server (or multiple non-colluding servers) compute aggregate values without learning the value of any one client's individual measurement 🍓 The Distributed Aggregation Protocol (DAP) is the group's primary working item, and it's the main star of the show 👑

At a high level, DAP uses cryptographic protection (in the form of secret sharing among non-colluding servers) to set up two contexts 🔐

  • an "upload context" between clients and non-colluding aggregation servers (where the servers are split into "Helper" and "Leader" roles). Here, aggregation servers might learn client identity, but they learn nothing about individual measurement reports; and
  • a "collect context" where a collector learns aggregate measurement results and nothing about individual client data 💜
   +-------------------------------------+--------------------+
   | Upload Context                      | Collect Context    |
   |                     +------------+  |                    |
   |              +----->|   Helper   |  |                    |
   | +--------+   |      +------------+  |                    |
   | |        +---+             ^        |   +-----------+    |
   | | Client |                 |        |   | Collector |    |
   | |        +---+             v        |   +-----+-----+    |
   | +--------+   |      +------------+  |         |          |
   |              +----->|   Leader   |<-----------+          |
   |                     +------------+  |                    |
   +-------------------------------------+--------------------+

Figure 8: Diagram of Contexts in DAP

4. Applying Privacy Partitioning ✨

Applying privacy partitioning to an existing or new system or protocol takes the following steps, bestie 💅

  1. Identify the types of information used or exposed in a system or protocol. Some of it can be used to identify a user or correlate to other contexts 🕵️
  2. Partition data to minimize the amount of user-identifying or correlatable information in any given context. Each context should only include what's necessary for that context, and data sharing across contexts should be prevented wherever possible 🧚

The most impactful types of information to partition are (a) user-identifying information, such as user identifiers (including account names or IP addresses) that can be linked, and (b) non-user-identifying information (including content a user generates or accesses), which can often be sensitive when combined with a user identifier 🌈

In this section, we talk through considerations for partitioning these types of information 🫶

4.1. User-Identifying Information ✨

okay so user data can itself be user-identifying 👀, and when it is, you should treat it like an identifier 🫶. Like, Oblivious DoH and Oblivious HTTP split the client IP address and the client request data into separate contexts 🦋, so nobody besides the client can see both 💅. iconic.

But if the contexts collude 💀, that partitioning can get reversed, and stuff that used to be harmless (non-user-identifying) can suddenly become user-identifying. For example, in CONNECT proxy systems that use QUIC, the QUIC connection ID is non-user-identifying by nature because it's generated randomly (Section 5.1 of [QUIC]) 🎲. However, if you combine it with another context that has user-identifying info, like the client IP address, the QUIC connection ID can become user-identifying info 😭.

Some info is just baked into client user-agents 🧁, including details of their network location and how protocols are implemented in hardware and software. That info can be used to build user-identifying info, a process people sometimes call "fingerprinting" 🕵️‍♀️. Depending on the application and system constraints, users may not be able to prevent fingerprinting in privacy contexts. So fingerprinting info, when combined with non-user-identifying user data, could turn that otherwise innocent data into user-identifying info. not me getting plot twisted 🙈

4.2. Selecting Client Identifiers 🎀

okay the way client identifiers get picked for the contexts used in privacy partitioning has a HUGE impact on how well partitioning works 🔥. Picking identifiers can either wreck the value of partitioning or make it even better 💖. Generally, each context involves some form of client identifier. It might be tied directly to a client identity, but it can also be a pseudonym or a random one-time identifier 🌸.

Using the same client identifier across multiple contexts can partly or fully undermine partitioning, because it lets those contexts get linked back to the same client 😩. For example, if a client uses proxies as described in Section 3.1 to separate connections, but uses the same email address to log into two servers in different contexts, those actions can be linked back to the same client 📧. Not all of the partitioning from proxying is lost, tho 💅: the contexts along the network path still can't correlate the client identity with which servers are being accessed. The overall effect is still diminished though 😔.

When possible, using per-context unique client identifiers gives better partitioning properties ✨. For example, a client can use a unique email address as an account identifier with each different server it needs to log into 💌. The same idea applies across many layers, like per-network MAC address randomization [RANDOM-MAC] 🎲, using multiple temporary IP addresses across connections and over time [RFC8981] 🦋, and using unique per-subscription identifiers for HTTP Web Push [RFC8030] 🔔. Main character identifier energy 👑.

4.3. Incorrect or Incomplete Partitioning 🙃

Privacy partitioning can be applied incorrectly or incompletely 😬. Contexts may contain more user-identifying info than anyone wanted, or some info in a context may be more user-identifying than intended. Also, splitting user-identifying info across multiple contexts has to be done with care 🧐, because creating more contexts can increase the number of entities that need to be trusted to not collude. Still, partitions can help improve the client's privacy posture when applied carefully 🌈.

Figuring out the privacy of a system or protocol that applies privacy partitioning depends on which contexts exist and what types of user-identifying info are in each one 🔍. This kind of evaluation helps spot ways a system or protocol can improve its privacy posture. For example, consider DNS over HTTPS [DOH] 🍓, which makes a single context containing both the client IP address and the client query. One application of privacy partitioning gives you ODoH, which makes two contexts: one with the client IP address and the other with the client query 🫶. two separate lanes, no crashes 🚗💨.

4.4. Selecting Information within a Context 🧠

To recognize where privacy partitioning could be applied, you need to identify the contexts in use, the information exposed in each context, and the intent behind the info exposed in each context 🎯. Figuring out what info belongs in a given context is a non-trivial task 😵‍💫. In principle, the info in a context should be fit for purpose ✨. So new systems or protocols should aim to make sure all info exposed in a context serves as few purposes as possible 💜. Designing with this in mind from the start helps prevent issues when users of a system or protocol accidentally ossify on the info available in contexts 🪨.

Legacy systems that have ossified on info available in contexts can be hard to change in practice 😭. For example, many existing anti-abuse systems depend on some client identifier, like the client IP address, combined with client data to be useful 🛡️. Partitioning the contexts in those systems so they no longer determine client identity means you need new solutions for the anti-abuse problem 🥲.

5. Limits of Privacy Partitioning ⚠️

Privacy partitioning aims to increase user privacy, but as we said, it's just one of possibly many architectural tools for managing privacy risks 🧰. Understanding its limits requires a more comprehensive analysis of the system in question 🔬. That analysis also helps determine whether the tool has been applied correctly ✅. The value of privacy partitioning depends on lots of factors, including (but not limited to) the following 📋:

  • non-collusion across contexts and
  • the type of information exposed in each context.

We'll break down each one in the sections below 💅.

5.1. Violations by Collusion 🤝💀

Privacy partitions make sure that only the client, the entity responsible for partitioning, can independently link all user-specific info 🧩. No other entity can individually figure out how to link all the user-specific info, as long as they don't collude with each other across contexts 🙅‍♀️. So non-collusion is a fundamental requirement for privacy partitioning to offer meaningful privacy for end users 🔐. The trust relationships users have with different parties also affect how much impact there is on the user's privacy 💭.

For example, look at Oblivious HTTP (OHTTP) 🦋. The Oblivious Relay knows the client identity but not the client data, and the Oblivious Gateway knows the client data but not the client identity. If the Oblivious Relay and Gateway collude, they can link client identity and data together for each request and response transaction, just by watching requests in transit 👀💀.

Right now, there's no way to guarantee with technical protocol measures that two entities aren't colluding 😩. Even if two entities don't collude directly, if both reveal info to other parties, you can't guarantee that the info won't get combined 🫠. There are still some mitigations to reduce the risk of collusion in practice 🛡️:

  • Policy and contractual agreements between entities involved in partitioning to disallow logging or sharing of data, along with auditing to check that the policies are being followed. For cases where logging is required (such as for service operation), the logged data should be minimized and anonymized so it can't be useful for collusion 📝.
  • Protocol requirements to make collusion or data sharing more difficult 🚧.
  • Adding more partitions and contexts to make it increasingly difficult to collude with enough parties to recover identities 🧱.

5.2. Violations by Insufficient or Incorrect Partitioning 🙀

Insufficient or incorrect application of privacy partitioning can lessen or cancel out the benefits for users 📉. It's possible to apply partitioning in a way that's either insufficient or incorrect for meaningful privacy 😤. For example, partitioning at one layer of the stack can fail to account for linkable info at different layers 🥞. Privacy violations can come from partitioning failures in a bunch of ways, and some are described in the following sections 🫣.

5.2.1. Violations from Application Information 📱

Partitioning at the network layer can be insufficient when the application layer doesn't partition properly 🙅‍♀️. For example, consider OHTTP used to hide client-identifying info for a browser telemetry system 📊. It's totally possible for reports in a telemetry system like that to contain both client-specific telemetry data, like info about their specific browser instance, and client-identifying info, like the client's email address, location, or IP address 😱. Even though OHTTP separates the client IP address from the server via a relay, the server can still learn it directly from the client's telemetry report 🤦‍♀️.

5.2.2. Violations from Network Information 🌐

It's also possible to partition inadequately at the network layer 📡. For example, consider both TLS Encrypted Client Hello (ECH) [TLS-ESNI] and VPNs 🔐. ECH uses cryptographic protection (encryption) to hide info from unauthorized parties, but both clients and servers (two entities) can link user-specific data to a user-specific identifier (IP address) 😬. Similarly, while VPNs hide identifiers from end servers, the VPN server can still see the identifiers of both the client and the server 👀. Applying privacy partitioning would call for at least two additional entities so that neither party reveals both identity (who) and user actions (what) 🫶.

5.2.3. Violations from Side Channels 🕳️

Beyond the info that's intentionally revealed by applying privacy partitioning, info can also be unintentionally revealed through side channels 😳. For example, in the two-hop proxy arrangement described in Section 3.1, Proxy A sees and proxies TLS data between the client and Proxy B 🔁. While it doesn't directly learn what Proxy B sees, it does learn info through metadata, like the timing and size of the encrypted data being proxied ⏱️. Traffic analysis could be exploited to learn more from that metadata, including, in some cases, application data that Proxy A was never meant to see 💀. Privacy partitioning doesn't stop these attacks, but it does increase the cost of carrying them out in practice 💸. See Section 7 for more discussion on this topic 📚.

5.2.4. Identifying Partitions ✨

okay so the obvious privacy leaks from not partitioning properly sound like they should be easy to fix, right? 🙈 but nope, it's still an open problem bestie 😭. figuring out exactly what info needs partitioning for real privacy, and then actually building it so it does what you want, is genuinely hard. it's hard to tell whether a bunch of info reveals "too much" about a specific person, and it's just as tricky to check whether a partitioning setup is actually working the way it's supposed to 💀. there are SO many cases where data was assumed to be "private" or "anonymous" and then, in hindsight, it said way too much and let people get linked back to individual clients 🫠. see [DataSetReconstruction] and [CensusReconstruction] for real-world examples, it's giving cautionary tale fr 📚

6. Partitioning Impacts 🦋

okay so applying privacy partitioning to communication protocols totally changes how the traffic moves 🌈. instead of sending traffic straight to a service, basically all user traffic gets routed through a set of intermediaries, and that can add more end-to-end round trips (depending on the system and protocol) 🧚. there are a few practical consequences, so let's go through them 👑:

  1. Service operational or management challenges: Information that is usually passively observed in the network, or metadata that got revealed to the service provider by accident, won't be available anymore 😭. this can impact existing security procedures like application rate limiting or DDoS mitigation. current network management techniques often rely on info exposed by typical traffic, which doesn't come with guarantees or accuracy 🙃.

privacy partitioning gives us a chance to level up these management techniques 💅. entities can actively exchange information with each other in a privacy-preserving way, and ask for exactly what they need for a specific task or function. that beats relying on a limited pile of accidentally revealed info that can't be guaranteed to stick around and might get removed in the future ✨.

  1. Varying performance effects and costs: Depending on how context separation is done, privacy partitioning may affect application performance 🐢. for example, Privacy Pass introduces an entire end-to-end round trip to issue a token before it can be redeemed, so performance takes a hit 💔. systems like CONNECT proxying might seem like they'd slow things down, but the highly optimized nature of proxy-to-proxy paths often leads to improved performance. plot twist 🎀.

reduced performance can be the reason protocols and deployments skip privacy partitioning altogether 🙈. take HTTPS connection reuse (Section 9.1.1 of [HTTP2]): it lets clients use an existing HTTPS session created for one origin to interact with different origins, as long as the original origin is authoritative for those alternative origins. reusing connections saves the cost of connection establishment, but it also means the server can link the client's activity across those two or more origins together 👀. applying privacy partitioning would stop that, but it usually costs performance.

in general, performance and privacy trade-offs get framed as a zero-sum game, but in practice that's often not the case 🌸. the relationship between privacy and performance shifts depending on a bunch of related factors, like application characteristics, network path properties, and so on.

  1. Increased attack surface: Even when information is adequately partitioned across non-colluding parties, the effects on the end user may not always be positive 😬. using OHTTP as an example, picture this: the Oblivious Gateway has an implementation flaw that causes all of its decrypt requests to get logged in a public or otherwise compromised location. say the Target Resource those requests are headed for doesn't have that flaw. applications that use OHTTP with this flawed Oblivious Gateway to reach the Target Resource risk having their user request info made public 🚨. it's decoupled from user identifying information, sure, but it's still out there. applications that don't use OHTTP to reach the Target Resource don't face that kind of disclosure risk 🧐.
  2. Centralization: Depending on the protocol, the system, and the privacy properties you want, partitioning may inherently force centralization onto a selected set of trusted participants 🏰. for example, the impact of OHTTP on end-user privacy generally goes up with the number of users behind a given Oblivious Relay. the probability of an Oblivious Gateway figuring out which client sent a request forwarded through an Oblivious Relay drops as the number of possible clients behind that relay grows 📈. that trade-off encourages centralization of the Oblivious Relays 🫤.

7. Security Considerations 🔥

okay this section is SERIOUS bestie, so pay attention 🚨. section 5 covers some of the limits of privacy partitioning in practice, and it pushes for holistic analysis so we can figure out how much meaningful privacy improvement partitioning actually gives 🧠. applied correctly, partitioning helps improve an end-user's privacy posture, which makes violations harder to pull off, whether they're technical, social, or policy-based 🛡️. but side channels are still a thing 💀. for example, traffic analysis [FINGERPINT] or timing analysis still work, and they can let an unauthorized entity learn about a context they aren't a participant of 👀. the proposed mitigations for these attacks, like padding application traffic or generating fake traffic, can be very expensive, so they're typically not applied in practice 💸.

still, privacy partitioning moves the threat from something that has direct access to user-specific information to something that takes a lot more effort to pull off, like burning computational resources, to violate end-user privacy 💪. that's a real win, even if it isn't a magic shield 🫶.

8. IANA Considerations 🌸

This document has no IANA actions. 💅

9. Informative References 📚

here's the reading list, bestie 🧚

IAB Members at the Time of Approval 👑

Here's the squad of Internet Architecture Board members who were in charge when this document got the final stamp of approval 💅:

  • Dhruv Dhody
  • Lars Eggert
  • Wes Hardaker
  • Cullen Jennings
  • Mallory Knodel
  • Suresh Krishnan
  • Mirja Kühlewind
  • Tommy Pauly
  • Alvaro Retana
  • David Schinazi
  • Christopher A. Wood
  • Qin Wu
  • Jiankang Yao

Acknowledgments 🫶

Huge thank-yous to Martin Thomson, Eliot Lear, Mark Nottingham, Niels ten Oever, Vittorio Bertola, Antoine Fressancourt, Cullen Jennings, and Dhruv Dhody for their reviews and feedback. You all are literal MVPs 🌸✨

Authors' Addresses 🎀

Mirja Kühlewind Email: mirja.kuehlewind@ericsson.com

Tommy Pauly Email: tpauly@apple.com

Christopher A. Wood Email: caw@heapingbits.net

📦 where this page comes from