idnits 2.17.00 (12 Aug 2021) /tmp/idnits20061/draft-farrell-perpass-attack-00.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 (November 20, 2013) is 3104 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: May 24, 2014 November 20, 2013 7 Pervasive Monitoring is an Attack 8 draft-farrell-perpass-attack-00.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 May 24, 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: This draft is written as if IETF consensus has been 51 established for the text.]] 53 The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive 54 monitoring and participants had strong agreement that this was an 55 attack and one that should be mitigated where possible via the design 56 of protocols that make pervasive monitoring significantly more 57 expensive or infeasible. Such pervasive surveillance requires the 58 monitoring party to take actions that are indistinguishable from an 59 attack on Internet communications. This Best Current Practice (BCP) 60 documents that consensus. 62 For the purposes of this BCP "pervasive monitoring" means very 63 widespread privacy-invasive gathering of protocol artefacts including 64 application content, protocol meta-data (such as headers) or keys 65 used to secure protocols. Other forms of traffic analysis, for 66 example, timing or measuring packet sizes can also be used for 67 pervasive monitoring. A fuller problem statement with more examples 68 and description can be found in [ProblemStatement]. 70 Note that the term "attack" is used here in a techincal sense that 71 differs somewhat from the natural English usage. In particular, the 72 term, when used technically, implies nothing about the motivation of 73 the bad-actor mounting the attack, who is still called a bad-actor no 74 matter what one really thinks about their motivation. We also use 75 the term in the singluar here, even though pervasive monitoring in 76 reality may require a multi-faceted set of co-ordinated attacks. 78 The motivation behind pervasive monitoring is not particularly 79 relevant for this document, but can range from non-targeted nation- 80 state surveillance, to legal but privacy-unfriendly purposes by 81 commercial enterprises, to illegal purposes by criminals. The same 82 techniques can be used in each case, regardless of motivation, and we 83 cannot defend against the most nefarious actors while allowing 84 monitoring by other actors no matter how benevolent some might 85 consider those. As technology continues to advance rapidly 86 techniques that have been shown to work but were once only accessible 87 to nation-state actors become accessible to non-nation-state actors, 88 so mitigating this threat is not only relevant when considering 89 nation-state bad actors. 91 2. And we'll work to Mitigate the Attack 93 The IETF also have consensus to, where possible, work to mitigate the 94 technical parts of the pervasive monitoring attack, in just the same 95 way as we do with any other protocol vulnerability. 97 There are various ways in which IETF protocols can be designed in 98 order to mitigate pervasive monitoring, but those will change over 99 time as mitigation and attack techniques develop and so are not 100 described here. This BCP simply records the consensus to design 101 protocols so as to mitigate the attack, where possible. 103 Note that more limited-scope monitoring to assist with network 104 management or that is required in order to operate the network or an 105 application are not considered pervasive monitoring. There is though 106 a clear potential for network management mechanisms to be abused as 107 part of pervasive monitoring, so this tension needs careful 108 consideration in protocol design: making networks unmanageable in 109 order to mitigate pervasive monitoring would not be an acceptable 110 outcome, but equally, ignoring pervasive monitoring in designing 111 network management mechanisms would go against the consensus 112 documented in this BCP. An appropriate balance will likely emerge 113 over time as real instances of this tension are considered. 115 It is also important to note that the term "mitigation" is also a 116 technical term that does not necessarily imply an ability to 117 completely prevent or thwart an attack. In this case, designing IETF 118 protocols to mitigate pervasive monitoring will almost certainly not 119 completely prevent such from happening, but can increase the cost 120 significantly or force what was covert monitoring to be more overt, 121 or more likely to be detected (possibly later) via other means. And 122 even where the IETF has done this work well and that has been fully 123 deployed, there will still be some privacy-relevant information that 124 will inevitably be disclosed by protocols. 126 Finally, we note that the IETF is not equipped to tackle the non- 127 technical aspects of mitigating pervasive surveillance. We hope that 128 others will step forward to tackle those. 130 3. Process Note 132 In the past, architectural statements of this sort, e.g., [RFC1984] 133 and [RFC2804] have been published as joint products of the IESG and 134 IAB. However, since those documents were published, the IETF and IAB 135 have separated their publication "streams" as described in [RFC4844] 136 and [RFC5741]. This document was initiated by both the IESG and IAB, 137 but it is being published as an IETF-stream consensus document, 138 having garnered the consensus of the IETF as approved by the IESG. 140 4. Security Considerations 142 This BCP is all about privacy. More information about the 143 relationship between security and privacy threats can be found in 144 [RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses 145 surveillance as a combined security-privacy threat. 147 5. IANA Considerations 149 There are none. We hope the RFC editor deletes this section before 150 publication. 152 6. Acknowledgements 154 We would like to thank the participants of the IETF 88 technical 155 plenary for their feedback. Additionally, we would like to thank all 156 those who contributed to their suggestions on how to improve Internet 157 security on various IETF mailing lists, such as the ietf@ietf.org and 158 the perpass@ietf.org lists. 160 Thanks in particular to the following for useful comments: Jari 161 Arkko, Marc Blanchet, Benoit Claise, Spencer Dawkins, Russ Housley, 162 Joel Jaeggli, Eliot Lear, Barry Leiba, Ted Lemon, Erik Nordmark, Pete 163 Resnick, 165 7. Informative References 167 [IETF88Plenary] 168 IETF, "IETF 88 Plenary Meeting Materials", URL: 169 https://datatracker.ietf.org/meeting/88/materials.html, 170 Nov 2013. 172 [ProblemStatement] 173 Richard Barnes, "Pervasive Monitoring: Problem Statement", 174 URL: To-Be-Published, Nov 2013. 176 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 177 Statement on Cryptographic Technology and the Internet", 178 RFC 1984, August 1996. 180 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 181 May 2000. 183 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 184 Series and RFC Editor", RFC 4844, July 2007. 186 [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, 187 and Boilerplates", RFC 5741, December 2009. 189 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 190 Morris, J., Hansen, M., and R. Smith, "Privacy 191 Considerations for Internet Protocols", RFC 6973, 192 July 2013. 194 Authors' Addresses 196 Stephen Farrell 197 Trinity College Dublin 198 Dublin, 2 199 Ireland 201 Phone: +353-1-896-2354 202 Email: stephen.farrell@cs.tcd.ie 204 Hannes Tschofenig 205 Brussels, 206 Belgium 208 Phone: 209 Email: hannes.tschofenig@gmx.net