< draft-farrell-perpass-attack-02.txt		draft-farrell-perpass-attack-03.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 6, 2014 December 3, 2013		Expires: June 23, 2014 December 20, 2013
	Pervasive Monitoring is an Attack		Pervasive Monitoring is an Attack
	draft-farrell-perpass-attack-02.txt		draft-farrell-perpass-attack-03.txt
	Abstract		Abstract
	The IETF has consensus that pervasive monitoring is a technical		Pervasive monitoring is a technical attack that should be mitigated
	attack that should be mitigated in the design of IETF protocols,		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
	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 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 6, 2014.		This Internet-Draft will expire on June 23, 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
	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. It's an Attack		1. Pervasive Monitoring is Indistinguishable from an Attack
	[[Note (to be removed before publication): This draft is written as
	if IETF consensus has been established for the text.]]
	The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive		The technical plenary of the November 2013 IETF meeting
	monitoring. Such pervasive surveillance requires the monitoring		[IETF88Plenary] discussed pervasive monitoring (or surveillance)
	party to take actions that are indistinguishable from an attack on		which requires the monitoring party to take actions that are
	Internet communications. Participants at that meeting therefore		indistinguishable from an attack on Internet communications.
	expressed strong agreement that this was an attack that should be		Participants at that meeting therefore expressed strong agreement
	mitigated where possible via the design of protocols that make		that this was an attack that should be mitigated where possible via
	pervasive monitoring significantly more expensive or infeasible.		the design of protocols that make pervasive monitoring significantly
	This Best Current Practice (BCP) formally documents that consensus,		more expensive or infeasible. This Best Current Practice (BCP, see
	having been through an IETF last call.		[RFC2026] Section 5) formally documents that consensus.
	For the purposes of this BCP "pervasive monitoring" means very		For the purposes of this document "pervasive monitoring" means often
	widespread privacy-invasive gathering of protocol artefacts including		covert and very widespread intrusive gathering of protocol artefacts
	application content, protocol meta-data (such as headers) or keys		including application content, protocol meta-data such as headers, or
	used to secure protocols. Other forms of traffic analysis, for		cryptographic keys used to secure protocols. Active or passive
	example, correlation, timing or measuring packet sizes can also be		wiretaps, traffic analysis, correlation, timing or measuring packet
	used for pervasive monitoring.		sizes can also be used as part of 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. Here, the term
	Internet, the term is used to refer to a behavior that subverts the		is used to refer to a behavior that subverts the intent of a
	intent of a communicator without the agreement of the parties to the		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, reveal information the communicator did
	communicator did not intend to be revealed. It may also have other		not intend to be revealed. It may also have other effects that
	effects that similarly subvert the intent of a communicator.		similarly subvert the intent of a communicator. [RFC4949] contains a
	[RFC4949] contains a more complete definition for the term "attack"		more complete definition for the term "attack." We also use the term
	as used here. We also use the term in the singular here, even though		in the singular here, even though pervasive monitoring in reality may
	pervasive monitoring in reality may require a multi-faceted set of		require a 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		how benevolent some might consider them to be. As technology
	advances, techniques that were once only available to extremely well		advances, techniques that were once only available to extremely well
	funded actors become more widely accessible. Mitigating this attack		funded actors become more widely accessible. Mitigating this attack
	is therefore a protection against wider usage of pervasive		is therefore a protection against wider usage of pervasive
	monitoring.		monitoring.
	2. And We Will Continue to Mitigate the Attack		2. The IETF will work to Mitigate Pervasive Monitoring
	The IETF also has consensus to, where possible, work to mitigate the		"Mitigation" is a technical term that does not imply an ability to
	technical parts of the pervasive monitoring attack, in just the same		completely prevent or thwart an attack. Protocols that mitigate
	way as we continually do for these and any other protocol		pervasive monitoring will not prevent the attack, but can
	vulnerability.		significantly change the threat. (See the diagram on page 24 of RFC
			4949 for how the terms attack and threat are related.) This can
			significantly increase the cost of attacking, force what was covert
			to be overt, or make the attack more likely to be detected, possibly
			later.
	There are various ways in which IETF protocols can be designed in		IETF standards already provide mechanisms to protect Internet
	order to mitigate pervasive monitoring, but those will change over		communications and there are guidelines [RFC3552] for applying these
	time as mitigation and attack techniques develop and so are not		in protocol design. But those generally do not consider pervasive
	described here. This BCP simply records the consensus to design		monitoring, the confidentiality of protocol meta-data, countering
	protocols so as to mitigate the attack, where possible.		traffic analysis nor data minimisation. [RFC6973] And in all cases,
			there will remain some privacy-relevant information that is
			inevitably disclosed by protocols.
	More limited-scope monitoring to assist with network management that		It is nonetheless timely to revisit the security and privacy
	is required in order to operate the network or an application is not		properties of our standards. The IETF will work to mitigate the
	considered pervasive monitoring. There is though a clear potential		technical parts of the pervasive monitoring threat, just as we do for
	for such limited monitoring mechanisms to be abused as part of		other protocol vulnerabilities. The ways in which IETF protocols
	pervasive monitoring, so this tension needs careful consideration in		mitigate pervasive monitoring will change over time as mitigation and
	protocol design. Making networks unmanageable in order to mitigate		attack techniques evolve and so are not described here.
	pervasive monitoring would not be an acceptable outcome. But
	equally, ignoring pervasive monitoring in designing network
	management mechanisms would go against the consensus documented in
	this BCP. An appropriate balance will likely emerge over time as
	real instances of this tension are considered.
	It is also important to note that the term "mitigation" is a		Those developing IETF specifications need to be able to describe how
	technical term that does not necessarily imply an ability to		they have considered pervasive monitoring, and, if the attack is
	completely prevent or thwart an attack. As in common English usage,		relevant to the work to be published, be able to justify related
	this term is used here in the sense of "make less severe, serious, or		design decisions. This does not mean a new "pervasive monitoring
	painful." [OED] In this case, designing IETF protocols to mitigate		considerations" section is needed in IETF documentation. It means
	pervasive monitoring will almost certainly not completely prevent		that, if asked, there needs to be a good answer to the question "is
	such from happening, but can significantly increase the cost of such		pervasive monitoring relevant to this work and if so how has it been
	monitoring or force what was covert monitoring to be more overt or		addressed?"
	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
	deployed, there will still be some privacy-relevant information that
	will inevitably be disclosed by protocols.
	While RFC 4949 does not contain a definition for the term mitigation,		While pervasive monitoring is an attack, other forms of monitoring
	we prefer it here to the term countermeasure which is defined in RFC		can be beneficial and not part of any attack, e.g. network management
	4949 since the latter term is more often understood to mean putting		functions monitor packets or flows, anti-spam mechanisms see mail
	in place a more fully effective mitigation of an attack.		message content and monitoring can even be a mitigation for pervasive
			monitoring in the case of Certificate Transparency. [RFC6962] There
			is though a clear potential for monitoring mechanisms to be abused
			for pervasive monitoring, so this tension needs careful consideration
			in protocol design. Making networks unmanageable to mitigate
			pervasive monitoring is not an acceptable outcome, but ignoring
			pervasive monitoring would go against the consensus documented in
			this BCP. An appropriate balance will likely emerge over time as
			real instances of this tension are considered.
	Finally, we note that the IETF is not equipped to tackle the non-		Finally, the IETF, as a standards development organisation, does not
	technical aspects of mitigating pervasive surveillance. Others need		control the implementation or deployment of our specifications
	to step forward to tackle those if pervasive monitoring is to be		(though IETF participants do develop many implementations), nor does
	fully addressed.		the IETF specify all layers of the protocol stack. And the non-
			technical (e.g. legal and political) aspects of mitigating pervasive
			monitoring are outside of the scope of the IETF. The broader
			Internet community will need to step forward to tackle pervasive
			monitoring, if it is to be 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 Internet
	IAB. However, since those documents were published, the IETF and IAB		Engineering Steering Group (IESG) and the Internet Architecture Board
	have separated their publication "streams" as described in [RFC4844]		(IAB). However, since those documents were published, the IETF and
	and [RFC5741]. This document was initiated by both the IESG and IAB,		IAB have separated their publication "streams" as described in
	but it is published as an IETF-stream consensus document, having		[RFC4844] and [RFC5741]. This document was initiated by both the
	garnered the consensus of the IETF as approved by the IESG.		IESG and IAB, but is published as an IETF-stream consensus document,
			in order to ensure that it properly reflects the consensus of the
			IETF community as a whole.
			[[Note (to be removed before publication): This draft is written as
			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 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 or comments: Jari Arkko, Fred Baker, Marc
	Arkko, Fred Baker, Marc Blanchet, Brian Carpenter, Benoit Claise,		Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit
	Spencer Dawkins, Adrian Farrel, Russ Housley, Joel Jaeggli, Eliot		Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria,
	Lear, Barry Leiba, Ted Lemon, Erik Nordmark, Pete Resnick, Peter		Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Ted Hardie, Sam
	Saint-Andre, and Sean Turner. Additionally, we would like to thank		Hartmann, Bjoern Hoehrmann, Phillip Hallam-Baker, Russ Housley, Joel
	all those who contributed suggestions on how to improve Internet		Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted Lemon,
	security and privacy or who commented on this on various IETF mailing		Subrahamian Moonesamy, Erik Nordmark, Pete Resnick, Peter Saint-
	lists, such as the ietf@ietf.org and the perpass@ietf.org lists.		Andre, Andrew Sullivan, Sean Turner, and Stefan Winter.
			Additionally, we would like to thank all those who contributed
			suggestions on how to improve Internet security and privacy or who
			commented on this on various IETF mailing 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
	University Press http://www.oxforddictionaries.com/
	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.
			[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
			Text on Security Considerations", BCP 72, RFC 3552,
			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.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	RFC 4949, August 2007.		RFC 4949, August 2007.
	[RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers,		[RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers,
	and Boilerplates", RFC 5741, December 2009.		and Boilerplates", RFC 5741, December 2009.
			[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
			Transparency", RFC 6962, June 2013.
	[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,
	July 2013.		July 2013.
	Authors' Addresses		Authors' Addresses
	Stephen Farrell		Stephen Farrell
	Trinity College Dublin		Trinity College Dublin
	Dublin, 2		Dublin, 2
End of changes. 22 change blocks.
	94 lines changed or deleted		113 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/