< draft-farrell-perpass-attack-01.txt		draft-farrell-perpass-attack-02.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 4, 2014 December 1, 2013		Expires: June 6, 2014 December 3, 2013
	Pervasive Monitoring is an Attack		Pervasive Monitoring is an Attack
	draft-farrell-perpass-attack-01.txt		draft-farrell-perpass-attack-02.txt
	Abstract		Abstract
	The IETF has consensus that pervasive monitoring is a technical		The IETF has consensus that pervasive monitoring is a technical
	attack that should be mitigated in the design of IETF protocols,		attack that should be mitigated in the design of IETF protocols,
	where possible.		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
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 4, 2014.		This Internet-Draft will expire on June 6, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	expressed strong agreement that this was an attack that should be		expressed strong agreement that this was an attack that should be
	mitigated where possible via the design of protocols that make		mitigated where possible via the design of protocols that make
	pervasive monitoring significantly more expensive or infeasible.		pervasive monitoring significantly more expensive or infeasible.
	This Best Current Practice (BCP) formally documents that consensus,		This Best Current Practice (BCP) formally documents that consensus,
	having been through an IETF last call.		having been through an IETF last call.
	For the purposes of this BCP "pervasive monitoring" means very		For the purposes of this BCP "pervasive monitoring" means very
	widespread privacy-invasive gathering of protocol artefacts including		widespread privacy-invasive gathering of protocol artefacts including
	application content, protocol meta-data (such as headers) or keys		application content, protocol meta-data (such as headers) or keys
	used to secure protocols. Other forms of traffic analysis, for		used to secure protocols. Other forms of traffic analysis, for
	example, timing or measuring packet sizes can also be used for		example, correlation, timing or measuring packet sizes can also be
	pervasive monitoring.		used for pervasive monitoring.
	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. In the		to enforce the opponent's will on the attacked party. In the
	Internet, the term is used to refer to a behavior that subverts the		Internet, the term is used to refer to a behavior that subverts the
	intent of a communicator without the agreement of the parties to the		intent of a communicator without the agreement of the parties to the
	communication. It may change the content of the communication,		communication. It may change the content of the communication,
	record the content of the communication, or through correlation with		record the content of the communication, or through correlation with
	other communication events or attempts, reveal information the		other communication events or attempts, reveal information the
	communicator did not intend to be revealed. It may also have other		communicator did not intend to be revealed. It may also have other
	effects that similarly subvert the intent of a communicator. RFC		effects that similarly subvert the intent of a communicator.
	4949 contains a more complete definition for the term "attack" as		[RFC4949] contains a more complete definition for the term "attack"
	used here. [RFC4949] Note that we also use the term in the singular		as used here. We also use the term in the singular here, even though
	here, even though pervasive monitoring in reality may require a		pervasive monitoring in reality may require a multi-faceted set of
	multi-faceted set of coordinated attacks.		coordinated attacks.
	In particular, the term "attack", when used technically, implies		In particular, the term "attack", when used technically, implies
	nothing about the motivation of the actor mounting the attack. The		nothing about the motivation of the actor mounting the attack. The
	motivation behind pervasive monitoring is not relevant for this		motivation behind pervasive monitoring is not relevant for this
	document, but can range from non-targeted nation-state surveillance,		document, but can range from non-targeted nation-state surveillance,
	to legal but privacy-unfriendly purposes by commercial enterprises,		to legal but privacy-unfriendly purposes by commercial enterprises,
	to illegal purposes by criminals. The same techniques can be used		to illegal purposes by criminals. The same techniques can be used
	regardless of motivation and we cannot defend against the most		regardless of motivation and we cannot defend against the most
	nefarious actors while allowing monitoring by other actors no matter		nefarious actors while allowing monitoring by other actors no matter
	how benevolent some might consider them to be. As technology has		how benevolent some might consider them to be. As technology
	advanced techniques that were once only available in constrained		advances, techniques that were once only available to extremely well
	environments have become more widely accessible. Mitigating this		funded actors become more widely accessible. Mitigating this attack
	attack is therefore a protection against wider usage of pervasive		is therefore a protection against wider usage of pervasive
	monitoring.		monitoring.
	2. And we'll work to Mitigate the Attack		2. And We Will Continue to Mitigate the Attack
	The IETF also has consensus to, where possible, work to mitigate the		The IETF also has consensus to, where possible, work to mitigate the
	technical parts of the pervasive monitoring attack, in just the same		technical parts of the pervasive monitoring attack, in just the same
	way as we do with any other protocol vulnerability.		way as we continually do for these and any other protocol
			vulnerability.
	There are various ways in which IETF protocols can be designed in		There are various ways in which IETF protocols can be designed in
	order to mitigate pervasive monitoring, but those will change over		order to mitigate pervasive monitoring, but those will change over
	time as mitigation and attack techniques develop and so are not		time as mitigation and attack techniques develop and so are not
	described here. This BCP simply records the consensus to design		described here. This BCP simply records the consensus to design
	protocols so as to mitigate the attack, where possible.		protocols so as to mitigate the attack, where possible.
	Note that more limited-scope monitoring to assist with network		More limited-scope monitoring to assist with network management that
	management or that is required in order to operate the network or an		is required in order to operate the network or an application is not
	application are not considered pervasive monitoring. There is though		considered pervasive monitoring. There is though a clear potential
	a clear potential for network management mechanisms to be abused as		for such limited monitoring mechanisms to be abused as part of
	part of pervasive monitoring, so this tension needs careful		pervasive monitoring, so this tension needs careful consideration in
	consideration in protocol design. Making networks unmanageable in		protocol design. Making networks unmanageable in order to mitigate
	order to mitigate pervasive monitoring would not be an acceptable		pervasive monitoring would not be an acceptable outcome. But
	outcome. But equally, ignoring pervasive monitoring in designing		equally, ignoring pervasive monitoring in designing network
	network management mechanisms would go against the consensus		management mechanisms would go against the consensus documented in
	documented in this BCP. An appropriate balance will likely emerge		this BCP. An appropriate balance will likely emerge over time as
	over time as real instances of this tension are considered.		real instances of this tension are considered.
	It is also important to note that the term "mitigation" is a		It is also important to note that the term "mitigation" is a
	technical term that does not necessarily imply an ability to		technical term that does not necessarily imply an ability to
	completely prevent or thwart an attack. As in common English usage,		completely prevent or thwart an attack. As in common English usage,
	this term is used here in the sense of "make less severe, serious, or		this term is used here in the sense of "make less severe, serious, or
	painful." [OED] In this case, designing IETF protocols to mitigate		painful." [OED] In this case, designing IETF protocols to mitigate
	pervasive monitoring will almost certainly not completely prevent		pervasive monitoring will almost certainly not completely prevent
	such from happening, but can significantly increase the cost of such		such from happening, but can significantly increase the cost of such
	monitoring or force what was covert monitoring to be more overt or		monitoring or force what was covert monitoring to be more overt or
	more likely to be detected (possibly later) via other means. And		more likely to be detected (possibly later) via other means. And
	even where the IETF has done this work well and that has been fully		even where the IETF has done this work well and that has been fully
	deployed, there will still be some privacy-relevant information that		deployed, there will still be some privacy-relevant information that
	will inevitably be disclosed by protocols.		will inevitably be disclosed by protocols.
	While RFC 4949 does not contain a definition for the term mitigation,		While RFC 4949 does not contain a definition for the term mitigation,
	we prefer it here to the term countermeasure which is defined in RFC		we prefer it here to the term countermeasure which is defined in RFC
	4949 since the latter term is more often understood to mean putting		4949 since the latter term is more often understood to mean putting
	in place a more fully effective mitigation of an attack.		in place a more fully effective mitigation of an attack.
	Finally, we note that the IETF is not equipped to tackle the non-		Finally, we note that the IETF is not equipped to tackle the non-
	technical aspects of mitigating pervasive surveillance. Others will		technical aspects of mitigating pervasive surveillance. Others need
	be required to step forward to tackle those if pervasive monitoring		to step forward to tackle those if pervasive monitoring is to be
	is to be fully addressed.		fully addressed.
	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 IESG and		and [RFC2804] have been published as joint products of the IESG and
	IAB. However, since those documents were published, the IETF and IAB		IAB. However, since those documents were published, the IETF and IAB
	have separated their publication "streams" as described in [RFC4844]		have separated their publication "streams" as described in [RFC4844]
	and [RFC5741]. This document was initiated by both the IESG and IAB,		and [RFC5741]. This document was initiated by both the IESG and IAB,
	but it is published as an IETF-stream consensus document, having		but it is published as an IETF-stream consensus document, having
	garnered the consensus of the IETF as approved by the IESG.		garnered the consensus of the IETF as approved by the IESG.
	4. Security Considerations		4. Security Considerations
	This BCP is all about privacy. More information about the		This BCP 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 that resulted in changes to this text: Jari		for useful suggestions that resulted in changes to this text: Jari
	Arkko, Fred Baker, Marc Blanchet, Brian Carpenter, Benoit Claise,		Arkko, Fred Baker, Marc Blanchet, Brian Carpenter, Benoit Claise,
	Spencer Dawkins, Adrian Farrel, Russ Housley, Joel Jaeggli, Eliot		Spencer Dawkins, Adrian Farrel, Russ Housley, Joel Jaeggli, Eliot
	Lear, Barry Leiba, Ted Lemon, Erik Nordmark, Pete Resnick, and Peter		Lear, Barry Leiba, Ted Lemon, Erik Nordmark, Pete Resnick, Peter
	StAndre. Additionally, we would like to thank all those who		Saint-Andre, and Sean Turner. Additionally, we would like to thank
	contributed suggestions on how to improve Internet security and		all those who contributed suggestions on how to improve Internet
	privacy or who commented on this on various IETF mailing lists, such		security and privacy or who commented on this on various IETF mailing
	as the ietf@ietf.org and the perpass@ietf.org lists.		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.
	[OED] Stevenson, Angus, "Oxford Dictionary of English", Oxford		[OED] Stevenson, Angus, "Oxford Dictionary of English", Oxford
	University Press http://www.oxforddictionaries.com/		University Press http://www.oxforddictionaries.com/
	definition/english/mitigate, 2010.		definition/english/mitigate, 2010.
	[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.
End of changes. 13 change blocks.
	37 lines changed or deleted		37 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/