idnits 2.17.00 (12 Aug 2021) /tmp/idnits20840/draft-farrell-perpass-attack-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 3, 2013) is 3091 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: BCP H. Tschofenig 5 Expires: June 6, 2014 December 3, 2013 7 Pervasive Monitoring is an Attack 8 draft-farrell-perpass-attack-02.txt 10 Abstract 12 The IETF has consensus that pervasive monitoring is a technical 13 attack that should be mitigated in the design of IETF protocols, 14 where possible. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 6, 2014. 33 Copyright Notice 35 Copyright (c) 2013 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 1. It's an Attack 50 [[Note (to be removed before publication): This draft is written as 51 if IETF consensus has been established for the text.]] 53 The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive 54 monitoring. Such pervasive surveillance requires the monitoring 55 party to take actions that are indistinguishable from an attack on 56 Internet communications. Participants at that meeting therefore 57 expressed strong agreement that this was an attack that should be 58 mitigated where possible via the design of protocols that make 59 pervasive monitoring significantly more expensive or infeasible. 60 This Best Current Practice (BCP) formally documents that consensus, 61 having been through an IETF last call. 63 For the purposes of this BCP "pervasive monitoring" means very 64 widespread privacy-invasive gathering of protocol artefacts including 65 application content, protocol meta-data (such as headers) or keys 66 used to secure protocols. Other forms of traffic analysis, for 67 example, correlation, timing or measuring packet sizes can also be 68 used for pervasive monitoring. 70 The term "attack" is used here in a technical sense that differs 71 somewhat from common English usage. In common English usage, an 72 "attack" is an aggressive action perpetrated by an opponent, intended 73 to enforce the opponent's will on the attacked party. In the 74 Internet, the term is used to refer to a behavior that subverts the 75 intent of a communicator without the agreement of the parties to the 76 communication. It may change the content of the communication, 77 record the content of the communication, or through correlation with 78 other communication events or attempts, reveal information the 79 communicator did not intend to be revealed. It may also have other 80 effects that similarly subvert the intent of a communicator. 81 [RFC4949] contains a more complete definition for the term "attack" 82 as used here. We also use the term in the singular here, even though 83 pervasive monitoring in reality may require a multi-faceted set of 84 coordinated attacks. 86 In particular, the term "attack", when used technically, implies 87 nothing about the motivation of the actor mounting the attack. The 88 motivation behind pervasive monitoring is not relevant for this 89 document, but can range from non-targeted nation-state surveillance, 90 to legal but privacy-unfriendly purposes by commercial enterprises, 91 to illegal purposes by criminals. The same techniques can be used 92 regardless of motivation and we cannot defend against the most 93 nefarious actors while allowing monitoring by other actors no matter 94 how benevolent some might consider them to be. As technology 95 advances, techniques that were once only available to extremely well 96 funded actors become more widely accessible. Mitigating this attack 97 is therefore a protection against wider usage of pervasive 98 monitoring. 100 2. And We Will Continue to Mitigate the Attack 102 The IETF also has consensus to, where possible, work to mitigate the 103 technical parts of the pervasive monitoring attack, in just the same 104 way as we continually do for these and any other protocol 105 vulnerability. 107 There are various ways in which IETF protocols can be designed in 108 order to mitigate pervasive monitoring, but those will change over 109 time as mitigation and attack techniques develop and so are not 110 described here. This BCP simply records the consensus to design 111 protocols so as to mitigate the attack, where possible. 113 More limited-scope monitoring to assist with network management that 114 is required in order to operate the network or an application is not 115 considered pervasive monitoring. There is though a clear potential 116 for such limited monitoring mechanisms to be abused as part of 117 pervasive monitoring, so this tension needs careful consideration in 118 protocol design. Making networks unmanageable in order to mitigate 119 pervasive monitoring would not be an acceptable outcome. But 120 equally, ignoring pervasive monitoring in designing network 121 management mechanisms would go against the consensus documented in 122 this BCP. An appropriate balance will likely emerge over time as 123 real instances of this tension are considered. 125 It is also important to note that the term "mitigation" is a 126 technical term that does not necessarily imply an ability to 127 completely prevent or thwart an attack. As in common English usage, 128 this term is used here in the sense of "make less severe, serious, or 129 painful." [OED] In this case, designing IETF protocols to mitigate 130 pervasive monitoring will almost certainly not completely prevent 131 such from happening, but can significantly increase the cost of such 132 monitoring or force what was covert monitoring to be more overt or 133 more likely to be detected (possibly later) via other means. And 134 even where the IETF has done this work well and that has been fully 135 deployed, there will still be some privacy-relevant information that 136 will inevitably be disclosed by protocols. 138 While RFC 4949 does not contain a definition for the term mitigation, 139 we prefer it here to the term countermeasure which is defined in RFC 140 4949 since the latter term is more often understood to mean putting 141 in place a more fully effective mitigation of an attack. 143 Finally, we note that the IETF is not equipped to tackle the non- 144 technical aspects of mitigating pervasive surveillance. Others need 145 to step forward to tackle those if pervasive monitoring is to be 146 fully addressed. 148 3. Process Note 150 In the past, architectural statements of this sort, e.g., [RFC1984] 151 and [RFC2804] have been published as joint products of the IESG and 152 IAB. However, since those documents were published, the IETF and IAB 153 have separated their publication "streams" as described in [RFC4844] 154 and [RFC5741]. This document was initiated by both the IESG and IAB, 155 but it is published as an IETF-stream consensus document, having 156 garnered the consensus of the IETF as approved by the IESG. 158 4. Security Considerations 160 This BCP is entirely about privacy. More information about the 161 relationship between security and privacy threats can be found in 162 [RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses 163 surveillance as a combined security-privacy threat. 165 5. IANA Considerations 167 There are none. We hope the RFC editor deletes this section before 168 publication. 170 6. Acknowledgements 172 We would like to thank the participants of the IETF 88 technical 173 plenary for their feedback. Thanks in particular to the following 174 for useful suggestions that resulted in changes to this text: Jari 175 Arkko, Fred Baker, Marc Blanchet, Brian Carpenter, Benoit Claise, 176 Spencer Dawkins, Adrian Farrel, Russ Housley, Joel Jaeggli, Eliot 177 Lear, Barry Leiba, Ted Lemon, Erik Nordmark, Pete Resnick, Peter 178 Saint-Andre, and Sean Turner. Additionally, we would like to thank 179 all those who contributed suggestions on how to improve Internet 180 security and privacy or who commented on this on various IETF mailing 181 lists, such as the ietf@ietf.org and the perpass@ietf.org lists. 183 7. Informative References 185 [IETF88Plenary] 186 IETF, "IETF 88 Plenary Meeting Materials", URL: 187 https://datatracker.ietf.org/meeting/88/materials.html, 188 Nov 2013. 190 [OED] Stevenson, Angus, "Oxford Dictionary of English", Oxford 191 University Press http://www.oxforddictionaries.com/ 192 definition/english/mitigate, 2010. 194 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 195 Statement on Cryptographic Technology and the Internet", 196 RFC 1984, August 1996. 198 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 199 May 2000. 201 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 202 Series and RFC Editor", RFC 4844, July 2007. 204 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 205 RFC 4949, August 2007. 207 [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, 208 and Boilerplates", RFC 5741, December 2009. 210 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 211 Morris, J., Hansen, M., and R. Smith, "Privacy 212 Considerations for Internet Protocols", RFC 6973, 213 July 2013. 215 Authors' Addresses 217 Stephen Farrell 218 Trinity College Dublin 219 Dublin, 2 220 Ireland 222 Phone: +353-1-896-2354 223 Email: stephen.farrell@cs.tcd.ie 225 Hannes Tschofenig 226 Brussels, 227 Belgium 229 Phone: 230 Email: hannes.tschofenig@gmx.net