< draft-farrell-perpass-attack-03.txt		draft-farrell-perpass-attack-04.txt >
	Network Working Group S. Farrell		Network Working Group S. Farrell
	Internet-Draft Trinity College Dublin		Internet-Draft Trinity College Dublin
	Intended status: BCP H. Tschofenig		Intended status: BCP H. Tschofenig
	Expires: June 23, 2014 December 20, 2013		Expires: July 22, 2014 January 18, 2014
	Pervasive Monitoring is an Attack		Pervasive Monitoring is an Attack
	draft-farrell-perpass-attack-03.txt		draft-farrell-perpass-attack-04.txt
	Abstract		Abstract
	Pervasive monitoring is a technical attack that should be mitigated		Pervasive monitoring is a technical attack that should be mitigated
	in the design of IETF protocols, where possible.		in the design of IETF protocols, where possible.
	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.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 23, 2014.		This Internet-Draft will expire on July 22, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Pervasive Monitoring is Indistinguishable from an Attack		1. Pervasive Monitoring is a Widespread Attack on Privacy
	The technical plenary of the November 2013 IETF meeting		Pervasive Monitoring (PM) is widespread (and often covert)
	[IETF88Plenary] discussed pervasive monitoring (or surveillance)		surveillance through intrusive gathering of protocol artefacts,
	which requires the monitoring party to take actions that are		including application content, or protocol meta-data such as headers.
	indistinguishable from an attack on Internet communications.		Active or passive wiretaps and traffic analysis, (e.g., correlation,
	Participants at that meeting therefore expressed strong agreement		timing or measuring packet sizes), or subverting the cryptographic
	that this was an attack that should be mitigated where possible via		keys used to secure protocols can also be used as part of pervasive
	the design of protocols that make pervasive monitoring significantly		monitoring.
	more expensive or infeasible. This Best Current Practice (BCP, see
	[RFC2026] Section 5) formally documents that consensus.
	For the purposes of this document "pervasive monitoring" means often		The IETF community's technical assessment is that PM is an attack on
	covert and very widespread intrusive gathering of protocol artefacts		the privacy of Internet users and organizations. PM is distinguished
	including application content, protocol meta-data such as headers, or		by being indiscriminate and very large-scale, rather than by
	cryptographic keys used to secure protocols. Active or passive		introducing new types of technical compromise. The IETF community
	wiretaps, traffic analysis, correlation, timing or measuring packet		has expressed strong agreement that PM is an attack that needs to be
	sizes can also be used as part of pervasive monitoring.		mitigated where possible, via the design of protocols that make PM
			significantly more expensive or infeasible. Pervasive Monitoring was
			discussed at the technical plenary of the November 2013 IETF meeting
			[IETF88Plenary] and then through extensive exchanges on IETF mailing
			lists. This document records the IETF community's consensus and
			establishes the technical nature of PM.
	The term "attack" is used here in a technical sense that differs		The term "attack" is used here in a technical sense that differs
	somewhat from common English usage. In common English usage, an		somewhat from common English usage. In common English usage, an
	"attack" is an aggressive action perpetrated by an opponent, intended		attack is an aggressive action perpetrated by an opponent, intended
	to enforce the opponent's will on the attacked party. Here, the term		to enforce the opponent's will on the attacked party. The term is
	is used to refer to a behavior that subverts the intent of a		used here to refer to behavior that subverts the intent of
	communicator without the agreement of the parties to the		communicating parties without the agreement of those parties. An
	communication. It may change the content of the communication,		attack may change the content of the communication, record the
	record the content of the communication, or through correlation with		content or external characteristics of the communication, or through
	other communication events, reveal information the communicator did		correlation with other communication events, reveal information the
	not intend to be revealed. It may also have other effects that		parties did not intend to be revealed. It may also have other
	similarly subvert the intent of a communicator. [RFC4949] contains a		effects that similarly subvert the intent of a communicator.
	more complete definition for the term "attack." We also use the term		[RFC4949] contains a more complete definition for the term attack.
	in the singular here, even though pervasive monitoring in reality may		We also use the term in the singular here, even though PM in reality
	require a multi-faceted set of coordinated attacks.		may require a multi-faceted set of coordinated attacks.
	In particular, the term "attack", when used technically, implies		In particular, the term attack, used technically, implies nothing
	nothing about the motivation of the actor mounting the attack. The		about the motivation of the actor mounting the attack. The
	motivation behind pervasive monitoring is not relevant for this		motivation for PM is not relevant for this document, but can range
	document, but can range from non-targeted nation-state surveillance,		from non-targeted nation-state surveillance, to legal but privacy-
	to legal but privacy-unfriendly purposes by commercial enterprises,		unfriendly purposes by commercial enterprises, to illegal actions by
	to illegal purposes by criminals. The same techniques can be used		criminals. The same techniques can be used regardless of motivation.
	regardless of motivation and we cannot defend against the most		Thus we cannot defend against the most nefarious actors while
	nefarious actors while allowing monitoring by other actors no matter		allowing monitoring by other actors no matter how benevolent some
	how benevolent some might consider them to be. As technology		might consider them to be, since the actions required are
	advances, techniques that were once only available to extremely well		indistinguishable from other attacks.
	funded actors become more widely accessible. Mitigating this attack
	is therefore a protection against wider usage of pervasive
	monitoring.
	2. The IETF will work to Mitigate Pervasive Monitoring		2. The IETF will work to Mitigate Pervasive Monitoring
	"Mitigation" is a technical term that does not imply an ability to		"Mitigation" is a technical term that does not imply an ability to
	completely prevent or thwart an attack. Protocols that mitigate		completely prevent or thwart an attack. Protocols that mitigate PM
	pervasive monitoring will not prevent the attack, but can		will not prevent the attack, but can significantly change the threat.
	significantly change the threat. (See the diagram on page 24 of RFC		(See the diagram on page 24 of RFC 4949 for how the terms attack and
	4949 for how the terms attack and threat are related.) This can		threat are related.) This can significantly increase the cost of
	significantly increase the cost of attacking, force what was covert		attacking, force what was covert to be overt, or make the attack more
	to be overt, or make the attack more likely to be detected, possibly		likely to be detected, possibly later.
	later.
	IETF standards already provide mechanisms to protect Internet		IETF standards already provide mechanisms to protect Internet
	communications and there are guidelines [RFC3552] for applying these		communications and there are guidelines [RFC3552] for applying these
	in protocol design. But those generally do not consider pervasive		in protocol design. But those generally do not consider PM, the
	monitoring, the confidentiality of protocol meta-data, countering		confidentiality of protocol meta-data, countering traffic analysis
	traffic analysis nor data minimisation. [RFC6973] And in all cases,		nor data minimisation. [RFC6973] In all cases, there will remain
	there will remain some privacy-relevant information that is		some privacy-relevant information that is inevitably disclosed by
	inevitably disclosed by protocols.		protocols. As technology advances, techniques that were once only
			available to extremely well funded actors become more widely
			accessible. Mitigating PM is therefore a protection against a wide
			range of similar attacks.
	It is nonetheless timely to revisit the security and privacy		It is therefore timely to revisit the security and privacy properties
	properties of our standards. The IETF will work to mitigate the		of our standards. The IETF will work to mitigate the technical
	technical parts of the pervasive monitoring threat, just as we do for		aspects of PM, just as we do for protocol vulnerabilities in general.
	other protocol vulnerabilities. The ways in which IETF protocols		The ways in which IETF protocols mitigate PM will change over time as
	mitigate pervasive monitoring will change over time as mitigation and		mitigation and attack techniques evolve and so are not described
	attack techniques evolve and so are not described here.		here.
	Those developing IETF specifications need to be able to describe how		Those developing IETF specifications need to be able to describe how
	they have considered pervasive monitoring, and, if the attack is		they have considered PM, and, if the attack is relevant to the work
	relevant to the work to be published, be able to justify related		to be published, be able to justify related design decisions. This
	design decisions. This does not mean a new "pervasive monitoring		does not mean a new "pervasive monitoring considerations" section is
	considerations" section is needed in IETF documentation. It means		needed in IETF documentation. It means that, if asked, there needs
	that, if asked, there needs to be a good answer to the question "is		to be a good answer to the question "is pervasive monitoring relevant
	pervasive monitoring relevant to this work and if so how has it been		to this work and if so how has it been considered?"
	addressed?"
	While pervasive monitoring is an attack, other forms of monitoring		In particular, architectural decisions, including which existing
	can be beneficial and not part of any attack, e.g. network management		technology is re-used, may significantly impact the vulnerability of
	functions monitor packets or flows, anti-spam mechanisms see mail		a protocol to PM. Those developing IETF specifications therefore
	message content and monitoring can even be a mitigation for pervasive		need to consider mitigating PM when making these architectural
	monitoring in the case of Certificate Transparency. [RFC6962] There		decisions and be prepared to justify their decisions. Getting
	is though a clear potential for monitoring mechanisms to be abused		adequate, early review of architectural decisions including whether
	for pervasive monitoring, so this tension needs careful consideration		appropriate mitigation of PM can be made is important. Revisiting
	in protocol design. Making networks unmanageable to mitigate		these architectural decisions late in the process is very costly.
	pervasive monitoring is not an acceptable outcome, but ignoring
	pervasive monitoring would go against the consensus documented in		While PM is an attack, other forms of monitoring can be beneficial
	this BCP. An appropriate balance will likely emerge over time as		and not part of any attack, e.g. network management functions monitor
	real instances of this tension are considered.		packets or flows and anti-spam mechanisms need to see mail message
			content. Some monitoring can even be part of the mitigation for PM,
			for example Certificate Transparency [RFC6962] involves monitoring
			Public Key Infrastructure in ways that could detect some PM attack
			techniques. There is though a clear potential for monitoring
			mechanisms to be abused for PM, so this tension needs careful
			consideration in protocol design. Making networks unmanageable to
			mitigate PM is not an acceptable outcome, but ignoring PM would go
			against the consensus documented here. An appropriate balance will
			emerge over time as real instances of this tension are considered.
	Finally, the IETF, as a standards development organisation, does not		Finally, the IETF, as a standards development organisation, does not
	control the implementation or deployment of our specifications		control the implementation or deployment of our specifications
	(though IETF participants do develop many implementations), nor does		(though IETF participants do develop many implementations), nor does
	the IETF specify all layers of the protocol stack. And the non-		the IETF standardise all layers of the protocol stack. Moreover, the
	technical (e.g. legal and political) aspects of mitigating pervasive		non-technical (e.g. legal and political) aspects of mitigating
	monitoring are outside of the scope of the IETF. The broader		pervasive monitoring are outside of the scope of the IETF. The
	Internet community will need to step forward to tackle pervasive		broader Internet community will need to step forward to tackle PM, if
	monitoring, if it is to be fully addressed.		it is to be fully addressed.
			To summarise: current capabilities permit some actors to monitor
			content and meta-data across the Internet at a scale never before
			seen. This pervasive monitoring is an attack on Internet privacy.
			The IETF will strive to produce specifications that mitigate
			pervasive monitoring attacks.
	3. Process Note		3. Process Note
	In the past, architectural statements of this sort, e.g., [RFC1984]		In the past, architectural statements of this sort, e.g., [RFC1984]
	and [RFC2804] have been published as joint products of the Internet		and [RFC2804] have been published as joint products of the Internet
	Engineering Steering Group (IESG) and the Internet Architecture Board		Engineering Steering Group (IESG) and the Internet Architecture Board
	(IAB). However, since those documents were published, the IETF and		(IAB). However, since those documents were published, the IETF and
	IAB have separated their publication "streams" as described in		IAB have separated their publication "streams" as described in
	[RFC4844] and [RFC5741]. This document was initiated by both the		[RFC4844] and [RFC5741]. This document was initiated by both the
	IESG and IAB, but is published as an IETF-stream consensus document,		IESG and IAB, but is published as an IETF-stream consensus document,
	in order to ensure that it properly reflects the consensus of the		in order to ensure that it properly reflects the consensus of the
	IETF community as a whole.		IETF community as a whole.
	[[Note (to be removed before publication): This draft is written as		[[Note (to be removed before publication): This draft is written as
	if IETF consensus has been established for the text.]]		if IETF consensus has been established for the text.]]
	4. Security Considerations		4. Security Considerations
	This BCP is entirely about privacy. More information about the		This document is entirely about privacy. More information about the
	relationship between security and privacy threats can be found in		relationship between security and privacy threats can be found in
	[RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses		[RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses
	surveillance as a combined security-privacy threat.		surveillance as a combined security-privacy threat.
	5. IANA Considerations		5. IANA Considerations
	There are none. We hope the RFC editor deletes this section before		There are none. We hope the RFC editor deletes this section before
	publication.		publication.
	6. Acknowledgements		6. Acknowledgements
	We would like to thank the participants of the IETF 88 technical		We would like to thank the participants of the IETF 88 technical
	plenary for their feedback. Thanks in particular to the following		plenary for their feedback. Thanks in particular to the following
	for useful suggestions or comments: Jari Arkko, Fred Baker, Marc		for useful suggestions or comments: Jari Arkko, Fred Baker, Marc
	Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit		Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit
	Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria,		Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria,
	Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Ted Hardie, Sam		Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Ted Hardie, Sam
	Hartmann, Bjoern Hoehrmann, Phillip Hallam-Baker, Russ Housley, Joel		Hartmann, Paul Hoffman, Bjoern Hoehrmann, Phillip Hallam-Baker, Russ
	Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted Lemon,		Housley, Joel Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted
	Subrahamian Moonesamy, Erik Nordmark, Pete Resnick, Peter Saint-		Lemon, Subramanian Moonesamy, Erik Nordmark, Pete Resnick, Peter
	Andre, Andrew Sullivan, Sean Turner, and Stefan Winter.		Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas Weaver, Stefan
	Additionally, we would like to thank all those who contributed		Winter, and Lloyd Wood. Additionally, we would like to thank all
	suggestions on how to improve Internet security and privacy or who		those who contributed suggestions on how to improve Internet security
	commented on this on various IETF mailing lists, such as the		and privacy or who commented on this on various IETF mailing lists,
	ietf@ietf.org and the perpass@ietf.org lists.		such as the ietf@ietf.org and the perpass@ietf.org lists.
	7. Informative References		7. Informative References
	[IETF88Plenary]		[IETF88Plenary]
	IETF, "IETF 88 Plenary Meeting Materials", URL:		IETF, "IETF 88 Plenary Meeting Materials", URL:
	https://datatracker.ietf.org/meeting/88/materials.html,		https://datatracker.ietf.org/meeting/88/materials.html,
	Nov 2013.		Nov 2013.
	[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG		[RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG
	Statement on Cryptographic Technology and the Internet",		Statement on Cryptographic Technology and the Internet",
	RFC 1984, August 1996.		RFC 1984, August 1996.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.
	[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,		[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
	May 2000.		May 2000.
	[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,
	July 2003.		July 2003.
	[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC		[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
	Series and RFC Editor", RFC 4844, July 2007.		Series and RFC Editor", RFC 4844, July 2007.
End of changes. 18 change blocks.
	99 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/