idnits 2.17.1 draft-farrell-perpass-attack-06.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 (February 11, 2014) is 3698 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) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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: August 15, 2014 ARM Ltd. 6 February 11, 2014 8 Pervasive Monitoring is an Attack 9 draft-farrell-perpass-attack-06.txt 11 Abstract 13 Pervasive monitoring is a technical attack that should be mitigated 14 in the design of IETF protocols, 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 August 15, 2014. 33 Copyright Notice 35 Copyright (c) 2014 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. Pervasive Monitoring is a Widespread Attack on Privacy 50 Pervasive Monitoring (PM) is widespread (and often covert) 51 surveillance through intrusive gathering of protocol artefacts, 52 including application content, or protocol meta-data such as headers. 53 Active or passive wiretaps and traffic analysis, (e.g., correlation, 54 timing or measuring packet sizes), or subverting the cryptographic 55 keys used to secure protocols can also be used as part of pervasive 56 monitoring. PM is distinguished by being indiscriminate and very 57 large-scale, rather than by introducing new types of technical 58 compromise. 60 The IETF community's technical assessment is that PM is an attack on 61 the privacy of Internet users and organizations. The IETF community 62 has expressed strong agreement that PM is an attack that needs to be 63 mitigated where possible, via the design of protocols that make PM 64 significantly more expensive or infeasible. Pervasive Monitoring was 65 discussed at the technical plenary of the November 2013 IETF meeting 66 [IETF88Plenary] and then through extensive exchanges on IETF mailing 67 lists. This document records the IETF community's consensus and 68 establishes the technical nature of PM. 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. The term is 74 used here to refer to behavior that subverts the intent of 75 communicating parties without the agreement of those parties. An 76 attack may change the content of the communication, record the 77 content or external characteristics of the communication, or through 78 correlation with other communication events, reveal information the 79 parties 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 We also use the term in the singular here, even though PM in reality 83 may consist of a multi-faceted set of coordinated attacks. 85 In particular, the term attack, used technically, implies nothing 86 about the motivation of the actor mounting the attack. The 87 motivation for PM can range from non-targeted nation-state 88 surveillance, to legal but privacy-unfriendly purposes by commercial 89 enterprises, to illegal actions by criminals. The same techniques to 90 achieve PM can be used regardless of motivation. Thus, we cannot 91 defend against the most nefarious actors while allowing monitoring by 92 other actors no matter how benevolent some might consider them to be, 93 since the actions required are indistinguishable from other attacks. 94 The motivation for PM is, therefore, not relevant for how PM is 95 mitigated in IETF protocols. 97 2. The IETF will work to Mitigate Pervasive Monitoring 99 "Mitigation" is a technical term that does not imply an ability to 100 completely prevent or thwart an attack. Protocols that mitigate PM 101 will not prevent the attack, but can significantly change the threat. 102 (See the diagram on page 24 of RFC 4949 for how the terms attack and 103 threat are related.) This can significantly increase the cost of 104 attacking, force what was covert to be overt, or make the attack more 105 likely to be detected, possibly later. 107 IETF standards already provide mechanisms to protect Internet 108 communications and there are guidelines [RFC3552] for applying these 109 in protocol design. But those generally do not consider PM, the 110 confidentiality of protocol meta-data, countering traffic analysis 111 nor data minimisation. In all cases, there will remain some privacy- 112 relevant information that is inevitably disclosed by protocols. As 113 technology advances, techniques that were once only available to 114 extremely well funded actors become more widely accessible. 115 Mitigating PM is therefore a protection against a wide range of 116 similar attacks. 118 It is therefore timely to revisit the security and privacy properties 119 of our standards. The IETF will work to mitigate the technical 120 aspects of PM, just as we do for protocol vulnerabilities in general. 121 The ways in which IETF protocols mitigate PM will change over time as 122 mitigation and attack techniques evolve and so are not described 123 here. 125 Those developing IETF specifications need to be able to describe how 126 they have considered PM, and, if the attack is relevant to the work 127 to be published, be able to justify related design decisions. This 128 does not mean a new "pervasive monitoring considerations" section is 129 needed in IETF documentation. It means that, if asked, there needs 130 to be a good answer to the question "is pervasive monitoring relevant 131 to this work and if so how has it been considered?" 133 In particular, architectural decisions, including which existing 134 technology is re-used, may significantly impact the vulnerability of 135 a protocol to PM. Those developing IETF specifications therefore 136 need to consider mitigating PM when making these architectural 137 decisions. Getting adequate, early review of architectural decisions 138 including whether appropriate mitigation of PM can be made is 139 important. Revisiting these architectural decisions late in the 140 process is very costly. 142 While PM is an attack, other forms of monitoring that might fit the 143 definition of PM can be beneficial and not part of any attack, e.g. 144 network management functions monitor packets or flows and anti-spam 145 mechanisms need to see mail message content. Some monitoring can 146 even be part of the mitigation for PM, for example Certificate 147 Transparency [RFC6962] involves monitoring Public Key Infrastructure 148 in ways that could detect some PM attack techniques. There is though 149 a clear potential for monitoring mechanisms to be abused for PM, so 150 this tension needs careful consideration in protocol design. Making 151 networks unmanageable to mitigate PM is not an acceptable outcome, 152 but ignoring PM would go against the consensus documented here. An 153 appropriate balance will emerge over time as real instances of this 154 tension are considered. 156 Finally, the IETF, as a standards development organisation, does not 157 control the implementation or deployment of our specifications 158 (though IETF participants do develop many implementations), nor does 159 the IETF standardise all layers of the protocol stack. Moreover, the 160 non-technical (e.g. legal and political) aspects of mitigating 161 pervasive monitoring are outside of the scope of the IETF. The 162 broader Internet community will need to step forward to tackle PM, if 163 it is to be fully addressed. 165 To summarise: current capabilities permit some actors to monitor 166 content and meta-data across the Internet at a scale never before 167 seen. This pervasive monitoring is an attack on Internet privacy. 168 The IETF will strive to produce specifications that mitigate 169 pervasive monitoring attacks. 171 3. Process Note 173 In the past, architectural statements of this sort, e.g., [RFC1984] 174 and [RFC2804] have been published as joint products of the Internet 175 Engineering Steering Group (IESG) and the Internet Architecture Board 176 (IAB). However, since those documents were published, the IETF and 177 IAB have separated their publication "streams" as described in 178 [RFC4844] and [RFC5741]. This document was initiated after 179 discussions in both the IESG and IAB, but is published as an IETF- 180 stream consensus document, in order to ensure that it properly 181 reflects the consensus of the IETF community as a whole. 183 4. Security Considerations 185 This document is entirely about privacy. More information about the 186 relationship between security and privacy threats can be found in 187 [RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses 188 surveillance as a combined security-privacy threat. 190 5. IANA Considerations 192 There are none. We hope the RFC editor deletes this section before 193 publication. 195 6. Acknowledgements 197 We would like to thank the participants of the IETF 88 technical 198 plenary for their feedback. Thanks in particular to the following 199 for useful suggestions or comments: Jari Arkko, Fred Baker, Marc 200 Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit 201 Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria, 202 Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Ted Hardie, Sam 203 Hartmann, Paul Hoffman, Bjoern Hoehrmann, Phillip Hallam-Baker, Russ 204 Housley, Joel Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted 205 Lemon, Subramanian Moonesamy, Erik Nordmark, Pete Resnick, Peter 206 Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas Weaver, Stefan 207 Winter, and Lloyd Wood. Additionally, we would like to thank all 208 those who contributed suggestions on how to improve Internet security 209 and privacy or who commented on this on various IETF mailing lists, 210 such as the ietf@ietf.org and the perpass@ietf.org lists. 212 7. Informative References 214 [IETF88Plenary] 215 IETF, "IETF 88 Plenary Meeting Materials", URL: 216 https://datatracker.ietf.org/meeting/88/materials.html, 217 Nov 2013. 219 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 220 Statement on Cryptographic Technology and the Internet", 221 RFC 1984, August 1996. 223 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 224 May 2000. 226 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 227 Text on Security Considerations", BCP 72, RFC 3552, 228 July 2003. 230 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 231 Series and RFC Editor", RFC 4844, July 2007. 233 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 234 RFC 4949, August 2007. 236 [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, 237 and Boilerplates", RFC 5741, December 2009. 239 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 240 Transparency", RFC 6962, June 2013. 242 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 243 Morris, J., Hansen, M., and R. Smith, "Privacy 244 Considerations for Internet Protocols", RFC 6973, 245 July 2013. 247 Authors' Addresses 249 Stephen Farrell 250 Trinity College Dublin 251 Dublin, 2 252 Ireland 254 Phone: +353-1-896-2354 255 Email: stephen.farrell@cs.tcd.ie 257 Hannes Tschofenig 258 ARM Ltd. 259 110 Fulbourn Rd 260 Cambridge CB1 9NJ 261 Great Britain 263 Email: Hannes.tschofenig@gmx.net 264 URI: http://www.tschofenig.priv.at