RFC 6973

RFC 6973: Privacy Considerations for Internet Protocols 🎀

Okay bestie, this one is from the Internet Architecture Board (IAB) 💅 and it's an Informational document, which means it's published for our benefit and is not an Internet Standard 🌸. It's dated July 2013 and has the ISSN 2070-1721 ✨. The authors are A. Cooper (CDT), H. Tschofenig (Nokia Siemens Networks), B. Aboba (Skype), J. Peterson (NeuStar, Inc.), J. Morris, M. Hansen (ULD), and R. Smith (Janet) 🫶. The title block doesn't list anything it Obsoletes or Updates, so this one is a standalone vibe 🦋.

Abstract

This doc gives guidance on writing privacy considerations for protocol specs 🧚. Its goal is to make designers, implementers, and users of Internet protocols aware of the privacy-related design choices they're making 👑. It also says that whether a particular RFC needs a specific privacy considerations section depends on what's actually in that document 💖.

Status of This Memo

Not an Internet Standards Track spec, just published for informational purposes 🍓. It's a product of the Internet Architecture Board (IAB), and the IAB decided it's valuable enough to keep on the permanent record ✨. It represents the consensus of the IAB 🫶. Documents the IAB approves for publication are not a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 💅.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6973 🌈.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication 📜. Please actually read these, because they lay out your rights and restrictions with respect to this document 🙈.

Table of Contents

1. Introduction ....................................................4
2. Scope of Privacy Implications of Internet Protocols .............5
3. Terminology .....................................................6
   3.1. Entities ...................................................7
   3.2. Data and Analysis ..........................................8
   3.3. Identifiability ............................................9
4. Communications Model ...........................................10
5. Privacy Threats ................................................12
   5.1. Combined Security-Privacy Threats .........................13
        5.1.1. Surveillance .......................................13
        5.1.2. Stored Data Compromise .............................14
        5.1.3. Intrusion ..........................................14
        5.1.4. Misattribution .....................................14
   5.2. Privacy-Specific Threats ..................................15
        5.2.1. Correlation ........................................15
        5.2.2. Identification .....................................16
        5.2.3. Secondary Use ......................................16
        5.2.4. Disclosure .........................................17
        5.2.5. Exclusion ..........................................17
6. Threat Mitigations .............................................18
   6.1. Data Minimization .........................................18
        6.1.1. Anonymity ..........................................19
        6.1.2. Pseudonymity .......................................20
        6.1.3. Identity Confidentiality ...........................20
        6.1.4. Data Minimization within Identity Management .......21
   6.2. User Participation ........................................21
   6.3. Security ..................................................22
7. Guidelines .....................................................23
   7.1. Data Minimization .........................................24
   7.2. User Participation ........................................25
   7.3. Security ..................................................25
   7.4. General ...................................................26
8. Example ........................................................26
9. Security Considerations ........................................31
10. Acknowledgements ..............................................31
11. IAB Members at the Time of Approval ...........................32
12. Informative References ........................................32

1. Introduction 🌸

Okay so, [RFC3552] already gives protocol designers solid guidance on two things: how to think about security while designing a protocol, and how to tell readers of the spec about security issues 🧠. This doc is trying to do the same thing, but for privacy 🔐.

Privacy is a complicated concept with a rich history across lots of disciplines 📚. When it comes to data, it's often applied to "personal data", which is commonly defined as information relating to an identified or identifiable individual 💅. People have come up with plenty of privacy principles and privacy design frameworks in different forums over the years 🌈. These include the Fair Information Practices [FIPs], a baseline set of privacy protections for collecting and using personal data (often based on the principles established in [OECD], for example) 📋. There's also the Privacy by Design concept, which gives high-level privacy guidance for systems design (see [PbD] for one example) ✨. This guidance is inspired by all that prior work, but it's aiming to be more concrete 🎯. It points protocol designers at specific engineering choices that can affect the privacy of the people using Internet protocols 💖.

Different people have wildly different ideas about what privacy means, both in general and for themselves personally [Westin] 🦋. On top of that, privacy as a legal concept is understood differently in different jurisdictions 🌍. So the guidance here is generic on purpose 🫶. It can be used to inform the design of any protocol, to be used anywhere in the world, without reference to specific legal frameworks 👑.

Whether any individual document warrants a specific privacy considerations section depends on the document's content 💅. Documents that are entirely focused on privacy may not need a separate section at all, like "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks" [RFC3325] 🙈. For some specs, privacy considerations are a subset of security considerations, so they can be discussed right there in the security considerations section 🔥. Some documents don't need any privacy discussion, like "Definition of the Opus Audio Codec" [RFC6716] 🍓. The guidance here can and should be used to assess privacy considerations in protocol, architectural, and operational specifications 🧚. It also helps you decide whether those considerations go in a stand-alone section, inside the security considerations section, or throughout the document 💜. The point is to help your thought process during privacy analysis, not to hand you specific directions for writing a privacy considerations section 🎀.

Here's how the rest of this doc is laid out 🗺️. Section 2 describes how far the guidance applies within the IETF and the larger Internet community 🌐. Section 3 explains the terminology used in the doc 📖. Section 4 reviews typical communications architectures, so we can see where privacy threats might pop up 👀. Section 5 talks through privacy threats as they apply to Internet protocols 😭. Section 6 covers the mitigations for those threats 🛡️. Section 7 gives the guidelines for analyzing and documenting privacy considerations in IETF specs 📝. And Section 8 walks through the privacy characteristics of an IETF protocol to show the guidance framework in action ✨.

2. Scope of Privacy Implications of Internet Protocols ✨

Okay so protocols are built to be super flexible 🦋 They can slide into tons of different architectures, contexts, and setups without needing a bunch of tightly coupled parts that depend on each other. Protocol designers usually have a target architecture (or a few) in mind when they're designing, but architectural frameworks often show up later, after the implementations already exist and have been deployed alongside other protocols and components to build full systems. Plot twist 🌀

So, the privacy implications of a protocol can only be predicted so far at design time 🙈 A single protocol might be pretty harmless on its own, and it may lean on privacy and security features at lower layers of the stack (Internet Protocol Security, Transport Layer Security, and so forth) to reduce the risk of attack. But once it's deployed inside a bigger system, or used in a way nobody imagined at design time, it can create new privacy risks 💀 Protocols also get implemented and deployed long after design time, often by different people than the ones who designed them. The guidelines in Section 7 ask protocol designers to think about how their protocols are expected to interact with systems and information that live outside the protocol bounds, but they are not asking anyone to imagine every single possible deployment scenario. Nobody's psychic 🔮

Also, in lots of cases the privacy properties of a system depend on the whole system design, where several protocols get combined into a product; the implementation, which includes the user interface design; and operational deployment practices, like default privacy settings and the security processes of the company doing the deploying. These details are specific to each particular instantiation and are generally outside the scope of what the IETF works on. The guidance here may still help when making choices about these details, but its main goal is to help with the design, implementation, and operation of protocols 🎀

Transparency of data collection and use (often handled through user interface design) is usually relied on, whether rightly or wrongly, as a key factor when figuring out a system's privacy impact 👀 Most IETF work doesn't involve standardizing user interfaces or user-facing communications, but sometimes understanding how users are expected to interact can matter a lot for protocol design. Unexpected user behavior may have an adverse impact on security and/or privacy 😭

Basically, privacy issues (even the ones tied to protocol development) go beyond the technical guidance in this document 💅 Take HTTP [RFC2616] for example. It was designed to allow the exchange of arbitrary data. A complete privacy analysis for uses of HTTP might look at what type of data is exchanged, how that data is stored, and how it is processed. So the analysis for someone's static personal web page would be totally different from using HTTP to exchange health records 🏥 A protocol designer working on HTTP extensions (like Web Distributed Authoring and Versioning (WebDAV) [RFC4918]) isn't expected to describe the privacy risks from every possible usage scenario. Instead, they're expected to describe the privacy properties specific to the extensions, and any particular uses of those extensions that are expected and foreseen at design time 🫶

---

3. Terminology 🧚

This section defines the basic terms used in this document, with references to existing definitions where they fit. Like in [RFC4949], each entry starts with a dollar sign ($) and a space so it's easy to search for automatically. Quick heads up: this document doesn't try to define 'privacy' in one brief sentence 🙅‍♀️ Instead, privacy is the sum of everything in this document. So we follow the approach taken by [RFC3552]. If you want to see a bunch of different short definitions, check out [RFC4949] 📚

3.1. Entities 🧍‍♀️

Several of these terms get elaborated further in Section 4.

$ Attacker: An entity that works against one or more privacy protection goals. Unlike observers, attackers' behavior is unauthorized. 😈

$ Eavesdropper: A type of attacker that passively observes an initiator's communications without the initiator's knowledge or authorization. See [RFC4949]. 👀

$ Enabler: A protocol entity that facilitates communication between an initiator and a recipient without being directly in the communications path. 🪄

$ Individual: A human being. 🫶

$ Initiator: A protocol entity that initiates communications with a recipient. 🚀

$ Intermediary: A protocol entity that sits between the initiator and the recipient and is necessary for the initiator and recipient to communicate. Unlike an eavesdropper, an intermediary is an entity that is part of the communication architecture and is therefore at least tacitly authorized. For example, a SIP [RFC3261] proxy is an intermediary in the SIP architecture. 🌉

$ Observer: An entity that is able to observe and collect information from communications, potentially posing privacy threats depending on the context. As defined in this document, initiators, recipients, intermediaries, and enablers can all be observers. Observers are distinguished from eavesdroppers by being at least tacitly authorized. 🔍

$ Recipient: A protocol entity that receives communications from an initiator. 💌

3.2. Data and Analysis 📊

$ Attack: An intentional act by which an entity attempts to violate an individual's privacy. See [RFC4949]. 💥

$ Correlation: The combination of various pieces of information that relate to an individual, or that obtain that characteristic when combined. 🧩

$ Fingerprint: A set of information elements that identifies a device or application instance. 🫆

$ Fingerprinting: The process of an observer or attacker uniquely identifying (with a sufficiently high probability) a device or application instance based on multiple information elements communicated to the observer or attacker. See [EFF]. 🕵️‍♀️

$ Item of Interest (IOI): Any data item that an observer or attacker might be interested in. This includes attributes, identifiers, identities, communications content, and the fact that a communication interaction has taken place. 🎯

$ Personal Data: Any information relating to an individual who can be identified, directly or indirectly. 🪪

$ (Protocol) Interaction: A unit of communication within a particular protocol. A single interaction may be made up of a single message between an initiator and recipient, or multiple messages, depending on the protocol. 💬

$ Traffic Analysis: The inference of information from observation of traffic flows (presence, absence, amount, direction, timing, packet size, packet composition, and/or frequency), even if flows are encrypted. See [RFC4949]. 🔐

$ Undetectability: The inability of an observer or attacker to sufficiently distinguish whether an item of interest exists or not. 👻

$ Unlinkability: Within a particular set of information, the inability of an observer or attacker to distinguish whether two items of interest are related or not (with a high enough degree of probability to be useful to the observer or attacker). 🔗

3.3. Identifiability 🪞

$ Anonymity: The state of being anonymous. 🥷

$ Anonymity Set: A set of individuals that have the same attributes, making them indistinguishable from each other from the perspective of a particular attacker or observer. 🫥

$ Anonymous: A state of an individual in which an observer or attacker cannot identify the individual within a set of other individuals (the anonymity set). 🌫️

$ Attribute: A property of an individual. 🏷️

$ Identifiability: The extent to which an individual is identifiable. 📏

$ Identifiable: A property in which an individual's identity is capable of being known to an observer or attacker. 👁️

$ Identification: The linking of information to a particular individual to infer an individual's identity, or to allow the inference of an individual's identity in some context. 🔎

$ Identified: A state in which an individual's identity is known. 📣

$ Identifier: A data object uniquely referring to a specific identity of a protocol entity or individual in some context. See [RFC4949]. Identifiers can be based upon natural names (official names, personal names, and/or nicknames) or can be artificial (for example, x9z32vb). However, identifiers are by definition unique within their context of use, while natural names are often not unique. 🆔

$ Identity: Any subset of an individual's attributes, including names, that identifies the individual within a given context. Individuals usually have multiple identities for use in different contexts. 🎭

$ Identity Confidentiality: A property of an individual where only the recipient can sufficiently identify the individual within a set of other individuals. This can be a desirable property of authentication protocols. 🤫

$ Identity Provider: An entity (usually an organization) that is responsible for establishing, maintaining, securing, and vouching for the identities associated with individuals. 🏛️

$ Official Name: A personal name for an individual that is registered in some official context (for example, the name on an individual's birth certificate). Official names are often not unique. 📜

$ Personal Name: A natural name for an individual. Personal names are often not unique and often comprise given names in combination with a family name. An individual may have multiple personal names at any time and over a lifetime, including official names. From a technological perspective, it cannot always be determined whether a given reference to an individual is, or is based upon, the individual's personal name(s) (see Pseudonym). 🙋‍♀️

$ Pseudonym: A name assumed by an individual in some context, unrelated to the individual's personal names known by others in that context, with an intent of not revealing the individual's identities associated with his or her other names. Pseudonyms are often not unique. 🦊

$ Pseudonymity: The state of being pseudonymous. 🫣

$ Pseudonymous: A property of an individual in which the individual is identified by a pseudonym. 🐱

$ Real Name: See Personal Name and Official Name. 🪪

$ Relying Party: An entity that relies on assertions of individuals' identities from identity providers in order to provide services to individuals. In effect, the relying party delegates aspects of identity management to the identity provider(s). Such delegation requires protocol exchanges, trust, and a common understanding of the semantics of information exchanged between the relying party and the identity provider. 🤝

4. Communications Model ✨

okay so bestie, before we get into the spicy stuff, we need the cast list 💅 To understand privacy-harm attacks, you have to see the whole communication setup and what job each actor has in it.

Picture a protocol entity called the initiator 🦋. That's the one who starts the conversation with some recipient. Privacy analysis matters most when the initiator is acting on behalf of an individual (or a different individual each time). That person is the one whose privacy is on the line. Sometimes the initiator is telling the recipient about someone else, and then both people's privacy interests are involved 🫶

Messages can go straight from initiator to recipient, or they can go through an application-layer middleman, like a proxy, cache, or relay, that the two parties need in order to talk at all 🌸 Sometimes that middleman is in the chat the whole time. Sometimes it only shows up to set the call up, for inbound or outbound traffic. Sometimes there's a whole line of middlemen. And down at the lower layers, the entities that forward packets can also get in the way of privacy goals 👀

Some tasks need a bunch of different conversations first. Like, an HTTP request to a server might be preceded by a chat with an Authentication, Authorization, and Accounting (AAA) server so you can get network access, and a chat with a Domain Name System (DNS) server for name resolution 🧚 In that setup the HTTP server is the recipient, and the other servers are enablers helping the initiator talk to the recipient. The roles can flip, too. An HTTP request might set off a chat with an authentication server or other resource servers, and the recipient becomes the initiator in those later chats 🔄

So when you analyze privacy for an architecture with multiple phases, the same entity can be on different teams, or even opposing teams, from a privacy point of view depending on the phase. To really understand the privacy picture, you may need to analyze each phase separately 🎀

Protocol design usually assumes recipients, intermediaries, and enablers are authorized to receive and handle the initiator's data. As [RFC3552] explains, "we assume that the end systems engaging in a protocol exchange have not themselves been compromised". But privacy analysis has to question that assumption, because systems often get compromised specifically to grab personal data 😭

Recipients, intermediaries, and enablers usually aren't thought of as attackers. Still, they can all be privacy threats, depending on context, because they can observe, collect, process, and transfer privacy-relevant data 💜 So the document collectively calls them observers to set them apart from traditional attackers. From a privacy angle, one especially important kind of attacker is the eavesdropper: an entity that quietly watches the initiator's communications without the initiator knowing or agreeing to it 👁️

The threat descriptions in the next section show how observers and attackers can hurt people's privacy. Different attacks work at different points along the path. An observer could run surveillance or identification attacks between the initiator and an intermediary, or it could spy on an enabler instead, like by watching DNS queries coming from the initiator 🍓

---

5. Privacy Threats 🚨

okay, this is the part where we list all the ways privacy can get wrecked 😭 Privacy harms come in a bunch of flavors: harm to your financial standing, your reputation, your solitude, your autonomy, and your safety. Like, if someone gets hit by identity theft or blackmail, they can lose money as a result 💸 Reputational harm happens when information about someone gets disclosed, whether it's true or false, and that person ends up dealing with stigma, embarrassment, or losing their personal dignity. Intrusion or interruption can mess with someone's ability to just be left alone 🙈 When people get monitored, exposed, or are at risk of being exposed, they may hold back on expressing themselves, hanging out with people, or living their lives freely. They can also just feel uneasy, because being watched or having data collected on you is creepy 🫣 And if monitoring is for stalking or violence (like watching the communications going to or from a domestic abuse shelter), it can put people in real physical danger ⚠️

This section lists common privacy threats (pulling heavily from [Solove], plus [CoE]), shows how each one can lead to harm, and gives examples of how these threats show up on the Internet 🌐 The threat modeling is inspired by security threat analysis. It's not a perfect fit for assessing privacy risks in Internet protocols and systems, but honestly, no better methodology has been developed yet 🤷‍♀️

Some privacy threats are already handled in Internet protocols as part of normal security analysis. Others are pure privacy threats that existing security considerations usually don't cover 💅 So the threats here are split into two groups: those that could also count as security threats, and those that are mainly privacy threats 🎀

Here's the thing: whether an individual is aware of the practices described below, and whether they agreed to them, can totally change how they feel about the threat and how worried they are about privacy 🌈 If someone authorizes surveillance of their own activities, for example, they may be able to take steps to reduce the harm, or they may decide the risk is tolerable 🫶

5.1. Combined Security-Privacy Threats

5.1.1. Surveillance

Surveillance is when someone observes or monitors an individual's communications or activities 👀 The effects on the person can range from anxiety and discomfort all the way to behavior changes like holding back and self-censoring, and even to violence against them 😳 The individual doesn't have to know about the surveillance for it to affect their privacy. The mere possibility of surveillance may be enough to harm their autonomy 🦋

Surveillance can affect privacy even when the people being watched aren't identifiable or when their communications are encrypted 🔐 For example, an observer or eavesdropper doing traffic analysis might figure out what type of traffic is flowing (real-time communications or bulk file transfers, say) or which protocols are in use, even if the content is encrypted or the communicating parties can't be identified 🕵️‍♀️ This kind of surveillance can hurt the people involved by making them targets for further investigation or enforcement. It can also enable attacks specific to a protocol, like redirecting traffic to a specialized interception point or protocol-specific denial of service attacks 💥 Protocols that use predictable packet sizes or timing, or that include fixed tokens at predictable offsets within a packet, can make this kind of surveillance easier 🍓

Surveillance can be carried out by observers or eavesdroppers at any point along the communications path 🛤️ Confidentiality protections (as discussed in Section 3 of [RFC3552]) are necessary to stop surveillance of the content of communications 🔒 But to prevent traffic analysis or other surveillance of communication patterns, other measures may be needed, such as [Tor] 🧅

5.1.2. Stored Data Compromise

End systems that don't take adequate measures to protect stored data from unauthorized or inappropriate access put individuals at risk of financial, reputational, or physical harm 💔

Protecting against stored data compromise is usually outside the scope of IETF protocols 🙃 But a bunch of common protocol functions, like key management, access control, or operational logging, need to store data about the initiators of communications 📝 When information about initiators or their communications gets required or recommended to be stored or logged by end systems (see, e.g., RFC 6302 [RFC6302]), it's important to remember that this info could be compromised, and that risk needs to be weighed against the benefits of storing the data ⚖️ Any recipient, intermediary, or enabler that stores data may be vulnerable to compromise 😬 (Note that stored data compromise is different from purposeful disclosure, which is discussed in Section 5.2.4 💅)

5.1.3. Intrusion

Intrusion is all about invasive acts that disturb or interrupt someone's life or activities 📵 It can take away people's desire to be left alone, drain their time or attention, or interrupt what they're doing 😤 This threat is about intrusion into someone's life, not direct intrusion into their communications. The communications version is covered in Section 5.1.1 🔁

Unsolicited messages and denial-of-service attacks are the most common types of intrusion on the Internet 📨 Any attacker who can send unwanted traffic to the initiator can commit intrusion 🚫

5.1.4. Misattribution

Misattribution happens when data or communications related to one individual get attributed to someone else 🙀 It can lead to bad reputational, financial, or other consequences for the people who get misidentified 💔

In the protocol context, misattribution comes from using inadequate or insecure forms of identity or authentication, and it's sometimes tied to spoofing 🎭 For example, as [RFC6269] points out, abuse mitigation is often based on the source IP address. So connections from certain IP addresses may get blocked or temporarily blacklisted if abusive activity is traced back to those addresses 🚧 But if one IP address is shared by multiple individuals, everyone sharing it can take the penalty, even the people who had nothing to do with the abuse 😩 This threat can be reduced by using identity management mechanisms with proper forms of authentication (ideally with cryptographic properties), so actions can be attributed uniquely to an individual. That gives you a basis for accountability without generating false positives ✨

5.2. Privacy-Specific Threats 🌸

5.2.1. Correlation ✨

okay so correlation is when you take a bunch of little pieces of info about someone, or pieces that only mean something once they're put together, and smush them into one picture 🧩. It can seriously shock people at how much others know about them 😭. The one doing the correlating gets more power over the individual and gets better at judging them, which is a big threat to autonomy and reputation 💅.

Correlation and identification are basically besties 👯. Internet protocols can make correlation easier by letting someone's activities get tracked and combined over time 🦋. Any persistent or rarely swapped identifier at any layer of the stack can help with this. Like, if an initiator keeps using the same device ID, certificate, or email address across lots of interactions, recipients (and observers) could connect all of their communications over time 🕰️.

Take TLS session resumption [RFC5246] or TLS session resumption without server-side state [RFC5077] as an example 🎀. In RFC 5246 [RFC5246], the server gives the client a session_id in the ServerHello message and caches the master_secret for later. When the client opens a new connection, it reuses that session_id in its ClientHello message. The server agrees to resume by using the same session_id and the stored master_secret to generate the TLS Record Layer security association. RFC 5077 [RFC5077] borrows the session resumption idea, but instead of caching state, the server packs all of it into a ticket 🎫. Here's the tea: an attacker who can watch the exchanges between the TLS client and server can link the first handshake to later resumed sessions, because the session_id and the ticket get sent in the clear (which is the case in the initial handshake messages) 👀.

In theory, any observer or attacker that gets an initiator's communications can correlate. How much they can do depends on what data the entity gets from the initiator and what else they can access 🔍. Intermediaries often only need a little info for routing and/or security. In theory, protocol mechanisms could keep end-to-end information away from these entities, but in practice, end-to-end security is hard to deploy, adds messaging or computational overhead, and runs into business or legal requirements. All of that often slows down or blocks it 🙃. So intermediaries end up with more exposure to initiators' data than is strictly necessary from a technical point of view 😬.

5.2.2. Identification 🕵️

Identification is linking info to a particular individual so that their identity can be worked out, or so that someone can infer it 🔎. In some contexts, identifying people is totally legit. In others, it can stifle what people do or say by stopping them from being anonymous or pseudonymous 🙈. It also makes it easier for others (like governments) to explicitly control individuals and treat them differently from everyone else 👑.

Lots of protocols have features to show that some means was provided to validate that entities are who they claim to be. Usually that's cryptographic authentication 🔐. Protocol identifiers like the ones used in SIP or the Extensible Messaging and Presence Protocol (XMPP) can also directly identify individuals. Protocol identifiers can add to identification indirectly through correlation too. For example, a website that doesn't directly authenticate users might match its HTTP header logs with logs from another site that does, and suddenly users on the first site are identifiable 🧩.

As with correlation, any observer or attacker might be able to identify people, depending on what info about the initiator is available through the protocol mechanism or other channels 👀.

5.2.3. Secondary Use 🙅‍♀️

Secondary use is using collected info about someone without their consent, for a purpose different from the one it was collected for 📦. It can violate people's expectations or desires. Uncertainty about how info will be used later can make people hesitant to share it in the first place 😟. Secondary use covers any use of data, including disclosure.

One example is an authentication server using a network access server's Access-Requests to track an initiator's location 📍. Any observer or attacker could potentially make unwanted secondary uses of initiators' data. Protecting against secondary use is typically outside the scope of IETF protocols 🙃.

5.2.4. Disclosure 👀

Disclosure is revealing info about someone that affects how others judge them 🫣. It can violate people's expectations of confidentiality for the data they share. The threat of disclosure can stop people from doing certain things, out of fear of reputational harm or simply because they don't want to be watched 🙈.

Any observer or attacker that receives data about an initiator can disclose it. Sometimes it's unintentional, because system designers don't realize the info relates to individuals 😅. The most common way protocols limit disclosure is through access control mechanisms (discussed in Section 5.2.5) 🔒. Another example is the IETF geolocation privacy architecture [RFC6280], which supports a way for users to express a preference that their location info not be disclosed beyond the intended recipient 📍.

5.2.5. Exclusion 🚫

Exclusion is when individuals aren't allowed to know what data others have about them, or to take part in how it's handled and used 😣. It reduces accountability for entities that keep info about people, and it makes people feel vulnerable about controlling how info about them is collected and used 💔.

The most common way Internet protocols get involved in enforcing exclusion is through access control mechanisms. The IETF presence architecture is a great example of individuals being included in controlling info about them 🌸. Using a rules expression language (e.g., presence authorization rules [RFC5025]), presence clients can authorize the specific conditions under which their presence info can be shared 💖.

Exclusion is mainly a problem when the recipient doesn't involve the initiator in decisions about data collection, handling, and use. Eavesdroppers do exclusion by their very nature, since their collection and handling practices are covert 🥷.

---

6. Threat Mitigations 🛡️

Privacy is notoriously hard to measure and quantify 📏. How much a protocol, system, or architecture "protects" or "enhances" privacy depends on loads of factors about its design, use, and potential misuse. Still, there are certain widely recognized classes of mitigations against the threats in Section 5 💜. This section describes three categories: (1) data minimization, (2) user participation, and (3) security. They can loosely map to existing privacy principles like the Fair Information Practices, but they've been adapted to fit this document's target audience ✨.

6.1. Data Minimization 🍓

Data minimization is about collecting, using, disclosing, and storing only the minimal data needed to do a task 🧺. Less data exchanged means less data that can be misused or leaked 🔐.

It can be done in lots of ways, including by limiting collection, use, disclosure, retention, identifiability, sensitivity, and access to personal data. Limiting the data collected by protocol elements to only what's necessary (collection limitation) is the most straightforward way to cut the privacy risks of using the protocol 🙌. Sometimes protocol designers can recommend limits on use or retention, although protocols themselves usually can't control those properties 🤷.

But the most direct application of data minimization to protocol design is limiting identifiability 🎯. Reducing identifiability by using pseudonyms or no identifiers at all helps weaken the link between a person and their communications 🦋. Creating new or randomized identifiers periodically reduces the chance that multiple interactions or communications can be correlated back to the same person 🔀. The following sections explore different properties related to identifiability that protocol designers may want to achieve 👀.

Data minimization mitigates the following threats: surveillance, stored data compromise, correlation, identification, secondary use, and disclosure 💅.

6.1.1. Anonymity ✨

okay so anonymity is basically blending into a crowd 🫶 For one person to be anonymous, there has to be a group of people who all look like they have the same attribute(s) as them. To the attacker or the observer, every single one of those people has to look indistinguishable from the rest 👀 That whole group is called the anonymity set, and who's in it can change over time 🦋

The anonymity set depends on what the observer or attacker already knows, so anonymity is always relative to who's watching 💅 An initiator can only be anonymous within a set of potential initiators (its initiator anonymity set), and that set might itself be just a subset of everyone who could start a communication 🌸 Recipients get their own version: a recipient is anonymous only within its set of potential recipients (its recipient anonymity set) 💜 The two sets might be totally separate, partly overlapping, or literally the same one 🙈

Here's a fave example: RFC 3325 (P-Asserted-Identity (PAI)) [RFC3325] is an extension for the Session Initiation Protocol (SIP). It lets a person, like a Voice over IP (VoIP) caller, tell an intermediary they trust to stop it from filling in the SIP From header field with their authenticated and verified identity 🎀 So the recipient of the call, plus anyone else outside the caller's trust domain, only learns that the SIP message (usually a SIP INVITE) was sent with a header field of 'From: "Anonymous" <sip:anonymous@anonymous.invalid>'. They don't see the caller's address-of-record, which is usually thought of as the user's "public address" 🧚 When PAI is in use, the caller blends into the initiator anonymity set made up of everyone using that same intermediary. Iconic. 👑

Quick caveat though 🥹 This example ignores the fact that the recipient might still infer or obtain personal data from the other SIP payloads (for example, the SIP Via and Contact headers, and the Session Description Protocol (SDP)). So PAI only tackles one specific threat: the disclosure of identity (in the From header) to the recipient. That caveat keeps the analysis of this one extension simple, but you can't just assume it when you're analysing an entire architecture 🙅‍♀️

6.1.2. Pseudonymity 🦋

Okay, pseudonymity time 💖 In Internet protocols, almost every identifier can be a nickname or pseudonym, because there's usually no requirement to use personal names in the protocol. Still, in some scenarios it's fair to assume personal names will show up anyway (with vCard [RFC6350], for example) 🙈

Pseudonymity gets stronger when less personal data can be linked to the pseudonym, when the same pseudonym gets used less often and across fewer contexts, and when independently chosen pseudonyms get used more often for new actions. That last one makes them unlinkable from an observer's or attacker's point of view, which is so chic 🌈

For Internet protocols, these things matter a lot: whether the protocol lets pseudonyms change without a human having to do anything, the default length of a pseudonym's lifetime, who the pseudonyms get exposed to, how people can control that disclosure, how often pseudonyms can be changed, and what happens when they do get changed 💅

6.1.3. Identity Confidentiality 🔐

An initiator has identity confidentiality when no party other than the recipient can sufficiently identify them within the anonymity set. The size of that set directly affects identity confidentiality: the smaller the set, the easier it is to pick out the initiator 📉 Identity confidentiality is there to protect against eavesdroppers and intermediaries, not against the intended communication endpoints 👀

Example time 🎀 Think about network access authentication using the Extensible Authentication Protocol (EAP) [RFC3748]. EAP has an identity exchange where the Identity Response is mainly used for routing and for picking which EAP method to use. Since EAP Identity Requests and Identity Responses go over the wire in cleartext, eavesdroppers and intermediaries on the path between the EAP peer and the EAP server can snoop on the identity, which is encoded as a Network Access Identifier (NAI) as defined in RFC 4282 [RFC4282] 😭

To fix that, as RFC 4282 [RFC4282] explains, the username part of the NAI (but not the realm part) can be hidden from those eavesdroppers and intermediaries, using the cryptographic support that EAP methods offer 🔐 Identity confidentiality has actually become a recommended design criteria for EAP (see [RFC4017]) ✨ The EAP method for 3rd Generation Authentication and Key Agreement (EAP-AKA) [RFC4187], for example, protects the EAP peer's identity against passive adversaries by using temporal identities 🧚 And the EAP-Internet Key Exchange Protocol version 2 (EAP-IKEv2) method [RFC5106] is an example of an EAP method that protects the individual's identity against active attackers too 💪

6.1.4. Data Minimization within Identity Management 🍓

Modern systems rely more and more on multi-party transactions to authenticate people 🌐 A lot of these systems use an identity provider that does AAA functionality for relying parties offering protected resources. To make that work, an identity provider usually goes through verifying the individual's identity and issuing them credentials 🪪 When someone wants to use a service from a relying party, the relying party leans on the authentication assertions its identity provider hands over. In fancier setups, those assertions are traits showing what the individual is capable of and what roles they have 🧠 Authorization responsibility can also be shared between the identity provider and the relying party, so it doesn't have to live only with the identity provider 🫶

These systems can support several properties that minimize data collection in different ways 💜

• In certain use cases, relying parties don't need to know an individual's real name or date of birth. For example, this works when the individual's age is the only attribute that needs authenticating 🎂
• Relying parties that collude can be stopped from using an individual's credentials to track them. In other words, two different relying parties can be kept from figuring out that the same individual authenticated to both of them. This usually takes identity management protocol support, plus support from both the relying party and the identity provider 🔥
• The identity provider can be kept from knowing which relying parties an individual interacted with. That requires, at a minimum, avoiding direct communication between the identity provider and the relying party at the moment the initiator accesses a resource 🙈

6.2. User Participation 🫶

As Section 5.2.5 explains, data collection and use that happen "in secret", without the individual knowing, are likely to violate their expectation of privacy and can create incentives for misuse of data 😭 That's why privacy regimes usually include rules requiring that individuals get informed about data collection and use, and get involved in decisions about how their data is treated 📣 In an engineering context, supporting user participation usually means giving users ways to control the data shared about them. It can also mean giving users ways to signal how they expect their data to be used and shared 💅

Different protocol and architectural designs make user participation easier or harder to support. For example, the ability to show a dialog box for user interaction is easier in some designs than others. OAuth-based services may have more natural hooks for user input than AAA services do 🎀

User participation mitigates the following threats: surveillance, secondary use, disclosure, and exclusion. 🛡️✨

6.3. Security 🔒

Keeping data secure at rest and in transit is another big piece of privacy protection 💖 As described in Section 2 of [RFC3552], a number of security goals also help enhance privacy:

• Confidentiality: Keeping data secret from unintended listeners.
• Peer entity authentication: Making sure the endpoint of a communication is the one that's intended (which supports keeping things confidential).
• Unauthorized usage: Limiting data access to only the users who are authorized. (This goal also falls within data minimization.)
• Inappropriate usage: Limiting how authorized users can use data. (This goal also falls within data minimization.)

Here's the tea ☕ Even when these goals are achieved, the existence of things an attacker or observer might care about can still be detectable, even if they can't be read. That includes attributes, identifiers, identities, communications, actions (like sending or receiving a communication), or anything else of interest. So undetectability is another security goal to consider: an observer or attacker can't sufficiently tell whether an item of interest exists or not. It can be extremely difficult to pull off, but it's still worth aiming for 😭

Defending against traffic analysis, which reveals which protocols or applications are in use, can be especially hard 🕵️‍♀️ Just like with the anonymity of individuals, "protocol anonymity" needs multiple protocols or applications that look the same in terms of attributes like packet sizes, content, token locations, or inter-packet timing. If several protocols or applications are indistinguishable, an attacker or observer can't use traffic analysis to figure out which one is in use 🦋

How well you can defend against traffic analysis varies between protocols, and it can depend on implementation- or use-specific details and on which other protocols already exist and whether they share similar traffic characteristics 🌸 The defenses also change depending on what the protocol is designed to do. For example, randomizing packet sizes, timing, or token locations can reduce the threat of traffic analysis in some situations. In others, like real-time communications, holding some or all of those factors constant is the more appropriate defense 💅 For an example of how these trade-offs should be evaluated, check out "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" [RFC6562] 📚✨

By providing proper security protection, the following threats can be mitigated: surveillance, stored data compromise, misattribution, secondary use, disclosure, and intrusion. 🛡️💜

7. Guidelines ✨

okay so this section is basically a questionnaire for protocol designers 📝 It's meant to help you think through privacy, and it can be useful at any point in the design process, especially once you've built a high-level protocol model like the one described in [RFC4101] 🧠

Quick disclaimer, bestie: this section does NOT tell you which practices to use 🙅‍♀️ The IETF makes way too many different kinds of protocols for that to work. What it does do is help you carefully answer each question so you end up with a thorough analysis. That analysis can then be the basis for talking about whether your protocol actually protects against privacy threats 🔍 This is a thinking tool, not a template for how to write a privacy considerations section, so don't expect it to hand you one 💅

The framework has four sections. Three of them go through each of the mitigation classes from Section 6, and the last one is general 🌈 Security only gets a light treatment here because [RFC3552] already has a ton of solid guidance on it 🔐

7.1. Data Minimization 🎀

• a. Identifiers. What identifiers does the protocol use to tell apart the initiators of communications? Does it use identifiers that let different protocol interactions get correlated? Which identifiers could be left out, or made less identifying, while still meeting the protocol's goals? 🪪
• b. Data. What information does the protocol reveal about individuals, their devices, and/or how they use their devices (aside from the identifiers in (a))? How closely is that information tied to the identities of the individuals? How does the protocol combine personal data with the identifiers from (a)? 📊
• c. Observers. Which of the information from (a) and (b) is exposed to each other protocol entity (that is, recipients, intermediaries, and enablers)? Can protocol implementers choose to limit what gets shared with each entity? Are there operational controls that can limit what gets shared with each entity? 👀
• d. Fingerprinting. Honestly, in lots of cases the specific ordering and/or occurrences of information elements in a protocol let users, devices, or software using it get fingerprinted 🫣 So: is this protocol vulnerable to fingerprinting? If so, how? Can it be designed to reduce or eliminate that vulnerability? If not, why not? 🕵️‍♀️
• e. Persistence of identifiers. What assumptions does the protocol design make about how long the identifiers from (a) last? Does the protocol let implementers or users delete or replace identifiers? How often does the specification recommend deleting or replacing identifiers by default? Can the identifiers, along with other state information, be set to expire automatically? ⏳
• f. Correlation. Does the protocol allow identifiers to be correlated? Are there expected ways that information the protocol exposes will be combined or correlated with information obtained outside the protocol? How would that combining or correlating make it easier to fingerprint a user, device, or application? Are there expected combinations or correlations with outside data that will make people using the protocol more identifiable? 🧩
• g. Retention. Does the protocol, or how it's expected to be used, require that the information from (a) or (b) be kept by recipients, intermediaries, or enablers? If so, why? Is that retention expected to be persistent or temporary? 🗄️

7.2. User Participation 🫶

• a. User control. What controls or consent mechanisms does the protocol define or require before personal data or identifiers get shared or exposed through it? If the protocol doesn't specify any such mechanisms or controls, is control and consent expected to be handled outside of the protocol? 🙋‍♀️
• b. Control over sharing with individual recipients. Does the protocol give initiators ways to share different information with different recipients? If not, are there mechanisms outside the protocol that give initiators that control? 🎯
• c. Control over sharing with intermediaries. Does the protocol give initiators ways to limit which information gets shared with intermediaries? If not, are there mechanisms outside the protocol that give users that control? Is it expected that users will have relationships (contractual or otherwise) that govern how their information is used by those who operate these intermediaries? 🤝
• d. Preference expression. Does the protocol give initiators ways to express individuals' preferences to recipients or intermediaries about the collection, use, or disclosure of their personal data? 💌

7.3. Security 🔐

• a. Surveillance. How do the protocol's security considerations prevent surveillance, including eavesdropping and traffic analysis? Does the protocol leak information that can be seen through traffic analysis? For example, does it use a fixed token at fixed offsets, or packet sizes or timing that let observers figure out things about the traffic, like which protocol is in use or whether the traffic is part of a real-time flow? 👁️
• b. Stored data compromise. How do the protocol's security considerations prevent or mitigate stored data compromise? 🗝️
• c. Intrusion. How do the protocol's security considerations prevent or mitigate intrusion, including denial-of-service attacks and unsolicited communications more generally? 🚨
• d. Misattribution. How do the protocol's mechanisms for identifying and/or authenticating individuals prevent misattribution? 🎭

7.4. General 🌸

• a. Trade-offs. Does the protocol make trade-offs between privacy and usability, privacy and efficiency, privacy and implementability, or privacy and other design goals? Describe the trade-offs and the reasoning behind the chosen design. ⚖️
• b. Defaults. If the protocol can run in multiple modes or with multiple configurable options, does the default mode or option minimize the amount, identifiability, and persistence of the data and identifiers the protocol exposes? Does the default mode or option maximize opportunities for user participation? Does it provide the strictest security features of all the modes/options? If the answer to any of these questions is no, explain why less protective defaults were chosen. 🎛️

8. Example 🦋

This section walks through the threat analysis and threat mitigations recommended by this document, using a particularly difficult application protocol: presence. It's a great way to see these principles applied to an architecture that's exposed to a lot of the threats described above 😭 Just know this text is NOT meant to be a sample privacy considerations section for an IETF specification. It's more of an example of the thinking that should go into protocol design when privacy is treated as a first principle 🧠💖

A presence service, as defined in the abstract in [RFC2778], lets users of a communications service keep an eye on one another's availability and disposition so they can decide whether to communicate 👀 Presence info is super dynamic. It usually tells you whether someone is online or offline, busy or idle, away from their devices or nearby, and things like that 📱 Because of that, it has real privacy implications, and from the very beginning the IETF approached this work with the goal of giving users controls over how their presence info gets shared 🙌 The Common Profile for Presence (CPP) [RFC3859] defines a set of logical operations for delivering presence information. That abstract model works across multiple presence systems 🌐 The SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence system [RFC3856] uses CPP as its baseline architecture, and the presence operations in the Extensible Messaging and Presence Protocol (XMPP) have also been mapped to CPP [RFC3922] 🧩

So the fundamental architecture in RFC 2778 and RFC 3859 is mediated. Clients (called presentities in RFC 2778 terms) publish their presence information to presence servers, and those servers pass it along to authorized watchers 📮 Presence servers hang on to presence information for a while, until it changes or expires, so it can be revealed to authorized watchers when they ask 🗂️ This setup mirrors deployment models that existed before the standards 🏗️ Adding an explicit authorization mechanism to the presence architecture has been a huge success, since it gets end users involved in deciding what to share before anything gets shared 🎉 Nearly every presence system out there today has one, usually a reciprocal authorization system where two users who agree to be "buddies" consent to sharing their presence info with each other 🫂 Buddylists are managed by servers but controlled by end users. Users can also explicitly block each other through a similar interface, and some deployments benefit from "polite blocking" of various kinds 🙅‍♀️

But from a privacy design angle, the classic presence architecture is basically a worst-case scenario 😩 Look at data minimization: presentities hand their sensitive info over to presence services. The services only share it with watchers the user has authorized, but no technical mechanism stops those watchers from passing presence along to even more third parties 💸 Any of these entities could conceivably log or keep presence info forever 🥲 You also can't fix this by making the user anonymous, because the whole point of the system is to help users who know each other communicate 💬 The identifiers users rely on are long-lived and often contain personal information, including personal names and the domains of service providers 🙈 Users do get to take part in building buddylists and blacklists, but they have very little way to hold anyone accountable 😤 Basically, the user tosses their presence info over the wall to a presence server, which then distributes it to watchers. Users typically can't verify that presence only goes to authorized watchers, especially since the server is the one that authenticates watchers, not the end user 🫠 On top of that, the connections between the server and every publisher and consumer of presence data are a juicy target for eavesdroppers, so they really need strong confidentiality mechanisms 🔓 And even then, the end user has no way to check what mechanisms are in place between the presence server and a watcher 💀

The thing is, presence info isn't only about whether you're free to chat 👀 Capabilities can reveal what kind of device someone's using, and since multiple devices can publish the same user's presence, attackers could correlate a person's devices. Scary stuff 😭 An important extension to presence was then built for location sharing. The effort to standardize protocols for systems sharing geolocation kicked off in the GEOPRIV working group 🌍 While they were figuring out the initial requirements and privacy threat analysis for chartering the group, it became super clear that the system needed an underlying communication mechanism that supports user consent to share location. The resemblance to the presence framework was spotted pretty quickly, and that design decision got written down in [RFC4079]. So location info now mingles with everything else in the system and gets passed along to intermediaries and authorized watchers 💫

Privacy concerns about presence mostly come from the built-in mediation of the presence architecture 🕸️ The need for a presence server comes from two main design requirements. First, the server can respond with an "offline" indication when a user isn't online. Second, the server can compose presence information published by different devices under the user's control. Also, to make URIs work as identifiers for entities, some service has to operate a host with the domain name in a presence URI, and realistically no commercial presence architecture would make end users own and run their own domain names 🙃 A lot of end users are also behind NATs or firewalls and basically can't receive direct connections from the Internet. The persistent bidirectional channel these clients open and maintain with a presence server is essential to how the protocol works 🔁

So first we have to ask: is the trade-off of mediation for presence worth it? Does a server really need to sit in the middle of every publication of presence information? You might think end-to-end encryption of presence info could fix a lot of this 🔐 A presentity could encrypt the presence information with a watcher's public key, and only then send it through the server. The IETF defined an object format for presence information called the Presence Information Data Format (PIDF). For conveying location information, it was extended to the PIDF Location Object (PIDF-LO). These XML objects were designed to accommodate an encrypted wrapper 🎀 Encrypting this data would also stop stored cleartext presence information from being seized by an attacker who manages to compromise a presence server. Okay, but this idea quickly runs into usability problems 😩 Discovering watchers' public keys is the first difficulty, and very few Internet protocols have solved that successfully. The solution would also require the presentity to publish one encrypted copy of its presence information per authorized watcher to the presence service, whether or not a watcher is actively seeking presence information. For a presentity with lots of watchers, that could place an unacceptable burden on the presence server, especially given how dynamic presence information is. And finally, it stops the server from composing presence information reported by multiple devices under the same user's control. On the whole, these difficulties make object encryption of presence information a pretty doubtful prospect 💀

Some protocols that support presence information, like SIP, can run intermediaries in a redirecting mode instead of a publishing or proxying mode 🧚 Rather than sending presence information through the server, these protocols can just redirect watchers to the presentity. Then presence information could pass directly and securely from the presentity to the watcher. Worth noting, though, that this would disclose the presentity's IP address to the watcher, which comes with its own set of risks 👀 In that setup, the presentity can decide exactly what information it wants to share with a given watcher. It can authenticate the watcher with whatever strength of credential it chooses, and with end-to-end encryption it can reduce the likelihood of eavesdropping 🔒 In a redirection architecture, a presence server could still provide the necessary "offline" indication without having to observe and forward all information itself. This mechanism is more promising than encryption, but it also has significant difficulties 😤 It doesn't provide for composition of presence information from multiple devices either. In fact, it forces the watcher to do that composition itself. The biggest single obstacle here is the difficulty of creating end-to-end connections between the presentity's device(s) and a watcher, since some or all of those endpoints may be behind NATs or firewalls that prevent peer-to-peer connections. There are potential solutions, like Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN), but they add complexity to the overall system 🛠️

Bottom line: mediation is a seriously hard feature of the presence architecture to remove 🚧 It's hard to minimize the data shared with intermediaries, especially because of the requirement for composition. So control over sharing with intermediaries has to come from some other explicit component of the architecture.

So the presence work in the IETF focused on improving user participation in the activities of the presence server 💅 This work started in the GEOPRIV working group, with controls on location privacy, because location of users is seen as having especially sensitive properties 📍 To meet the privacy requirements defined in [RFC2779], a set of usage indications was added to the PIDF-LO. Things like whether retransmission is allowed, or when the retention period expires, always travel with the location information itself 🎁 These privacy preferences apply not just to the intermediaries that store and forward presence information, but also to the watchers who consume it.

This approach really follows the spirit of Creative Commons [CC], using a limited number of conditions, like 'Share Alike' [CC-SA] 🌈 Unlike Creative Commons, though, the GEOPRIV working group didn't start any work on legal language or graphical icons, since that would fall outside the scope of the IETF 🙅‍♀️ Specifically, the GEOPRIV rules state a preference on the retention and retransmission of location information. GEOPRIV can't force any entity receiving a PIDF-LO object to abide by those preferences. But if users can't express their preferences at all, then we can guarantee those preferences won't be honored 😭 The GEOPRIV rules can, however, provide a means to establish accountability ⚖️

The retention and retransmission elements were envisioned as the most essential examples of preference expression in sharing presence 💜 The PIDF object was designed for extensibility, and the rulesets created for the PIDF-LO can also be extended to express new user preferences. Not all user preference information should be bound into a particular PIDF object, though. Many forms of access control policy that the presence architecture assumes need to be provisioned in the presence server through some interface with the user ⚙️ That requirement eventually led to standardizing a general access control policy language called the common policy framework, defined in [RFC4745]. This language lets you express ways to control the distribution of information as simple conditions, actions, and transformation rules, written in an XML format 🧾 Common Policy is an abstract format that needs to be instantiated. Two examples are the presence authorization rules [RFC5025] and the Geolocation Policy [RFC6772]. The former adds extra expressiveness for presence-based systems, while the latter defines syntax and semantics for location-based conditions and transformations 🗺️

Ultimately, the privacy work on presence is a compromise between privacy principles and the needs of the architecture and marketplace 🤷‍♀️ It wasn't feasible to remove intermediaries from the architecture entirely or stop them from accessing presence information. But the IETF did provide a way for users to express their preferences and set up their controls at the presence service 🫶 We haven't had great success in the implementation space with privacy mechanisms so far. Still, by documenting and acknowledging the limitations of these mechanisms, the designers gave implementers and end users an informed perspective on the privacy properties of the IETF's presence protocols 🧠✨

---

9. Security Considerations 🔐

This doc lays out privacy aspects that protocol designers should consider on top of regular security analysis. Security AND privacy, bestie 💜

10. Acknowledgements 🫶

Huge thanks to Christine Runnegar for her extensive, super helpful review comments 💖

We'd also love to thank Scott Brim, Kasey Chappelle, Marc Linsner, Bryan McLaughlin, Nick Mathewson, Eric Rescorla, Scott Bradner, Nat Sakimura, Bjoern Hoehrmann, David Singer, Dean Willis, Lucy Lynch, Trent Adams, Mark Lizar, Martin Thomson, Josh Howlett, Mischa Tuffield, S. Moonesamy, Zhou Sujing, Claudia Diaz, Leif Johansson, Jeff Hodges, Stephen Farrell, Steven Johnston, Cullen Jennings, Ted Hardie, Dave Thaler, Klaas Wierenga, Adrian Farrel, Stephane Bortzmeyer, Dave Crocker, and Hector Santos for their useful feedback on this document 🌸

Finally, we want to thank the participants for the feedback they gave during the December 2010 Internet Privacy workshop, co-organized by MIT, ISOC, W3C, and the IAB 🎉

Although John Morris is currently employed by the U.S. Government, he participated in the development of this document in his personal capacity. The views expressed in the document may not reflect those of his employer 🙈

11. IAB Members at the Time of Approval 👑

• Bernard Aboba
• Jari Arkko
• Marc Blanchet
• Ross Callon
• Alissa Cooper
• Spencer Dawkins
• Joel Halpern
• Russ Housley
• Eliot Lear
• Xing Li
• Andrew Sullivan
• Dave Thaler
• Hannes Tschofenig

12. Informative References ✨

okay bestie, this is the reading list 📚🫶 the doc points at all of these for extra context. none of them are required reading, but they're the receipts.

• [CC-SA] Creative Commons, "Share Alike", 2012, http://wiki.creativecommons.org/Share_Alike.
• [CC] Creative Commons, "Creative Commons", 2012, http://creativecommons.org/.
• [CoE] Council of Europe, "Recommendation CM/Rec(2010)13 of the Committee of Ministers to member states on the protection of individuals with regard to automatic processing of personal data in the context of profiling", November 2010, https://wcd.coe.int/ViewDoc.jsp?Ref=CM/Rec%282010%2913.
• [EFF] Electronic Frontier Foundation, "Panopticlick", 2013, http://panopticlick.eff.org.
• [FIPs] Gellman, B., "Fair Information Practices: A Basic History", 2012, http://bobgellman.com/rg-docs/rg-FIPShistory.pdf.
• [OECD] Organisation for Economic Co-operation and Development, "OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data", (adopted 1980), September 2010, http://www.oecd.org/.
• [PbD] Office of the Information and Privacy Commissioner, Ontario, Canada, "Privacy by Design", 2013, http://privacybydesign.ca/.
• [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
• [RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
• [RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
• [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
• [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
• [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
• [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
• [RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
• [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
• [RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, October 2004.
• [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
• [RFC4079] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005.
• [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
• [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
• [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
• [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
• [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
• [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
• [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.
• [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
• [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.
• [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
• [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
• [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
• [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
• [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011.
• [RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, March 2012.
• [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, September 2012.
• [RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.
• [Solove] Solove, D., "Understanding Privacy", March 2010.
• [Tor] The Tor Project, Inc., "Tor", 2013, https://www.torproject.org/.
• [Westin] Kumaraguru, P. and L. Cranor, "Privacy Indexes: A Survey of Westin's Studies", December 2005, http://reports-archive.adm.cs.cmu.edu/anon/isri2005/CMU-ISRI-05-138.pdf.

---

Authors' Addresses 🎀

the squad behind this doc, with their contact info 💌

Alissa Cooper
CDT
1634 Eye St. NW, Suite 1100
Washington, DC  20006
US

Phone: +1-202-637-9800
EMail: acooper@cdt.org
URI:   http://www.cdt.org/


Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo  02600
Finland

Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI:   http://www.tschofenig.priv.at


Bernard Aboba
Skype

EMail: bernard_aboba@hotmail.com


Jon Peterson
NeuStar, Inc.
1800 Sutter St. Suite 570
Concord, CA  94520
US

EMail: jon.peterson@neustar.biz


John B. Morris, Jr.

EMail: ietf@jmorris.org


Marit Hansen
ULD

EMail: marit.hansen@datenschutzzentrum.de


Rhys Smith
Janet

EMail: rhys.smith@ja.net