Network Working Group J. Arkko Internet-Draft Ericsson Intended status: Informational July 12, 2022 Expires: January 13, 2023 Data minimization draft-arkko-iab-data-minimization-principle-02 Abstract 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 document recommends that this is no longer alone sufficient to cater for the 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. It is important to consider the role of data passed to various parties - including the primary protocol participants - and balance the information given to them considering their roles and possible compromise of the information. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 13, 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Arkko Expires January 13, 2023 [Page 1] Internet-Draft Data Minimization in Internet Architecture July 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Dealing with compromise . . . . . . . . . . . . . . . . . 4 3.2. Related work . . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. Informative References . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Communications security has been at the center of many security improvements on the Internet. The goal has been to ensure that communications are protected against outside observers and attackers. This has been exemplified in many aspects of IETF efforts, in the threat models [RFC3552], concerns about surveillance [RFC7258], IAB statements [Confidentiality], and the introduction of encryption in many protocols [RFC9000], [RFC7858], [RFC8484]. This has been very successful. Advances in protecting most of our communications with strong cryptographic has resulted in much improved security. Work on these advances continues to be a key part of IETF's security effort. This document recommends that further action is needed, however. For instance, the possibility that endpoints are compromised, malicious, or have interests that do not align with the interests of users. Given the advances in communication seceurity, adversaries have had to increase their pressure against new avenues of attack. New adversaries and risks have also arisen, e.g., due to increasing amount of information stored in various Internet services. While such protection is difficult, there are some measures that can be taken. This document focuses on the specific question of data passed to various parties - including the primary protocol participants. What information is given to any other party should depend on the role of that party. And the possibility of a Arkko Expires January 13, 2023 [Page 2] Internet-Draft Data Minimization in Internet Architecture July 2022 compromised entity sharing the information beyond the users' expectations should be kept in mind. 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 [RFC8546] 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. 2. Recommendations The Principle of Least Privilege [PoLP] is applicable: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." 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. This recommendation is of course very similar to the current approach to communications security. 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. Of course, participants may provide more information to each after careful consideration, e.g., information provided in exchange of some benefit, or to parties that are trusted by the participant. 3. Discussion Information sharing may relate to different types of protocol exchanges: o The interaction of an endpoint with the network, e.g., information they provide in any network attachment process or the wire images of the packets sent via the network. o The interaction of an endpoint with intermediaries such as group messaging servers or NAT traversal relays. Arkko Expires January 13, 2023 [Page 3] Internet-Draft Data Minimization in Internet Architecture July 2022 o The interaction of an endpoint with a service, such as a website, social networking function, or a telemetry collection point. o End-to-end interactions between users, represented by applications running on their computers. Information sharing need not be explicitly carried information, e.g., a data item in a message sent to a protocol participant. 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 [WP2021]. 3.1. Dealing with compromise Even with careful exposure of information, compromises may occur. It is important to build defenses to protect information, even when some component in a system becomes compromised. This may involve designs where no single party has all information such as with Oblivious DNS [I-D.annee-dprive-oblivious-dns], [I-D.pauly-dprive-oblivious-doh] or HTTP [I-D.ietf-ohai-ohttp], cryptographic designs where a service such as with the recent IETF PPM effort [I-D.ietf-ppm-dap], service side encryption of data at rest, confidential computing, and other mechanisms. Protocols can ensure that forward secrecy is provided, so that the damage resulting from a compromise of keying material has limited impact. On the client side, the client may trust that another party handles information appropriately, but take steps to ensure or verify that this is the case. For instance, as discussed above, the client can encrypt a message only to the actual final recipient, even if the server holds the message before it is delivered. A corollary of the recommendation is 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. For instance, a transport connection between two components of a system is not an end-to-end connection even if it encompasses all the protocol layers up to the application layer. It is not end-to-end, if the information or control function it carries extends beyond those components. For instance, just because an e-mail server can Arkko Expires January 13, 2023 [Page 4] Internet-Draft Data Minimization in Internet Architecture July 2022 read the contents of an e-mail message do not make it a legitimate recipient of the e-mail. The general topic of ensuring that protocol mechanisms stays evolvable and workable is covered in [I-D.iab-use-it-or-lose-it]. But the associated methods for reducing fingerprinting possibilities probably deserve further study [Fingerprinting] [AmIUnique]. [I-D.wood-pearg-website-fingerprinting] discusses one aspect of this. 3.2. Related work Hardie [RFC8558] discusses 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. The document recommends a principle that implicit signals should be avoided and that explicit signals be used instead, and only when the signal's originator intends that it be used by the network elements on the path. Arkko, Kuhlewind, Pauly, and Hardie [I-D.iab-path-signals-collaboration] discuss the same topic, and extend the RFC 8558 principles with recommendations to ensure minimum set of parties, minimum information, and consent. Thomson [I-D.thomson-tmi] 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, e.g., deliberate selection of protocol participants or limiting the capabilities or information exposure related to the intermediaries. Trammel and Kuehlewind [RFC8546] discuss the concept of a "wire image" of a protocol. This is an abstraction of the information available to an on-path non-participant in a networking protocol. It relates to the topic of non-participants interpreting information that is available to them in the "wire image" (or associated timing and other indirect information). The issues are largely the same even for participants. Even proper protocol participants may start to use information available to them, regardless of whether it was intended to that participant or simply relayed through them. Arkko Expires January 13, 2023 [Page 5] Internet-Draft Data Minimization in Internet Architecture July 2022 4. Acknowledgements The author would like to thank the members of the IAB, and the participants of IETF SAAG WG, Model-T IAB program, and the 2019 IAB DEDR workshop that all discussed some aspects of these issues. The author would like to acknowledge the significant contributions of Martin Thomson, Stephen Farrell, Mark McFadden, John Mattsson, Chris Wood, Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton, Mirja Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema in discussions around this general problem area. This work has been influenced greatly by discussions about trends in attacks, for instance, in [RFC8980], [I-D.farrell-etm] [I-D.arkko-arch-internet-threat-model-guidance], [I-D.lazanski-smart-users-internet], and others. 5. Informative References [AmIUnique] INRIA, ., "Am I Unique?", https://amiunique.org , 2020. [Confidentiality] The Internet Architecture Board, ., "IAB Statement on Internet Confidentiality", https://www.iab.org/2014/11/14/ iab-statement-on-internet-confidentiality/ , November 2014. [Fingerprinting] Laperdrix, P., Bielova, N., Baudry, B., and G. Avoine, "Browser Fingerprinting: A survey", arXiv:1905.01051v2 [cs.CR] 4 Nov 2019 , November 2019. [I-D.annee-dprive-oblivious-dns] Princeton University, Princeton University, Princeton University, and Salesforce, "Oblivious DNS - Strong Privacy for DNS Queries", draft-annee-dprive-oblivious- dns-00 (work in progress), July 2018. [I-D.arkko-arch-internet-threat-model-guidance] Ericsson and Trinity College Dublin, "Internet Threat Model Guidance", draft-arkko-arch-internet-threat-model- guidance-00 (work in progress), July 2021. [I-D.farrell-etm] Trinity College Dublin, "We're gonna need a bigger threat model", draft-farrell-etm-03 (work in progress), July 2019. Arkko Expires January 13, 2023 [Page 6] Internet-Draft Data Minimization in Internet Architecture July 2022 [I-D.iab-path-signals-collaboration] Ericsson, Cisco, Apple, and Ericsson, "Considerations on Application - Network Collaboration Using Path Signals", draft-iab-path-signals-collaboration-01 (work in progress), July 2022. [I-D.iab-use-it-or-lose-it] Mozilla and Apple, "Long-Term Viability of Protocol Extension Mechanisms", draft-iab-use-it-or-lose-it-04 (work in progress), October 2021. [I-D.ietf-ohai-ohttp] Mozilla and Cloudflare, "Oblivious HTTP", draft-ietf-ohai- ohttp-02 (work in progress), July 2022. [I-D.ietf-ppm-dap] ISRG, Cloudflare, Mozilla, and Cloudflare, "Distributed Aggregation Protocol for Privacy Preserving Measurement", draft-ietf-ppm-dap-01 (work in progress), July 2022. [I-D.lazanski-smart-users-internet] Last Press Label, "An Internet for Users Again", draft- lazanski-smart-users-internet-00 (work in progress), July 2019. [I-D.pauly-dprive-oblivious-doh] Apple Inc., Fastly, Apple Inc., Cloudflare, and Cloudflare, "Oblivious DNS over HTTPS", draft-pauly- dprive-oblivious-doh-11 (work in progress), February 2022. [I-D.thomson-tmi] Mozilla, "Principles for the Involvement of Intermediaries in Internet Protocols", draft-thomson-tmi-03 (work in progress), March 2022. [I-D.wood-pearg-website-fingerprinting] University of Waterloo, HK University of Science and Technology, and Apple, Inc., "Network-Based Website Fingerprinting", draft-wood-pearg-website- fingerprinting-00 (work in progress), November 2019. [PoLP] Saltzer, J. and M. Schroader, "The Protection of Information in Computer Systems", Fourth ACM Symposium on Operating System Principles , October 1975. Arkko Expires January 13, 2023 [Page 7] Internet-Draft Data Minimization in Internet Architecture July 2022 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2019, . [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, . [RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol Development", RFC 8980, DOI 10.17487/RFC8980, February 2021, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [WP2021] Fowler, Geoffrey., "There's no escape from Facebook, even if you don't use it", Washington Post , August 2021. Author's Address Jari Arkko Ericsson Valitie 1B Kauniainen Finland Email: jari.arkko@piuha.net Arkko Expires January 13, 2023 [Page 8]