draft-arkko-farrell-arch-model-t-01.txt		draft-arkko-farrell-arch-model-t.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: June 17, 2020 Trinity College Dublin		Expires: 16 August 2020 Trinity College Dublin
	December 15, 2019		13 February 2020
	Challenges and Changes in the Internet Threat Model		Challenges and Changes in the Internet Threat Model
	draft-arkko-farrell-arch-model-t-01		draft-arkko-farrell-arch-model-t-pre-03
	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 threat model, while important		This memo suggests that the existing RFC 3552 threat model, while
	and still valid, is no longer alone sufficient to cater for the		important and still valid, is no longer alone sufficient to cater for
	pressing security issues in the Internet. For instance, it is also		the pressing security and privacy issues seen on the Internet today.
	necessary to protect systems against endpoints that are compromised,		For instance, it is often also necessary to protect against endpoints
	malicious, or whose interests simply do not align with the interests		that are compromised, malicious, or whose interests simply do not
	of the users. While such protection is difficult, there are some		align with the interests of users. While such protection is
	measures that can be taken.		difficult, there are some measures that can be taken and we argue
			that investigation of these issues is warranted.
	It is particularly important to ensure that as we continue to develop		It is particularly important to ensure that as we continue to develop
	Internet technology, non-communications security related threats, and		Internet technology, non-communications security related threats, and
	privacy issues, are properly understood.		privacy issues, are properly understood.
	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 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 June 17, 2020.		This Internet-Draft will expire on 16 August 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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/
	(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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Observations
	2.1. Communications Security Improvements . . . . . . . . . . 6		2.1. Communications Security Improvements
	2.2. Beyond Communications Security . . . . . . . . . . . . . 6		2.2. Beyond Communications Security
	2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9		2.3. Examples
	2.3.1. Deliberate adversarial behaviour in applications . . 9		2.3.1. Deliberate adversarial behaviour in
	2.3.2. Inadvertent adversarial behaviours . . . . . . . . . 13		applications
	3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 14		2.3.2. Inadvertent adversarial behaviours
	3.1. The Role of End-to-end . . . . . . . . . . . . . . . . . 14		3. Analysis
	3.2. Trusted networks . . . . . . . . . . . . . . . . . . . . 16		3.1. The Role of End-to-end
	3.2.1. Even closed networks can have compromised nodes . . . 17		3.2. Trusted networks
	3.3. Balancing Threats . . . . . . . . . . . . . . . . . . . . 18		3.2.1. Even closed networks can have compromised
	4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		nodes
	4.1. Basic Guidelines . . . . . . . . . . . . . . . . . . . . 19		3.3. Balancing Threats
	4.2. Potential Further Guidelines . . . . . . . . . . . . . . 21		4. Areas requiring more study
	4.2.1. Consider ABuse-cases as well as use-cases . . . . . . 21		5. Guidelines
	4.2.2. Isolation . . . . . . . . . . . . . . . . . . . . . . 21		6. Potential changes in BCP 72/RFC 3552
	4.2.3. Transparency . . . . . . . . . . . . . . . . . . . . 21		7. Potential Changes in BCP 188/RFC 7258
	4.2.4. Minimise . . . . . . . . . . . . . . . . . . . . . . 22		8. Conclusions
	4.2.5. Same-Origin Policy . . . . . . . . . . . . . . . . . 22		9. Informative References
	4.2.6. Greasing . . . . . . . . . . . . . . . . . . . . . . 22		Appendix A. Acknowledgements
	4.2.7. Generalise OAuth Threat Model . . . . . . . . . . . . 22		Authors' Addresses
	4.2.8. Look again at how well we're securing infrastructure 23
	4.2.9. Consider recovery from attack as part of protocol
	design . . . . . . . . . . . . . . . . . . . . . . . 23
	4.2.10. Don't think in terms of hosts . . . . . . . . . . . . 23
	4.2.11. Trusted Computing . . . . . . . . . . . . . . . . . . 24
	4.2.12. Trust Boundaries . . . . . . . . . . . . . . . . . . 24
	4.3. Does IETF Analysis of Protocols Need to Change? . . . . . 25
	4.3.1. Develop a BCP for privacy considerations . . . . . . 25
	4.3.2. Re-consider protocol design "lore" . . . . . . . . . 25
	4.3.3. Consider the user perspective . . . . . . . . . . . . 25
	4.3.4. Potential changes in RFC 3552 . . . . . . . . . . . . 25
	4.3.5. Potential Changes in RFC 7258 . . . . . . . . . . . . 26
	5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
	6. Informative References . . . . . . . . . . . . . . . . . . . 28
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	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 40		skipping to change at line 114
	possible to design protocols which minimize the extent of the		possible to design protocols which minimize the extent of the
	damage done under these circumstances.		damage done under these circumstances.
	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. This is due to three factors:		outdated. Some of the causes for this are:
	o Advances in protecting most of our communications with strong		* Success! Advances in protecting most of our communications with
	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		improvements are still needed. Not all communications have been
	protected, and even out of the already protected communications,		protected, and even out of the already protected communications,
	not all of their aspects have been fully protected. Fortunately,		not all of their aspects have been fully protected. Fortunately,
	there are ongoing projects working on improvements.		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 compromising devices to legal coercion of centralized		attack, from supply-channel attacks, to compromising devices to
	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.		privacy, more is needed, especially if endpoints choose to act
			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		In addition, trading information about users and ability to influence
	them has become a common practice for many Internet services, often		them has become a common practice for many Internet services, often
	without users understanding those practices.		without users understanding those practices.
	This memo suggests that the existing threat model, while important		This memo suggests that the existing threat model, while important
	and still valid, is no longer alone sufficient to cater for the		and still valid, is no longer alone sufficient to cater for the
	pressing security issues in the Internet. For instance, while it		pressing security and privacy issues on the Internet. For instance,
	continues to be very important to protect Internet communications		while it continues to be very important to protect Internet
	against outsiders, it is also necessary to protect systems against		communications against outsiders, it is also necessary to protect
	endpoints that are compromised, malicious, or whose interests simply		systems against endpoints that are compromised, malicious, or whose
	do not align with the interests of the users.		interests simply do not align with the interests of the users.
	Of course, there are many trade-offs in the Internet on who one		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		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		memo to dictate those choices. But it is important that we
	understand the implications of different practices. It is also		understand the implications of different practices. It is also
	important that when it comes to basic Internet infrastructure, our		important that when it comes to basic Internet infrastructure, our
	chosen technologies lead to minimal exposure with respect to the non-		chosen technologies lead to minimal exposure with respect to the non-
	communications threats.		communications threats.
	It is particularly important to ensure that non-communications		It is particularly important to ensure that non-communications
	skipping to change at page 5, line 4		skipping to change at line 175
	monitoring. Further down the road, updated threat models could		monitoring. Further down the road, updated threat models could
	result in changes in BCP 72 [RFC3552] (guidelines for writing		result in changes in BCP 72 [RFC3552] (guidelines for writing
	security considerations) and BCP 188 [RFC7258] (pervasive		security considerations) and BCP 188 [RFC7258] (pervasive
	monitoring), to include proper consideration of non-communications		monitoring), to include proper consideration of non-communications
	security threats.		security threats.
	It may also be necessary to have dedicated guidance on how systems		It may also be necessary to have dedicated guidance on how systems
	design and architecture affect security. The sole consideration of		design and architecture affect security. The sole consideration of
	communications security aspects in designing Internet protocols may		communications security aspects in designing Internet protocols may
	lead to accidental or increased impact of security issues elsewhere.		lead to accidental or increased impact of security issues elsewhere.
	For instance, allowing a participant to unnecessarily collect or		For instance, allowing a participant to unnecessarily collect or
	receive information may lead to a similar effect as described in		receive information may lead to a similar effect as described in
	[RFC8546] for protocols: over time, unnecessary information will get		[RFC8546] for protocols: over time, unnecessary information will get
	used with all the associated downsides, regardless of what deployment		used with all the associated downsides, regardless of what deployment
	expectations there were during protocol design.		expectations there were during protocol design.
	This memo does not stand alone. To begin with, it is a merge of		This memo does not stand alone. To begin with, it is a merge of
	earlier work by the two authors [I-D.farrell-etm]		earlier work by the two authors [I-D.farrell-etm] [I-D.arkko-arch-
	[I-D.arkko-arch-internet-threat-model]. There are also other		internet-threat-model]. There are also other documents discussing
	documents discussing this overall space, e.g.		this overall space, e.g. [I-D.lazanski-smart-users-internet] [I-
	[I-D.lazanski-smart-users-internet] [I-D.arkko-arch-dedr-report].		D.arkko-arch-dedr-report].
	The authors of this memo envisage independent development of each of		The authors of this memo envisage independent development of each of
	those (and other work) with an eventual goal to extract an updated		those (and other work) with an eventual goal to extract an updated
	(but usefully brief!) description of an extended threat model from		(but usefully brief!) description of an extended threat model from
	the collection of works. We consider it an open question whether		the collection of works. We consider it an open question whether
	this memo, or any of the others, would be usefully published as an		this memo, or any of the others, would be usefully published as an
	RFC.		RFC.
	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 situation, with respect to communications
	security and beyond. The section also provides a number of real-		security and beyond. The section also provides a number of real-
	world examples.		world examples.
	Section 3 discusses some high-level implications that can be drawn,		Section 3 discusses some high-level implications that can be drawn,
	such as the need to consider what the "ends" really are in an "end-		such as the need to consider what the "ends" really are in an "end-
	to-end" communication.		to-end" communication.
	Section 4 discusses some potential remedies, both from the point of		Section 4 lists some areas where additional work is required before
	view of a system design, as well as from the point of IETF procedures		we could feel confident in crafting guidelines, whereas Section 5
	and recommended analysis procedures when designing new protocols.		presents what we think are perhaps already credible potential
	For instance, Section 4.1 will also discuss high-level guidance to		guidelines - both from the point of view of a system design, as well
	addressing these threats, and Section 4.3.4 suggests some potential		as from the point of IETF procedures and recommended analysis
	changes to the definition of the IETF's "Internet Threat Model". It		procedures when designing new protocols. Section 6 and Section 7
	is also apparent that the dangers posed by pervasive monitoring need		tentatively suggest some changes to current IETF BCPs in this space.
	to be taken in a broader light, given the evolution of the threats
	beyond communications security.
	Comments are solicited on these and other aspects of this document.		Comments are solicited on these and other aspects of this document.
	The best place for discussion is on the arch-discuss list		The best place for discussion is on the model-t list.
	(https://www.ietf.org/mailman/listinfo/Architecture-discuss).		(https://www.ietf.org/mailman/listinfo/model-t)
	Finally, Section 5 draws some conclusions for next steps.		Finally, Section 8 draws some conclusions for next steps.
	2. Observations		2. Observations
	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
	cryptographically protected has grown tremendously in the last few		cryptographically protected has grown tremendously in the last few
	years. Several factors have contributed to this change, from Snowden		years. Several factors have contributed to this change, from Snowden
	revelations to business reasons and to better available technology		revelations to business reasons and to better available technology
	such as HTTP/2 [RFC7540], TLS 1.3 [RFC8446], QUIC		such as HTTP/2 [RFC7540], TLS 1.3 [RFC8446], QUIC [I-D.ietf-quic-
	[I-D.ietf-quic-transport].		transport].
	In many networks, the majority of traffic has flipped from being		In many networks, the majority of traffic has flipped from being
	cleartext to being encrypted. Reaching the level of (almost) all		cleartext to being encrypted. Reaching the level of (almost) all
	traffic being encrypted is no longer something unthinkable but rather		traffic being encrypted is no longer something unthinkable but rather
	a likely outcome in a few years.		a likely outcome in a few years.
	At the same time, technology developments and policy choices have		At the same time, technology developments and policy choices have
	driven the scope of cryptographic protection from protecting only the		driven the scope of cryptographic protection from protecting only the
	pure payload to protecting much of the rest as well, including far		pure payload to protecting much of the rest as well, including far
	more header and meta-data information than was protected before. For		more header and meta-data information than was protected before. For
	instance, efforts are ongoing in the IETF to assist encrypting		instance, efforts are ongoing in the IETF to assist encrypting
	transport headers [I-D.ietf-quic-transport], server domain name		transport headers [I-D.ietf-quic-transport], server domain name
	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-
	[I-D.ietf-httpbis-expect-ct].		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, however, significant issues beyond communications security
	in the Internet. To begin with, it is not necessarily clear that one		in the Internet. To begin with, it is not necessarily clear that one
	can trust all the endpoints in any protocol interaction.		can trust all the endpoints in any protocol interaction.
	Of course, the endpoints were never trusted, but the pressures		Of course, client endpoint implementations were never fully trusted,
	against endpoints issues seem to be mounting. For instance, the		but the environments in which those endpoints exist are changing.
	users may not be in as much control over their own devices as they		For instance, users may not have as much control over their own
	used to be due to manufacturer-controlled operating system		devices as they used to, due to manufacturer-controlled operating
	installations and locked device ecosystems. And within those		system installations and locked device ecosystems. And within those
	ecosystems, even the applications that are available tend to have		ecosystems, even the applications that are available tend to have
	privileges that users by themselves would most likely not desire		privileges that users by themselves might not desire those
	those applications have, such as excessive rights to media, location,		applications be granted, such as excessive rights to media, location,
	and peripherals. There are also designated efforts by various		and peripherals. There are also designated efforts by various
	authorities to hack end-user devices as a means of intercepting data		authorities to hack end-user devices as a means of intercepting data
	about the user.		about the user.
	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. The pattern of communications in today's Internet is almost		servers. The pattern of communications in today's Internet is almost
	always via a third party that has at least as much information as the		always via a third party that has at least as much information as the
	other parties have. For instance, these third parties are typically		other parties have. For instance, these third parties are typically
	endpoints for any transport layer security connections, and able to		endpoints for any transport layer security connections, and able to
	see any 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 protection.		end confidentiality protection.
	With the growth of trading users' information by many of these third		With the growth of trading users' information by many of these third
	parties, it becomes necessary to take precautions against endpoints		parties, it becomes necessary to take precautions against endpoints
	that are compromised, malicious, or whose interests simply do not		that are compromised, malicious, or whose interests simply do not
	align with the interests of the users.		align with the interests of the users.
	Specifically, the following issues need attention:		Specifically, the following issues need attention:
	o Security of users' devices and the ability of the user to control		* Security of users' devices and the ability of the user to control
	their own equipment.		their own equipment.
	o Leaks and attacks related to data at rest.		* Leaks and attacks related to data at rest.
	o Coercion of some endpoints to reveal information to authorities or		* Coercion of some endpoints to reveal information to authorities or
	surveillance organizations, sometimes even in an extra-territorial		surveillance organizations, sometimes even in an extra-territorial
	fashion.		fashion.
	o Application design patterns that result in cleartext information		* Application design patterns that result in cleartext information
	passing through a third party or the application owner.		passing through a third party or the application owner.
	o Involvement of entities that have no direct need for involvement		* Involvement of entities that have no direct need for involvement
	for the sake of providing the service that the user is after.		for the sake of providing the service that the user is after.
	o Network and application architectures that result in a lot of		* Network and application architectures that result in a lot of
	information collected in a (logically) central location.		information collected in a (logically) central location.
	o Leverage and control points outside the hands of the users or end-		* Leverage and control points outside the hands of the users or end-
	user device owners.		user device owners.
	For instance, while e-mail transport security [RFC7817] has become		For instance, while e-mail transport security [RFC7817] has become
	much more widely distributed in recent years, progress in securing		much more widely deployed in recent years, progress in securing
	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 sercurity protocols).		(with today's end-to-end mail security protocols) and there are many
			significant challenges should one desire to deploy end-to-end email
			security at scale.
	The Domain Name System (DNS) shows signs of ageing but due to the		The Domain Name System (DNS) shows signs of ageing but due to the
	legacy of deployed systems has changed very slowly. Newer technology		legacy of deployed systems has changed very slowly. Newer technology
	[RFC8484] developed at the IETF enables DNS queries to be performed		[RFC8484] developed at the IETF enables DNS queries to be performed
	confidentially, but its initial deployment is happening mostly in		with confidentiality and authentication (of a recursive resolver),
	browsers that use global DNS resolver services, such as Cloudflare's		but its initial deployment is happening mostly in browsers that use
	1.1.1.1 or Google's 8.8.8.8. This results in faster evolution and		global DNS resolver services, such as Cloudflare's 1.1.1.1 or
	better security for end users.		Google's 8.8.8.8. This results in faster evolution and better
			security for end users.
	However, if one steps back and considers the potential security and		However, if one steps back and considers the potential security and
	privacy effects of these developments, the outcome could appear		privacy effects of these developments, the outcome could appear
	different. While the security and confidentiality of the protocol		different. While the security and confidentiality of the protocol
	exchanges improves with the introduction of this new technology, at		exchanges improves with the introduction of this new technology, at
	the same time this could lead to a move from using a worldwide		the same time this could lead to a move from using (what appears to
	distributed set of DNS resolvers into a far smaller set of		be) a large worldwide distributed set of DNS resolvers into a far
	centralised global resolvers. While these resolvers are very well		smaller set of centralised global resolvers. While these resolvers
	maintained (and a great service), they are potential high-value		are very well maintained (and a great service), they are potential
	targets for pervasive monitoring and Denial-of-Service (DoS) attacks.		high-value targets for pervasive monitoring and Denial-of-Service
	In 2016, for example, DoS attacks were launched against Dyn, one of		(DoS) attacks. In 2016, for example, DoS attacks were launched
	the largest DNS providers, leading to some outages. It is difficult		against Dyn, [DynDDoS] then one of the largest DNS providers, leading
	to imagine that DNS resolvers wouldn't be a target in many future		to some outages. It is difficult to imagine that DNS resolvers
	attacks or pervasive monitoring projects.		wouldn't be a target in many future attacks or pervasive monitoring
			projects.
	Unfortunately, there is little that even large service providers can		Unfortunately, there is little that even large service providers can
	do to not be a DDoS target, not to refuse authority-sanctioned		do to not be a DDoS target, (though anycast and other DDoS
	pervasive monitoring. As a result it seems that a reasonable defense		mitigations can certainly help when one is targeted), nor to refuse
	strategy may be to aim for outcomes where such highly centralised		authority-sanctioned pervasive monitoring. As a result it seems that
	control points are unecessary or don't handle sensitive data.		a reasonable defense strategy may be to aim for outcomes where such
	(Recalling that with the DNS, information about the requestor and the		highly centralised control points are unnecessary or don't handle
	act of requesting an answer are what is potentially sensitive, rather		sensitive data. (Recalling that with the DNS, meta-data about the
	than the content of the answer.)		requestor and the act of requesting an answer are what is potentially
			sensitive, rather than the content of the answer.)
	There are other examples of the perils of centralised solutions in		There are other examples of the perils of centralised solutions in
	Internet infrastructure. The DNS example involves an interesting		Internet infrastructure. The DNS example involves an interesting
	combination of information flows (who is asking for what domain		combination of information flows (who is asking for what domain
	names) as well as a potential ability to exert control (what domains		names) as well as a potential ability to exert control (what domains
	will actually resolve to an address). Routing systems are primarily		will actually resolve to an address). Routing systems are primarily
	about control. While there are intra-domain centralized routing		about control. While there are intra-domain centralized routing
	solutions (such as PCE [RFC4655]), a control within a single		solutions (such as PCE [RFC4655]), a control within a single
	administrative domain is usually not the kind of centralization that		administrative domain is usually not the kind of centralization that
	we would be worried about. Global centralization would be much more		we would be worried about. Global centralization would be much more
	concerning. Fortunately, global Internet routing is performed a		concerning. Fortunately, global Internet routing is performed among
	among peers. However, controls could be introduced even in this		peers. However, controls could be introduced even in this global,
	global, distributed system. To secure some of the control exchanges,		distributed system. To secure some of the control exchanges, the
	the Resource Public Key Infrastructure (RPKI) system ([RFC6480])		Resource Public Key Infrastructure (RPKI) system ([RFC6480]) allows
	allows selected Certification Authorities (CAs) to help drive		selected Certification Authorities (CAs) to help drive decisions
	decisions about which participants in the routing infrastructure can		about which participants in the routing infrastructure can make what
	make what claims. If this system were globally centralized, it would		claims. If this system were globally centralized, it would be a
	be a concern, but again, fortunately, current designs involve at		concern, but again, fortunately, current designs involve at least
	least regional distribution.		regional distribution.
	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. Examples		2.3. Examples
	2.3.1. Deliberate adversarial behaviour in applications		2.3.1. Deliberate adversarial behaviour in applications
	In this section we describe a few documented examples of deliberate		In this section we describe some documented examples of deliberate
	adversarial behaviour by applications that could affect Internet		adversarial behaviour by applications that could affect Internet
	protocol development. The adversarial behaviours described below		protocol development. The adversarial behaviours described below
	involve various kinds of attack, varying from simple fraud, to		involve various kinds of attack, varying from simple fraud, to
	credential theft, surveillance and contributing to DDoS attacks.		credential theft, surveillance and contributing to DDoS attacks.
	This is not intended to be a comprehensive nor complete survey, but		This is not intended to be a comprehensive nor complete survey, but
	to motivate us to consider deliberate adversarial behaviour by		to motivate us to consider deliberate adversarial behaviour by
	applications.		applications.
	While we have these examples of deliberate adversarial behaviour,		While we have these examples of deliberate adversarial behaviour,
	there are also many examples of application developers doing their		there are also many examples of application developers doing their
	skipping to change at page 9, line 51		skipping to change at line 413
	network operators who do act primarily in the best interests of their		network operators who do act primarily in the best interests of their
	users.		users.
	2.3.1.1. Malware in curated application stores		2.3.1.1. Malware in curated application stores
	Despite the best efforts of curators, so-called App-Stores frequently		Despite the best efforts of curators, so-called App-Stores frequently
	distribute malware of many kinds and one recent study [Curated]		distribute malware of many kinds and one recent study [Curated]
	claims that simple obfuscation enables malware to avoid detection by		claims that simple obfuscation enables malware to avoid detection by
	even sophisticated operators. Given the scale of these deployments,		even sophisticated operators. Given the scale of these deployments,
	distribution of even a small percentage of malware-infected		distribution of even a small percentage of malware-infected
	applictions can affect a huge number of people.		applications can affect a huge number of people.
	2.3.1.2. Virtual private networks (VPNs)		2.3.1.2. Virtual private networks (VPNs)
	Virtual private networks (VPNs) are supposed to hide user traffic to		Virtual private networks (VPNs) are supposed to hide user traffic to
	various degrees depending on the particular technology chosen by the		various degrees depending on the particular technology chosen by the
	VPN provider. However, not all VPNs do what they say, some for		VPN provider. However, not all VPNs do what they say, some for
	example misrepresenting the countries in which they provide vantage		example misrepresenting the countries in which they provide vantage
	points [Vpns].		points [Vpns].
	2.3.1.3. Compromised (home) networks		2.3.1.3. Compromised (home) networks
	skipping to change at page 12, line 18		skipping to change at line 525
	of Things" as all devices were already things:-) have been found		of Things" as all devices were already things:-) have been found
	deficient when their security and privacy aspects were analysed, for		deficient when their security and privacy aspects were analysed, for
	example children's toys [Toys]. While in some cases this may be due		example children's toys [Toys]. While in some cases this may be due
	to incompetence rather than being deliberately adversarial behaviour,		to incompetence rather than being deliberately adversarial behaviour,
	the levels of incompetence frequently seen imply these aspects have		the levels of incompetence frequently seen imply these aspects have
	simply not been considered a priority.		simply not been considered a priority.
	2.3.1.10. Attacks leveraging compromised high-level DNS infrastructure		2.3.1.10. Attacks leveraging compromised high-level DNS infrastructure
	Recent attacks [DeepDive] against DNS infrastructure enable		Recent attacks [DeepDive] against DNS infrastructure enable
	subsequent targetted attacks on specific application layer sources or		subsequent targeted attacks on specific application layer sources or
	destinations. The general method appears to be to attack DNS		destinations. The general method appears to be to attack DNS
	infrastructure, in these cases infrastructure that is towards the top		infrastructure, in these cases infrastructure that is towards the top
	of the DNS naming hierarchy and "far" from the presumed targets, in		of the DNS naming hierarchy and "far" from the presumed targets, in
	order to be able to fake DNS responses to a PKI, thereby acquiring		order to be able to fake DNS responses to a PKI, thereby acquiring
	TLS server certificates so as to subsequently attack TLS connections		TLS server certificates so as to subsequently attack TLS connections
	from clients to services (with clients directed to an attacker-owned		from clients to services (with clients directed to an attacker-owned
	server via additional fake DNS responses).		server via additional fake DNS responses).
	Attackers in these cases seem well resourced and patient - with		Attackers in these cases seem well resourced and patient - with
	"practice" runs over months and with attack durations being		"practice" runs over months and with attack durations being
	skipping to change at page 13, line 27		skipping to change at line 583
	currently most important security protocol (TLS).		currently most important security protocol (TLS).
	2.3.1.11. BGP hijacking		2.3.1.11. BGP hijacking
	There is a clear history of BGP hijacking [BgpHijack] being used to		There is a clear history of BGP hijacking [BgpHijack] being used to
	ensure endpoints connect to adversarial applications. As in the		ensure endpoints connect to adversarial applications. As in the
	previous example, such hijacks can be used to trick a PKI into		previous example, such hijacks can be used to trick a PKI into
	issuing a certificate for a fake entity. Indeed one study		issuing a certificate for a fake entity. Indeed one study
	[HijackDet] used the emergence of new web server TLS key pairs during		[HijackDet] used the emergence of new web server TLS key pairs during
	the event, (detected via Internet-wide scans), as a distinguisher		the event, (detected via Internet-wide scans), as a distinguisher
	between one form of deliberate BGP hijacking and indadvertent route		between one form of deliberate BGP hijacking and inadvertent route
	leaks.		leaks.
			2.3.1.12. Anti-virus vendor selling user clickstream data
			An anti-virus product vendor was feeding user clickstream data to a
			subsidiary that then sold on supposedly "anonymised" but highly
			detailed data to unrelated parties. [avleak] After browser makers
			had removed that vendor's browser extension from their online stores,
			the anti-virus product itself apparently took over data collection
			initially only offering users an opt-out, with the result that
			apparently few users were even aware of the data collection, never
			mind the subsequent clickstream sales. Very shortly after
			publication of [avleak], the anti-virus vendor announced they were
			closing down the subsidiary.
	2.3.2. Inadvertent adversarial behaviours		2.3.2. Inadvertent adversarial behaviours
	Not all adversarial behaviour by applications is deliberate, some is		Not all adversarial behaviour by applications is deliberate, some is
	likely due to various levels of carelessness (some quite		likely due to various levels of carelessness (some quite
	understandable, others not) and/or due to erroneous assumptions about		understandable, others not) and/or due to erroneous assumptions about
	the environments in which those applications (now) run.		the environments in which those applications (now) run.
	We very briefly list some such cases:		We very briefly list some such cases:
	o Application abuse for command and control, for example, use of IRC		* Application abuse for command and control, for example, use of IRC
	or apache logs for [CommandAndControl]		or apache logs for [CommandAndControl]
	o Carelessly leaky data stores [LeakyBuckets], for example, lots of		* Carelessly leaky data stores [LeakyBuckets], for example, lots of
	Amazon S3 leaks showing that careless admins can too easily cause		Amazon S3 leaks showing that careless admins can too easily cause
	application server data to become available to adversaries		application server data to become available to adversaries
	o Virtualisation exposing secrets, for example, Meltdown and Spectre		* Virtualisation exposing secrets, for example, Meltdown and Spectre
	[MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar		[MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar
	side-channel attacks.		side-channel attacks.
	o Compromised badly-maintained web sites, that for example, have led		* Compromised badly-maintained web sites, that for example, have led
	to massive online [Passwords].		to massive online [Passwords].
	o Supply-chain attacks, for example, the [TargetAttack] or malware		* Supply-chain attacks, for example, the [TargetAttack] or malware
	within pre-installed applications on Android phones [Bloatware].		within pre-installed applications on Android phones [Bloatware].
	o Breaches of major service providers, that many of us might have		* Breaches of major service providers, that many of us might have
	assumed would be sufficiently capable to be the best large-scale		assumed would be sufficiently capable to be the best large-scale
	"Identity providers", for example:		"Identity providers", for example:
	* 3 billion accounts: https://www.wired.com/story/yahoo-breach-		- 3 billion accounts: https://www.wired.com/story/yahoo-breach-
	three-billion-accounts/		three-billion-accounts/
	* "up to 600M" account passwords stored in clear:		- "up to 600M" account passwords stored in clear:
	https://www.pcmag.com/news/367319/facebook-stored-up-to-600m-		https://www.pcmag.com/news/367319/facebook-stored-up-to-600m-
	user-passwords-in-plain-text		user-passwords-in-plain-text
	* many millions at risk: https://www.zdnet.com/article/us-telcos-		- many millions at risk: https://www.zdnet.com/article/us-telcos-
	caught-selling-your-location-data-again-senator-demands-new-		caught-selling-your-location-data-again-senator-demands-new-
	laws/		laws/
	* 50 million accounts: https://www.cnet.com/news/facebook-breach-		- 50 million accounts: https://www.cnet.com/news/facebook-breach-
	affected-50-million-people/		affected-50-million-people/
	* 14 million accounts: https://www.zdnet.com/article/millions-		- 14 million accounts: https://www.zdnet.com/article/millions-
	verizon-customer-records-israeli-data/		verizon-customer-records-israeli-data/
	* "hundreds of thousands" of accounts:		- "hundreds of thousands" of accounts:
	https://www.wsj.com/articles/google-exposed-user-data-feared-		https://www.wsj.com/articles/google-exposed-user-data-feared-
	repercussions-of-disclosing-to-public-1539017194		repercussions-of-disclosing-to-public-1539017194
	* unknown numbers, some email content exposed:		- unknown numbers, some email content exposed:
	https://motherboard.vice.com/en_us/article/ywyz3x/hackers-		https://motherboard.vice.com/en_us/article/ywyz3x/hackers-
	could-read-your-hotmail-msn-outlook-microsoft-customer-support		could-read-your-hotmail-msn-outlook-microsoft-customer-support
	o Breaches of smaller service providers: Too many to enumerate,		* Breaches of smaller service providers: Too many to enumerate,
	sadly		sadly
	3. Analysis		3. Analysis
	3.1. The Role of End-to-end		3.1. The Role of End-to-end
	[RFC1958] notes that "end-to-end functions can best be realised by		[RFC1958] notes that "end-to-end functions can best be realised by
	end-to-end protocols":		end-to-end protocols":
	The basic argument is that, as a first principle, certain required		The basic argument is that, as a first principle, certain required
	skipping to change at page 18, line 33		skipping to change at line 842
	proprietary programs, firmware, or even innocent-looking components		proprietary programs, firmware, or even innocent-looking components
	on a circuit board can be suspect. In addition, complex underlying		on a circuit board can be suspect. In addition, complex underlying
	computing platforms, such as modern CPUs with underlying security and		computing platforms, such as modern CPUs with underlying security and
	management tools are prone to problems.		management tools are prone to problems.
	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. Analysis for		system where you picked all the components yourself. Analysis for
	the security of many interesting real-world systems now commonly		the security of many interesting real-world systems now commonly
	needs to include cross-component attacks, e.g., the use of car radios		needs to include cross-component attacks, e.g., the use of car radios
	and other externally communicating devices as part of attacks		and other externally communicating devices as part of attacks
	launched against the control components such as breaks in a car		launched against the control components such as brakes in a car
	[Savage].		[Savage].
	3.3. Balancing Threats		3.3. Balancing Threats
	Note that not all information needs to be protected, and not all		Note that not all information needs to be protected, and not all
	threats can be protected against. But it is important that the main		threats can be protected against. But it is important that the main
	threats are understood and protected against.		threats are understood and protected against.
	Sometimes there are higher-level mechanisms that provide safeguards		Sometimes there are higher-level mechanisms that provide safeguards
	for failures. For instance, it is very difficult in general to		for failures. For instance, it is very difficult in general to
	skipping to change at page 19, line 8		skipping to change at line 866
	Another example is from packet-carrying networks. Payload traffic		Another example is from packet-carrying networks. Payload traffic
	that has been properly protected with encryption does not provide		that has been properly protected with encryption does not provide
	much value to an attacker. For instance, it does not always make		much value to an attacker. For instance, it does not always make
	sense to encrypt every packet transmission in a packet-carrying		sense to encrypt every packet transmission in a packet-carrying
	system where the traffic is already encrypted at other layers. But		system where the traffic is already encrypted at other layers. But
	it almost always makes sense to protect control communications and to		it almost always makes sense to protect control communications and to
	understand the impacts of compromised nodes, particularly control		understand the impacts of compromised nodes, particularly control
	nodes.		nodes.
	4. Actions		4. Areas requiring more study
	This section discusses potential actions to be taken by the Internet
	community:
	4.1. Basic Guidelines
	As [RFC3935] says:
	We embrace technical concepts such as decentralized control, edge-
	user empowerment and sharing of resources, because those concepts
	resonate with the core values of the IETF community.
	To be more specific, this memo suggests the following guidelines for
	protocol designers:
	1. Consider first principles in protecting information and systems,
	rather than following a specific pattern such as protecting
	information in a particular way or at a particular protocol
	layer. It is necessary to understand what components can be
	compromised, where interests may or may not be aligned, and what
	parties have a legitimate role in being a party to a specific
	information or a control task.
	2. Once you have something, do not pass it onto others without
	serious consideration: In other words, minimize information
	passed to others. Information passed to another party in a
	protocol exchange should be minimized to guard against the
	potential compromise of that party.
	3. Perform end-to-end protection via other parties: Information
	passed via another party who does not intrinsically need the
	information to perform its function should be protected end-to-
	end to its intended recipient. This guideline is general, and
	holds equally for sending TCP/IP packets, TLS connections, or
	application-layer interactions. As [RFC8546] notes, it is a
	useful design rule to avoid "accidental invariance" (the
	deployment of on-path devices that over-time start to make
	assumptions about protocols). However, it is also a necessary
	security design rule to avoid "accidental disclosure" where
	information originally thought to be benign and untapped over-
	time becomes a significant information leak. This guideline can
	also be applied for different aspects of security, e.g.,
	confidentiality and integrity protection, depending on what the
	specific need for information is in the other parties.
	4. Minimize passing of control functions to others: Any passing of
	control functions to other parties should be minimized to guard
	against the potential misuse of those control functions. This
	applies to both technical (e.g., nodes that assign resources) and
	process control functions (e.g., the ability to allocate number
	or develop extensions). Control functions can also become a
	matter of contest and power struggle, even in cases where their
	function as such is minimal, as we saw with the IANA transition
	debates.
	5. Avoid centralized resources: While centralized components,
	resources, and function provide usually a useful function, there
	are grave issues associated with them. Protocol and network
	design should balance the benefits of centralized resources or
	control points against the threats arising from them. The
	general guideline is to avoid such centralized resources when
	possible. And if it is not possible, find a way to allow the
	centralized resources to be selectable, depending on context and
	user settings.
	6. Have explicit agreements: When users and their devices provide
	information to network entities, it would be beneficial to have
	an opportunity for the users to state their requirements
	regarding the use of the information provided in this way. While
	the actual use of such requirements and the willingness of
	network entities to agree to them remains to be seen, at the
	moment even the technical means of doing this are limited. For
	instance, it would be beneficial to be able to embed usage
	requirements within popular data formats.
	7. Treat parties that your equipment connects to with suspicion,
	even if the communications are encrypted. The other endpoint may
	misuse any information or control opportunity in the
	communication. Similarly, even parties within your own system
	need to be treated with suspicision, as some nodes may become
	compromised.
	8. Do not take any of this as blanket reason to provide no
	information to anyone, encrypt everything to everyone, or other
	extreme measures. However, the designers of a system need to be
	aware of the different threats facing their system, and deal with
	the most serious ones (of which there are typically many).
	Similarly, users should be aware of the choices made in a
	particular design, and avoid designs or products that protect
	against some threats but are wide open to other serious issues.
	4.2. Potential Further Guidelines
	4.2.1. Consider ABuse-cases as well as use-cases
	Protocol developers and those implementing and deploying Internet
	technologies are typically most interested in a few specific use-
	cases for which they need solutions. Expanding our threat model to
	include adversarial application behaviours [AbuseCases] seems likely
	to call for significant attention to be paid to potential abuses of
	whatever new or re-purposed technology is being considered.
	4.2.2. Isolation		In addition to the guidelines in (Section 5), we suggest there may be
			value in further study on the topics below, with the goal of
			producing more concrete guidelines.
	Sophisticated users can sometimes deal with adversarial behaviours in		1. Isolation: Sophisticated users can sometimes deal with
	applications by using different instances of those applications, for		adversarial behaviours in applications by using different
	example, differently configured web browsers for use in different		instances of those applications, for example, differently
	contexts. Applications (including web browsers) and operating		configured web browsers for use in different contexts.
	systems are also building in isolation via use of different processes		Applications (including web browsers) and operating systems are
	or sandboxing. Protocol artefacts that relate to uses of such		also building in isolation via use of different processes or
	isolation mechanisms might be worth considering. To an extent, the		sandboxing. Protocol artefacts that relate to uses of such
	IETF has in practice already recognised some of these issues as being		isolation mechanisms might be worth considering. To an extent,
	in-scope, e.g. when considering the linkability issues with		the IETF has in practice already recognised some of these issues
	mechanisms such as TLS session tickets, or QUIC connection		as being in-scope, e.g. when considering the linkability issues
			with mechanisms such as TLS session tickets, or QUIC connection
	identifiers.		identifiers.
	4.2.3. Transparency		2. Transparency: Certificate transparency (CT) [RFC6962] has been
			an effective countermeasure for X.509 certificate mis-issuance,
	Certificate transparency (CT) [RFC6962] has been an effective		which used be a known application layer misbehaviour in the
	countermeasure for X.509 certificate mis-issuance, which used be a		public web PKI. CT can also help with post-facto detection of
	known application layer misbehaviour in the public web PKI. CT can		some infrastructure attacks where BGP or DNS weaknesses have
	also help with post-facto detection of some infrastructure attacks		been leveraged so that some certification authority is tricked
	where BGP or DNS weakenesses have been leveraged so that some		into issuing a certificate for the wrong entity. While the
	certification authority is tricked into issuing a certificate for the		context in which CT operates is very constrained (essentially to
	wrong entity.		the public CAs trusted by web browsers), similar approaches
			could perhaps be useful for other protocols or technologies. In
	While the context in which CT operates is very constrained		addition, legislative requirements such as those imposed by the
	(essentially to the public CAs trusted by web browsers), similar
	approaches could perhaps be useful for other protocols or
	technologies.
	In addition, legislative requirements such as those imposed by the
	GDPR [GDPRAccess] could lead to a desire to handle internal data		GDPR [GDPRAccess] could lead to a desire to handle internal data
	structures and databases in ways that are reminiscent of CT, though		structures and databases in ways that are reminiscent of CT,
	clearly with significant authorisation being required and without the		though clearly with significant authorisation being required and
	append-only nature of a CT log.		without the append-only nature of a CT log.
	4.2.4. Minimise		3. Same-Origin Policy: The Same-Origin Policy (SOP) [RFC6454]
			perhaps already provides an example of how going beyond the RFC
			3552 threat model can be useful. Arguably, the existence of the
			SOP demonstrates that at least web browsers already consider the
			3552 model as being too limited. (Clearly, differentiating
			between same and not-same origins implicitly assumes that some
			origins are not as trustworthy as others.)
	As recommended in [RFC6973] data minimisation and additional		4. Greasing: The TLS protocol [RFC8446] now supports the use of
	encryption are likely to be helpful - if applications don't ever see		GREASE [I-D.ietf-tls-grease] as a way to mitigate on-path
	data, or a cleartext form of data, then they should have a harder		ossification. While this technique is not likely to prevent any
	time misbehaving. Similarly, not adding new long-term identifiers,		deliberate misbehaviours, it may provide a proof-of-concept that
	and not exposing existing ones, would seem helpful.		network protocol mechanisms can have impact in this space, if we
			spend the time to try analyse the incentives of the various
			parties.
	4.2.5. Same-Origin Policy		5. Generalise OAuth Threat Model: The OAuth threat model [RFC6819]
			provides an extensive list of threats and security
			considerations for those implementing and deploying OAuth
			version 2.0 [RFC6749]. It could be useful to attempt to derive
			a more abstract threat model from that RFC that considers
			threats in more generic multi-party contexts. That document is
			perhaps too detailed to serve as useful generic guidance but
			does go beyond the Internet threat model from RFC3552, for
			example it says:
	The Same-Origin Policy (SOP) [RFC6454] perhaps already provides an		two of the three parties involved in the OAuth protocol may
	example of how going beyond the RFC 3552 threat model can be useful.		collude to mount an attack against the 3rd party. For
	Arguably, the existence of the SOP demonstrates that at least web		example, the client and authorization server may be under
	browsers already consider the 3552 model as being too limited.		control of an attacker and collude to trick a user to gain
	(Clearly, differentiating between same and not-same origins		access to resources.
	implicitly assumes that some origins are not as trustworthy as
	others.)
	4.2.6. Greasing		6. Look again at how well we're securing infrastructure: Some
			attacks (e.g. against DNS or routing infrastructure) appear to
			benefit from current infrastructure mechanisms not being
			deployed, e.g. DNSSEC, RPKI. In the case of DNSSEC, deployment
			is still minimal despite much time having elapsed. This
			suggests a number of different possible avenues for
			investigation:
	The TLS protocol [RFC8446] now supports the use of GREASE		* For any protocol dependent on infrastructure like DNS or BGP,
	[I-D.ietf-tls-grease] as a way to mitigate on-path ossification.		we ought analyse potential outcomes in the event the relevant
	While this technique is not likely to prevent any deliberate		infrastructure has been compromised
	misbehaviours, it may provide a proof-of-concept that network
	protocol mechanisms can have impact in this space, if we spend the
	time to try analyse the incentives of the various parties.
	4.2.7. Generalise OAuth Threat Model		* Protocol designers perhaps ought consider post-facto
			detection compromise mechanisms in the event that it is
			infeasible to mitigate attacks on infrastructure that is not
			under local control
	The OAuth threat model [RFC6819] provides an extensive list of		* Despite the sunk costs, it may be worth re-considering
	threats and security considerations for those implementing and		infrastructure security mechanisms that have not been
	deploying OAuth version 2.0 [RFC6749]. That document is perhaps too		deployed, and hence are ineffective.
	detailed to serve as useful generic guidance but does go beyond the
	Internet threat model from RFC3552, for example it says:
	two of the three parties involved in the OAuth protocol may		7. Trusted Computing: Various trusted computing mechanisms allow
	collude to mount an attack against the 3rd party. For example,		placing some additional trust on a particular endpoint. This
	the client and authorization server may be under control of an		can be useful to address some of the issues in this memo:
	attacker and collude to trick a user to gain access to resources.
	It could be useful to attempt to derive a more abstract threat model		* A network manager of a set of devices may be assured that the
	from that RFC that considers threats in more generic multi-party		devices have not been compromised.
	contexts.
	4.2.8. Look again at how well we're securing infrastructure		* An outside party may be assured that someone who runs a
			device employs a particular software installation in that
			device, and that the software runs in a protected
			environment.
	Some attacks (e.g. against DNS or routing infrastructure) appear to		IETF work such as TEEP [I-D.ietf-teep-architecture] [I-D.ietf-
	benefit from current infrastructure mechanisms not being deployed,		teep-protocol] and RATS [I-D.ietf-rats-eat] may be helpful in
	e.g. DNSSEC, RPKI. In the case of DNSSEC, deployment is still		providing attestations to other nodes about a particular
	minimal despite much time having elapsed. This suggests a number of		endpoint, or lifecycle management of such endpoints.
	different possible avenues for investigation:
	o For any protocol dependent on infrastructure like DNS or BGP, we		One should note, however, that it is often not possible to fully
	ought analysse potential outcomes in the event the relevant		protect endpoints (see, e.g., [Kocher2019] [Lipp2018] [I-
	infrastructure has been compromised		D.taddei-smart-cless-introduction] [I-D.mcfadden-smart-endpoint-
			taxonomy-for-cless]). And of course, a trusted computing may be
			set up and controlled by a party that itself is not trusted; a
			client that contacts a server that the server's owner runs in a
			trusted computing setting does not change the fact that the
			client and the server's owner may have different interests. As
			a result, there is a need to prepare for the possibility that
			another party in a communication is not entirely trusted.
	o Protocol designers perhaps ought consider post-facto detection		8. Trust Boundaries: Traditional forms of communication equipment
	compromise mechanisms in the event that it is infeasible to		have morphed into today's virtualized environments, where new
	mitigate attacks on infrastructure that is not under local control		trust boundaries exist, e.g., between different virtualisation
			layers. And an application might consider itself trusted while
			not entirely trusting the underlying operating system. A
			browser application wants to protect itself against Javascript
			loaded from a website, while the website considers itself and
			the Javascript an application that it wants to protect from the
			browser. In general, there are multiple parties even in a
			single device, with differing interests, including some that
			have (or claim to) the interest of the human user in mind.
	o Despite the sunk costs, it may be worth re-considering		9. Develop a BCP for privacy considerations: It may be time for the
	infrastructure security mechanisms that have not been deployed,		IETF to develop a BCP for privacy considerations, possibly
	and hence are ineffective.		starting from [RFC6973].
	4.2.9. Consider recovery from attack as part of protocol design		10. Re-consider protocol design "lore": It could be that this
			discussion demonstrates that it is timely to reconsider some
			protocol design "lore" as for example is done in [I-D.iab-
			protocol-maintenance]. More specifically, protocol
			extensibility mechanisms may inadvertently create vectors for
			abuse-cases, given that designers cannot fully analyse their
			impact at the time a new protocol is defined or standardised.
			One might conclude that a lack of extensibility could be a
			virtue for some new protocols, in contrast to earlier
			assumptions. As pointed out by one commenter though, people can
			find ways to extend things regardless, if they feel the need.
	Recent work on multiparty messaging security primitives		11. Consider the user perspective: [I-D.nottingham-for-the-users]
	[I-D.ietf-mls-architecture] considers "post-compromise security" as		argues that, in relevant cases where there are conflicting
	an inherent part of the design of that protocol. Perhaps protocol		requirements, the "IETF considers end users as its highest
	designers ought generally consider recovery from attack during		priority concern." Doing so seems consistent with the expanded
	protocol design - we do know that all widely used protocols will at		threat model being argued for here, so may indicate that a BCP
	sometime be subject to successful attack, whether that is due to		in that space could also be useful.
	deployment or implementation error, or, as is less common, due to
	protocol design flaws.
	4.2.10. Don't think in terms of hosts		12. Have explicit agreements: When users and their devices provide
			information to network entities, it would be beneficial to have
			an opportunity for the users to state their requirements
			regarding the use of the information provided in this way.
			While the actual use of such requirements and the willingness of
			network entities to agree to them remains to be seen, at the
			moment even the technical means of doing this are limited. For
			instance, it would be beneficial to be able to embed usage
			requirements within popular data formats.
	More and more, protocol endpoints are not being executed on what used		As appropriate, users should be made aware of the choices made
	be understood as a host system. The web and Javascript model clearly		in a particular design, and avoid designs or products that
	differs from traditional host models, but so do most server-side		protect against some threats but are wide open to other serious
	deployments these days, thanks to virtualisation.		issues. (SF doesn't know what that last bit means;-)
	As yes unpublished work on this topic within the IAB [StackEvo]		13. Perform end-to-end protection via other parties: Information
	programme, appears to posit the same kind of thesis. In the stackevo		passed via another party who does not intrinsically need the
	case, that work would presumably lead to some new definition of		information to perform its function should be protected end-to-
	protocol endpoint, but (consensus on) such a definition may not be		end to its intended recipient. This guideline is general, and
	needed for an expanded threat model. For this work, it may be		holds equally for sending TCP/IP packets, TLS connections, or
	sufficient to note that protocol endpoints can no longer be		application-layer interactions. As [RFC8546] notes, it is a
	considered to be executing on a traditional host, to assume (at		useful design rule to avoid "accidental invariance" (the
	protocol design time) that all endpoints will be run in a virtualised		deployment of on-path devices that over-time start to make
	environment where co-tenants and (sometimes) hypervisors are		assumptions about protocols). However, it is also a necessary
	adversaries, and to then call for analysis of such scenarios.		security design rule to avoid "accidental disclosure" where
			information originally thought to be benign and untapped over-
			time becomes a significant information leak. This guideline can
			also be applied for different aspects of security, e.g.,
			confidentiality and integrity protection, depending on what the
			specific need for information is in the other parties.
	4.2.11. Trusted Computing		The main reason that further study is needed here is that the
			key management consequences can be significant here - once one
			enters into a multi-party world, securely managing keys for all
			entities can be so burdonsome that deployment just doesn't
			happen.
	Various trusted computing mechanisms allow placing some additional		5. Guidelines
	trust on a particular endpoint. This can be useful to address some
	of the issues in this memo:
	o A network manager of a set of devices may be assured that the		As [RFC3935] says:
	devices have not been compromised.
	o An outside party may be assured that someone who runs a device		We embrace technical concepts such as decentralized control, edge-
	employs a particular software installation in that device, and		user empowerment and sharing of resources, because those concepts
	that the software runs in a protected environment.		resonate with the core values of the IETF community.
	IETF work such as TEEP [I-D.ietf-teep-architecture]		To be more specific, this memo suggests the following guidelines for
	[I-D.ietf-teep-protocol] and RATS [I-D.ietf-rats-eat] may be helpful		protocol designers:
	in providing attestations to other nodes about a particular endpoint,
	or lifecycle management of such endpoints.
	One should note, however, that it is often not possible to fully		1. Consider first principles in protecting information and systems,
	protect endpoints (see, e.g., [Kocher2019] [Lipp2018]		rather than following a specific pattern such as protecting
	[I-D.taddei-smart-cless-introduction]		information in a particular way or only at a particular protocol
	[I-D.mcfadden-smart-endpoint-taxonomy-for-cless]). And of course, a		layer. It is necessary to understand what components can be
	trusted computing may be set up and controlled by a party that itself		compromised, where interests may or may not be aligned, and what
	is not trusted; a client that contacts a server that the server's		parties have a legitimate role in being a party to a specific
	owner runs in a trusted computing setting does not change the fact		information or a control task.
	that the client and the server's owner may have different interests.
	As a result, there is a need to prepare for the possibility that
	another party in a communication is not entirely trusted.
	4.2.12. Trust Boundaries		2. Consider how you depend on infrastructure. For any protocol
			directly or indirectly dependent on infrastructure like DNS or
			BGP, analyse potential outcomes in the event that the relevant
			infrastructure has been compromised. Such attacks occur in the
			wild. [DeepDive]
	Traditional forms of communication equipment have morphed into		3. Protocol endpoints are commonly no longer executed on what used
	today's virtualized environments, where new trust boundaries exist,		be understood as a host system. [StackEvo] The web and
	e.g., between different virtualisation layers. And an application		Javascript model clearly differs from traditional host models,
	might consider itself trusted while not entirely trusting the		but so do many server-side deployments, thanks to
	underlying operating system. A browser application wants to protect		virtualisation. At protocol design time assume that all
	itself against Javascript loaded from a website, while the website		endpoints will be run in virtualised environments where co-
	considers itself and the Javascript an application that it wants to		tenants and (sometimes) hypervisors are adversaries, and then
	protect from the browser.		analyse such scenarios.
	In general, there are multiple parties even in a single device, with		4. Once you have something, do not pass it onto others without
	differing interests, including some that have (or claim to) the		serious consideration. In other words, minimize information
	interest of the human user in mind.		passed to others to guard against the potential compromise of
			that party. As recommended in [RFC6973] data minimisation and
			additional encryption can be helpful - if applications don't
			ever see data, or a cleartext form of data, then they should
			have a harder time misbehaving. Similarly, not defining new
			long-term identifiers, and not exposing existing ones, help in
			minimising risk.
	4.3. Does IETF Analysis of Protocols Need to Change?		5. Minimize passing of control functions to others. Any passing of
			control functions to other parties should be minimized to guard
			against the potential misuse of those control functions. This
			applies to both technical (e.g., nodes that assign resources)
			and process control functions (e.g., the ability to allocate
			number or develop extensions). Control functions of all kinds
			can become a matter of contention and power struggle, even in
			cases where their actual function is minimal, as we saw with the
			IANA transition debates.
	It may also be necessary to make procedural changes in how new		6. Where possible, avoid centralized resources. While centralized
	protocols are defined at the IETF. For instance, our existing		components, resources, and functions are often simpler, there
	documentation of threat models and requirements for security		can be grave issues associated with them, for example meta-data
	considerations sections may not be adequate in today's world.		leakage. Designers should balance the benefits of centralized
			resources or control points against the threats arising. If it
			is not possible to avoid, find a way to allow the centralized
			resources to be selectable, depending on context and user
			settings.
	These suggested changes are entirely tentative.		7. Treat parties with which your protocol endpoints interact with
			suspicion, even if the communications are encrypted. Other
			endpoints may misuse any information or control opportunity in
			the communication. Similarly, even endpoints within your own
			system need to be treated with suspicion, as some may become
			compromised.
	4.3.1. Develop a BCP for privacy considerations		8. Consider abuse-cases. Protocol developers are typically most
			interested in a few specific use-cases for which they need
			solutions. Expanding the threat model to consider adversarial
			behaviours [AbuseCases] calls for significant attention to be
			paid to potential abuses of whatever new or re-purposed
			technology is being considered.
	It may be time for the IETF to develop a BCP for privacy		9. Consider recovery from compromse or attack during protocol
	considerations, possibly starting from [RFC6973].		design - all widely used protocols will at some time be subject
			to successful attack, whether that is due to deployment or
			implementation error, or, less commonly, due to protocol design
			flaws. For example, recent work on multiparty messaging
			security primitives [I-D.ietf-mls-architecture] considers "post-
			compromise security" as an inherent part of the design of that
			protocol.
	4.3.2. Re-consider protocol design "lore"		10. Consider linkability. As discussed in [RFC6973] the ability to
			link or correlate different protocol messages with one another,
			or with external sources of information (e.g. public or private
			databases) can create privacy or security issues. As an
			example, re-use of TLS session tickets can enable an observer to
			associate multiple TLS sessions regardless of changes in source
			or destination addressing, which may reduce privacy or help a
			bad actor in targeting an attack. The same effects may result
			regardless of how protocol exchanges can be linked to one
			another. Protocol designs that aim to prevent such linkage may
			produce have fewer unexpected or unwanted side-effects when
			deployed.
	It could be that this discussion demonstrates that it is timely to		But when applying these guidelines, don't take this as blanket reason
	reconsider some protocol design "lore" as for example is done in		to provide no information to anyone, or (impractically) insist on
	[I-D.iab-protocol-maintenance]. More specifically, protocol		encrypting everything, or other extreme measures. Designers need to
	extensibility mechanisms may inadvertently create vectors for abuse-		be aware of the different threats facing their system, and deal with
	cases, given that designers cannot fully analyse their impact at the		the most serious ones (of which there are typically many) within
	time a new protocol is defined or standardised. One might conclude		their applicable resource constraints.
	that a lack of extensibility could be a virtue for some new
	protocols, in contrast to earlier assumptions. As pointed out by one
	commenter though, people can find ways to extend things regardless,
	if they feel the need.
	4.3.3. Consider the user perspective		6. Potential changes in BCP 72/RFC 3552
	[I-D.nottingham-for-the-users] argues that, in relevant cases where		BCP 72/RFC 3553 [RFC3552] defines an "Internet Threat Model" and
	there are conflicting requirements, the "IETF considers end users as		provides guidance on writing Security Considerations sections in
	its highest priority concern." Doing so seems consistent with the		other RFCs. It is important to note that BCP 72 is (or should be:-)
	expanded threat model being argued for here, so may indicate that a		used by all IETF participants when developing protocols. Potential
	BCP in that space could also be useful.		changes to RFC 3552 therefore need to be brief - IETF participants
			cannot in general be expected to devote huge amounts of time to
			developing their security considerations text. Potential changes
			also need to be easily understood as IETF participants from all
			backgrounds need to be able to use BCP 72. In this section we
			provide a couple of initial suggested changes to BCP 72 that will
			need to be further developed as part of this work. (For example, it
			may be possible to include some of the guidelines from Section 5 as
			those are further developed.)
	4.3.4. Potential changes in RFC 3552		As evidenced in the OAuth quote in Section 4 - it can be useful to
			consider the effect of compromised endpoints on those that are not
			compromised. It may therefore be interesting to consider the
			consequences that would follow from a change to [RFC3552] that
			recognises how the landscape has changed since 2003.
	The earlier quote from OAuth (Section 4.2.7) also has another aspect		One initial, draft proposal for such a change could be:
	- it considers the effect of compromised endpoints on those that are
	not compromised. It may therefore be interesting to consider the
	consequeneces that would follow from a change to [RFC3552]. RFC 3552
	is the RFC that defines "An Internet Threat Model". It also provides
	guidance to writing Security Considerations sections in other RFCs.
	One initial, draft proposal for such changes would be this:
	OLD:		OLD:
	In general, we assume that the end-systems engaging in a protocol		In general, we assume that the end-systems engaging in a protocol
	exchange have not themselves been compromised. Protecting against		exchange have not themselves been compromised. Protecting against
	an attack when one of the end-systems has been compromised is		an attack when one of the end-systems has been compromised is
	extraordinarily difficult. It is, however, possible to design		extraordinarily difficult. It is, however, possible to design
	protocols which minimize the extent of the damage done under these		protocols which minimize the extent of the damage done under these
	circumstances.		circumstances.
	skipping to change at page 26, line 45		skipping to change at line 1226
	from Internet technology developers and standards organizations.		from Internet technology developers and standards organizations.
	Here is one possible addition:		Here is one possible addition:
	NEW:		NEW:
	The design of any Internet technology should start from an		The design of any Internet technology should start from an
	understanding of the participants in a system, their roles, and		understanding of the participants in a system, their roles, and
	the extent to which they should have access to information and		the extent to which they should have access to information and
	ability to control other participants.		ability to control other participants.
	4.3.5. Potential Changes in RFC 7258		7. Potential Changes in BCP 188/RFC 7258
	Other additional guidelines may be necessary also in [RFC7258], the		Other additional guidelines may be necessary also in BCP 188/RFC
	RFC that specifies how IETF work should take into account pervasive		7258[RFC7258], which specifies how IETF work should take into account
	monitoring, such as the one performed as a part of broad,		pervasive monitoring.
	indiscriminate surveillance activity.
	An initial, draft suggestion for starting point of those changes		An initial, draft suggestion for starting point of those changes
	could be adding the following paragraph after the 2nd paragraph in		could be adding the following paragraph after the 2nd paragraph in
	Section 2:		Section 2:
	NEW:		NEW:
	PM attacks include those cases where information collected by a		PM attacks include those cases where information collected by a
	legitimate protocol participant is misused for PM purposes. The		legitimate protocol participant is misused for PM purposes. The
	attacks also include those cases where a protocol or network		attacks also include those cases where a protocol or network
	architecture results in centralized data storage or control		architecture results in centralized data storage or control
	functions relating to many users, raising the risk of said misuse.		functions relating to many users, raising the risk of said misuse.
	5. Conclusions		8. Conclusions
	At this stage we don't think it approriate to claim that any strong		At this stage we don't think it appropriate to claim that any strong
	conclusion can be reached based on the above. We do however, claim		conclusion can be reached based on the above. We do however, claim
	that the is a topic that could be worth discussion and more work.		that the is a topic that could be worth discussion and more work.
	To start with, Internet technology developers need to be better aware		To start with, Internet technology developers need to be better aware
	of the issues beyond communications security, and consider them in		of the issues beyond communications security, and consider them in
	design. At the IETF it would be beneficial to include some of these		design. At the IETF it would be beneficial to include some of these
	considerations in the usual systematic security analysis of		considerations in the usual systematic security analysis of
	technologies under development.		technologies under development.
	In particular, when the IETF develops infrastructure technology for		In particular, when the IETF develops infrastructure technology for
	skipping to change at page 27, line 49		skipping to change at line 1276
	work is needed in equivalently broadly deployed tools for minimising		work is needed in equivalently broadly deployed tools for minimising
	or obfuscating information provided by users to other entities, and		or obfuscating information provided by users to other entities, and
	the use of end-to-end security through entities that are involved in		the use of end-to-end security through entities that are involved in
	the protocol exchange but who do not need to know everything that is		the protocol exchange but who do not need to know everything that is
	being passed through them.		being passed through them.
	Comments on the issues discussed in this memo are gladly taken either		Comments on the issues discussed in this memo are gladly taken either
	privately or on the model-t mailing list		privately or on the model-t mailing list
	(https://www.ietf.org/mailman/listinfo/Model-t).		(https://www.ietf.org/mailman/listinfo/Model-t).
	Some further work includes items listed in Section 4.1 and		Some further work includes items listed in Section 5 and Section 4,
	Section 4.3, as well as compiling categories of vulnerabilities that		as well as compiling categories of vulnerabilities that need to be
	need to be addressed, examples of specific attacks, and continuing		addressed, examples of specific attacks, and continuing the analysis
	the analysis of the situation and possible new remedies.		of the situation and possible new remedies.
	It is also necessary find suitable use cases that the IETF can		It is also necessary find suitable use cases that the IETF can
	address by further work in this space. A completely adversial		address by further work in this space. A completely adversial
	situation is not really workable, but there are situations where some		situation is not really workable, but there are situations where some
	parties are trustworthy, and wish to co-operate to show to each other		parties are trustworthy, and wish to co-operate to show to each other
	that this is really the case. In these situations data minimisation		that this is really the case. In these situations data minimisation
	can be beneficial to both, attestation can provide additional trust,		can be beneficial to both, attestation can provide additional trust,
	detection of incidents can alert the parties to action, and so on.		detection of incidents can alert the parties to action, and so on.
	6. Informative References		9. Informative References
	[AbuseCases]		[AbuseCases]
	McDermott, J. and C. Fox, "Using abuse case models for		McDermott, J. and C. Fox, "Using abuse case models for
	security requirements analysis", IEEE Annual Computer		security requirements analysis", IEEE Annual Computer
	Security Applications Conference (ACSAC'99),		Security Applications Conference (ACSAC'99),
	https://www.acsac.org/1999/papers/wed-b-1030-john.pdf ,		https://www.acsac.org/1999/papers/wed-b-1030-john.pdf ,
	1999.		1999.
	[Attitude]		[Attitude] "User Perceptions of Sharing, Advertising, and Tracking",
	"User Perceptions of Sharing, Advertising, and Tracking",
	Symposium on Usable Privacy and Security (SOUPS),		Symposium on Usable Privacy and Security (SOUPS),
	https://www.usenix.org/conference/soups2015/proceedings/		https://www.usenix.org/conference/soups2015/proceedings/
	presentation/chanchary , 2015.		presentation/chanchary , 2015.
	[BgpHijack]		[avleak] Cox, J., "Leaked Documents Expose the Secretive Market for
	Sermpezis, P., Kotronis, V., Dainotti, A., and X.		Your Web Browsing Data",
			https://www.vice.com/en_us/article/qjdkq7/
			avast-antivirus-sells-user-browsing-data-investigation ,
			February 2020.
			[BgpHijack]Sermpezis, P., Kotronis, V., Dainotti, A., and X.
	Dimitropoulos, "A survey among network operators on BGP		Dimitropoulos, "A survey among network operators on BGP
	prefix hijacking", ACM SIGCOMM Computer Communication		prefix hijacking", ACM SIGCOMM Computer Communication
	Review 48, no. 1 (2018): 64-69,		Review 48, no. 1 (2018): 64-69,
	https://arxiv.org/pdf/1801.02918.pdf , 2018.		https://arxiv.org/pdf/1801.02918.pdf , 2018.
	[Bloatware]		[Bloatware]Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and
	Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and
	N. Vallina, "An Analysis of Pre-installed Android		N. Vallina, "An Analysis of Pre-installed Android
	Software", arXiv preprint arXiv:1905.02713 (2019) , 2019.		Software", arXiv preprint arXiv:1905.02713 (2019) , 2019.
	[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.
	[CommandAndControl]		[CommandAndControl]
	Botnet, ., "Creating botnet C&C server. What architecture		Botnet, ., "Creating botnet C&C server. What architecture
	should I use? IRC? HTTP?", Stackexchange.com question,		should I use? IRC? HTTP?", Stackexchange.com question,
	https://security.stackexchange.com/questions/100577/		https://security.stackexchange.com/questions/100577/
	creating-botnet-cc-server-what-architecture-should-i-use-		creating-botnet-cc-server-what-architecture-should-i-use-
	irc-http , 2014.		irc-http , 2014.
	[Curated] Hammad, M., Garcia, J., and S. MaleK, "A large-scale		[Curated] Hammad, M., Garcia, J., and S. MaleK, "A large-scale
	empirical study on the effects of code obfuscations on		empirical study on the effects of code obfuscations on
	Android apps and anti-malware products", ACM International		Android apps and anti-malware products", ACM International
	Conference on Software Engineering 2018,		Conference on Software Engineering 2018,
	https://www.ics.uci.edu/~seal/		https://www.ics.uci.edu/~seal/
	publications/2018ICSE_Hammad.pdf , 2018.		publications/2018ICSE_Hammad.pdf , 2018.
	[DeepDive]		[DeepDive] Krebs on Security, ., "A Deep Dive on the Recent
	Krebs on Security, ., "A Deep Dive on the Recent
	Widespread DNS Hijacking Attacks", krebsonsecurity.com		Widespread DNS Hijacking Attacks", krebsonsecurity.com
	blog, https://krebsonsecurity.com/2019/02/a-deep-dive-on-		blog, https://krebsonsecurity.com/2019/02/a-deep-dive-on-
	the-recent-widespread-dns-hijacking-attacks/ , 2019.		the-recent-widespread-dns-hijacking-attacks/ , 2019.
			[DynDDoS] York, K., "Dyn's Statement on the 10/21/2016 DNS DDoS
			Attack", Company statement: https://dyn.com/blog/
			dyn-statement-on-10212016-ddos-attack/ , 2016.
	[GDPRAccess]		[GDPRAccess]
	EU, ., "Right of access by the data subject", Article 15,		EU, ., "Right of access by the data subject", Article 15,
	GDPR, https://gdpr-info.eu/art-15-gdpr/ , n.d..		GDPR, https://gdpr-info.eu/art-15-gdpr/ , February 2020.
	[HijackDet]		[HijackDet]Schlamp, J., Holz, R., Gasser, O., Korste, A., Jacquemart,
	Schlamp, J., Holz, R., Gasser, O., Korste, A., Jacquemart,
	Q., Carle, G., and E. Biersack, "Investigating the nature		Q., Carle, G., and E. Biersack, "Investigating the nature
	of routing anomalies: Closing in on subprefix hijacking		of routing anomalies: Closing in on subprefix hijacking
	attacks", International Workshop on Traffic Monitoring and		attacks", International Workshop on Traffic Monitoring and
	Analysis, pp. 173-187. Springer, Cham,		Analysis, pp. 173-187. Springer, Cham,
	https://www.net.in.tum.de/fileadmin/bibtex/publications/		https://www.net.in.tum.de/fileadmin/bibtex/publications/
	papers/schlamp_TMA_1_2015.pdf , 2015.		papers/schlamp_TMA_1_2015.pdf , 2015.
	[Home] Nthala, N. and I. Flechais, "Rethinking home network		[Home] Nthala, N. and I. Flechais, "Rethinking home network
	security", European Workshop on Usable Security		security", European Workshop on Usable Security
	(EuroUSEC), https://ora.ox.ac.uk/objects/		(EuroUSEC), https://ora.ox.ac.uk/objects/
	uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa		uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa
	fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica		fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica
	tion%2Fpdf&type_of_work=Conference+item , 2018.		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", draft-arkko-arch-dedr-report-00 (work in
	progress), November 2019.		progress), 4 November 2019,
			<http://www.ietf.org/internet-drafts/draft-arkko-arch-
			dedr-report-00.txt>.
	[I-D.arkko-arch-infrastructure-centralisation]		[I-D.arkko-arch-infrastructure-centralisation]
	Arkko, J., "Centralised Architectures in Internet		Arkko, J., "Centralised Architectures in Internet
	Infrastructure", draft-arkko-arch-infrastructure-		Infrastructure", draft-arkko-arch-infrastructure-
	centralisation-00 (work in progress), November 2019.		centralisation-00 (work in progress), 4 November 2019,
			<http://www.ietf.org/internet-drafts/draft-arkko-arch-
			infrastructure-centralisation-00.txt>.
	[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", draft-
	arkko-arch-internet-threat-model-01 (work in progress),		arkko-arch-internet-threat-model-01 (work in progress), 8
	July 2019.		July 2019,
			<http://www.ietf.org/internet-drafts/draft-arkko-arch-
			internet-threat-model-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.		draft-farrell-etm-03 (work in progress), 6 July 2019,
			<http://www.ietf.org/internet-drafts/draft-farrell-etm-
			03.txt>.
	[I-D.iab-protocol-maintenance]		[I-D.iab-protocol-maintenance]
	Thomson, M., "The Harmful Consequences of the Robustness		Thomson, M., "The Harmful Consequences of the Robustness
	Principle", draft-iab-protocol-maintenance-04 (work in		Principle", draft-iab-protocol-maintenance-04 (work in
	progress), November 2019.		progress), 3 November 2019,
			<http://www.ietf.org/internet-drafts/draft-iab-protocol-
			maintenance-04.txt>.
	[I-D.ietf-httpbis-expect-ct]		[I-D.ietf-httpbis-expect-ct]
	estark@google.com, e., "Expect-CT Extension for HTTP",		estark@google.com, e., "Expect-CT Extension for HTTP",
	draft-ietf-httpbis-expect-ct-08 (work in progress),		draft-ietf-httpbis-expect-ct-08 (work in progress), 9
	December 2018.		December 2018,
			<http://www.ietf.org/internet-drafts/draft-ietf-httpbis-
			expect-ct-08.txt>.
	[I-D.ietf-mls-architecture]		[I-D.ietf-mls-architecture]
	Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon,		Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon,
	A., and A. Duric, "The Messaging Layer Security (MLS)		A., and A. Duric, "The Messaging Layer Security (MLS)
	Architecture", draft-ietf-mls-architecture-03 (work in		Architecture", draft-ietf-mls-architecture-04 (work in
	progress), September 2019.		progress), 26 January 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-mls-
			architecture-04.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-24 (work		and Secure Transport", draft-ietf-quic-transport-25 (work
	in progress), November 2019.		in progress), 21 January 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-quic-
			transport-25.txt>.
	[I-D.ietf-rats-eat]		[I-D.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Ballesteros, M., and J.		Mandyam, G., Lundblade, L., Ballesteros, M., and J.
	O'Donoghue, "The Entity Attestation Token (EAT)", draft-		O'Donoghue, "The Entity Attestation Token (EAT)", draft-
	ietf-rats-eat-01 (work in progress), July 2019.		ietf-rats-eat-02 (work in progress), 9 January 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-rats-eat-
			02.txt>.
	[I-D.ietf-teep-architecture]		[I-D.ietf-teep-architecture]
	Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,		Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
	"Trusted Execution Environment Provisioning (TEEP)		"Trusted Execution Environment Provisioning (TEEP)
	Architecture", draft-ietf-teep-architecture-05 (work in		Architecture", draft-ietf-teep-architecture-06 (work in
	progress), December 2019.		progress), 8 February 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-teep-
			architecture-06.txt>.
	[I-D.ietf-teep-protocol]		[I-D.ietf-teep-protocol]
	Tschofenig, H., Pei, M., Wheeler, D., and D. Thaler,		Tschofenig, H., Pei, M., Wheeler, D., and D. Thaler,
	"Trusted Execution Environment Provisioning (TEEP)		"Trusted Execution Environment Provisioning (TEEP)
	Protocol", draft-ietf-teep-protocol-00 (work in progress),		Protocol", draft-ietf-teep-protocol-00 (work in progress),
	December 2019.		12 December 2019,
			<http://www.ietf.org/internet-drafts/draft-ietf-teep-
			protocol-00.txt>.
	[I-D.ietf-tls-esni]		[I-D.ietf-tls-esni]
	Rescorla, E., Oku, K., Sullivan, N., and C. Wood,		Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
	"Encrypted Server Name Indication for TLS 1.3", draft-		"Encrypted Server Name Indication for TLS 1.3", draft-
	ietf-tls-esni-05 (work in progress), November 2019.		ietf-tls-esni-05 (work in progress), 4 November 2019,
			<http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-
			05.txt>.
	[I-D.ietf-tls-grease]		[I-D.ietf-tls-grease]
	Benjamin, D., "Applying GREASE to TLS Extensibility",		Benjamin, D., "Applying GREASE to TLS Extensibility",
	draft-ietf-tls-grease-04 (work in progress), August 2019.		draft-ietf-tls-grease-04 (work in progress), 22 August
			2019, <http://www.ietf.org/internet-drafts/draft-ietf-tls-
			grease-04.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", draft-
	lazanski-smart-users-internet-00 (work in progress), July		lazanski-smart-users-internet-00 (work in progress), 8
	2019.		July 2019,
			<http://www.ietf.org/internet-drafts/draft-lazanski-smart-
			users-internet-00.txt>.
	[I-D.mcfadden-smart-endpoint-taxonomy-for-cless]		[I-D.mcfadden-smart-endpoint-taxonomy-for-cless]
	McFadden, M., "Endpoint Taxonomy for CLESS", draft-		McFadden, M., "Endpoint Taxonomy for CLESS", draft-
	mcfadden-smart-endpoint-taxonomy-for-cless-00 (work in		mcfadden-smart-endpoint-taxonomy-for-cless-01 (work in
	progress), July 2019.		progress), 5 February 2020,
			<http://www.ietf.org/internet-drafts/draft-mcfadden-smart-
			endpoint-taxonomy-for-cless-01.txt>.
	[I-D.nottingham-for-the-users]		[I-D.nottingham-for-the-users]
	Nottingham, M., "The Internet is for End Users", draft-		Nottingham, M., "The Internet is for End Users", draft-
	nottingham-for-the-users-09 (work in progress), July 2019.		nottingham-for-the-users-09 (work in progress), 22 July
			2019,
			<http://www.ietf.org/internet-drafts/draft-nottingham-for-
			the-users-09.txt>.
	[I-D.taddei-smart-cless-introduction]		[I-D.taddei-smart-cless-introduction]
	Taddei, A., Wueest, C., Roundy, K., and D. Lazanski,		Taddei, A., Wueest, C., Roundy, K., and D. Lazanski,
	"Capabilities and Limitations of an Endpoint-only Security		"Capabilities and Limitations of an Endpoint-only Security
	Solution", draft-taddei-smart-cless-introduction-01 (work		Solution", draft-taddei-smart-cless-introduction-02 (work
	in progress), July 2019.		in progress), 9 January 2020,
			<http://www.ietf.org/internet-drafts/draft-taddei-smart-
			cless-introduction-02.txt>.
	[Kocher2019]		[Kocher2019]
	Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D.,		Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D.,
	Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher,		Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher,
	T., Schwarz, M., and Y. Yarom, "Spectre Attacks:		T., Schwarz, M., and Y. Yarom, "Spectre Attacks:
	Exploiting Speculative Execution", 40th IEEE Symposium on		Exploiting Speculative Execution", 40th IEEE Symposium on
	Security and Privacy (S&P'19) , 2019.		Security and Privacy (S&P'19) , 2019.
	[LeakyBuckets]		[LeakyBuckets]
	Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3		Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3
	Breaches", Bitdefender blog,		Breaches", Bitdefender blog,
	https://businessinsights.bitdefender.com/		https://businessinsights.bitdefender.com/
	worst-amazon-breaches , 2018.		worst-amazon-breaches , 2018.
	[Lipp2018]		[Lipp2018] Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W.,
	Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W.,
	Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D.,		Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D.,
	Yarom, Y., and M. Hamburg, "Meltdown: Reading Kernel		Yarom, Y., and M. Hamburg, "Meltdown: Reading Kernel
	Memory from User Space", 27th USENIX Security Symposium		Memory from User Space", 27th USENIX Security Symposium
	(USENIX Security 18) , 2018.		(USENIX Security 18) , 2018.
	[Mailbug] Englehardt, S., Han, J., and A. Narayanan, "I never signed		[Mailbug] Englehardt, S., Han, J., and A. Narayanan, "I never signed
	up for this! Privacy implications of email tracking",		up for this! Privacy implications of email tracking",
	Proceedings on Privacy Enhancing Technologies 2018.1		Proceedings on Privacy Enhancing Technologies 2018.1
	(2018): 109-126, https://www.degruyter.com/downloadpdf/j/		(2018): 109-126, https://www.degruyter.com/downloadpdf/j/
	popets.2018.2018.issue-1/popets-2018-0006/		popets.2018.2018.issue-1/popets-2018-0006/
	popets-2018-0006.pdf , 2018.		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
	Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,		Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
	<https://www.rfc-editor.org/info/rfc1958>.		<https://www.rfc-editor.org/info/rfc1958>.
	[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,		DOI 10.17487/RFC3552, July 2003,
	<https://www.rfc-editor.org/info/rfc3552>.		<https://www.rfc-editor.org/info/rfc3552>.
	[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",		[RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
	BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,		BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
	<https://www.rfc-editor.org/info/rfc3935>.		<https://www.rfc-editor.org/info/rfc3935>.
	[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation		[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
	Element (PCE)-Based Architecture", RFC 4655,		Computation Element (PCE)-Based Architecture", RFC 4655,
	DOI 10.17487/RFC4655, August 2006,		DOI 10.17487/RFC4655, August 2006,
	<https://www.rfc-editor.org/info/rfc4655>.		<https://www.rfc-editor.org/info/rfc4655>.
	[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
	<https://www.rfc-editor.org/info/rfc6454>.		<https://www.rfc-editor.org/info/rfc6454>.
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,		Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
	February 2012, <https://www.rfc-editor.org/info/rfc6480>.		February 2012, <https://www.rfc-editor.org/info/rfc6480>.
	skipping to change at page 34, line 18		skipping to change at line 1612
	[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		[Saltzer] Saltzer, J.H., Reed, D.P., and D.D. Clark, "End-To-End
	in System Design", ACM TOCS, Vol 2, Number 4, pp 277-288 ,		Arguments in System Design", ACM TOCS, Vol 2, Number 4, pp
	November 1984.		277-288 , November 1984.
	[Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes,		[Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes,
	Disclosures, and Outcomes", USENIX , 2016.		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.
	[StackEvo]		[StackEvo] Trammell, B., Thomson, M., Howard, L., and T. Hardie,
	Trammell, B., Thomson, M., Howard, L., and T. Hardie,
	"What Is an Endpoint?", Unpublished work,		"What Is an Endpoint?", Unpublished work,
	https://github.com/stackevo/endpoint-draft/blob/master/		https://github.com/stackevo/endpoint-draft/blob/master/
	draft-trammell-whats-an-endpoint.md , 2017.		draft-trammell-whats-an-endpoint.md , 2017.
	[Sybil] Viswanath, B., Post, A., Gummadi, K., and A. Mislove, "An		[Sybil] Viswanath, B., Post, A., Gummadi, K., and A. Mislove, "An
	analysis of social network-based sybil defenses", ACM		analysis of social network-based sybil defenses", ACM
	SIGCOMM Computer Communication Review 41(4), 363-374,		SIGCOMM Computer Communication Review 41(4), 363-374,
	https://conferences.sigcomm.org/sigcomm/2010/papers/		https://conferences.sigcomm.org/sigcomm/2010/papers/
	sigcomm/p363.pdf , 2011.		sigcomm/p363.pdf , 2011.
	skipping to change at page 35, line 10		skipping to change at line 1648
	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.
	[Toys] Chu, G., Apthorpe, N., and N. Feamster, "Security and		[Toys] Chu, G., Apthorpe, N., and N. Feamster, "Security and
	Privacy Analyses of Internet of Things Childrens' Toys",		Privacy Analyses of Internet of Things Childrens' Toys",
	IEEE Internet of Things Journal 6.1 (2019): 978-985,		IEEE Internet of Things Journal 6.1 (2019): 978-985,
	https://arxiv.org/pdf/1805.02751.pdf , 2019.		https://arxiv.org/pdf/1805.02751.pdf , 2019.
	[Tracking]		[Tracking] Ermakova, T., Fabian, B., Bender, B., and K. Klimek, "Web
	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		[Troll] Stewart, L., Arif, A., and K. Starbird, "Examining trolls
	and polarization with a retweet network", ACM Workshop on		and polarization with a retweet network", ACM Workshop on
	Misinformation and Misbehavior Mining on the Web,		Misinformation and Misbehavior Mining on the Web,
	https://faculty.washington.edu/kstarbi/		https://faculty.washington.edu/kstarbi/
	examining-trolls-polarization.pdf , 2018.		examining-trolls-polarization.pdf , 2018.
	skipping to change at page 36, line 9		skipping to change at line 1694
	Harald Alvestrand, Roman Danyliw, Daniel Kahn Gilmore, Wes Hardaker,		Harald Alvestrand, Roman Danyliw, Daniel Kahn Gilmore, Wes Hardaker,
	Bret Jordan, Ben Kaduk, Dominique Lazanski, Eliot Lear, Lawrence		Bret Jordan, Ben Kaduk, Dominique Lazanski, Eliot Lear, Lawrence
	Lundblade, Kathleen Moriarty, Kirsty Paine, Eric Rescorla, Ali		Lundblade, Kathleen Moriarty, Kirsty Paine, Eric Rescorla, Ali
	Rezaki, Mohit Sethi, Ben Schwartz, Dave Thaler, Paul Turner, David		Rezaki, Mohit Sethi, Ben Schwartz, Dave Thaler, Paul Turner, David
	Waltemire, and Jeffrey Yaskin.		Waltemire, and Jeffrey Yaskin.
	The authors would also like to thank the participants of the IAB 2019		The authors would also like to thank the participants of the IAB 2019
	DEDR workshop:		DEDR workshop:
	Tuomas Aura, Vittorio Bertola, Carsten Bormann, Stephane Bortzmeyer,		Tuomas Aura, Vittorio Bertola, Carsten Bormann, Stephane Bortzmeyer,
	Alissa Cooper, Stephen Farrell, Hannu Flinck, Carl Gahnberg, Phillip		Alissa Cooper, Hannu Flinck, Carl Gahnberg, Phillip Hallam-Baker, Ted
	Hallam-Baker, Ted Hardie, Paul Hoffman, Christian Huitema, Geoff		Hardie, Paul Hoffman, Christian Huitema, Geoff Huston, Konstantinos
	Huston, Konstantinos Komaitis, Mirja Kuhlewind, Dirk Kutscher,		Komaitis, Mirja Kuhlewind, Dirk Kutscher, Zhenbin Li, Julien
	Zhenbin Li, Julien Maisonneuve, John Mattson, Moritz Muller, Joerg		Maisonneuve, John Mattson, Moritz Muller, Joerg Ott, Lucas Pardue,
	Ott, Lucas Pardue, Jim Reid, Jan-Frederik Rieckers, Mohit Sethi,		Jim Reid, Jan-Frederik Rieckers, Mohit Sethi, Melinda Shore, Jonne
	Melinda Shore, Jonne Soininen, Andrew Sullivan, and Brian Trammell.		Soininen, Andrew Sullivan, and Brian Trammell.
	The authors would also like to thank the participants of the November		The authors would also like to thank the participants of the November
	2016 meeting at the IETF:		2016 meeting at the IETF:
	Carsten Bormann, Tommy C, Roman Danyliw, Christian Huitema, Ben		Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie,
	Kaduk, Dirk Kutscher, Dominique Lazanski, Eric Rescorla, Ali Rezaki,		Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric
	Melinda Shore, Martin Thomson, and Robin Wilton ... (missing many		Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and
	people... did we have minutes other than the list of actions?) ...		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.
	Finally, the authors would like to thank numerous other people for		Finally, the authors would like to thank numerous other people for
	insightful comments and discussions in this space.		insightful comments and discussions in this space.
	Authors' Addresses		Authors' Addresses
	Jari Arkko
	Ericsson		Ericsson
			Jari Arkko
			FI-
			Finland
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
	Stephen Farrell		Stephen Farrell
	Trinity College Dublin		Trinity College Dublin
			Ireland
	Email: stephen.farrell@cs.tcd.ie		Email: stephen.farrell@cs.tcd.ie
End of changes. 144 change blocks.
	507 lines changed or deleted		545 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/