Ericsson

Valitie 1B Kauniainen Finland jari.arkko@piuha.net

Internet-Draft Data minimization is an important privacy technique, as it can reduce the amount information exposed about a user. This document emphasizes the need for data minimization among primary protocol participants, such as between clients and servers. Avoiding data leakage to outside parties is of course very important as well, but both need to be considered in minimization. This is because is necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. It is important to consider the role of a participant and limit any data provided to it according to that role.

Privacy been at the center of many activities in the IETF. Privacy and its impact on protocol development activities at IETF is discussed in , covering a number of topics, from understanding privacy threats to threat mitigation, including data minimization. This document emphasizes the need for data minimization among primary protocol participants, such as between clients and servers. Avoiding data leakage to outside parties such as observers or attackers is of course very important as well, but minimization needs to consider both. As RFC 6973 states:

This document offers some further discussion, recommendations, and clarifications for this. This document suggests that limiting the sharing of data to the protocol participants is a key technique in limiting the data collection mentioned above. It is important that minimization happens prior to disclosing information to another party, rather than relying on the good will of the other party to avoid storing the information. This is because is necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. It is important to consider the role of a participant and limit any data provided to it according to that role. Even closed, managed networks may have compromised nodes, justifying careful consideration of what information is provided to different nodes in the network. And in all networks, increased use of communication security means adversaries may resort to new avenues of attack. New adversaries and risks have also arisen, e.g., due to increasing amount of information stored in various Internet services. And in situations where interests do not align across the protocol participants, limiting data collection by a protocol participant itself - who is interested in data collection - may not be sufficient. Careful control of information is also useful for technology evolution. For instance, allowing a party to unnecessarily collect or receive information may lead to a similar effect as described in for protocols: regardless of initial expectations, over time unnecessary information will get used, leading to, for instance, ossification. Systems end up depend on having access to exactly the same information as they had access to previously. This makes it hard to change what information is provided or how it is provided.

The Principle of Least Privilege is applicable:

In this context, it is recommended that the protocol participants minimize the information they share. I.e., they should provide only the information to each other that is necessary for the function that is expected to be performed by the other party.

Information sharing may relate to different types of protocol exchanges, e.g., interaction of an endpoint with outsiders, the network, or intermediaries. Other documents address aspects related to networks (, , ). Thomson discusses the role intermediaries. Communications security largely addresses observers and outsider adversaries, see for instance , , , , . And discusses associated traffic analysis threats. The focus in this document is on the primary protocol participants, such as a server in a client-server architecture or a service enables some kind of interaction among groups of users. As with communication security, we try to avoid providing too much information as it may be misused or leak through attacks. The same principle applies not just to routers and potential attackers on path, but also many other services in the Internet, including servers that provide some function.

The use of identifiers has been extensively discussed in , Note that indirectly inferred information can also end up being shared, such as message arrival times or patterns in the traffic flow (). Information may also be obtained from fingerprinting the protocol participants, in an effort to identify unique endpoints or users. Information may also be combined from multiple sources, e.g., websites and social media systems collaborating to identify visiting users .

The most straightforward approach is of course to avoid sending a particular piece of information at all. Or the information needs to be encrypted to very specific recipients, even if the encrypted message is shared with a broader set of protocol participants. For instance, a client can encrypt a message only to the actual final recipient, even if the server holds the message before it is delivered.

This document recommends that information should not be disclosed, stored, or routed in cleartext through services that do not need to have that information for the function they perform. Where the above methods are not possible due to the information being necessary for a function that the user wishes to be performed, there are still methods to set limits on the information sharing. Kühlewind et al discuss the concept of Privacy Partititioning . This may involve designs where no single party has all information such as with Oblivious DNS , or HTTP , cryptographic designs where a service such as with the recent IETF PPM effort , and so on.

Of course, participants may provide more information to each other after careful consideration, e.g., information provided in exchange of some benefit, or to parties that are trusted by the participant.

The general topic of ensuring that protocol mechanisms stays evolvable and workable is covered in . But the associated methods for reducing fingerprinting possibilities probably deserve further study . discusses one aspect of this.

Cooper et al. discuss the general concept of privacy, including data minimization. Among other things, it provides the general statement quoted in . It also provides guidelines to authors of specifications, a number of questions that protocol designers can use to further analyze the impact of their design. For data minimization the questions relate to identifiers, data, observers, and fingerprinting. This includes, for instance, asking what information is exposed to which protocol entities, and if there are ways to limit such exposure:

This is very much in line with this document, although today it would be desirable to have recommendation as well as questions. For instance, recommending against sharing information with a participant if it is not necessary for the expected role of that participant. And, as discussed earlier, it is important to distinguish between the choices of a sender not sharing information and a receiver choosing to not collect information. Trusting an entity to not collect is not sufficient. There has also been a number of documents that address data minimization for specific situations, such as one DNS Query Name Minimization , general DNS privacy advice including data minimization , advice for DHCP clients for minimizing information in requests they send to DHCP servers (along with general privacy considerations of DHCP ). These are on the topic of limiting information sent by one primary protocol particiant (client) to another (server). Hardie and Arkko et al. discuss path signals, i.e., messages to or from on-path elements to endpoints. In the past, path signals were often implicit, e.g., network nodes interpreting in a particular way transport protocol headers originally intended for end-to-end consumption. Implicit signals should be avoided and that explicit signals be used instead. Kühlewind, Pauly, and Wood discuss the concept of privacy partitioning: how information can be split and carefully shared in ways where no individual party beyond the client requesting a service has full picture of who is asking and what is being asked. Thomson discusses the role intermediaries in the Internet architecture, at different layers of the stack. For instance, a router is an intermediary, some parts of DNS infrastructure can be intermediaries, messaging gateways are intermediaries. Thomson discusses when intermediaries are or are not an appropriate tool and presents a number of principles relating to the use of intermediaries. Trammel and Kühlewind discuss the concept of a “wire image” of a protocol, and how network elements may start to rely on information in the image, even if it was not originally intended for them. The issues are largely the same even for participants.

The author would like to thank the participants of various IAB workshops and programs, and IETF discussion list contributors for interesting discussions in this area. The author would in particular like to acknowledge the significant contributions of Martin Thomson, Nick Doty, Alissa Cooper, Stephen Farrell, Mark McFadden, John Mattsson, Chris Wood, Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton, Mirja Kühlewind, Tommy Pauly, Jaime Jiménez and Christian Huitema. This work has been influenced by , , , ,

This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users. It is intended to be an analysis of the present situation and does not propose any solutions. Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information. This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image. This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. The Design Expectations vs. Deployment Reality in Protocol Development Workshop was convened by the Internet Architecture Board (IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. Trinity College Dublin We argue that an expanded threat model is needed for Internet protocol development as protocol endpoints can no longer be considered to be generally trustworthy for any general definition of "trustworthy." Ericsson Trinity College Dublin Communications security has been at the center of many security improvements in the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This memo suggests that the existing RFC 3552 threat model, while important and still valid, is no longer alone sufficient to cater for the pressing security and privacy issues seen on the Internet today. For instance, it is often also necessary to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users. While such protection is difficult, there are some measures that can be taken and we argue that investigation of these issues is warranted. It is particularly important to ensure that as we continue to develop Internet technology, non-communications security related threats, and privacy issues, are properly understood. Last Press Label RFC 3552 introduces a threat model that does not include endpoint security. In the fifteen years since RFC 3552 security issues and cyber attacks have increased, especially on the endpoint. This document proposes a new approach to Internet cyber security protocol development that focuses on the user of the Internet, namely those who use the endpoint and are the most vulnerable to attacks. Ericsson Cisco Apple Ericsson This document discusses principles for designing mechanisms that use or provide path signals, and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements, and points out that visible information will be used whether it is intended as a signal or not. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path. Ericsson Research Apple Cloudflare This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve the privacy by separating user identity from user data. This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models. Mozilla This document proposes a set of principles for designing protocols with rules for intermediaries. The goal of these principles is to limit the ways in which intermediaries can produce undesirable effects and to protect the useful functions that intermediaries legitimately provide. Mozilla Apple The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. University of Waterloo HK University of Science and Technology Apple, Inc. The IETF is well on its way to protecting connection metadata with protocols such as DNS-over-TLS and DNS-over-HTTPS, and work-in- progress towards encrypting the TLS SNI. However, more work is needed to protect traffic metadata, especially in the context of web traffic. In this document, we survey Website Fingerprinting attacks, which are a class of attacks that use machine learning techniques to attack web privacy, and highlight metadata leaks used by said attacks. We also survey proposed mitigations for such leakage and discuss their applicability to IETF protocols such as TLS, QUIC, and HTTP. We endeavor to show that Website Fingerprinting attacks are a serious problem that affect all Internet users, and we pose open problems and directions for future research in this area. Mozilla Cloudflare This document describes a system for forwarding encrypted HTTP messages. This allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. Apple Inc. Fastly Apple Inc. Cloudflare Cloudflare This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party distributed aggregation protocol (DAP) for privacy preserving measurement (PPM) which can be used to collect aggregate data without revealing any individual user's data. Princeton University Princeton University Princeton University Salesforce Recognizing the privacy vulnerabilities associated with DNS queries, a number of standards have been developed and services deployed that that encrypt a user's DNS queries to the recursive resolver and thus obscure them from some network observers and from the user's Internet service provider. However, these systems merely transfer trust to a third party. We argue that no single party should be able to associate DNS queries with a client IP address that issues those queries. To this end, this document specifies Oblivious DNS (ODNS), which introduces an additional layer of obfuscation between clients and their queries. To accomplish this, ODNS uses its own authoritative namespace; the authoritative servers for the ODNS namespace act as recursive resolvers for the DNS queries that they receive, but they never see the IP addresses for the clients that initiated these queries. The ODNS experimental protocol is compatible with existing DNS infrastructure.