draft-arkko-iab-data-minimization-principle-02.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 July 12, 2022		Intended status: Informational October 25, 2022
	Expires: January 13, 2023		Expires: April 28, 2023
	Data minimization		Data minimization
	draft-arkko-iab-data-minimization-principle-02		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		Privacy has also been a key focus area, and understanding the privacy
	cater for the security and privacy issues seen on the Internet today.		implications of new Internet technology is an important factor when
	For instance, it is often also necessary to protect against endpoints		IETF works on such technologies.
	that are compromised, malicious, or whose interests simply do not
	align with the interests of users. While such protection is		This document highlights the need for a particular focus with respect
	difficult, there are some measures that can be taken. It is		to privacy. It is necessary to protect against endpoints that are
	important to consider the role of data passed to various parties -		compromised, malicious, or whose interests simply do not align with
	including the primary protocol participants - and balance the		the interests of users. It is important to consider the role of data
	information given to them considering their roles and possible		passed to various parties - including the primary protocol
	compromise of the information.		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 January 13, 2023.		This Internet-Draft will expire on April 28, 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
	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
	3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Types of information . . . . . . . . . . . . . . . . . . 4
	3.1. Dealing with compromise . . . . . . . . . . . . . . . . . 4		2.2. Dealing with compromise . . . . . . . . . . . . . . . . . 4
	3.2. Related work . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Related work . . . . . . . . . . . . . . . . . . . . . . 5
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	5. Informative References . . . . . . . . . . . . . . . . . . . 6		4. Informative References . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Communications security has been at the center of many security		Communications security has been at the center of many security
	improvements on the Internet. The goal has been to ensure that		improvements on 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 has been exemplified in many aspects of IETF efforts, in the		This has been exemplified in many aspects of IETF efforts, in the
	threat models [RFC3552], concerns about surveillance [RFC7258], IAB		threat models [RFC3552], concerns about surveillance [RFC7258], IAB
	statements [Confidentiality], and the introduction of encryption in		statements [Confidentiality], and the introduction of encryption in
	many protocols [RFC9000], [RFC7858], [RFC8484]. This has been very		many protocols [RFC9000], [RFC7858], [RFC8484]. This has been very
	successful. Advances in protecting most of our communications with		successful. Advances in protecting most of our communications with
	strong cryptographic has resulted in much improved security. Work on		strong cryptographic has resulted in much improved security. Work on
	these advances continues to be a key part of IETF's security effort.		these advances continues to be a key part of IETF's security effort.
	This document recommends that further action is needed, however. For		Privacy has also been at the center of many activities in the IETF.
	instance, the possibility that endpoints are compromised, malicious,		Improvements in communications security obviously have improved
	or have interests that do not align with the interests of users.		privacy as well, but the concept is broader. Privacy and its impact
	Given the advances in communication seceurity, adversaries have had		on protocol development activities at IETF is discussed in [RFC6973],
	to increase their pressure against new avenues of attack. New		covering a number of topics, from understanding privacy threats to
	adversaries and risks have also arisen, e.g., due to increasing		threat mitigation, including data minimization.
	amount of information stored in various Internet services.
	While such protection is difficult, there are some measures that can		This document highlights the need for a particular focus with respect
	be taken. This document focuses on the specific question of data		to privacy, on data collection, particularly when it comes to the
	passed to various parties - including the primary protocol		primary protocol participants (and not just observers/attackers). As
	participants. What information is given to any other party should		RFC 6973 states:
	depend on the role of that party. And the possibility of a
	compromised entity sharing the information beyond the users'		"Limiting the data collected by protocol elements to
	expectations should be kept in mind.		only what is necessary (collection limitation) is
			the most straightforward way to help reduce privacy
			risks associated with the use of the protocol."
			This document offers some further discussion and motivation 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. This document also suggests that what
			information is given to any other participant should depend on the
			role of that participant.
			The reason why this is important is that it is possible that
			endpoints are compromised, malicious, or have interests that do not
			align with the interests of users. 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		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.
	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
	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.
	This recommendation is of course very similar to the current approach		Information sharing may relate to different types of protocol
	to communications security. As with communication security, we try		exchanges, e.g., interaction of an endpoint with the network or with
	to avoid providing too much information as it may be misused or leak		intermediaries. Other documents address aspects related to networks
	through attacks. The same principle applies not just to routers and		([RFC8546], [RFC8558], [I-D.iab-path-signals-collaboration]).
	potential attackers on path, but also many other services in the		Thomson [I-D.thomson-tmi] discusses the role intermediaries.
	Internet, including servers that provide some function.		Communications security largely addresses observers and outsider
			adversaries, and [RFC6973] 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.
	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		2.1. Types of information
	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.
	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.,		The use of identifiers has been extensively discussed in [RFC6973],
	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.,		Note that indirectly inferred information can also end up being
	websites and social media systems collaborating to identify visiting		shared, such as message arrival times or patterns in the traffic flow
	users [WP2021].		([RFC6973]). Information may also be obtained from fingerprinting
			the protocol participants, in an effort to identify unique endpoints
			or users ([RFC6973]). 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		2.2. 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 becomes compromised. This may involve designs		component in a system becomes compromised. This may involve designs
	where no single party has all information such as with Oblivious DNS		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], service
	side encryption of data at rest, confidential computing, and other		side encryption of data at rest, confidential computing, and other
	mechanisms.		mechanisms.
	skipping to change at page 5, line 13		skipping to change at page 5, line 29
	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 [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.
	3.2. Related work		2.3. Related work
			Cooper et al. [RFC6973] discuss the general concept of privacy,
			including data minimization. They provide the general statement
			quoted in Section 1, which is exactly about what this document is
			about. However, this document attempts to go further than the
			general statement, suggesting that information should not even be
			shared with a participant if it is not necessary for the expected
			role of that participant.
			[RFC6973] further discuss identifiability, i.e., the use of various
			types of identifiers. [RFC6973] also provides a questionnaire that
			protocol designers can use to further analyse 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. 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		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.
	skipping to change at page 6, line 5		skipping to change at page 6, line 34
	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. This is an abstraction of the information
	available to an on-path non-participant in a networking protocol. It		available to an on-path non-participant in a networking protocol. It
	relates to the topic of non-participants interpreting information		relates to the topic of non-participants interpreting information
	that is available to them in the "wire image" (or associated timing		that is available to them in the "wire image" (or associated timing
	and other indirect information). The issues are largely the same		and other indirect information). The issues are largely the same
	even for participants. Even proper protocol participants may start		even for participants. Even proper protocol participants may start
	to use information available to them, regardless of whether it was		to use information available to them, regardless of whether it was
	intended to that participant or simply relayed through them.		intended to that participant or simply relayed through them.
	4. Acknowledgements		3. Acknowledgements
	The author would like to thank the members of the IAB, and the		The author would like to thank the participants of various IAB
	participants of IETF SAAG WG, Model-T IAB program, and the 2019 IAB		workshops and programs, and IETF discussion list contributors for
	DEDR workshop that all discussed some aspects of these issues. The		interesting discussions in this area. The author would in particular
	author would like to acknowledge the significant contributions of		like to acknowledge the significant contributions of Martin Thomson,
	Martin Thomson, Stephen Farrell, Mark McFadden, John Mattsson, Chris		Nick Doty, Stephen Farrell, Mark McFadden, John Mattsson, Chris Wood,
	Wood, Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton,		Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton, Mirja
	Mirja Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema in		Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema.
	discussions around this general problem area.
	This work has been influenced greatly by discussions about trends in		This work has been influenced by [RFC6973], [RFC8980],
	attacks, for instance, in [RFC8980], [I-D.farrell-etm]		[I-D.farrell-etm] [I-D.arkko-arch-internet-threat-model-guidance],
	[I-D.arkko-arch-internet-threat-model-guidance],		[I-D.lazanski-smart-users-internet],
	[I-D.lazanski-smart-users-internet], and others.
	5. Informative References		4. 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]
	Princeton University, Princeton University, Princeton		Annie Edmundson, , Paul Schmitt, , Nick Feamster, , and
	University, and Salesforce, "Oblivious DNS - Strong		Allison Mankin, "Oblivious DNS - Strong Privacy for DNS
	Privacy for DNS Queries", draft-annee-dprive-oblivious-		Queries", draft-annee-dprive-oblivious-dns-00 (work in
	dns-00 (work in progress), July 2018.		progress), July 2018, <https://www.ietf.org/archive/id/
			draft-annee-dprive-oblivious-dns-00.txt>.
	[I-D.arkko-arch-internet-threat-model-guidance]		[I-D.arkko-arch-internet-threat-model-guidance]
	Ericsson and Trinity College Dublin, "Internet Threat		Jari Arkko, and Stephen Farrell, "Internet Threat Model
	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-
			internet-threat-model-guidance-00.txt>.
	[I-D.farrell-etm]		[I-D.farrell-etm]
	Trinity College Dublin, "We're gonna need a bigger threat		Stephen Farrell, , "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, <https://www.ietf.org/archive/id/draft-farrell-etm-
			03.txt>.
	[I-D.iab-path-signals-collaboration]		[I-D.iab-path-signals-collaboration]
	Ericsson, Cisco, Apple, and Ericsson, "Considerations on		Arkko, J., Hardie, T., Pauly, T., and M. Kuehlewind,
	Application - Network Collaboration Using Path Signals",		"Considerations on Application - Network Collaboration
	draft-iab-path-signals-collaboration-01 (work in		Using Path Signals", draft-iab-path-signals-
	progress), July 2022.		collaboration-02 (work in progress), October 2022,
			<https://www.ietf.org/archive/id/draft-iab-path-signals-
			collaboration-02.txt>.
	[I-D.iab-use-it-or-lose-it]		[I-D.iab-use-it-or-lose-it]
	Mozilla and Apple, "Long-Term Viability of Protocol		Martin Thomson, and Tommy Pauly, "Long-Term Viability of
	Extension Mechanisms", draft-iab-use-it-or-lose-it-04		Protocol Extension Mechanisms", draft-iab-use-it-or-lose-
	(work in progress), October 2021.		it-04 (work in progress), October 2021,
			<https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-
			it-04.txt>.
	[I-D.ietf-ohai-ohttp]		[I-D.ietf-ohai-ohttp]
	Mozilla and Cloudflare, "Oblivious HTTP", draft-ietf-ohai-		Thomson, M. and C. Wood, "Oblivious HTTP", draft-ietf-
	ohttp-02 (work in progress), July 2022.		ohai-ohttp-05 (work in progress), September 2022,
			<https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-
			05.txt>.
	[I-D.ietf-ppm-dap]		[I-D.ietf-ppm-dap]
	ISRG, Cloudflare, Mozilla, and Cloudflare, "Distributed		Geoghegan, T., Patton, C., Rescorla, E., and C. Wood,
	Aggregation Protocol for Privacy Preserving Measurement",		"Distributed Aggregation Protocol for Privacy Preserving
	draft-ietf-ppm-dap-01 (work in progress), July 2022.		Measurement", draft-ietf-ppm-dap-02 (work in progress),
			September 2022, <https://www.ietf.org/archive/id/draft-
			ietf-ppm-dap-02.txt>.
	[I-D.lazanski-smart-users-internet]		[I-D.lazanski-smart-users-internet]
	Last Press Label, "An Internet for Users Again", draft-		Dominique Lazanski, , "An Internet for Users Again",
	lazanski-smart-users-internet-00 (work in progress), July		draft-lazanski-smart-users-internet-00 (work in progress),
	2019.		July 2019, <https://www.ietf.org/archive/id/draft-
			lazanski-smart-users-internet-00.txt>.
	[I-D.pauly-dprive-oblivious-doh]		[I-D.pauly-dprive-oblivious-doh]
	Apple Inc., Fastly, Apple Inc., Cloudflare, and		Eric Kinnear, , Patrick McManus, , Tommy Pauly, , Tanya
	Cloudflare, "Oblivious DNS over HTTPS", draft-pauly-		Verma, , and A. Christopher Wood, "Oblivious DNS Over
	dprive-oblivious-doh-11 (work in progress), February 2022.		HTTPS", draft-pauly-dprive-oblivious-doh-11 (work in
			progress), February 2022,
			<https://www.ietf.org/archive/id/draft-pauly-dprive-
			oblivious-doh-11.txt>.
	[I-D.thomson-tmi]		[I-D.thomson-tmi]
	Mozilla, "Principles for the Involvement of Intermediaries		Martin Thomson, , "Principles for the Involvement of
	in Internet Protocols", draft-thomson-tmi-03 (work in		Intermediaries in Internet Protocols", draft-thomson-
	progress), March 2022.		tmi-04 (work in progress), September 2022,
			<https://www.ietf.org/archive/id/draft-thomson-tmi-
			04.txt>.
	[I-D.wood-pearg-website-fingerprinting]		[I-D.wood-pearg-website-fingerprinting]
	University of Waterloo, HK University of Science and		Ian Goldberg, , Tao Wang, , and A. Christopher Wood,
	Technology, and Apple, Inc., "Network-Based Website		"Network-Based Website Fingerprinting", draft-wood-pearg-
	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-
			website-fingerprinting-00.txt>.
	[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		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003, <https://www.rfc-		DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
	editor.org/info/rfc3552>.		editor.org/info/rfc3552>.
			[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
			Morris, J., Hansen, M., and R. Smith, "Privacy
			Considerations for Internet Protocols", RFC 6973,
			DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
			editor.org/info/rfc6973>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/info/rfc7258>.		2014, <https://www.rfc-editor.org/info/rfc7258>.
	[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>.
	[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS		[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
End of changes. 31 change blocks.
	119 lines changed or deleted		175 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/