draft-arkko-arch-internet-threat-model-00.txt		draft-arkko-arch-internet-threat-model.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational April 30, 2019		Intended status: Informational July 09, 2019
	Expires: November 1, 2019		Expires: January 10, 2020
	Changes in the Internet Threat Model		Changes in the Internet Threat Model
	draft-arkko-arch-internet-threat-model-00		draft-arkko-arch-internet-threat-model-01
	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 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, it is also		pressing security issues in the Internet. For instance, it is also
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	and architecture affects security.		and architecture affects security.
	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 http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 1, 2019.		This Internet-Draft will expire on January 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Improvements in Communications Security . . . . . . . . . . . 5		2. Improvements in Communications Security . . . . . . . . . . . 5
	3. Issues in Security Beyond Communications Security . . . . . . 5		3. Issues in Security Beyond Communications Security . . . . . . 5
	4. The Role of End-to-end . . . . . . . . . . . . . . . . . . . 8		4. Impacts . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Guidelines . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. The Role of End-to-end . . . . . . . . . . . . . . . . . 8
	5. Potential Changes in IETF Analysis of Protocols . . . . . . . 11		4.2. Trusted networks . . . . . . . . . . . . . . . . . . . . 10
	5.1. Changes in RFC 3552 . . . . . . . . . . . . . . . . . . . 11		4.2.1. Even closed networks can have compromised nodes . . . 11
	5.2. Changes in RFC 7258 . . . . . . . . . . . . . . . . . . . 12		4.3. Balancing Threats . . . . . . . . . . . . . . . . . . . . 12
	5.3. System and Architecture Aspects . . . . . . . . . . . . . 12		5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. Other Work . . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Potential Changes in IETF Analysis of Protocols . . . . . . . 14
	7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.1. Changes in RFC 3552 . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		6.2. Changes in RFC 7258 . . . . . . . . . . . . . . . . . . . 15
	9. Informative References . . . . . . . . . . . . . . . . . . . 13		6.3. System and Architecture Aspects . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16		7. Other Work . . . . . . . . . . . . . . . . . . . . . . . . . 15
			8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
			9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
			10. Informative References . . . . . . . . . . . . . . . . . . . 16
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
	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 26		skipping to change at page 3, line 29
	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. This is due to three factors:
	o Advances in protecting most of our communications with strong		o Advances in protecting most of our communications with strong
	cryptographic means. This has resulted in much improved		cryptographic means. This has resulted in much improved
	communications security, but also higlights 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		o Adversaries have increased their pressure against other avenues of
	attack, from compromising devices to legal coercion of centralized		attack, from compromising devices to legal coercion of centralized
	endpoints in conversations.		endpoints in conversations.
	skipping to change at page 4, line 39		skipping to change at page 4, line 41
	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 be lead to a similar effect as described in		receive information may be 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.
	The rest of this memo is organized as follows. Section 2 and		The rest of this memo is organized as follows. Section 2 and
	Section 3 outline the situation with respect to communications		Section 3 outline the situation with respect to communications
	security and beyond it. Section 4 discusses how the author believes		security and beyond it. Section 4.1 discusses how the author
	the Internet threat model should evolve, and what types of threats		believes the Internet threat model should evolve, and what types of
	should be seen as critical ones and in-scope. Section 4.1 will also		threats should be seen as critical ones and in-scope. Section 5 will
	discuss high-level guidance to addressing these threats.		also discuss high-level guidance to addressing these threats.
	Section 5 outlines the author's suggested future changes to RFC 3552		Section 6 outlines the author's suggested future changes to RFC 3552
	and RFC 7258 and the need for guidance on the impacts of system		and RFC 7258 and the need for guidance on the impacts of system
	design and architecture on security. Comments are solicited on these		design and architecture on security. Comments are solicited on these
	and other aspects of this document. The best place for discussion is		and other aspects of this document. The best place for discussion is
	on the arch-discuss list (https://www.ietf.org/mailman/listinfo/		on the arch-discuss list (https://www.ietf.org/mailman/listinfo/
	Architecture-discuss). This memo acts also as an input for the IAB		Architecture-discuss). This memo acts also as an input for the IAB
	retreat discussion on threat models, and it is a submission for the		retreat discussion on threat models, and it is a submission for the
	IAB DEDR workshop (https://www.iab.org/activities/workshops/dedr-		IAB DEDR workshop (https://www.iab.org/activities/workshops/dedr-
	workshop/).		workshop/).
	Finally, Section 6 highlights other discussions in this problem space		Finally, Section 7 highlights other discussions in this problem space
	and Section 7 draws some conclusions for next steps.		and Section 8 draws some conclusions for next steps.
	2. Improvements in Communications Security		2. Improvements in Communications Security
	The fraction of Internet traffic that is cryptographically protected		The fraction of Internet traffic that is cryptographically protected
	has grown tremendously in the last few years. Several factors have		has grown tremendously in the last few years. Several factors have
	contributed to this change, from Snowden revelations to business		contributed to this change, from Snowden revelations to business
	reasons and to better available technology such as HTTP/2 [RFC7540],		reasons and to better available technology such as HTTP/2 [RFC7540],
	TLS 1.3 [RFC8446], QUIC [I-D.ietf-quic-transport].		TLS 1.3 [RFC8446], QUIC [I-D.ietf-quic-transport].
	In many networks, the majority of traffic has flipped from being		In many networks, the majority of traffic has flipped from being
	skipping to change at page 8, line 17		skipping to change at page 8, line 17
	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.
	4. The Role of End-to-end		4. Impacts
			4.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
	end-to-end functions can only be performed correctly by the end-		end-to-end functions can only be performed correctly by the end-
	systems themselves. A specific case is that any network, however		systems themselves. A specific case is that any network, however
	carefully designed, will be subject to failures of transmission at		carefully designed, will be subject to failures of transmission at
	some statistically determined rate. The best way to cope with		some statistically determined rate. The best way to cope with
	this is to accept it, and give responsibility for the integrity of		this is to accept it, and give responsibility for the integrity of
	skipping to change at page 10, line 25		skipping to change at page 10, line 25
	with anyone else than its user may be implemented on top of a		with anyone else than its user may be implemented on top of a
	distributed system where some information about the user is exposed		distributed system where some information about the user is exposed
	to untrusted parties.		to untrusted parties.
	The implications of the system security also extend beyond		The implications of the system security also extend beyond
	information and control aspects. For instance, poorly design		information and control aspects. For instance, poorly design
	component protocols can become DoS vectors which are then used to		component protocols can become DoS vectors which are then used to
	attack other parts of the system. Availability is an important		attack other parts of the system. Availability is an important
	aspect to consider in the analysis along other aspects.		aspect to consider in the analysis along other aspects.
	4.1. Guidelines		4.2. Trusted networks
			Some systems are thought of as being deployed only in a closed
			setting, where all the relevant nodes are under direct control of the
			network administrators. Technologies developed for such networks
			tend to be optimized, at least initially, for these environments, and
			may lack security features necessary for different types of
			deployments.
			It is well known that many such systems evolve over time, grow, and
			get used and connected in new ways. For instance, the collaboration
			and mergers between organizations, and new services for customers may
			change the system or its environment. A system that used to be truly
			within an administrative domain may suddenly need to cross network
			boundaries or even run over the Internet. As a result, it is also
			well known that it is good to ensure that underlying technologies
			used in such systems can cope with that evolution, for instance, by
			having the necessary security capabilities to operate in different
			environments.
			In general, the outside vs. inside security model is outdated for
			most situations, due to the complex and evolving networks and the
			need to support mixture of devices from different sources (e.g., BYOD
			networks). Network virtualization also implies that previously clear
			notions of local area networks and physical proximity may create an
			entirely different reality from what appears from a simple notion of
			a local network.
			4.2.1. Even closed networks can have compromised nodes
			This memo argues that the situation is even more dire than what was
			explained above. It is impossible to ensure that all components in a
			network are actually trusted. Even in a closed network with
			carefully managed components there may be compromised components, and
			this should be factored into the design of the system and protocols
			used in the system.
			For instance, during the Snowden revelations it was reported that
			internal communication flows of large content providers were
			compromised in an effort to acquire information from large number of
			end users. This shows the need to protect not just communications
			targeted to go over the Internet, but in many cases also internal and
			control communications.
			Furthermore, there is a danger of compromised nodes, so
			communications security alone will be insufficient to protect against
			this. The defences against this include limiting information within
			networks to the parties that have a need to know, as well as limiting
			control capabilities. This is necessary even when all the nodes are
			under the control of the same network manager; the network manager
			needs to assume that some nodes and communications will be
			compromised, and build a system to mitigate or minimise attacks even
			under that assumption.
			Even airgapped networks can have these issues, as evidenced, for
			instance, by the Stuxnet worm. The Internet is not the only form of
			connectivity, as most systems include, for instance, USB ports that
			proved to be the achilles heel of the targets in the Stuxnet case.
			More commonly, every system runs large amount of software, and it is
			often not practical or even possible to black the software to prevent
			compromised code even in a high-security setting, let alone in
			commercial or private networks. Installation media, physical ports,
			both open source and proprietary programs, firmware, or even
			innocent-looking components on a circuit board can be suspect. In
			addition, complex underlying computing platforms, such as modern CPUs
			with underlying security and management tools are prone for problems.
			In general, this means that one cannot entirely trust even a closed
			system where you picked all the components yourself. Analysis for
			the security of many interesting real-world systems now commonly
			needs to include cross-component attacks, e.g., the use of car radios
			and other externally communicating devices as part of attacks
			launched against the control components such as breaks in a car
			[Savage].
			4.3. Balancing Threats
			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 are understood and protected against.
			Sometimes there are higher-level mechanisms that provide safeguards
			for failures. For instance, it is very difficult in general to
			protect against denial-of-service against compromised nodes on a
			communications path. However, it may be possible to detect that a
			service has failed.
			Another example is from packet-carrying networks. Payload traffic
			that has been properly protected with encryption does not provide
			much value to an attacker. As a result, it does not always make
			sense, for instance, encrypt every packet transmission in a packet-
			carrying system where the traffic is already encrypted at other
			layers. But it almost always makes sense to protect control
			communications and to understand the impacts of compromised nodes,
			particularly control nodes.
			5. Guidelines
	As [RFC3935] says:		As [RFC3935] says:
	We embrace technical concepts such as decentralized control, edge-		We embrace technical concepts such as decentralized control, edge-
	user empowerment and sharing of resources, because those concepts		user empowerment and sharing of resources, because those concepts
	resonate with the core values of the IETF community.		resonate with the core values of the IETF community.
	To be more specific, this memo suggests the following guidelines for		To be more specific, this memo suggests the following guidelines for
	protocol designers:		protocol designers:
	1. Minimizing information passed to others: Information passed to		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. Minimize information passed to others: Information passed to
	another party in a protocol exchange should be minimized to guard		another party in a protocol exchange should be minimized to guard
	against the potential compromise of that party.		against the potential compromise of that party.
	2. End-to-end protection via other parties: Information passed via		3. Perform end-to-end protection via other parties: Information
	another party who does not intrinsically need the information to		passed via another party who does not intrinsically need the
	perform its function should be protected end-to-end to its		information to perform its function should be protected end-to-
	intended recipient. This guideline is general, and holds equally		end to its intended recipient. This guideline is general, and
	for sending TCP/IP packets, TLS connections, or application-layer		holds equally for sending TCP/IP packets, TLS connections, or
	interactions. As [I-D.iab-wire-image] notes, it is a useful		application-layer interactions. As [I-D.iab-wire-image] notes,
	design rule to avoid "accidental invariance" (the deployment of		it is a useful design rule to avoid "accidental invariance" (the
	on-path devices that over-time start to make assumptions about		deployment of on-path devices that over-time start to make
	protocols). However, it is also a necessary security design rule		assumptions about protocols). However, it is also a necessary
	to avoid "accidental disclosure" where information originally		security design rule to avoid "accidental disclosure" where
	thought to be benign and untapped over-time becomes a significant		information originally thought to be benign and untapped over-
	information leak. This guideline can also be applied for		time becomes a significant information leak. This guideline can
	different aspects of security, e.g., confidentiality and		also be applied for different aspects of security, e.g.,
	integrity protection, depending on what the specific need for		confidentiality and integrity protection, depending on what the
	information is in the other parties.		specific need for information is in the other parties.
	3. Minimizing passing of control functions to others: Any passing of		4. Minimize passing of control functions to others: Any passing of
	control functions to other parties should be minimized to guard		control functions to other parties should be minimized to guard
	against the potential misuse of those control functions. This		against the potential misuse of those control functions. This
	applies to both technical (e.g., nodes that assign resources) and		applies to both technical (e.g., nodes that assign resources) and
	process control functions (e.g., the ability to allocate number		process control functions (e.g., the ability to allocate number
	or develop extensions). Control functions can also become a		or develop extensions). Control functions can also become a
	matter of contest and power struggle, even in cases where their		matter of contest and power struggle, even in cases where their
	function as such is minimal, as we saw with the IANA transition		function as such is minimal, as we saw with the IANA transition
	debates.		debates.
	4. Avoiding centralized resources: While centralized components,		5. Avoid centralized resources: While centralized components,
	resources, and function provide usually a useful function, there		resources, and function provide usually a useful function, there
	are grave issues associated with them. Protocol and network		are grave issues associated with them. Protocol and network
	design should balance the benefits of centralized resources or		design should balance the benefits of centralized resources or
	control points against the threats arising from them. The		control points against the threats arising from them. The
	general guideline is to avoid such centralized resources when		general guideline is to avoid such centralized resources when
	possible. And if it is not possible, find a way to allow the		possible. And if it is not possible, find a way to allow the
	centralized resources to be selectable, depending on context and		centralized resources to be selectable, depending on context and
	user settings.		user settings.
	5. Explicit agreements: When users and their devices provide		6. Have explicit agreements: When users and their devices provide
	information to network entities, it would be beneficial to have		information to network entities, it would be beneficial to have
	an opportunity for the users to state their requirements		an opportunity for the users to state their requirements
	regarding the use of the information provided in this way. While		regarding the use of the information provided in this way. While
	the actual use of such requirements and the willingness of		the actual use of such requirements and the willingness of
	network entities to agree to them remains to be seen, at the		network entities to agree to them remains to be seen, at the
	moment even the technical means of doing this are limited. For		moment even the technical means of doing this are limited. For
	instance, it would be beneficial to be able to embed usage		instance, it would be beneficial to be able to embed usage
	requirements within popular data formats.		requirements within popular data formats.
	5. Potential Changes in IETF Analysis of Protocols		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.
	5.1. Changes in RFC 3552		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.
			6. Potential Changes in IETF Analysis of Protocols
			6.1. Changes in RFC 3552
	This memo suggests that changes maybe necessary in RFC 3552. One		This memo suggests that changes maybe necessary in RFC 3552. One
	initial, draft proposal for such changes would be this:		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
	skipping to change at page 12, line 29		skipping to change at page 15, line 5
	NEW:		NEW:
	3.x. Other endpoint compromise		3.x. Other endpoint compromise
	In this attack, the other endpoints in the protocol become		In this attack, the other endpoints in the protocol become
	compromised. As a result, they can, for instance, misuse any		compromised. As a result, they can, for instance, misuse any
	information that the end-system implementing a protocol has sent		information that the end-system implementing a protocol has sent
	to the compromised endpoint.		to the compromised endpoint.
	5.2. Changes in RFC 7258		6.2. Changes in RFC 7258
	This memo also suggests that additional guidelines may be necessary		This memo also suggests that additional guidelines may be necessary
	in RFC 7258. An initial, draft suggestion for starting point of		in RFC 7258. An initial, draft suggestion for starting point of
	those changes could be adding the following paragraph after the 2nd		those changes could be adding the following paragraph after the 2nd
	paragraph in Section 2:		paragraph in 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.3. System and Architecture Aspects		6.3. System and Architecture Aspects
	This definitely needs more attention from Internet technology		This definitely needs more attention from Internet technology
	developers and standards organizations. Here is one possible		developers and standards organizations. Here is one possible
	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.
	6. Other Work		7. Other Work
	See, for instance, [I-D.farrell-etm].		See, for instance, [I-D.farrell-etm].
	7. Conclusions		8. Conclusions
	More work is needed in this area. To start with, Internet technology		More work is needed in this area. To start with, Internet technology
	developers need to be better aware of the issues beyond		developers need to be better aware of the issues beyond
	communications security, and consider them in design. At the IETF it		communications security, and consider them in design. At the IETF it
	would be beneficial to include some of these considerations in the		would be beneficial to include some of these considerations in the
	usual systematic security analysis of technologies under development.		usual systematic security analysis of technologies under development.
	In particular, when the IETF develops infrastructure technology for		In particular, when the IETF develops infrastructure technology for
	the Internet (such as routing or naming systems), considering the		the Internet (such as routing or naming systems), considering the
	impacts of data generated by those technologies is important.		impacts of data generated by those technologies is important.
	skipping to change at page 13, line 38		skipping to change at page 16, line 12
	provide the right security for various applications. However, more		provide the right security for various applications. However, more
	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 architecture-discuss mailing list.		privately or on the architecture-discuss mailing list.
	8. Acknowledgements		9. Acknowledgements
	The author would like to thank John Mattsson, Mirja Kuehlewind,		The author would like to thank John Mattsson, Mirja Kuehlewind,
	Alissa Cooper, Stephen Farrell, Eric Rescorla, Simone Ferlin,		Alissa Cooper, Stephen Farrell, Eric Rescorla, Simone Ferlin,
	Kathleen Moriarty, Brian Trammell, Mark Nottingham, Christian		Kathleen Moriarty, Brian Trammell, Mark Nottingham, Christian
	Huitema, Karl Norrman, Ted Hardie, Mohit Sethi, Phillip Hallam-Baker,		Huitema, Karl Norrman, Ted Hardie, Mohit Sethi, Phillip Hallam-Baker,
	Goran Eriksson and the IAB for interesting discussions in this		Goran Eriksson and the IAB for interesting discussions in this
	problem space.		problem space. The author would also like to thank all members of
			the 2019 Design Expectations vs. Deployment Reality (DEDR) IAB
			workshop held in Kirkkonummi, Finland.
	9. Informative References		10. Informative References
	[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-00 (work in progress), April 2019.		draft-farrell-etm-03 (work in progress), July 2019.
	[I-D.iab-wire-image]		[I-D.iab-wire-image]
	Trammell, B. and M. Kuehlewind, "The Wire Image of a		Trammell, B. and M. Kuehlewind, "The Wire Image of a
	Network Protocol", draft-iab-wire-image-01 (work in		Network Protocol", draft-iab-wire-image-01 (work in
	progress), November 2018.		progress), November 2018.
	[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),
	December 2018.		December 2018.
	skipping to change at page 14, line 27		skipping to change at page 16, line 51
	and Secure Transport", draft-ietf-quic-transport-20 (work		and Secure Transport", draft-ietf-quic-transport-20 (work
	in progress), April 2019.		in progress), April 2019.
	[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-03 (work in progress), March 2019.		ietf-tls-esni-03 (work in progress), March 2019.
	[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-07 (work in progress), March		nottingham-for-the-users-08 (work in progress), June 2019.
	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-
	<https://www.rfc-editor.org/info/rfc3552>.		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., and J. Ash, "A Path Computation
	Element (PCE)-Based Architecture", RFC 4655,		Element (PCE)-Based Architecture", RFC 4655,
	DOI 10.17487/RFC4655, August 2006,		DOI 10.17487/RFC4655, August 2006, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc4655>.		editor.org/info/rfc4655>.
	[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>.
	[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict		[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
	Transport Security (HSTS)", RFC 6797,		Transport Security (HSTS)", RFC 6797,
	DOI 10.17487/RFC6797, November 2012,		DOI 10.17487/RFC6797, November 2012, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6797>.		editor.org/info/rfc6797>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973,		Considerations for Internet Protocols", RFC 6973,
	DOI 10.17487/RFC6973, July 2013,		DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6973>.		editor.org/info/rfc6973>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/info/rfc7258>.		2014, <https://www.rfc-editor.org/info/rfc7258>.
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April		Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	2015, <https://www.rfc-editor.org/info/rfc7469>.		2015, <https://www.rfc-editor.org/info/rfc7469>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7540>.		editor.org/info/rfc7540>.
	[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)		[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
	Server Identity Check Procedure for Email-Related		Server Identity Check Procedure for Email-Related
	Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,		Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
	<https://www.rfc-editor.org/info/rfc7817>.		<https://www.rfc-editor.org/info/rfc7817>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	skipping to change at page 16, line 6		skipping to change at page 18, line 28
	[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., Reed, D., and D. Clark, "End-To-End Arguments
	in System Design", ACM TOCS, Vol 2, Number 4, November		in System Design", ACM TOCS, Vol 2, Number 4, pp 277-288 ,
	1984, pp 277-288. , n.d..		November 1984.
			[Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes,
			Disclosures, and Outcomes", USENIX , 2016.
	Author's Address		Author's Address
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
End of changes. 34 change blocks.
	70 lines changed or deleted		200 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/