draft-arkko-iab-data-minimization-principle-01.txt   draft-arkko-iab-data-minimization-principle.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational March 8, 2022 Intended status: Informational July 28, 2022
Expires: September 9, 2022 Expires: January 29, 2023
Data minimization Data minimization
draft-arkko-iab-data-minimization-principle-01 draft-arkko-iab-data-minimization-principle
Abstract Abstract
Communications security has been at the center of many security Communications security has been at the center of many security
improvements in the Internet. The goal has been to ensure that improvements in the Internet. The goal has been to ensure that
communications are protected against outside observers and attackers. communications are protected against outside observers and attackers.
This document recommends that this is no longer alone sufficient to This document recommends that this is no longer alone sufficient to
cater for the security and privacy issues seen on the Internet today. cater for the security and privacy issues seen on the Internet today.
For instance, it is often also necessary to protect against endpoints For instance, it is often also necessary to protect against endpoints
that are compromised, malicious, or whose interests simply do not that are compromised, malicious, or whose interests simply do not
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2022. This Internet-Draft will expire on January 29, 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
instance, the possibility that endpoints are compromised, malicious, instance, the possibility that endpoints are compromised, malicious,
or have interests that do not align with the interests of users. or have interests that do not align with the interests of users.
Given the advances in communication seceurity, adversaries have had Given the advances in communication seceurity, adversaries have had
to increase their pressure against new avenues of attack. New to increase their pressure against new avenues of attack. New
adversaries and risks have also arisen, e.g., due to increasing adversaries and risks have also arisen, e.g., due to increasing
amount of information stored in various Internet services. amount of information stored in various Internet services.
While such protection is difficult, there are some measures that can While such protection is difficult, there are some measures that can
be taken. This document focuses on the specific question of data be taken. This document focuses on the specific question of data
passed to various parties - including the primary protocol passed to various parties - including the primary protocol
participants. What information given to any other party needs to participants. What information is given to any other party should
depend on the role of that party, with the possibility of a depend on the role of that party. And the possibility of a
compromised access to the information kept in mind. This compromised entity sharing the information beyond the users'
consideration is important particularly when designing new technology expectations should be kept in mind.
or planning new deployments.
Careful control of information is also necessary from the perspective Careful control of information is also useful for technology
of technology evolution. For instance, allowing a participant to evolution. For instance, allowing a party to unnecessarily collect
unnecessarily collect or receive information may lead to a similar or receive information may lead to a similar effect as described in
effect as described in [RFC8546] for protocols: over time, [RFC8546] for protocols: regardless of initial expectations, over
unnecessary information will get used with all the associated time unnecessary information will get used, leading to, for instance,
downsides, regardless of what deployment expectations there were ossification. Systems end up depend on having access to exactly the
during protocol design. This may also lead to ossification, as same information as they had access to previously. This makes it
systems start to expect they have access to the information. hard to change what information is provided or how it is provided.
2. Recommendations 2. Recommendations
The Principle of Least Privilege [PoLP] is applicable: The Principle of Least Privilege [PoLP] is applicable:
"Every program and every user of the system should operate "Every program and every user of the system should operate
using the least set of privileges necessary to complete the using the least set of privileges necessary to complete the
job." job."
In this context, it is recommended that the protocol participants In this context, it is recommended that the protocol participants
skipping to change at page 3, line 43 skipping to change at page 3, line 42
through attacks. The same principle applies not just to routers and through attacks. The same principle applies not just to routers and
potential attackers on path, but also many other services in the potential attackers on path, but also many other services in the
Internet, including servers that provide some function. Internet, including servers that provide some function.
Of course, participants may provide more information to each after Of course, participants may provide more information to each after
careful consideration, e.g., information provided in exchange of some careful consideration, e.g., information provided in exchange of some
benefit, or to parties that are trusted by the participant. benefit, or to parties that are trusted by the participant.
3. Discussion 3. Discussion
Information disclosure may relate to different types of protocol Information sharing may relate to different types of protocol
exchanges: exchanges:
o The interaction of an endpoint with the network, e.g., information o The interaction of an endpoint with the network, e.g., information
they provide in any network attachment process or the wire images they provide in any network attachment process or the wire images
of the packets sent via the network. of the packets sent via the network.
o The interaction of an endpoint with intermediaries, in the meaning o The interaction of an endpoint with intermediaries such as group
discussed by Thomson [I-D.thomson-tmi]. messaging servers or NAT traversal relays.
o The interaction of an endpoint with a service, such as a website o The interaction of an endpoint with a service, such as a website,
or social networking function. social networking function, or a telemetry collection point.
o End-to-end interactions between users, represented by applications o End-to-end interactions between users, represented by applications
running on their computers. running on their computers.
It is also important to observe that information disclosure can Information sharing need not be explicitly carried information, e.g.,
appear in several ways. It can be explicitly carried information, a data item in a message sent to a protocol participant. Indirectly
e.g., a data item in a message sent to a protocol participant. But inferred information can also end up being shared, such as message
it can also be indirectly inferred information, such as message
arrival times or patterns in the traffic flow. Information may also arrival times or patterns in the traffic flow. Information may also
be obtained from fingerprinting the protocol participants, in an be obtained from fingerprinting the protocol participants, in an
effort to identify unique endpoints or users. Finally, information effort to identify unique endpoints or users.
gathered from a collaboration among several parties, e.g., websites
and social media systems collaborating to identify visiting users Information may also be combined from multiple sources, e.g.,
[WP2021]. websites and social media systems collaborating to identify visiting
users [WP2021].
3.1. Dealing with compromise 3.1. Dealing with compromise
Even with careful exposure of information, compromises may occur. It Even with careful exposure of information, compromises may occur. It
is important to build defenses to protect information, even when some is important to build defenses to protect information, even when some
component in a system is or becomes compromised. This may involve component in a system becomes compromised. This may involve designs
designs where no single party has all information such as with where no single party has all information such as with Oblivious DNS
Oblivious DNS, cryptographic designs where a service such as with the [I-D.annee-dprive-oblivious-dns], [I-D.pauly-dprive-oblivious-doh] or
recent IETF PPM effort, service side encryption of data at rest, HTTP [I-D.ietf-ohai-ohttp], cryptographic designs where a service
confidential computing, and other mechanisms. 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 Protocols can ensure that forward secrecy is provided, so that the
damage resulting from a compromise of keying material has limited damage resulting from a compromise of keying material has limited
impact. impact.
On the client side, the client may trust that another party handles On the client side, the client may trust that another party handles
information appropriately, but take steps to ensure or verify that information appropriately, but take steps to ensure or verify that
this is the case. For instance, as discussed above, the client can this is the case. For instance, as discussed above, the client can
encrypt a message only to the actual final recipient, even if the encrypt a message only to the actual final recipient, even if the
server holds our message before it is delivered. server holds the message before it is delivered.
A corollary of the recommendation is that information should not be A corollary of the recommendation is that information should not be
disclosed, stored, or routed in cleartext through services that do disclosed, stored, or routed in cleartext through services that do
not need to have that information for the function they perform. not need to have that information for the function they perform.
For instance, a transport connection between two components of a For instance, a transport connection between two components of a
system is not an end-to-end connection even if it encompasses all the 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, protocol layers up to the application layer. It is not end-to-end,
if the information or control function it carries extends beyond if the information or control function it carries extends beyond
those components. For instance, just because an e-mail server can those components. For instance, just because an e-mail server can
read the contents of an e-mail message do not make it a legitimate read the contents of an e-mail message do not make it a legitimate
recipient of the e-mail. recipient of the e-mail.
The general topic of ensuring that protocol mechanisms stays The general topic of ensuring that protocol mechanisms stays
evolvable and workable is covered in [I-D.iab-use-it-or-lose-it]. evolvable and workable is covered in [I-D.iab-use-it-or-lose-it].
But the associated methods for reducing fingerprinting possibilities But the associated methods for reducing fingerprinting possibilities
probably deserve further study. probably deserve further study [Fingerprinting] [AmIUnique].
[I-D.wood-pearg-website-fingerprinting] discusses one aspect of this. [I-D.wood-pearg-website-fingerprinting] discusses one aspect of this.
3.2. Related work 3.2. Related work
Trends in attacks have been discussed at length in, for instance, in
[RFC8980], [I-D.farrell-etm]
[I-D.arkko-arch-internet-threat-model-guidance],
[I-D.lazanski-smart-users-internet], and others.
Hardie [RFC8558] discusses path signals, i.e., messages to or from Hardie [RFC8558] discusses path signals, i.e., messages to or from
on-path elements to endpoints. In the past, path signals were often on-path elements to endpoints. In the past, path signals were often
implicit, e.g., network nodes interpreting in a particular way implicit, e.g., network nodes interpreting in a particular way
transport protocol headers originally intended for end-to-end transport protocol headers originally intended for end-to-end
consumption. The document recommends a principle that implicit consumption. The document recommends a principle that implicit
signals should be avoided and that explicit signals be used instead, 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 and only when the signal's originator intends that it be used by the
network elements on the path. network elements on the path.
Arkko, Kuhlewind, Pauly, and Hardie Arkko, Kuhlewind, Pauly, and Hardie
skipping to change at page 6, line 16 skipping to change at page 6, line 16
The author would like to thank the members of the IAB, and the 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 participants of IETF SAAG WG, Model-T IAB program, and the 2019 IAB
DEDR workshop that all discussed some aspects of these issues. The DEDR workshop that all discussed some aspects of these issues. The
author would like to acknowledge the significant contributions of author would like to acknowledge the significant contributions of
Martin Thomson, Stephen Farrell, Mark McFadden, John Mattsson, Chris Martin Thomson, Stephen Farrell, Mark McFadden, John Mattsson, Chris
Wood, Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton, Wood, Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton,
Mirja Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema in Mirja Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema in
discussions around this general problem area. 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 5. Informative References
[AmIUnique] [AmIUnique]
INRIA, ., "Am I Unique?", https://amiunique.org , 2020. INRIA, ., "Am I Unique?", https://amiunique.org , 2020.
[Confidentiality] [Confidentiality]
The Internet Architecture Board, ., "IAB Statement on The Internet Architecture Board, ., "IAB Statement on
Internet Confidentiality", https://www.iab.org/2014/11/14/ Internet Confidentiality", https://www.iab.org/2014/11/14/
iab-statement-on-internet-confidentiality/ , November iab-statement-on-internet-confidentiality/ , November
2014. 2014.
[Fingerprinting] [Fingerprinting]
Laperdrix, P., Bielova, N., Baudry, B., and G. Avoine, Laperdrix, P., Bielova, N., Baudry, B., and G. Avoine,
"Browser Fingerprinting: A survey", arXiv:1905.01051v2 "Browser Fingerprinting: A survey", arXiv:1905.01051v2
[cs.CR] 4 Nov 2019 , November 2019. [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] [I-D.arkko-arch-internet-threat-model-guidance]
Ericsson and Trinity College Dublin, "Internet Threat Ericsson and Trinity College Dublin, "Internet Threat
Model Guidance", draft-arkko-arch-internet-threat-model- Model Guidance", draft-arkko-arch-internet-threat-model-
guidance-00 (work in progress), July 2021. guidance-00 (work in progress), July 2021.
[I-D.farrell-etm] [I-D.farrell-etm]
Trinity College Dublin, "We're gonna need a bigger threat Trinity College Dublin, "We're gonna need a bigger threat
model", draft-farrell-etm-03 (work in progress), July model", draft-farrell-etm-03 (work in progress), July
2019. 2019.
[I-D.iab-path-signals-collaboration] [I-D.iab-path-signals-collaboration]
Ericsson, Cisco, Apple, and Ericsson, "Considerations on Ericsson, Cisco, Apple, and Ericsson, "Considerations on
Application - Network Collaboration Using Path Signals", Application - Network Collaboration Using Path Signals",
draft-iab-path-signals-collaboration-00 (work in draft-iab-path-signals-collaboration-01 (work in
progress), March 2022. progress), July 2022.
[I-D.iab-use-it-or-lose-it] [I-D.iab-use-it-or-lose-it]
Mozilla and Apple, "Long-Term Viability of Protocol Mozilla and Apple, "Long-Term Viability of Protocol
Extension Mechanisms", draft-iab-use-it-or-lose-it-04 Extension Mechanisms", draft-iab-use-it-or-lose-it-04
(work in progress), October 2021. (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] [I-D.lazanski-smart-users-internet]
Last Press Label, "An Internet for Users Again", draft- Last Press Label, "An Internet for Users Again", draft-
lazanski-smart-users-internet-00 (work in progress), July lazanski-smart-users-internet-00 (work in progress), July
2019. 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] [I-D.thomson-tmi]
Mozilla, "Principles for the Involvement of Intermediaries Mozilla, "Principles for the Involvement of Intermediaries
in Internet Protocols", draft-thomson-tmi-02 (work in in Internet Protocols", draft-thomson-tmi-03 (work in
progress), July 2021. progress), March 2022.
[I-D.wood-pearg-website-fingerprinting] [I-D.wood-pearg-website-fingerprinting]
University of Waterloo, HK University of Science and University of Waterloo, HK University of Science and
Technology, and Apple, Inc., "Network-Based Website Technology, and Apple, Inc., "Network-Based Website
Fingerprinting", draft-wood-pearg-website- Fingerprinting", draft-wood-pearg-website-
fingerprinting-00 (work in progress), November 2019. fingerprinting-00 (work in progress), November 2019.
[PoLP] Saltzer, J. and M. Schroader, "The Protection of [PoLP] Saltzer, J. and M. Schroader, "The Protection of
Information in Computer Systems", Fourth ACM Symposium on Information in Computer Systems", Fourth ACM Symposium on
Operating System Principles , October 1975. Operating System Principles , October 1975.
 End of changes. 20 change blocks. 
46 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/