Privacy Considerations for Internet Protocols

All IETF specifications are required by to contain a security considerations section. provides detailed guidance to protocol designers about both how to consider security as part of protocol design and how to inform readers of IETF documents about security issues. This document intends to provide a similar set of guidance for considering privacy in protocol design. Whether any individual document will require a specific privacy considerations section will depend on the document's content. The guidance provided here can and should be used to assess the privacy considerations of protocol and architectural specifications regardless of whether those considerations are documented in a stand-alone section. Privacy is a complicated concept with a rich history that spans many disciplines. Many sets of privacy principles and privacy design frameworks have been developed in different forums over the years. These include the Fair Information Practices (FIPs) , a baseline set of privacy protections pertaining to the collection and use of data about individuals, and the Privacy by Design framework , which provides high-level privacy guidance for systems design. The guidance provided in this document is inspired by this prior work, but it aims to be more concrete, pointing protocol designers to specific engineering choices that can impact the privacy of the individuals that make use of Internet protocols. Privacy as a legal concept is understood differently in different jurisdictions. The guidance provided in this document is generic and can be used to inform the design of any protocol to be used anywhere in the world, without reference to specific legal frameworks. The document is organized as follows: describes the extent to which the guidance offered in this document is applicable within the IETF, discusses a generic threat model to motivate the need for privacy considerations, provides the guidelines for analyzing and documenting privacy considerations within IETF specifications, and examines the privacy characteristics of an IETF protocol to demonstrate the use of the guidance framework.

The core function of IETF activity is building protocols. Internet protocols are often built flexibly, making them useful in a variety of architectures, contexts, and deployment scenarios without requiring significant interdependency between disparately designed components. Although some protocols assume particular architectures at design time, it is not uncommon for architectural frameworks to develop later, after implementations exist and have been deployed in combination with other protocols or components to form complete systems. As a consequence, the extent to which protocol designers can foresee all of the privacy implications of a particular protocol at design time is significantly limited. An individual protocol may be relatively benign on its own, but when deployed within a larger system or used in a way not envisioned at design time, its use may create new privacy risks. The guidelines in ask protocol designers to consider how their protocols are expected to interact with systems and information that exist outside the protocol bounds, but not to imagine every possible deployment scenario. Furthermore, in many cases the privacy properties of a system are dependent upon API specifics, internal application functionality, database structure, local policy, and other details that are specific to particular instantiations and generally outside the scope of the work conducted in the IETF. The guidance provided here only reaches as far as protocol design can go. As an example, consider HTTP , which was designed to allow the exchange of arbitrary data. A complete analysis of the privacy considerations for uses of HTTP might include what type of data is exchanged, how this data is stored, and how it is processed. Hence the analysis for an individual's static personal web page would be different than the use of HTTP for exchanging health records. A protocol designer working on HTTP extensions (such as WebDAV ) is not expected to describe the privacy risks derived from all possible usage scenarios, but rather the privacy properties specific to the extensions and any particular uses of the extensions that are expected and foreseen at design time.

To consider privacy in protocol design it is helpful to consider the overall communication architecture and different actors' roles within it. This analysis is similar to a threat analysis found in the security considerations sections of IETF documents. presents a communication model found in many of today's protocols where a sender wants to establish communication with some recipient and thereby uses some form of intermediary. In some cases this intermediary stays in the communication path for the entire duration of the communication and sometimes it is only used for communication establishment, for either inbound or outbound communication. In rare cases there may be a series of intermediaries that are traversed.

| Recipient | / | | ,' +-----------+ +--------+ )--------------( ,' +-----------+ | | | | - | | | Sender |<------>|Intermediary |<------>| Recipient | | | | |`. | | +--------+ )--------------( \ +-----------+ ˆ `. +-----------+ : \ | | : `>| Recipient | .....................................>| | +-----------+ Legend: <....> End-to-End Communication <----> Hop-by-Hop Communication ]]> This model is vulnerable to three types of adversaries: describes the act of 'eavesdropping' as "Passive wiretapping done secretly, i.e., without the knowledge of the originator or the intended recipients of the communication." Eavesdropping is often considered by IETF protocols in the context of a security analysis. Confidentiality protection is often employed to defend against attacks based on eavesdropping, and demands that confidentiality be incorporated as a security consideration. While IETF protocols offer guidance on how to secure communication against eavesdroppers, deployments sometimes choose not to enable such security. Many protocols developed today show a more complex communication pattern than simple client-server or peer-to-peer communication, as motivated in . Store-and-forward protocols are examples where entities participate in the message delivery even though they are not the final recipients. Often, these intermediaries only require a small amount of information for message routing and/or security. In theory, protocol mechanisms could ensure that end-to-end information is not made accessible to these entities, but in practice the difficulty of deploying end-to-end security procedures, additional messaging or computational overhead, and other business or legal requirements often slow or prevent the deployment of end-to-end security mechanisms, giving intermediaries greater exposure to communication patterns and payloads than is strictly necessary. It may not seem intuitive to treat the recipient as an adversary since the entire purpose of the communication interaction is to provide information to the recipient. However, the recipient can act as the sender's privacy foe in two respects. First, the sender may be unintentionally communicating with the recipient, whether because of a lack of access control or because the sender was not properly informed about what data it would be communicating to the recipient. Second, the recipient may choose to use the sender's data in ways that contravene the sender's wishes, whether by putting it to some purpose that the sender opposes, sharing it with other entities, or storing it after the communication session has ended. Whether the recipient becomes an adversary depends on whether it makes use of mechanisms that reduce these risks, including informing the sender about how his or her data will be used, offering choices, and obtaining authorization to receive and use the sender's data.

This section provides guidance for document authors in the form of a questionnaire about a protocol being designed. The questionnaire may be useful at any point in the design process, particularly after document authors have developed a high-level protocol model as described in . Note that the guidance does not recommend specific practices. The range of protocols developed in the IETF is too broad to make recommendations about particular uses of data or how privacy might be balanced against other design goals. However, by carefully considering the answers to each question, document authors should be able to produce a comprehensive analysis that can serve as the basis for discussion of whether the protocol adequately protects against privacy threats. The framework is divided into four sections that address different aspects of privacy -- data minimization, user participation, security, and accountability -- plus a general section. Security is not elaborated since substantial guidance already exists in . Privacy-specific terminology used in the framework is [will be] defined in .

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 rationale for the design chosen.

a. Identifiers. What identifiers does the protocol use for distinguishing endpoints? Does the protocol use identifiers that allow different protocol interactions to be correlated? b. User information. What information does the protocol expose about end users and/or their devices (other than the identifiers discussed in (a))? How identifiable is this information? How does the protocol combine user information with the identifiers discussed in (a)? c. Fingerprinting. In many cases the specific ordering and/or occurrences of information elements in a protocol allow devices using the protocol to be uniquely fingerprinted. Is this protocol vulnerable to fingerprinting? If so, how? d. Persistence of identifiers. What assumptions are made in the protocol design about the lifetime of the identifiers discussed in (a)? Does the protocol allow implementers or users to delete or recycle identifiers? How often does the specification recommend to delete or recycle identifiers by default? e. Leakage. Are there expected ways that information exposed by the protocol will be combined or correlated with information obtained outside the protocol? How will such combination or correlation facilitate user or device fingerprinting? Are there expected combinations or correlations with outside data that will make the information exposed by the protocol more identifiable? f. Recipients. In the protocol design, what information discussed in (a) and (b) is exposed to other endpoints (i.e., recipients)? Are there ways for protocol implementers to choose to limit the information shared with other endpoints? g. Intermediaries. In the protocol design, what information discussed in (a) and (b) is exposed to intermediaries? Are there ways for protocol implementers to choose to limit the information shared with intermediaries? h. Retention. Do the protocol or its anticipated uses require that the information discussed in (a) or (b) be retained by recipients or intermediaries? Is the retention expected to be persistent or temporary?

a. Control over initial sharing. What user controls or consent mechanisms does the protocol define or require before user information or identifiers are shared or exposed via the protocol? If no such mechanisms are specified, is it expected that control and consent will be handled outside of the protocol? b. Control over sharing with recipients. Does the protocol provide ways for users to limit which information is shared with recipients? If not, are there mechanisms that exist outside of the protocol to provide users with such control? c. Control over sharing with intermediaries. Does the protocol provide ways for users to limit which information is shared with intermediaries? If not, are there mechanisms that exist outside of the protocol to provide users with such control? Is it expected that users will have relationships (contractual or otherwise) with intermediaries that govern the use of the information? d. Preference expression. Does the protocol provide ways for users to express their preferences to recipients or intermediaries with regard to the use or disclosure of their information?

a. Communication security. Do the protocol's security considerations account for communication security, per RFC 3552?

a. User verification. If the protocol provides for user preference expression, does it also define or require mechanisms that allow users to verify that their preferences are being honored? If not, are there mechanisms that exist outside of the protocol that allow for user verification?

[To be provided in a future version.]

This document describes privacy aspects that protocol designers should consider in addition to regular security analysis.

This document does not require actions by IANA.

We would like to thank the participants for the feedback they provided during the December 2010 Internet Privacy workshop co-organized by MIT, ISOC, W3C and the IAB.