draft-arkko-iab-data-minimization-principle-03.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 October 25, 2022		Intended status: Informational March 2023
	Expires: April 28, 2023		Expires: September 2, 2023
	Data minimization		Emphasizing Data minimization among protocol participants
	draft-arkko-iab-data-minimization-principle-03		draft-arkko-iab-data-minimization-principle
	Abstract		Abstract
	Communications security has been at the center of many security		Data minimization is an important privacy technique, as it can reduce
	improvements in the Internet. The goal has been to ensure that		the amount information exposed about a user. This document
	communications are protected against outside observers and attackers.		emphasizes the need for data minimization among primary protocol
	Privacy has also been a key focus area, and understanding the privacy		participants, such as between clients and servers. Avoiding data
	implications of new Internet technology is an important factor when		leakage to outside parties is of course very important as well, but
	IETF works on such technologies.		both need to be considered in minimization.
	This document highlights the need for a particular focus with respect		This is because is necessary to protect against endpoints that are
	to privacy. It is necessary to protect against endpoints that are
	compromised, malicious, or whose interests simply do not align with		compromised, malicious, or whose interests simply do not align with
	the interests of users. It is important to consider the role of data		the interests of users. It is important to consider the role of a
	passed to various parties - including the primary protocol		participant and limit any data provided to it according to that role.
	participants - and balance the information given to them considering
	their roles and possible compromise of the information.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 28, 2023.		This Internet-Draft will expire on September 2, 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2023 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3		2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Types of information . . . . . . . . . . . . . . . . . . 4		3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Dealing with compromise . . . . . . . . . . . . . . . . . 4		3.1. Types of Protocol Exchanges . . . . . . . . . . . . . . . 3
	2.3. Related work . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Types of information . . . . . . . . . . . . . . . . . . 4
	3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Different Ways of Avoiding Information Sharing . . . . . 4
	4. Informative References . . . . . . . . . . . . . . . . . . . 7		3.4. Role of Trust . . . . . . . . . . . . . . . . . . . . . . 5
			3.5. Evolvability and Fingerprinting . . . . . . . . . . . . . 5
			3.6. Related work . . . . . . . . . . . . . . . . . . . . . . 5
			4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
			5. Informative References . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Communications security has been at the center of many security		Privacy been at the center of many activities in the IETF. Privacy
	improvements on the Internet. The goal has been to ensure that		and its impact on protocol development activities at IETF is
	communications are protected against outside observers and attackers.		discussed in [RFC6973], covering a number of topics, from
			understanding privacy threats to threat mitigation, including data
	This has been exemplified in many aspects of IETF efforts, in the		minimization.
	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.
	Privacy has also been at the center of many activities in the IETF.		This document emphasizes the need for data minimization among primary
	Improvements in communications security obviously have improved		protocol participants, such as between clients and servers. Avoiding
	privacy as well, but the concept is broader. Privacy and its impact		data leakage to outside parties such as observers or attackers is of
	on protocol development activities at IETF is discussed in [RFC6973],		course very important as well, but minimization needs to consider
	covering a number of topics, from understanding privacy threats to		both.
	threat mitigation, including data minimization.
	This document highlights the need for a particular focus with respect		As RFC 6973 states:
	to privacy, on data collection, particularly when it comes to the
	primary protocol participants (and not just observers/attackers). As
	RFC 6973 states:
	"Limiting the data collected by protocol elements to		"Limiting the data collected by protocol elements to
	only what is necessary (collection limitation) is		only what is necessary (collection limitation) is
	the most straightforward way to help reduce privacy		the most straightforward way to help reduce privacy
	risks associated with the use of the protocol."		risks associated with the use of the protocol."
	This document offers some further discussion and motivation for this.		This document offers some further discussion, motivation, and
	This document suggests that limiting the sharing of data to the		clarification for this. This document suggests that limiting the
	protocol participants is a key technique in limiting the data		sharing of data to the protocol participants is a key technique in
	collection mentioned above. This document also suggests that what		limiting the data collection mentioned above. It is important that
	information is given to any other participant should depend on the		minimization happens prior to disclosing information to another
	role of that participant.		party, rather than relying on the good will of the other party to
			avoid storing the information.
	The reason why this is important is that it is possible that		This is because is necessary to protect against endpoints that are
	endpoints are compromised, malicious, or have interests that do not		compromised, malicious, or whose interests simply do not align with
	align with the interests of users. Even closed, managed networks may		the interests of users. It is important to consider the role of a
	have compromised nodes, justifying careful consideration of what		participant and limit any data provided to it according to that role.
	information is provided to different nodes in the network. And in
	all networks, increased use of communication security means		Even closed, managed networks may have compromised nodes, justifying
	adversaries may resort to new avenues of attack. New adversaries and		careful consideration of what information is provided to different
	risks have also arisen, e.g., due to increasing amount of information		nodes in the network. And in all networks, increased use of
	stored in various Internet services. And in situations where		communication security means adversaries may resort to new avenues of
	interests do not align across the protocol participants, limiting		attack. New adversaries and risks have also arisen, e.g., due to
	data collection by a protocol participant itself - who is interested		increasing amount of information stored in various Internet services.
	in data collection - may not be sufficient.		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		Careful control of information is also useful for technology
	evolution. For instance, allowing a party to unnecessarily collect		evolution. For instance, allowing a party to unnecessarily collect
	or receive information may lead to a similar effect as described in		or receive information may lead to a similar effect as described in
	[RFC8546] for protocols: regardless of initial expectations, over		[RFC8546] for protocols: regardless of initial expectations, over
	time unnecessary information will get used, leading to, for instance,		time unnecessary information will get used, leading to, for instance,
	ossification. Systems end up depend on having access to exactly the		ossification. Systems end up depend on having access to exactly the
	same information as they had access to previously. This makes it		same information as they had access to previously. This makes it
	hard to change what information is provided or how it is provided.		hard to change what information is provided or how it is provided.
	skipping to change at page 4, line 5		skipping to change at page 3, line 45
	"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
	minimize the information they share. I.e., they should provide only		minimize the information they share. I.e., they should provide only
	the information to each other that is necessary for the function that		the information to each other that is necessary for the function that
	is expected to be performed by the other party.		is expected to be performed by the other party.
			3. Discussion
			3.1. Types of Protocol Exchanges
	Information sharing may relate to different types of protocol		Information sharing may relate to different types of protocol
	exchanges, e.g., interaction of an endpoint with the network or with		exchanges, e.g., interaction of an endpoint with outsiders, the
	intermediaries. Other documents address aspects related to networks		network, or intermediaries.
	([RFC8546], [RFC8558], [I-D.iab-path-signals-collaboration]).
	Thomson [I-D.thomson-tmi] discusses the role intermediaries.		Other documents address aspects related to networks ([RFC8546],
	Communications security largely addresses observers and outsider		[RFC8558], [I-D.iab-path-signals-collaboration]). Thomson
	adversaries, and [RFC6973] discusses associated traffic analysis		[I-D.thomson-tmi] discusses the role intermediaries. Communications
			security largely addresses observers and outsider adversaries, see
			for instance [Confidentiality], [RFC7858], [RFC8446], [RFC8484],
			[RFC9000]. And [RFC6973] discusses associated traffic analysis
	threats. The focus in this document is on the primary protocol		threats. The focus in this document is on the primary protocol
	participants, such as a server in a client-server architecture or a		participants, such as a server in a client-server architecture or a
	service enables some kind of interaction among groups of users.		service enables some kind of interaction among groups of users.
	As with communication security, we try to avoid providing too much		As with communication security, we try to avoid providing too much
	information as it may be misused or leak through attacks. The same		information as it may be misused or leak through attacks. The same
	principle applies not just to routers and potential attackers on		principle applies not just to routers and potential attackers on
	path, but also many other services in the Internet, including servers		path, but also many other services in the Internet, including servers
	that provide some function.		that provide some function.
	Of course, participants may provide more information to each after		3.2. Types of information
	careful consideration, e.g., information provided in exchange of some
	benefit, or to parties that are trusted by the participant.
	2.1. Types of information
	The use of identifiers has been extensively discussed in [RFC6973],		The use of identifiers has been extensively discussed in [RFC6973],
	Note that indirectly inferred information can also end up being		Note that indirectly inferred information can also end up being
	shared, such as message arrival times or patterns in the traffic flow		shared, such as message arrival times or patterns in the traffic flow
	([RFC6973]). Information may also be obtained from fingerprinting		([RFC6973]). Information may also be obtained from fingerprinting
	the protocol participants, in an effort to identify unique endpoints		the protocol participants, in an effort to identify unique endpoints
	or users ([RFC6973]). Information may also be combined from multiple		or users. Information may also be combined from multiple sources,
	sources, e.g., websites and social media systems collaborating to		e.g., websites and social media systems collaborating to identify
	identify visiting users [WP2021].		visiting users [WP2021].
	2.2. Dealing with compromise		3.3. Different Ways of Avoiding Information Sharing
	Even with careful exposure of information, compromises may occur. It		The most straightforward approach is of course to avoid sending a
	is important to build defenses to protect information, even when some		particular piece of information at all.
	component in a system becomes compromised. This may involve designs
	where no single party has all information such as with Oblivious DNS		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.
			Architectural note: 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. Just
			because an e-mail server can read the contents of
			an e-mail message do not make it a legitimate
			recipient of the e-mail.
			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 possihle 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.
			Kuehlewind et al discuss the concept of Privacy Partititioning
			[I-D.iab-privacy-partitioning]. 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		[I-D.annee-dprive-oblivious-dns], [I-D.pauly-dprive-oblivious-doh] or
	HTTP [I-D.ietf-ohai-ohttp], cryptographic designs where a service		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		such as with the recent IETF PPM effort [I-D.ietf-ppm-dap], and so
	side encryption of data at rest, confidential computing, and other		on.
	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		3.4. Role of Trust
	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		Of course, participants may provide more information to each other
	disclosed, stored, or routed in cleartext through services that do		after careful consideration, e.g., information provided in exchange
	not need to have that information for the function they perform.		of some benefit, or to parties that are trusted by the participant.
	For instance, a transport connection between two components of a		3.5. Evolvability and Fingerprinting
	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
	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		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 [Fingerprinting] [AmIUnique].		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.
	2.3. Related work		3.6. Related work
	Cooper et al. [RFC6973] discuss the general concept of privacy,		Cooper et al. [RFC6973] discuss the general concept of privacy,
	including data minimization. They provide the general statement		including data minimization. Among other things, it provides the
	quoted in Section 1, which is exactly about what this document is		general statement quoted in Section 1. It also provides guidelines
	about. However, this document attempts to go further than the		to authors of specifications, a number of questions that protocol
	general statement, suggesting that information should not even be		designers can use to further analyse the impact of their design. For
	shared with a participant if it is not necessary for the expected		data minimization the questions relate to identifiers, data,
	role of that participant.		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:
	[RFC6973] further discuss identifiability, i.e., the use of various		Observers. Which information discussed in (a) and (b)
	types of identifiers. [RFC6973] also provides a questionnaire that		is exposed to each other protocol entity (i.e., recipients,
	protocol designers can use to further analyse the impact of their		intermediaries, and enablers)? Are there ways for protocol
	design. For data minimization the questions relate to identifiers,		implementers to choose to limit the information shared with
	data, observers, and fingerprinting. This includes, for instance,		each entity? Are there operational controls available to
	asking what information is exposed to which protocol entities, and if		limit the information shared with each entity?
	there are ways to limit such exposure. These questions are in line
	with avoiding sharing information to a protocol participant unless it
	is needed for its role.
	Hardie [RFC8558] discusses path signals, i.e., messages to or from		This is is very much in line with this document, although it would be
	on-path elements to endpoints. In the past, path signals were often		desirable to have recommendation as well as questions, e.g.,
	implicit, e.g., network nodes interpreting in a particular way		recommending against sharing information with a participant if it is
	transport protocol headers originally intended for end-to-end		not necessary for the expected role of that participant. And, as
	consumption. The document recommends a principle that implicit		discussed earlier, it is important to distinguish between the choices
	signals should be avoided and that explicit signals be used instead,		of a sender not sharing information and a receiver choosing to not
	and only when the signal's originator intends that it be used by the		collect information. Trusting an entity to not collect is not
	network elements on the path.		sufficient.
	Arkko, Kuhlewind, Pauly, and Hardie		There has also been a number of documents that address data
	[I-D.iab-path-signals-collaboration] discuss the same topic, and		minimization for specific situations, such as one DNS Query Name
	extend the RFC 8558 principles with recommendations to ensure minimum		Minimization [RFC7816], general DNS privacy advice including data
	set of parties, minimum information, and consent.		minimization [RFC9076], advice for DHCP clients for minimizing
			information in requests they send to DHCP servers [RFC7844] (along
			with general privacy considerations of DHCP [RFC7819] [RFC7824]).
			These are on the topic of limiting information sent by one primary
			protocol particiant (client) to another (server).
			Hardie [RFC8558] and Arkko et al.
			[I-D.iab-path-signals-collaboration] 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.
			Kuehlewind, Pauly, and Wood [I-D.iab-privacy-partitioning] 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 [I-D.thomson-tmi] discusses the role intermediaries in the		Thomson [I-D.thomson-tmi] discusses the role intermediaries in the
	Internet architecture, at different layers of the stack. For		Internet architecture, at different layers of the stack. For
	instance, a router is an intermediary, some parts of DNS		instance, a router is an intermediary, some parts of DNS
	infrastructure can be intermediaries, messaging gateways are		infrastructure can be intermediaries, messaging gateways are
	intermediaries. Thomson discusses when intermediaries are or are not		intermediaries. Thomson discusses when intermediaries are or are not
	an appropriate tool, and presents a number of principles relating to		an appropriate tool, and presents a number of principles relating to
	the use of intermediaries, e.g., deliberate selection of protocol		the use of intermediaries.
	participants or limiting the capabilities or information exposure
	related to the intermediaries.
	Trammel and Kuehlewind [RFC8546] discuss the concept of a "wire		Trammel and Kuehlewind [RFC8546] discuss the concept of a "wire
	image" of a protocol. This is an abstraction of the information		image" of a protocol, and how network elements may start to rely on
	available to an on-path non-participant in a networking protocol. It		information in the image, even if it was not originally intended for
	relates to the topic of non-participants interpreting information		them. The issues are largely the same even for participants.
	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.
	3. Acknowledgements		4. Acknowledgements
	The author would like to thank the participants of various IAB		The author would like to thank the participants of various IAB
	workshops and programs, and IETF discussion list contributors for		workshops and programs, and IETF discussion list contributors for
	interesting discussions in this area. The author would in particular		interesting discussions in this area. The author would in particular
	like to acknowledge the significant contributions of Martin Thomson,		like to acknowledge the significant contributions of Martin Thomson,
	Nick Doty, Stephen Farrell, Mark McFadden, John Mattsson, Chris Wood,		Nick Doty, Alissa Cooper, Stephen Farrell, Mark McFadden, John
	Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton, Mirja		Mattsson, Chris Wood, Dominique Lazanski, Eric Rescorla, Russ
	Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema.		Housley, Robin Wilton, Mirja Kuehlewind, Tommy Pauly, Jaime Jimenez
			and Christian Huitema.
	This work has been influenced by [RFC6973], [RFC8980],		This work has been influenced by [RFC6973], [RFC8980],
	[I-D.farrell-etm] [I-D.arkko-arch-internet-threat-model-guidance],		[I-D.farrell-etm] [I-D.arkko-arch-internet-threat-model-guidance],
	[I-D.lazanski-smart-users-internet],		[I-D.lazanski-smart-users-internet],
	4. 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]		[I-D.annee-dprive-oblivious-dns]
	Annie Edmundson, , Paul Schmitt, , Nick Feamster, , and		Edmundson, A., Schmitt, P., Feamster, N., and A. Mankin,
	Allison Mankin, "Oblivious DNS - Strong Privacy for DNS		"Oblivious DNS - Strong Privacy for DNS Queries", draft-
	Queries", draft-annee-dprive-oblivious-dns-00 (work in		annee-dprive-oblivious-dns-00 (work in progress), July
	progress), July 2018, <https://www.ietf.org/archive/id/		2018, <https://datatracker.ietf.org/doc/html/draft-annee-
	draft-annee-dprive-oblivious-dns-00.txt>.		dprive-oblivious-dns-00>.
	[I-D.arkko-arch-internet-threat-model-guidance]		[I-D.arkko-arch-internet-threat-model-guidance]
	Jari Arkko, and Stephen Farrell, "Internet Threat Model		Arkko, J. and S. Farrell, "Internet Threat Model
	Guidance", draft-arkko-arch-internet-threat-model-		Guidance", draft-arkko-arch-internet-threat-model-
	guidance-00 (work in progress), July 2021,		guidance-00 (work in progress), July 2021,
	<https://www.ietf.org/archive/id/draft-arkko-arch-		<https://datatracker.ietf.org/doc/html/draft-arkko-arch-
	internet-threat-model-guidance-00.txt>.		internet-threat-model-guidance-00>.
	[I-D.farrell-etm]		[I-D.farrell-etm]
	Stephen Farrell, , "We're gonna need a bigger threat		Farrell, S., "We're gonna need a bigger threat model",
	model", draft-farrell-etm-03 (work in progress), July		draft-farrell-etm-03 (work in progress), July 2019,
	2019, <https://www.ietf.org/archive/id/draft-farrell-etm-		<https://datatracker.ietf.org/doc/html/draft-farrell-etm-
	03.txt>.		03>.
	[I-D.iab-path-signals-collaboration]		[I-D.iab-path-signals-collaboration]
	Arkko, J., Hardie, T., Pauly, T., and M. Kuehlewind,		Arkko, J., Hardie, T., Pauly, T., and M. Kuehlewind,
	"Considerations on Application - Network Collaboration		"Considerations on Application - Network Collaboration
	Using Path Signals", draft-iab-path-signals-		Using Path Signals", draft-iab-path-signals-
	collaboration-02 (work in progress), October 2022,		collaboration-03 (work in progress), February 2023,
	<https://www.ietf.org/archive/id/draft-iab-path-signals-		<https://datatracker.ietf.org/doc/html/draft-iab-path-
	collaboration-02.txt>.		signals-collaboration-03>.
			[I-D.iab-privacy-partitioning]
			Kuehlewind, M., Pauly, T., and C. Wood, "Partitioning as
			an Architecture for Privacy", draft-iab-privacy-
			partitioning-01 (work in progress), March 2023,
			<https://datatracker.ietf.org/doc/html/draft-iab-privacy-
			partitioning-01>.
	[I-D.iab-use-it-or-lose-it]		[I-D.iab-use-it-or-lose-it]
	Martin Thomson, and Tommy Pauly, "Long-Term Viability of		Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
	Protocol Extension Mechanisms", draft-iab-use-it-or-lose-		Extension Mechanisms", draft-iab-use-it-or-lose-it-04
	it-04 (work in progress), October 2021,		(work in progress), October 2021,
	<https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-		<https://datatracker.ietf.org/doc/html/draft-iab-use-it-
	it-04.txt>.		or-lose-it-04>.
	[I-D.ietf-ohai-ohttp]		[I-D.ietf-ohai-ohttp]
	Thomson, M. and C. Wood, "Oblivious HTTP", draft-ietf-		Thomson, M. and C. Wood, "Oblivious HTTP", draft-ietf-
	ohai-ohttp-05 (work in progress), September 2022,		ohai-ohttp-08 (work in progress), March 2023,
	<https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-		<https://datatracker.ietf.org/doc/html/draft-ietf-ohai-
	05.txt>.		ohttp-08>.
	[I-D.ietf-ppm-dap]		[I-D.ietf-ppm-dap]
	Geoghegan, T., Patton, C., Rescorla, E., and C. Wood,		, , , and , "Distributed Aggregation Protocol for Privacy
	"Distributed Aggregation Protocol for Privacy Preserving		Preserving Measurement", draft-ietf-ppm-dap-05 (work in
	Measurement", draft-ietf-ppm-dap-02 (work in progress),		progress), July 2023,
	September 2022, <https://www.ietf.org/archive/id/draft-		<https://datatracker.ietf.org/api/v1/doc/document/draft-
	ietf-ppm-dap-02.txt>.		ietf-ppm-dap/>.
	[I-D.lazanski-smart-users-internet]		[I-D.lazanski-smart-users-internet]
	Dominique Lazanski, , "An Internet for Users Again",		Lazanski, D., "An Internet for Users Again", draft-
	draft-lazanski-smart-users-internet-00 (work in progress),		lazanski-smart-users-internet-00 (work in progress), July
	July 2019, <https://www.ietf.org/archive/id/draft-		2019, <https://datatracker.ietf.org/doc/html/draft-
	lazanski-smart-users-internet-00.txt>.		lazanski-smart-users-internet-00>.
	[I-D.pauly-dprive-oblivious-doh]		[I-D.pauly-dprive-oblivious-doh]
	Eric Kinnear, , Patrick McManus, , Tommy Pauly, , Tanya		Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.
	Verma, , and A. Christopher Wood, "Oblivious DNS Over		Wood, "Oblivious DNS over HTTPS", draft-pauly-dprive-
	HTTPS", draft-pauly-dprive-oblivious-doh-11 (work in		oblivious-doh-11 (work in progress), February 2022,
	progress), February 2022,		<https://datatracker.ietf.org/doc/html/draft-pauly-dprive-
	<https://www.ietf.org/archive/id/draft-pauly-dprive-		oblivious-doh-11>.
	oblivious-doh-11.txt>.
	[I-D.thomson-tmi]		[I-D.thomson-tmi]
	Martin Thomson, , "Principles for the Involvement of		Thomson, M., "Principles for the Involvement of
	Intermediaries in Internet Protocols", draft-thomson-		Intermediaries in Internet Protocols", draft-thomson-
	tmi-04 (work in progress), September 2022,		tmi-04 (work in progress), September 2022,
	<https://www.ietf.org/archive/id/draft-thomson-tmi-		<https://datatracker.ietf.org/doc/html/draft-thomson-tmi-
	04.txt>.		04>.
	[I-D.wood-pearg-website-fingerprinting]		[I-D.wood-pearg-website-fingerprinting]
	Ian Goldberg, , Tao Wang, , and A. Christopher Wood,		Goldberg, I., Wang, T., and C. Wood, "Network-Based
	"Network-Based Website Fingerprinting", draft-wood-pearg-		Website Fingerprinting", draft-wood-pearg-website-
	website-fingerprinting-00 (work in progress), November		fingerprinting-00 (work in progress), November 2019,
	2019, <https://www.ietf.org/archive/id/draft-wood-pearg-		<https://datatracker.ietf.org/doc/html/draft-wood-pearg-
	website-fingerprinting-00.txt>.		website-fingerprinting-00>.
	[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.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
	editor.org/info/rfc3552>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973,		Considerations for Internet Protocols", RFC 6973,
	DOI 10.17487/RFC6973, July 2013, <https://www.rfc-		DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
	editor.org/info/rfc6973>.		editor.org/info/rfc6973>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
	2014, <https://www.rfc-editor.org/info/rfc7258>.		<https://www.rfc-editor.org/info/rfc7816>.
			[RFC7819] Jiang, S., Krishnan, S., and T. Mrugalski, "Privacy
			Considerations for DHCP", RFC 7819, DOI 10.17487/RFC7819,
			April 2016, <https://www.rfc-editor.org/info/rfc7819>.
			[RFC7824] Krishnan, S., Mrugalski, T., and S. Jiang, "Privacy
			Considerations for DHCPv6", RFC 7824,
			DOI 10.17487/RFC7824, May 2016, <https://www.rfc-
			editor.org/info/rfc7824>.
			[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
			Profiles for DHCP Clients", RFC 7844,
			DOI 10.17487/RFC7844, May 2016, <https://www.rfc-
			editor.org/info/rfc7844>.
	[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,		[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
	and P. Hoffman, "Specification for DNS over Transport		and P. Hoffman, "Specification for DNS over Transport
	Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May		Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
	2016, <https://www.rfc-editor.org/info/rfc7858>.		2016, <https://www.rfc-editor.org/info/rfc7858>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
	(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,		(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
	<https://www.rfc-editor.org/info/rfc8484>.		<https://www.rfc-editor.org/info/rfc8484>.
	[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a		[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
	Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April		Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
	2019, <https://www.rfc-editor.org/info/rfc8546>.		2019, <https://www.rfc-editor.org/info/rfc8546>.
	[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",		[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
	RFC 8558, DOI 10.17487/RFC8558, April 2019,		RFC 8558, DOI 10.17487/RFC8558, April 2019,
	skipping to change at page 9, line 51		skipping to change at page 10, line 36
	[RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on		[RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on
	Design Expectations vs. Deployment Reality in Protocol		Design Expectations vs. Deployment Reality in Protocol
	Development", RFC 8980, DOI 10.17487/RFC8980, February		Development", RFC 8980, DOI 10.17487/RFC8980, February
	2021, <https://www.rfc-editor.org/info/rfc8980>.		2021, <https://www.rfc-editor.org/info/rfc8980>.
	[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021, <https://www.rfc-		DOI 10.17487/RFC9000, May 2021, <https://www.rfc-
	editor.org/info/rfc9000>.		editor.org/info/rfc9000>.
			[RFC9076] Wicinski, T., Ed., "DNS Privacy Considerations", RFC 9076,
			DOI 10.17487/RFC9076, July 2021, <https://www.rfc-
			editor.org/info/rfc9076>.
	[WP2021] Fowler, Geoffrey., "There's no escape from Facebook, even		[WP2021] Fowler, Geoffrey., "There's no escape from Facebook, even
	if you don't use it", Washington Post , August 2021.		if you don't use it", Washington Post , August 2021.
	Author's Address		Author's Address
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Valitie 1B		Valitie 1B
	Kauniainen		Kauniainen
	Finland		Finland
End of changes. 50 change blocks.
	201 lines changed or deleted		244 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/