draft-arkko-farrell-arch-model-t-redux-01.txt		draft-arkko-arch-internet-threat-model-guidance.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational S. Farrell		Intended status: Informational S. Farrell
	Expires: August 26, 2021 Trinity College Dublin		Expires: 13 January 2022 Trinity College Dublin
	February 22, 2021		July 2021
	Internet Threat Model Evolution: Background and Principles		Internet Threat Model Guidance
	draft-arkko-farrell-arch-model-t-redux-01		draft-arkko-arch-internet-threat-model-guidance
	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 memo suggests that the existing RFC 3552 threat model, while		This memo suggests that the existing RFC 3552 threat model, while
	important and still valid, is no longer alone sufficient to cater for		important and still valid, is no longer alone sufficient to cater for
	the pressing security and privacy issues seen on the Internet today.		the pressing security and privacy issues seen on the Internet today.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 26, 2021.		This Internet-Draft will expire on 2 January 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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. Attack Landscape . . . . . . . . . . . . . . . . . . . . . . 5		2. Attack Landscape . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Communications Security Improvements . . . . . . . . . . 5		2.1. Communications Security Improvements . . . . . . . . . . 4
	2.2. Beyond Communications Security . . . . . . . . . . . . . 6		2.2. Beyond Communications Security . . . . . . . . . . . . . 5
	2.3. Types of Attacks . . . . . . . . . . . . . . . . . . . . 7		2.3. Accidental Vulnerabilities . . . . . . . . . . . . . . . 6
	2.3.1. Misuse of Accidental Vulnerabilities . . . . . . . . 7		2.4. Misbehaving Applications . . . . . . . . . . . . . . . . 6
	2.3.2. Misbehaving Applications . . . . . . . . . . . . . . 8		2.5. Untrustworthy Devices . . . . . . . . . . . . . . . . . . 7
	2.3.3. Network Infrastructure Attacks . . . . . . . . . . . 8		2.6. Untrustworthy "Closed" Networks . . . . . . . . . . . . . 7
	2.3.4. Untrustworthy Devices . . . . . . . . . . . . . . . . 9		2.7. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.3.5. Tracking . . . . . . . . . . . . . . . . . . . . . . 10		3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.1. Trusting Devices . . . . . . . . . . . . . . . . . . . . 9
	3.1. Trusting Devices . . . . . . . . . . . . . . . . . . . . 13		3.2. Protecting Information . . . . . . . . . . . . . . . . . 10
	3.2. Protecting Information . . . . . . . . . . . . . . . . . 13		3.3. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.3. Tracking . . . . . . . . . . . . . . . . . . . . . . . . 13		3.4. Role of End-to-End . . . . . . . . . . . . . . . . . . . 11
	3.4. Role of End-to-End . . . . . . . . . . . . . . . . . . . 14		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 15		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. Informative References . . . . . . . . . . . . . . . . . . . 12
	6. Informative References . . . . . . . . . . . . . . . . . . . 15		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 22		Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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 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.
	At the IETF, this approach has been formalized in BCP 72 [RFC3552],		At the IETF, this approach has been formalized in BCP 72 [RFC3552],
	which defined the Internet threat model in 2003.		which defined the Internet threat model in 2003.
	The purpose of a threat model is to outline what threats exist in		The purpose of a threat model is to outline what threats exist in
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 24 ¶
	By contrast, we assume that the attacker has nearly complete		By contrast, we assume that the attacker has nearly complete
	control of the communications channel over which the end-systems		control of the communications channel over which the end-systems
	communicate. This means that the attacker can read any PDU		communicate. This means that the attacker can read any PDU
	(Protocol Data Unit) on the network and undetectably remove,		(Protocol Data Unit) on the network and undetectably remove,
	change, or inject forged packets onto the wire.		change, or inject forged packets onto the wire.
	However, the communications-security -only threat model is becoming		However, the communications-security -only threat model is becoming
	outdated. Some of the causes for this are:		outdated. Some of the causes for this are:
	o Success! Advances in protecting most of our communications with		* Success! Advances in protecting most of our communications with
	strong cryptographic means. This has resulted in much improved		strong cryptographic means. This has resulted in much improved
	communications security, but also highlights the need for		communications security, but also highlights the need for
	addressing other, remaining issues. This is not to say that		addressing other, remaining issues. This is not to say that
	communications security is not important, it still is:		communications security is not important, it still is.
	improvements are still needed. Not all communications have been		Fortunately, there are ongoing projects working on improvements.
	protected, and even out of the already protected communications,
	not all of their aspects have been fully protected. Fortunately,
	there are ongoing projects working on improvements.
	o Adversaries have increased their pressure against other avenues of		* Adversaries have increased their pressure against other avenues of
	attack, from supply-channel attacks, to compromising devices to		attack, from supply-channel attacks, to compromising devices to
	legal coercion of centralized endpoints in conversations.		legal coercion of centralized endpoints in conversations.
	o New adversaries and risks have arisen, e.g., due to creation of		* New adversaries and risks have arisen, e.g., due to creation of
	large centralized information sources.		large centralized information sources.
	o While communications-security does seem to be required to protect		* While communications-security does seem to be required to protect
	privacy, more is needed, especially if endpoints choose to act		privacy, more is needed, especially if endpoints choose to act
	against the interests of their peers or users.		against the interests of their peers or users.
	In short, attacks are migrating towards the currently easier targets,		In short, attacks are migrating towards the currently easier targets,
	which no longer necessarily include direct attacks on traffic flows.		which no longer necessarily include direct attacks on traffic flows.
	In addition, trading information about users and ability to influence
	them has become a common practice for many Internet services, often
	without users understanding those practices.
	This memo suggests that the existing threat model, while important
	and still valid, is no longer alone sufficient to cater for the
	pressing security and privacy issues on the Internet. For instance,
	while it continues to be very important to protect Internet
	communications against outsiders, it is also necessary to protect
	systems against endpoints that are compromised, malicious, or whose
	interests simply do not align with the interests of the users.
	Of course, there are many trade-offs in the Internet on who one
	chooses to interact with and why or how. It is not the role of this
	memo to dictate those choices. But it is important that we
	understand the implications of different practices. It is also
	important that when it comes to basic Internet infrastructure, our
	chosen technologies lead to minimal exposure with respect to the non-
	communications threats.
	It is particularly important to ensure that non-communications
	security related threats are properly understood for any new Internet
	technology. While the consideration of these issues is relatively
	new in the IETF, this memo provides some initial ideas about
	potential broader threat models to consider when designing protocols
	for the Internet or when trying to defend against pervasive
	monitoring. Further down the road, updated threat models could
	result in changes in BCP 72 [RFC3552] (guidelines for writing
	security considerations) and BCP 188 [RFC7258] (pervasive
	monitoring), to include proper consideration of non-communications
	security threats.
	It may also be necessary to have dedicated guidance on how systems
	design and architecture affect security. The sole consideration of
	communications security aspects in designing Internet protocols may
	lead to accidental or increased impact of security issues elsewhere.
	For instance, allowing a participant to unnecessarily collect or
	receive information may lead to a similar effect as described in
	[RFC8546] for protocols: over time, unnecessary information will get
	used with all the associated downsides, regardless of what deployment
	expectations there were during protocol design.
	This memo does not stand alone. To begin with, it is a continuation		It is important that when it comes to basic Internet infrastructure,
	of earlier work by the two authors [I-D.farrell-etm]		our chosen technologies lead to minimal exposure with respect to the
	[I-D.arkko-arch-internet-threat-model]		non-communications threats. It is particularly important to ensure
	[I-D.arkko-farrell-arch-model-t]. There are also other documents		that non-communications security related threats are properly
	discussing this overall space, e.g.		understood for any new Internet technology. The sole consideration
	[I-D.lazanski-smart-users-internet] [I-D.arkko-arch-dedr-report].		of communications security aspects in designing Internet protocols
			may lead to accidental or increased impact of security issues
			elsewhere. For instance, allowing a participant to unnecessarily
			collect or receive information may lead to a similar effect as
			described in [RFC8546] for protocols: over time, unnecessary
			information will get used with all the associated downsides,
			regardless of what deployment expectations there were during protocol
			design.
	The rest of this memo is organized as follows. Section 2 makes some		The rest of this memo is organized as follows. Section 2 makes some
	observations about the situation, with respect to communications		observations about the threa situation. Section 3 discusses some
	security and beyond. The section also provides a number of real-		high-level principles that could be used to address some of the
	world examples.		emerging issues.
	Section 3 discusses some high-level principles that relate to these
	changes, and could be used to tackle some of the emerging issues.
	Comments are solicited on these and other aspects of this document.
	The best place for discussion is on the model-t list.
	(https://www.ietf.org/mailman/listinfo/model-t)
	2. Attack Landscape		2. Attack Landscape
	This section discusses the evolving landscape of security		This section discusses the evolving landscape of security
	vulnerabilities, threats, and attacks.		vulnerabilities, threats, and attacks.
	2.1. Communications Security Improvements		2.1. Communications Security Improvements
	Being able to ask about threat model improvements is due to progress		Being able to ask about threat model improvements is due to progress
	already made: The fraction of Internet traffic that is		already made: The fraction of Internet traffic that is
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 6 ¶
	information in TLS [I-D.ietf-tls-esni], and domain name queries		information in TLS [I-D.ietf-tls-esni], and domain name queries
	[RFC8484].		[RFC8484].
	There have also been improvements to ensure that the security		There have also been improvements to ensure that the security
	protocols that are in use actually have suitable credentials and that		protocols that are in use actually have suitable credentials and that
	those credentials have not been compromised, see, for instance, Let's		those credentials have not been compromised, see, for instance, Let's
	Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT		Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT
	[I-D.ietf-httpbis-expect-ct].		[I-D.ietf-httpbis-expect-ct].
	This is not to say that all problems in communications security have		This is not to say that all problems in communications security have
	been resolved - far from it. But the situation is definitely		been resolved -- far from it. But the situation is definitely
	different from what it was a few years ago. Remaining issues will be		different from what it was a few years ago. Remaining issues will be
	and are worked on; the fight between defense and attack will also		and are worked on; the fight between defense and attack will also
	continue. Communications security will stay at the top of the agenda		continue. Communications security will stay at the top of the agenda
	in any Internet technology development.		in any Internet technology development.
	2.2. Beyond Communications Security		2.2. Beyond Communications Security
	There are, however, significant issues beyond communications security		There are issues beyond communications security in the Internet. It
	in the Internet.		is not necessarily clear that one can trust all the endpoints in any
			protocol interaction, including the user's own devices. Managed or
	To begin with, it is not necessarily clear that one can trust all the		closed ecosystems with multiple layers of hardware and software have
	endpoints in any protocol interaction, including the user's own		made it harder to understand or influence what your devices do.
	devices. Managed or closed ecosystems with multiple layers of
	hardware and software have made it harder to understand or influence
	what your devices do.
	The situation is different, but not necessarily better on the side of		The situation is different, but not necessarily better on the side of
	servers. Even for applications that are for user-to-user		servers. Even for applications that are for user-to-user
	communication, a typical pattern of communications is almost always		communication, a typical pattern of communications is almost always
	via an intermediary that has at least as much information as the		via an intermediary that has at least as much information as the
	other parties have. For instance, these intermediaries are typically		other parties have. For instance, these intermediaries are typically
	endpoints for any transport layer security connections, and able to		endpoints for any transport layer security connections, and able to
	see much communications or other messaging in cleartext. There are		see much communications or other messaging in cleartext. There are
	some exceptions, of course, e.g., messaging applications with end-to-		some exceptions, of course, e.g., messaging applications with end-to-
	end confidentiality protection.		end confidentiality protection.
	skipping to change at page 6, line 41 ¶		skipping to change at page 5, line 42 ¶
	e-mail messages between users has been much slower. This has lead to		e-mail messages between users has been much slower. This has lead to
	a situation where e-mail content is considered a critical resource by		a situation where e-mail content is considered a critical resource by
	some mail service providers who use the content for machine learning,		some mail service providers who use the content for machine learning,
	advertisement targeting, and other purposes unrelated to message		advertisement targeting, and other purposes unrelated to message
	delivery. Equally however, it is unclear how some useful anti-spam		delivery. Equally however, it is unclear how some useful anti-spam
	techniques could be deployed in an end-to-end encrypted mail universe		techniques could be deployed in an end-to-end encrypted mail universe
	(with today's end-to-end mail security protocols) and there are many		(with today's end-to-end mail security protocols) and there are many
	significant challenges should one desire to deploy end-to-end email		significant challenges should one desire to deploy end-to-end email
	security at scale.		security at scale.
	Services that are not about user-to-user to communication often		Even services that are not about user-to-user to communication often
	collect information about the user.		collect information about the user.
	Even services that are part of the infrastructure may have security		Services that are part of the infrastructure may have security
	issues. For instance, despite progress in protecting DNS query		issues. For instance, despite progress in protecting DNS query
	protocols with encryption (see, e.g., [RFC7858] and [RFC8484]), DNS		protocols with encryption (see, e.g., [RFC7858] and [RFC8484]), DNS
	resolver services themselves may be targets for attack or sources for		resolver services themselves may be targets for attack or sources for
	leaks. For instance, the services may collect information or be		leaks. For instance, the services may collect information or be
	vulnerable targets of denial-of-service attacks, attacks to steal		vulnerable targets of denial-of-service attacks, attacks to steal
	user browsing history information, or be the target of surveillance		user browsing history information, or be the target of surveillance
	activities and government information requests. Infrastructure		activities and government information requests. Infrastructure
	services with information about a large number of users is collected		services with information about a large number of users is collected
	in small number of services are particularly attractive targets for		in small number of services are particularly attractive targets for
	these attacks.		these attacks.
	With the growth of trading users' information by many of these
	parties, it becomes necessary to take precautions against endpoints
	that are compromised, malicious, or whose interests simply do not
	align with the interests of the users.
	In general, many recent attacks relate more to information than		In general, many recent attacks relate more to information than
	communications. For instance, personal information leaks typically		communications. For instance, personal information leaks typically
	happen via information stored on a compromised server rather than		happen via information stored on a compromised server rather than
	capturing communications. There is little hope that such attacks can		capturing communications. There is little hope that such attacks can
	be prevented entirely. Again, the best course of action seems to be		be prevented entirely. Again, the best course of action seems to be
	avoid the disclosure of information in the first place, or at least		avoid the disclosure of information in the first place, or at least
	to not perform that in a manner that makes it possible that others		to not perform that in a manner that makes it possible that others
	can readily use the information.		can readily use the information.
	2.3. Types of Attacks		2.3. Accidental Vulnerabilities
	This section discusses a few classes of attacks that are relevant for
	our consideration.
	2.3.1. Misuse of Accidental Vulnerabilities
	Not all adversarial behaviour starts as deliberate, some is initiated
	due to various levels of carelessness and/or due to erroneous
	assumptions about the environments in which those applications
	currently run at. Nevertheless, a leak or vulnerability can be
	exploited by others that misuse the data for their own purposes.
	Some attacks in this category include:
	o Virtualisation exposing secrets, for example, Meltdown and Spectre
	[MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar
	side-channel attacks.
	o Compromised badly-maintained web sites or services, e.g.,
	[Passwords] or Amazon S3 leaks.
	o Supply-chain attacks, for example, the [TargetAttack] or malware		Some vulnerabilities came to being through various levels of
	within pre-installed applications on Android phones [Bloatware].		carelessness and/or due to erroneous assumptions about the
			environments in which those applications currently run at. A
			vulnerability can be exploited to misuse the data for someone's own
			purposes.
	o Breaches of major service providers, that many of us might have		Some attacks in this category include hardware-related issues, for
	assumed would be sufficiently capable to be the best large-scale		example, Meltdown and Spectre [MeltdownAndSpectre], compromised or
	"Identity providers", for example, Yahoo		badly-maintained web sites or services, e.g., [Passwords], supply-
	(https://www.wired.com/story/yahoo-breach-three-billion-		chain attacks, for example, the [TargetAttack], and breaches of major
	accounts/), Facebook (https://www.pcmag.com/news/367319/facebook-		service providers, that many of us might have assumed would be
	stored-up-to-600m-user-passwords-in-plain-text and		sufficiently capable to be the best large-scale "Identity providers",
	https://www.cnet.com/news/facebook-breach-affected-50-million-		for example, Yahoo (https://www.wired.com/story/yahoo-breach-three-
	people/), Telcos (https://www.zdnet.com/article/us-telcos-caught-		billion-accounts/), Facebook (https://www.pcmag.com/news/367319/
	selling-your-location-data-again-senator-demands-new-laws/ and		facebook-stored-up-to-600m-user-passwords-in-plain-text and many
	https://www.zdnet.com/article/millions-verizon-customer-records-		others.
	israeli-data/), Google (https://www.wsj.com/articles/google-
	exposed-user-data-feared-repercussions-of-disclosing-to-public-
	1539017194), and Microsoft
	(https://motherboard.vice.com/en_us/article/ywyz3x/hackers-could-
	read-your-hotmail-msn-outlook-microsoft-customer-support).
	2.3.2. Misbehaving Applications		2.4. Misbehaving Applications
	There are many examples of application developers doing their best to		There are many examples of application developers doing their best to
	protect the security and privacy of their users or customers. That's		protect the security and privacy of their users or customers. But
	just the same as the case today where we need to consider in-network		there are also some that do not act int he best interests of their
	actors as potential adversaries despite the many examples of network		users. As a result, it becomes necessary to consider applications as
	operators who both act in the best interests of their users and		potentially untrusted, much in the same way that we consider in-
	succeed in defending against attacks from others.		network actors as potential adversaries despite the many examples of
			network operators who both act in the best interests of their users
	In short, there are applications that do not act in the best		and succeed in defending against attacks from others.
	interests of their users.
	This can also happen indirectly. Despite the best efforts of		This can also happen indirectly. Despite the best efforts of
	curators, so-called App-Stores frequently distribute malware of many		curators, so-called App-Stores frequently distribute malware of many
	kinds and one recent study [Curated] claims that simple obfuscation		kinds.
	enables malware to avoid detection by even sophisticated operators.
	Given the scale of these deployments, distribution of even a small
	percentage of malware-infected applications can affect a large number
	of people. The end result is an application that
	Applications may also mislead users. Many web sites today provide		Applications may also mislead users. Many web sites today provide
	some form of privacy policy and terms of service, that are known to		some form of privacy policy and terms of service, that are known to
	be mostly unread [Unread]. This implies that, legal fiction aside,		be mostly unread [Unread]. This implies that, legal fiction aside,
	users of those sites have not in reality agreed to the specific terms		users of those sites have not in reality agreed to the specific terms
	published and so users are therefore highly exposed to being		published and so users are therefore highly exposed to being
	exploited by web sites, for example [Cambridge] is a recent well-		exploited by web sites, for example [Cambridge] is a recent well-
	publicised case where a service provider abused the data of 87		publicised case where a service provider abused the data of 87
	million users via a partnership. While many web site operators claim		million users via a partnership.
	that they care deeply about privacy, it seems prudent to assume that
	some do not in fact care about user privacy in ways with which many
	of their users would agree.
	2.3.3. Network Infrastructure Attacks
	The network infrastructure may also work in an inappropriate manner.
	For instance, a Virtual Private Network (VPN) may misrepresent how it
	carries the users' traffic, for example misrepresenting the countries
	in which they provide vantage points [Vpns]. A user's home network
	equipment may also be malicous or compromised. For example, one
	study [Home] reports on a 2011 attack that affected 4.5 million DSL
	modems in Brazil. The absence of software update [RFC8240] has been
	a major cause of these issues and rises to the level that considering
	this as intentional behaviour by device vendors who have chosen this
	path is warranted.
	2.3.4. Untrustworthy Devices		2.5. Untrustworthy Devices
	Traditionally, there's been an implied trust in various parts of the		Traditionally, there's been an implied trust in various parts of the
	system - such as the user's own device, nodes inside a particular		system -- such as the user's own device, nodes inside a particular
	network perimeter, or nodes under a single administrative control.		network perimeter, or nodes under a single administrative control.
	Client endpoint implementations were never fully trusted, but the		Client endpoint implementations were never fully trusted, but the
	environments in which those endpoints exist are changing. Users may		environments in which those endpoints exist are changing. Users may
	not have as much control over their own devices as they used to, due		not have as much control over their own devices as they used to, due
	to manufacturer-controlled operating system installations and locked		to manufacturer-controlled operating system installations and locked
	device ecosystems. And within those ecosystems, even the		device ecosystems. And within those ecosystems, even the
	applications that are available tend to have privileges that users by		applications that are available tend to have privileges that users by
	themselves might not desire those applications be granted, such as		themselves might not desire those applications be granted, such as
	excessive rights to media, location, and peripherals. There are also		excessive rights to media, location, and peripherals. There are also
	designated efforts by various authorities to hack end-user devices as		designated efforts by various authorities to hack end-user devices as
	a means of intercepting data about the user.		a means of intercepting data about the user.
	Examples of these issues are too many to list, for instance, so-		Examples of these issues are too many to list, for instance, so-
	called "smart" televisions spying on their owners and one survey of		called "smart" televisions spying on their owners and one survey of
	user attitudes [SmartTV].		user attitudes [SmartTV]. Untrustworthy devices can also cause
			damage to other parties, such as badly constructed IoT devices
			[DynDDoS] attacking large Internet services.
	There are similar issues with larger, networked systems. As these		2.6. Untrustworthy "Closed" Networks
	systems evolve over time, they get used and connected in different
	ways, run in virtual environments, and expanded for new functions.
	Old assumptions and security mechanisms may no longer be applicable
	in these new environments, leading to security vulnerabilities.
	Even in a closed network with carefully managed components there may		Even in a closed network with carefully managed components there may
	be compromised components, as evidenced in the most extreme way by		be compromised components, as evidenced in the most extreme way by
	the Stuxnet worm that operated in an airgapped network.		the Stuxnet worm that operated in an airgapped network. Every system
			runs large amount of software, and it is often not practical or even
	Every system runs large amount of software, and it is often not		possible to prevent compromised code even in a high-security setting,
	practical or even possible to prevent compromised code even in a		let alone in commercial or private networks. Installation media,
	high-security setting, let alone in commercial or private networks.		physical ports, both open source and proprietary programs, firmware,
	Installation media, physical ports, both open source and proprietary		or even innocent-looking components on a circuit board can be suspect
	programs, firmware, or even innocent-looking components on a circuit		[TinyChip]. In addition, complex underlying computing platforms,
	board can be suspect [TinyChip]. In addition, complex underlying		such as modern CPUs with underlying security and management tools are
	computing platforms, such as modern CPUs with underlying security and		prone to problems.
	management tools are prone to problems. Analysis for the security of
	many interesting real-world systems now commonly needs to include
	cross-component attacks, e.g., the use of car radios and other
	externally communicating devices as part of attacks launched against
	the control components such as brakes in a car [Savage].
	Untrustworthy systems can also cause damage to other parties.
	Examples of this range from attacks of badly constructed IoT devices
	[DynDDoS] to large Internet services that become single points of
	failure [I-D.arkko-arch-infrastructure-centralisation].
	2.3.5. Tracking		2.7. Tracking
	One of the biggest threats to user privacy on the Web is ubiquitous		One of the biggest threats to user privacy on the Web is ubiquitous
	tracking. This is often done to support advertising based business		tracking. This is often done to support advertising based business
	models.		models, or more specifically advertising based business models that
			attempt to find out information about the user.
	While some people may be sanguine about this kind of tracking, others		While some people may be sanguine about this kind of tracking, others
	consider this behaviour unwelcome, when or if they are informed that		consider this behaviour unwelcome, when or if they are informed that
	it happens, [Attitude] though the evidence here seems somewhat harder		it happens. Historically, browsers have not made this kind of
	to interpret and many studies (that we have found to date) involve		tracking visible and have enabled it by default, though some recent
	small numbers of users. Historically, browsers have not made this		browser versions are starting to enable visibility and blocking of
	kind of tracking visible and have enabled it by default, though some		some kinds of tracking.
	recent browser versions are starting to enable visibility and
	blocking of some kinds of tracking. Browsers are also increasingly
	imposing more stringent requirements on plug-ins for varied security
	reasons.
	Third party tracking
	One form of tracking is by third parties. HTTP header fields (such		One form of tracking is by third parties. HTTP header fields (such
	as cookies, [RFC6265]) are commonly used for such tracking, as are		as cookies, [RFC6265]) are commonly used for such tracking, as are
	structures within the content of HTTP responses such as links to 1x1		structures within the content of HTTP responses such as links to 1x1
	pixel images and (ab)use of Javascript APIs offered by browsers		pixel images and (ab)use of Javascript APIs offered by browsers
	[Tracking].		[Tracking]. Whenever a resource is loaded from a server, that server
			can include a cookie which will be sent back to the server on future
	Whenever a resource is loaded from a server, that server can include		loads. The combination of these features makes it possible to track
	a cookie which will be sent back to the server on future loads. This		a user across the Web.
	includes situations where the resource is loaded as a resource on a
	page, such as an image or a JavaScript module. When loading a
	resource, the server is aware of the top-level page that the resource
	is used on, through the use of the Referer HTTP header [RFC7231].
	those loads include a Referer header which contains the top-level
	page from which that subresource is being loaded.
	The combination of these features makes it possible to track a user
	across the Web. The tracker convinces a number of content sites
	("first parties") to include a resource from the tracker site. This
	resource can perform some function such as displaying an
	advertisement or providing analytics to the first party site. But
	the resource may also be simply a tracker. When the user visits one
	of the content sites, the tracker receives both a Referer header and
	the cookie. For an individual user with a particular browser, the
	cookie is the same regardless of which site the tracker is on. This
	allows the tracker to observe what pages within the set of content
	sites the user visits. The resulting information is commonly used
	for targeting advertisements, but it can also be used for other
	purposes.
	This capability itself constitutes a major threat to user privacy.		This capability itself constitutes a major threat to user privacy.
	Additional techniques such as cookie syncing, identifier correlation,		Additional techniques such as cookie syncing, identifier correlation,
	and fingerprinting make the problem even worse		and fingerprinting make the problem even worse
	[I-D.wood-pearg-website-fingerprinting].		[I-D.wood-pearg-website-fingerprinting]. For instance, features such
			as User-Agent string, plugin and font support, screen resolution, and
	As a given tracker will not be on all sites, that tracker has		timezone can yield a fingerprint that is sometimes unique to a single
	incomplete coverage. However, trackers often collude (a practice		user [AmIUnique] and which persists beyond cookie scope and lifetime.
	called "cookie syncing") to combine the information from different
	tracking cookies.
	Sometimes trackers will be embedded on a site which collects a user
	identifier, such as social media identity or an e-mail address. If
	the site can inform the tracker of the identifier, that allows the
	tracker to tie the identifier to the cookie.
	While a browser may block cookies, fingerprinting browsers often
	allows tracking the users. For instance, features such as User-Agent
	string, plugin and font support, screen resolution, and timezone can
	yield a fingerprint that is sometimes unique to a single user
	[AmIUnique] and which persists beyond cookie scope and lifetime.
	Even in cases where this fingerprint is not unique, the anonymity set
	may be sufficiently small that, coupled with other data, this yields
	a unique, per-user identifier. Fingerprinting of this type is more
	prevalent on systems and platforms where data-set features are
	flexible, such as desktops, where plugins are more commonly in use.
	Fingerprinting prevention is an active research area; see [Boix2018]
	for more information.
	Other types of tracking linked to web tracking
	Third party web tracking is not the only concern. An obvious		Third party web tracking is not the only concern. An obvious
	tracking danger exists also in popular ecosystems - such as social		tracking danger exists also in popular ecosystems -- such as social
	media networks - that house a large part of many users' online		media networks -- that house a large part of many users' online
	existence. There is no need for a third party to track the user's		existence. There is no need for a third party to track the user's
	browsing as all actions are performed within a single site, where		browsing as all actions are performed within a single site, where
	most messaging, viewing, and sharing activities happen.		most messaging, viewing, and sharing activities happen.
	Browsers themselves or services used by the browser can also become a		Browsers themselves or services used by the browser can also become a
	potential source of tracking users. For instance, the URL/search bar		potential source of tracking users. For instance, the URL/search bar
	service may leak information about the user's actions to a search		service may leak information about the user's actions to a search
	provider via an "autocomplete" feature. [Leith2020]		provider via an "autocomplete" feature. [Leith2020]
	Tracking through users' IP addresses or DNS queries is also a danger.		Tracking through users' IP addresses or DNS queries is also a danger.
	This may happen by directly observing the cleartext IP or DNS		This may happen by directly observing the cleartext IP or DNS
	traffic, though DNS tracking may be preventable via DNS protocols		traffic, though DNS tracking may be preventable via DNS protocols
	that are secured end-to-end. But the DNS queries are also (by		that are secured end-to-end. But the DNS queries are also (by
	definition) seen by the used DNS recursive resolver service, which		definition) seen by the used DNS recursive resolver service, which
	may accidentally or otherwise track the users' activities. This is		may accidentally or otherwise track the users' activities.
	particularly problematic if a large number of users employ either a
	commonly used ISP service or an Internet-based resolver service
	[I-D.arkko-arch-infrastructure-centralisation]. In contrast, use of
	a DNS recursive that sees little traffic could equally be used for
	tracking. Similarly, other applications, such an mail or instant
	messaging protocols, that can carry HTML content can be integrated
	with web tracking. For instance, intentional tracking are also seen
	many times per day by email users - in one study [Mailbug] the
	authors estimated that 62% of leakage to third parties was
	intentional, for example if leaked data included a hash of the
	recipient email address.
	Tracking happens through other systems besides the web, of course.		Tracking happens through other systems besides the web, of course.
	For instance, some mail user agents (MUAs) render HTML content by		For instance, some mail user agents (MUAs) render HTML content by
	default (with a subset not allowing that to be turned off, perhaps		default (with a subset not allowing that to be turned off, perhaps
	particularly on mobile devices) and thus enable the same kind of		particularly on mobile devices) and thus enable the same kind of
	adversarial tracking seen on the web. Attempts at such intentional		adversarial tracking seen on the web.
	tracking are also seen many times per day by email users - in one
	study [Mailbug] the authors estimated that 62% of leakage to third		One of the concerns with universal user tracking is that it provides
	parties was intentional, for example if leaked data included a hash		yet another avenue for pervasive surveillance [RFC7258], e.g.,
	of the recipient email address.		intelligence agencies can tap into the databases constructed by user
			tracking.
	3. Principles		3. Principles
	Based on the above issues, it is necessary to pay attention to the		Based on the above issues, it is necessary to pay attention to the
	following aspects:		following aspects:
	o Security of devices, including the user's own devices.		* Security of devices, including the user's own devices.
	o Security of data at rest, in various parts of the system.		* Security of data at rest or in use, in various parts of the
			system.
	o Tracking and identification of users and their devices.		* Tracking and identification of users and their devices.
	o Role of intermediaries, and in particular information passing		* Role of servers, and in particular information passing through
	through them.		them.
	These topics are discussed below. There are obviously many detailed		These topics are discussed below. There are obviously many detailed
	technical questions and approaches to tackling them. However, in		technical questions and approaches to tackling them. However, in
	this memo we wish to focus on higher level architectural principles		this memo we wish to focus on higher level architectural principles
	that might guide us in thinking about about the topics.		that might guide us in thinking about about the topics.
	3.1. Trusting Devices		3.1. Trusting Devices
	In general, this means that one cannot entirely trust even a closed		In general, this means that one cannot entirely trust even a closed
	system where you picked all the components yourself, let alone		system where you picked all the components yourself, let alone
	typical commercial, networked and Internet-connected systems.		typical commercial, networked and Internet-connected systems.
	PRINCIPLE: Consider all system components as potentially		PRINCIPLE: Consider all system components as potentially
	untrustworthy, and consider the implications of their compromise.		untrustworthy, and consider the implications of their compromise.
	There may also be ways to mitigate damages, should a compromise		There may also be ways to mitigate damages, should a compromise
	occur.		occur.
	3.2. Protecting Information		3.2. Protecting Information
	Data leaks have become the primary concern. Even trusted, well-		Data leaks have become the primary concern. Even trusted, well-
	managed parties can be problematic, such as when large data stores		managed parties can be problematic, such as when large data stores
	attract attempts to use that data in a manner that is not consistent		attract attempts to use that data in a manner that is not consistent
	with the users' interests.		with the users' interests.
	Mere encryption of communications is not sufficient to protect		Mere encryption of communications is not sufficient to protect
	information.		information.
	PRINCIPLE: Consider information passed to another party as a		PRINCIPLE: Consider information passed to another party as a
	publication to at least some number of entities.		publication. Avoid passing information that should not be published.
	This principle applies even if the communications that carry that		This principle applies even if the communications that carry that
	information are encrypted.		information are encrypted.
			PRINCIPLE: Build defences to protect information, even when some
			component in a system is compromised.
			For instance, encryption of data at rest or in use may assist in
			protecting information when an attacker gainst access to a server
			system.
			PRINCIPLE: Trust that information is handled appropriately, but
			verify that this is actually the case.
			It is not wise to merely trust that someone acts correctly, without
			mistakes, and does not misuse your information. When we send packets
			over the Internet, we encrypt them and know that they can only
			received by a specific party. Similarly, if we send information to a
			server, we can, for instance:
			* encrypt a message only to the actual final recipient, even if the
			server holds our message before it is delivered
			* verify (e.g., through confidential computing attestations) that
			the server runs a software that we know does not leak our
			information
	3.3. Tracking		3.3. Tracking
	Information leakage is particularly harmful in situations where the		Information leakage is particularly harmful in situations where the
	information can be traced to an individual, such as is the case with		information can be traced to an individual, such as is the case with
	any information that users would consider private, be it about		any information that users would consider private, be it about
	messages to another users, browsing history, or even user's medical		messages to another users, browsing history, or even user's medical
	information.		information.
	PRINCIPLE: Assume that every interaction with another party can		PRINCIPLE: Assume that every interaction with another party can
	result in fingerprinting or identification of the user in		result in fingerprinting or identification of the user in question.
	question.
	In many cases there are readily available user identifiers in data		In many cases there are readily available user identifiers in data
	that is leaked, such as was the case with a recent medical		that is leaked. But even when such identifiers are not present,
	information leak in Finland [Vastaamo]. But even when such		there is often an opportunity to narrow down which entity is
	identifiers are not present, in many communication methods, there is		connecting, through, for instance, geolocation or fingerprinting.
	ample opportunity for narrowing down which entity is connecting,
	through geolocation, fingerprinting, and correlation with other
	information.
	3.4. Role of End-to-End		3.4. Role of End-to-End
	[RFC1958] notes that "end-to-end functions can best be realised by		[RFC1958] noted that "end-to-end functions can best be realised by
	end-to-end protocols":		end-to-end protocols". This functional argument aligns with other,
			practical arguments about the evolution of the Internet under the
			end-to-end model. The endpoints evolve quickly, often with simply
			having one party change the necessary software on both ends. The
			end-to-end model supports permissionless innovation where new
			innovation can flourish in the Internet without excessive wait for
			other parties to act.
	The basic argument is that, as a first principle, certain required		However, there is a significant difference between actual endpoints
	end-to-end functions can only be performed correctly by the end-		from a user's interaction perspective (e.g., another user) and from a
	systems themselves. A specific case is that any network, however		system perspective (e.g., a party relaying a message). In general,
	carefully designed, will be subject to failures of transmission at		there needs to be distinction between the intended interaction
	some statistically determined rate. The best way to cope with		participants and the services used to carry this interaction out.
	this is to accept it, and give responsibility for the integrity of		These services are typically implemented as servers that provide,
	communication to the end systems. Another specific case is end-		e.g., the messaging relay function.
	to-end security.
	The "end-to-end argument" was originally described by Saltzer et al		Thomson [I-D.thomson-tmi] discusses the role of intermediaries. We
	[Saltzer]. They said:		prefer to use the term services to underline how all types of
			services can have issues -- including the simple case of an end-user
			contacting a server for some information.
	The function in question can completely and correctly be		In any case, as Thomson points out, intermediaries (or services) can
	implemented only with the knowledge and help of the application		provide a useful function. Networks themselves would not exist
	standing at the endpoints of the communication system. Therefore,		without intermediaries that can forward communications to others.
	providing that questioned function as a feature of the		Similarly, networks would not exist without services responding to
	communication system itself is not possible.		communications sent by end users.
	These functional arguments align with other, practical arguments		PRINCIPLE: Set clear limits what all services can do, and minimise
	about the evolution of the Internet under the end-to-end model. The		the use of those services to cases where they are necessary.
	endpoints evolve quickly, often with simply having one party change
	the necessary software on both ends. Whereas waiting for network
	upgrades would involve potentially a large number of parties from
	application owners to multiple network operators. The end-to-end
	model supports permissionless innovation where new innovation can
	flourish in the Internet without excessive wait for other parties to
	act.
	But the details matter. What is considered an endpoint? What		This is a general rule, but perhaps a few examples can illustrate it:
	characteristics of Internet are we trying to optimize?
	There is a significant difference between actual endpoints from a		* A router's role is to efficiently forward packets to their
	user's interaction perspective (e.g., another user) and from a system		destination, not to differentiate the treatment based on what
	perspective (e.g., a third party relaying a message). Such		content is being carried.
	intermediaries can provide a useful service. As [I-D.thomson-tmi]
	points out, networks themselves would not exist without
	intermediaries that can forward communications to others.
	PRINCIPLE: Limit the use of intermediaries, and what they can do.		* The role of an information service web server is to provide that
			information, not to gather the identity or personal information
			about the user accessing information.
	PRINCIPLE: Pass information only between the "real ends" of a		* The role of a messaging service is to deliver messages to other
	conversation, unless the information is necessary for a useful		users, not to process the contents of the messages.
	function in an intermediary.
			Note that this principle applies at multiple layers in the stack. It
			is not just about intermediaries in the network and transport layers,
			but also intermediaries and services on the application layer.
			PRINCIPLE: Pass information only between the "real ends" of a
			conversation, unless the information is necessary for a useful
			function in a service.
	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 actually extends		if the information or control function it carries actually extends
	beyond those components. For instance, just because an e-mail server		beyond those components. For instance, just because an e-mail server
	can read the contents of an e-mail message does not make it a		can read the contents of an e-mail message does not make it a
	legitimate recipient of the e-mail.		legitimate recipient of the e-mail.
	This memo also proposes to focus on the "need to know" aspect in		PRINCIPLE: Information should not be disclosed, stored, or routed in
	systems. Information should not be disclosed, stored, or routed in		cleartext through services that do not absolutely need to have that
	cleartext through parties that do not absolutely need to have that		information for the function they perform.
	information. This relates to the discussion in [I-D.thomson-tmi], in
	that the valuable functions provided by intermediaries need to be		This the "need to know" principle. It also relates to the discussion
	balanced against the information that they need to perform their		in [I-D.thomson-tmi], in that the valuable functions provided by
	function. And, in a lot of cases unnecessary information is provided		intermediaries need to be balanced against the information that they
	to intermediaries, which leads to privacy and other problems.		need to perform their function.
	4. Security Considerations		4. Security Considerations
	The entire memo covers the security considerations.		The entire memo covers the security considerations.
	5. IANA Considerations		5. IANA Considerations
	There are no IANA considerations in this work.		There are no IANA considerations in this work.
	6. Informative References		6. Informative References
	[AbuseCases]
	McDermott, J. and C. Fox, "Using abuse case models for
	security requirements analysis", IEEE Annual Computer
	Security Applications Conference (ACSAC'99),
	https://www.acsac.org/1999/papers/wed-b-1030-john.pdf ,
	1999.
	[AmIUnique]		[AmIUnique]
	INRIA, ., "Am I Unique?", https://amiunique.org , 2020.		INRIA, ., "Am I Unique?", https://amiunique.org , 2020.
	[Attitude]
	"User Perceptions of Sharing, Advertising, and Tracking",
	Symposium on Usable Privacy and Security (SOUPS),
	https://www.usenix.org/conference/soups2015/proceedings/
	presentation/chanchary , 2015.
	[avleak] Cox, J., "Leaked Documents Expose the Secretive Market for
	Your Web Browsing Data",
	https://www.vice.com/en_us/article/qjdkq7/
	avast-antivirus-sells-user-browsing-data-investigation ,
	2020.
	[Bloatware]
	Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and
	N. Vallina, "An Analysis of Pre-installed Android
	Software", arXiv preprint arXiv:1905.02713 (2019) , 2019.
	[Boix2018]
	Gomez-Boix, A., Laperdrix, P., and B. Baudry, "Hiding in
	the crowd: an analysis of the effectiveness of browser
	fingerprinting at large scale", Proceedings of the 2018
	world wide web conference , 2018.
	[Cambridge]		[Cambridge]
	Isaak, J. and M. Hanna, "User Data Privacy: Facebook,		Isaak, J. and M. Hanna, "User Data Privacy: Facebook,
	Cambridge Analytica, and Privacy Protection", Computer		Cambridge Analytica, and Privacy Protection", Computer
	51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/		51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/
	stamp.jsp?arnumber=8436400 , 2018.		stamp.jsp?arnumber=8436400 , 2018.
	[Curated] Hammad, M., Garcia, J., and S. MaleK, "A large-scale
	empirical study on the effects of code obfuscations on
	Android apps and anti-malware products", ACM International
	Conference on Software Engineering 2018,
	https://www.ics.uci.edu/~seal/
	publications/2018ICSE_Hammad.pdf , 2018.
	[DynDDoS] York, K., "Dyn's Statement on the 10/21/2016 DNS DDoS		[DynDDoS] York, K., "Dyn's Statement on the 10/21/2016 DNS DDoS
	Attack", Company statement: https://dyn.com/blog/		Attack", Company statement: https://dyn.com/blog/dyn-
	dyn-statement-on-10212016-ddos-attack/ , 2016.		statement-on-10212016-ddos-attack/ , 2016.
	[GDPRAccess]
	EU, ., "Right of access by the data subject", Article 15,
	GDPR, https://gdpr-info.eu/art-15-gdpr/ , n.d..
	[Home] Nthala, N. and I. Flechais, "Rethinking home network
	security", European Workshop on Usable Security
	(EuroUSEC), https://ora.ox.ac.uk/objects/
	uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa
	fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica
	tion%2Fpdf&type_of_work=Conference+item , 2018.
	[I-D.arkko-arch-dedr-report]		[I-D.arkko-arch-dedr-report]
	Arkko, J. and T. Hardie, "Report from the IAB workshop on		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", draft-arkko-arch-dedr-report-00 (work in		Development", Work in Progress, Internet-Draft, draft-
	progress), November 2019.		arkko-arch-dedr-report-00, 4 November 2019,
			<https://www.ietf.org/archive/id/draft-arkko-arch-dedr-
	[I-D.arkko-arch-infrastructure-centralisation]		report-00.txt>.
	Arkko, J., "Centralised Architectures in Internet
	Infrastructure", draft-arkko-arch-infrastructure-
	centralisation-00 (work in progress), November 2019.
	[I-D.arkko-arch-internet-threat-model]		[I-D.arkko-arch-internet-threat-model]
	Arkko, J., "Changes in the Internet Threat Model", draft-		Arkko, J., "Changes in the Internet Threat Model", Work in
	arkko-arch-internet-threat-model-01 (work in progress),		Progress, Internet-Draft, draft-arkko-arch-internet-
	July 2019.		threat-model-01, 8 July 2019,
			<https://www.ietf.org/archive/id/draft-arkko-arch-
			internet-threat-model-01.txt>.
	[I-D.arkko-farrell-arch-model-t]		[I-D.arkko-farrell-arch-model-t]
	Arkko, J. and S. Farrell, "Challenges and Changes in the		Arkko, J. and S. Farrell, "Challenges and Changes in the
	Internet Threat Model", draft-arkko-farrell-arch-model-		Internet Threat Model", Work in Progress, Internet-Draft,
	t-04 (work in progress), July 2020.		draft-arkko-farrell-arch-model-t-04, 13 July 2020,
			<https://www.ietf.org/archive/id/draft-arkko-farrell-arch-
			model-t-04.txt>.
			[I-D.arkko-farrell-arch-model-t-redux]
			Arkko, J. and S. Farrell, "Internet Threat Model
			Evolution: Background and Principles", Work in Progress,
			Internet-Draft, draft-arkko-farrell-arch-model-t-redux-01,
			22 February 2021, <https://www.ietf.org/archive/id/draft-
			arkko-farrell-arch-model-t-redux-01.txt>.
	[I-D.farrell-etm]		[I-D.farrell-etm]
	Farrell, S., "We're gonna need a bigger threat model",		Farrell, S., "We're gonna need a bigger threat model",
	draft-farrell-etm-03 (work in progress), July 2019.		Work in Progress, Internet-Draft, draft-farrell-etm-03, 6
			July 2019, <https://www.ietf.org/archive/id/draft-farrell-
			etm-03.txt>.
	[I-D.ietf-httpbis-expect-ct]		[I-D.ietf-httpbis-expect-ct]
	estark@google.com, e., "Expect-CT Extension for HTTP",		Stark, E., "Expect-CT Extension for HTTP", Work in
	draft-ietf-httpbis-expect-ct-08 (work in progress),		Progress, Internet-Draft, draft-ietf-httpbis-expect-ct-08,
	December 2018.		9 December 2018, <https://www.ietf.org/archive/id/draft-
			ietf-httpbis-expect-ct-08.txt>.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-34 (work		and Secure Transport", Work in Progress, Internet-Draft,
	in progress), January 2021.		draft-ietf-quic-transport-34, 14 January 2021,
			<https://www.ietf.org/archive/id/draft-ietf-quic-
			transport-34.txt>.
	[I-D.ietf-tls-esni]		[I-D.ietf-tls-esni]
	Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS		Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
	Encrypted Client Hello", draft-ietf-tls-esni-09 (work in		Encrypted Client Hello", Work in Progress, Internet-Draft,
	progress), December 2020.		draft-ietf-tls-esni-12, 7 July 2021,
			<https://www.ietf.org/archive/id/draft-ietf-tls-esni-
			12.txt>.
	[I-D.lazanski-smart-users-internet]		[I-D.lazanski-smart-users-internet]
	Lazanski, D., "An Internet for Users Again", draft-		Lazanski, D., "An Internet for Users Again", Work in
	lazanski-smart-users-internet-00 (work in progress), July		Progress, Internet-Draft, draft-lazanski-smart-users-
	2019.		internet-00, 8 July 2019,
			<https://www.ietf.org/archive/id/draft-lazanski-smart-
			users-internet-00.txt>.
	[I-D.thomson-tmi]		[I-D.thomson-tmi]
	Thomson, M., "Principles for the Involvement of		Thomson, M., "Principles for the Involvement of
	Intermediaries in Internet Protocols", draft-thomson-		Intermediaries in Internet Protocols", Work in Progress,
	tmi-01 (work in progress), January 2021.		Internet-Draft, draft-thomson-tmi-02, 6 July 2021,
			<https://www.ietf.org/archive/id/draft-thomson-tmi-
			02.txt>.
	[I-D.wood-pearg-website-fingerprinting]		[I-D.wood-pearg-website-fingerprinting]
	Goldberg, I., Wang, T., and C. Wood, "Network-Based		Goldberg, I., Wang, T., and C. A. Wood, "Network-Based
	Website Fingerprinting", draft-wood-pearg-website-		Website Fingerprinting", Work in Progress, Internet-Draft,
	fingerprinting-00 (work in progress), November 2019.		draft-wood-pearg-website-fingerprinting-00, 4 November
			2019, <https://www.ietf.org/archive/id/draft-wood-pearg-
	[Kocher2019]		website-fingerprinting-00.txt>.
	Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D.,
	Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher,
	T., Schwarz, M., and Y. Yarom, "Spectre Attacks:
	Exploiting Speculative Execution", 40th IEEE Symposium on
	Security and Privacy (S&P'19) , 2019.
	[Leith2020]		[Leith2020]
	Leith, D., "Web Browser Privacy: What Do Browsers Say When		Leith, D., "Web Browser Privacy: What Do Browsers Say When
	They Phone Home?", In submission,		They Phone Home?", In submission,
	https://www.scss.tcd.ie/Doug.Leith/pubs/		https://www.scss.tcd.ie/Doug.Leith/pubs/
	browser_privacy.pdf , March 2020.		browser_privacy.pdf , March 2020.
	[Lipp2018]
	Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W.,
	Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D.,
	Yarom, Y., and M. Hamburg, "Meltdown: Reading Kernel
	Memory from User Space", 27th USENIX Security Symposium
	(USENIX Security 18) , 2018.
	[Mailbug] Englehardt, S., Han, J., and A. Narayanan, "I never signed
	up for this! Privacy implications of email tracking",
	Proceedings on Privacy Enhancing Technologies 2018.1
	(2018): 109-126, https://www.degruyter.com/downloadpdf/j/
	popets.2018.2018.issue-1/popets-2018-0006/
	popets-2018-0006.pdf , 2018.
	[MeltdownAndSpectre]		[MeltdownAndSpectre]
	CISA, ., "Meltdown and Spectre Side-Channel Vulnerability		CISA, ., "Meltdown and Spectre Side-Channel Vulnerability
	Guidance", Alert (TA18-004A),		Guidance", Alert (TA18-004A),
	https://www.us-cert.gov/ncas/alerts/TA18-004A , 2018.		https://www.us-cert.gov/ncas/alerts/TA18-004A , 2018.
	[Passwords]		[Passwords]
	com, haveibeenpwned., "Pwned Passwords", Website		com, haveibeenpwned., "Pwned Passwords", Website
	https://haveibeenpwned.com/Passwords , 2019.		https://haveibeenpwned.com/Passwords , 2019.
	[RFC1958] Carpenter, B., Ed., "Architectural Principles of the		[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
	skipping to change at page 19, line 23 ¶		skipping to change at page 15, line 25 ¶
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict		[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
	Transport Security (HSTS)", RFC 6797,		Transport Security (HSTS)", RFC 6797,
	DOI 10.17487/RFC6797, November 2012,		DOI 10.17487/RFC6797, November 2012,
	<https://www.rfc-editor.org/info/rfc6797>.		<https://www.rfc-editor.org/info/rfc6797>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.
	[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>.
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April		Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	2015, <https://www.rfc-editor.org/info/rfc7469>.		2015, <https://www.rfc-editor.org/info/rfc7469>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	skipping to change at page 20, line 5 ¶		skipping to change at page 15, line 48 ¶
	[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)		[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
	Server Identity Check Procedure for Email-Related		Server Identity Check Procedure for Email-Related
	Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,		Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
	<https://www.rfc-editor.org/info/rfc7817>.		<https://www.rfc-editor.org/info/rfc7817>.
	[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>.
	[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
	of Things Software Update (IoTSU) Workshop 2016",
	RFC 8240, DOI 10.17487/RFC8240, September 2017,
	<https://www.rfc-editor.org/info/rfc8240>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<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>.
	[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.		[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
	Kasten, "Automatic Certificate Management Environment		Kasten, "Automatic Certificate Management Environment
	(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,		(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
	<https://www.rfc-editor.org/info/rfc8555>.		<https://www.rfc-editor.org/info/rfc8555>.
	[Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments
	in System Design", ACM TOCS, Vol 2, Number 4, pp 277-288 ,
	November 1984.
	[Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes,
	Disclosures, and Outcomes", USENIX , 2016.
	[SmartTV] Malkin, N., Bernd, J., Johnson, M., and S. Egelman, "What		[SmartTV] Malkin, N., Bernd, J., Johnson, M., and S. Egelman, "What
	Can't Data Be Used For? Privacy Expectations about Smart		Can't Data Be Used For? Privacy Expectations about Smart
	TVs in the U.S.", European Workshop on Usable Security		TVs in the U.S.", European Workshop on Usable Security
	(Euro USEC), https://www.ndss-symposium.org/wp-		(Euro USEC), https://www.ndss-symposium.org/wp-
	content/uploads/2018/06/		content/uploads/2018/06/
	eurousec2018_16_Malkin_paper.pdf" , 2018.		eurousec2018_16_Malkin_paper.pdf" , 2018.
	[Sybil] Viswanath, B., Post, A., Gummadi, K., and A. Mislove, "An
	analysis of social network-based sybil defenses", ACM
	SIGCOMM Computer Communication Review 41(4), 363-374,
	https://conferences.sigcomm.org/sigcomm/2010/papers/
	sigcomm/p363.pdf , 2011.
	[TargetAttack]		[TargetAttack]
	Osborne, C., "How hackers stole millions of credit card		Osborne, C., "How hackers stole millions of credit card
	records from Target", ZDNET,		records from Target", ZDNET,
	https://www.zdnet.com/article/how-hackers-stole-millions-		https://www.zdnet.com/article/how-hackers-stole-millions-
	of-credit-card-records-from-target/ , 2014.		of-credit-card-records-from-target/ , 2014.
	[TinyChip]		[TinyChip] Robertson, J. and M. Riley, "The Big Hack: How China Used
	Robertson, J. and M. Riley, "The Big Hack: How China Used
	a Tiny Chip to Infiltrate U.S. Companies",		a Tiny Chip to Infiltrate U.S. Companies",
	https://www.bloomberg.com/news/features/2018-10-04/the-		https://www.bloomberg.com/news/features/2018-10-04/the-
	big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-		big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-
	s-top-companies , October 2018.		s-top-companies , October 2018.
	[Toys] Chu, G., Apthorpe, N., and N. Feamster, "Security and		[Tracking] Ermakova, T., Fabian, B., Bender, B., and K. Klimek, "Web
	Privacy Analyses of Internet of Things Childrens' Toys",
	IEEE Internet of Things Journal 6.1 (2019): 978-985,
	https://arxiv.org/pdf/1805.02751.pdf , 2019.
	[Tracking]
	Ermakova, T., Fabian, B., Bender, B., and K. Klimek, "Web
	Tracking-A Literature Review on the State of Research",		Tracking-A Literature Review on the State of Research",
	Proceedings of the 51st Hawaii International Conference on		Proceedings of the 51st Hawaii International Conference on
	System Sciences, https://scholarspace.manoa.hawaii.edu/		System Sciences, https://scholarspace.manoa.hawaii.edu/
	bitstream/10125/50485/paper0598.pdf , 2018.		bitstream/10125/50485/paper0598.pdf , 2018.
	[Troll] Stewart, L., Arif, A., and K. Starbird, "Examining trolls
	and polarization with a retweet network", ACM Workshop on
	Misinformation and Misbehavior Mining on the Web,
	https://faculty.washington.edu/kstarbi/
	examining-trolls-polarization.pdf , 2018.
	[Unread] Obar, J. and A. Oeldorf, "The biggest lie on the		[Unread] Obar, J. and A. Oeldorf, "The biggest lie on the
	internet{:} Ignoring the privacy policies and terms of		internet{:} Ignoring the privacy policies and terms of
	service policies of social networking services",		service policies of social networking services",
	Information, Communication and Society (2018): 1-20 ,		Information, Communication and Society (2018): 1-20 ,
	2018.		2018.
	[Vastaamo]
	Redcross Finland, ., "Read this if your personal data was
	leaked in the Vastaamo data system break-in",
	https://www.redcross.fi/news/20201029/read-if-your-
	personal-data-was-leaked-vastaamo-data-system-break ,
	October 2020.
	[Vpns] Khan, M., DeBlasio, J., Voelker, G., Snoeren, A., Kanich,
	C., and N. Vallina, "An empirical analysis of the
	commercial VPN ecosystem", ACM Internet Measurement
	Conference 2018 (pp. 443-456),
	https://eprints.networks.imdea.org/1886/1/
	imc18-final198.pdf , 2018.
	Appendix A. Contributors		Appendix A. Contributors
	Eric Rescorla and Chris Wood provided much of the text in		Eric Rescorla and Chris Wood provided much of the text in
	Section 2.3.5. Martin Thomson's excellent document [I-D.thomson-tmi]		Section 2.7. Martin Thomson's excellent document [I-D.thomson-tmi]
	also inspired some of the work in Section 3.		also inspired some of the work in Section 3.
	Appendix B. Acknowledgements		Earlier variations of this draft were produced in [I-D.farrell-etm]
			[I-D.arkko-arch-internet-threat-model]
	The authors would like to thank the IAB:		[I-D.arkko-farrell-arch-model-t]
			[I-D.arkko-farrell-arch-model-t-redux].
	Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin
	Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura,
	Martin Thomson, Brian Trammel, Mirja Kuhlewind, and Colin Perkins.
	The authors would also like to thank the participants of the IETF
	SAAG meeting where this topic was discussed:
	Harald Alvestrand, Roman Danyliw, Daniel Kahn Gilmore, Wes Hardaker,
	Bret Jordan, Ben Kaduk, Dominique Lazanski, Eliot Lear, Lawrence
	Lundblade, Kathleen Moriarty, Kirsty Paine, Eric Rescorla, Ali
	Rezaki, Mohit Sethi, Ben Schwartz, Dave Thaler, Paul Turner, David
	Waltemire, and Jeffrey Yaskin.
	The authors would also like to thank the participants of the IAB 2019
	DEDR workshop:
	Tuomas Aura, Vittorio Bertola, Carsten Bormann, Stephane Bortzmeyer,
	Alissa Cooper, Hannu Flinck, Carl Gahnberg, Phillip Hallam-Baker, Ted
	Hardie, Paul Hoffman, Christian Huitema, Geoff Huston, Konstantinos
	Komaitis, Mirja Kuhlewind, Dirk Kutscher, Zhenbin Li, Julien
	Maisonneuve, John Mattson, Moritz Muller, Joerg Ott, Lucas Pardue,
	Jim Reid, Jan-Frederik Rieckers, Mohit Sethi, Melinda Shore, Jonne
	Soininen, Andrew Sullivan, and Brian Trammell.
	The authors would also like to thank the participants of the November
	2016 meeting at the IETF:
	Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie,		There are also other documents discussing this overall space, e.g.
	Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric		[I-D.lazanski-smart-users-internet] [I-D.arkko-arch-dedr-report].
	Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and
	Robin Wilton ... (missing many people... did we have minutes other
	than the list of actions?) ...
	Thanks for specific comments on this text to: Ronald van der Pol.		Appendix B. Acknowledgements
	Finally, the authors would like to thank numerous other people for		The authors would like to thank the members of the IAB, the
	insightful comments and discussions in this space.		participants of the IETF SAAG meeting where this topic was discussed,
			the participants of the IAB 2019 DEDR workshop, and the participants
			of the Model-T meetings at the IETFs.
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Valitie 1B		Valitie 1B
	Kauniainen		FI- Kauniainen
	Finland		Finland
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
	Stephen Farrell		Stephen Farrell
	Trinity College Dublin		Trinity College Dublin
	College Green		College Green
	Dublin		Dublin
	Ireland		Ireland
End of changes. 86 change blocks.
	548 lines changed or deleted		282 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/