idnits 2.17.00 (12 Aug 2021) /tmp/idnits21727/draft-farrell-perpass-attack-05.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 (January 20, 2014) is 3043 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: July 24, 2014 January 20, 2014 7 Pervasive Monitoring is an Attack 8 draft-farrell-perpass-attack-05.txt 10 Abstract 12 Pervasive monitoring is a technical attack that should be mitigated 13 in the design of IETF protocols, where possible. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 24, 2014. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 1. Pervasive Monitoring is a Widespread Attack on Privacy 49 Pervasive Monitoring (PM) is widespread (and often covert) 50 surveillance through intrusive gathering of protocol artefacts, 51 including application content, or protocol meta-data such as headers. 52 Active or passive wiretaps and traffic analysis, (e.g., correlation, 53 timing or measuring packet sizes), or subverting the cryptographic 54 keys used to secure protocols can also be used as part of pervasive 55 monitoring. 57 The IETF community's technical assessment is that PM is an attack on 58 the privacy of Internet users and organizations. PM is distinguished 59 by being indiscriminate and very large-scale, rather than by 60 introducing new types of technical compromise. The IETF community 61 has expressed strong agreement that PM is an attack that needs to be 62 mitigated where possible, via the design of protocols that make PM 63 significantly more expensive or infeasible. Pervasive Monitoring was 64 discussed at the technical plenary of the November 2013 IETF meeting 65 [IETF88Plenary] and then through extensive exchanges on IETF mailing 66 lists. This document records the IETF community's consensus and 67 establishes the technical nature of PM. 69 The term "attack" is used here in a technical sense that differs 70 somewhat from common English usage. In common English usage, an 71 attack is an aggressive action perpetrated by an opponent, intended 72 to enforce the opponent's will on the attacked party. The term is 73 used here to refer to behavior that subverts the intent of 74 communicating parties without the agreement of those parties. An 75 attack may change the content of the communication, record the 76 content or external characteristics of the communication, or through 77 correlation with other communication events, reveal information the 78 parties did not intend to be revealed. It may also have other 79 effects that similarly subvert the intent of a communicator. 80 [RFC4949] contains a more complete definition for the term attack. 81 We also use the term in the singular here, even though PM in reality 82 may require a multi-faceted set of coordinated attacks. 84 In particular, the term attack, used technically, implies nothing 85 about the motivation of the actor mounting the attack. The 86 motivation for PM is not relevant for this document, but can range 87 from non-targeted nation-state surveillance, to legal but privacy- 88 unfriendly purposes by commercial enterprises, to illegal actions by 89 criminals. The same techniques can be used regardless of motivation. 90 Thus we cannot defend against the most nefarious actors while 91 allowing monitoring by other actors no matter how benevolent some 92 might consider them to be, since the actions required are 93 indistinguishable from other attacks. 95 2. The IETF will work to Mitigate Pervasive Monitoring 97 "Mitigation" is a technical term that does not imply an ability to 98 completely prevent or thwart an attack. Protocols that mitigate PM 99 will not prevent the attack, but can significantly change the threat. 100 (See the diagram on page 24 of RFC 4949 for how the terms attack and 101 threat are related.) This can significantly increase the cost of 102 attacking, force what was covert to be overt, or make the attack more 103 likely to be detected, possibly later. 105 IETF standards already provide mechanisms to protect Internet 106 communications and there are guidelines [RFC3552] for applying these 107 in protocol design. But those generally do not consider PM, the 108 confidentiality of protocol meta-data, countering traffic analysis 109 nor data minimisation. [RFC6973] In all cases, there will remain 110 some privacy-relevant information that is inevitably disclosed by 111 protocols. As technology advances, techniques that were once only 112 available to extremely well funded actors become more widely 113 accessible. Mitigating PM is therefore a protection against a wide 114 range of similar attacks. 116 It is therefore timely to revisit the security and privacy properties 117 of our standards. The IETF will work to mitigate the technical 118 aspects of PM, just as we do for protocol vulnerabilities in general. 119 The ways in which IETF protocols mitigate PM will change over time as 120 mitigation and attack techniques evolve and so are not described 121 here. 123 Those developing IETF specifications need to be able to describe how 124 they have considered PM, and, if the attack is relevant to the work 125 to be published, be able to justify related design decisions. This 126 does not mean a new "pervasive monitoring considerations" section is 127 needed in IETF documentation. It means that, if asked, there needs 128 to be a good answer to the question "is pervasive monitoring relevant 129 to this work and if so how has it been considered?" 131 In particular, architectural decisions, including which existing 132 technology is re-used, may significantly impact the vulnerability of 133 a protocol to PM. Those developing IETF specifications therefore 134 need to consider mitigating PM when making these architectural 135 decisions. Getting adequate, early review of architectural decisions 136 including whether appropriate mitigation of PM can be made is 137 important. Revisiting these architectural decisions late in the 138 process is very costly. 140 While PM is an attack, other forms of monitoring can be beneficial 141 and not part of any attack, e.g. network management functions monitor 142 packets or flows and anti-spam mechanisms need to see mail message 143 content. Some monitoring can even be part of the mitigation for PM, 144 for example Certificate Transparency [RFC6962] involves monitoring 145 Public Key Infrastructure in ways that could detect some PM attack 146 techniques. There is though a clear potential for monitoring 147 mechanisms to be abused for PM, so this tension needs careful 148 consideration in protocol design. Making networks unmanageable to 149 mitigate PM is not an acceptable outcome, but ignoring PM would go 150 against the consensus documented here. An appropriate balance will 151 emerge over time as real instances of this tension are considered. 153 Finally, the IETF, as a standards development organisation, does not 154 control the implementation or deployment of our specifications 155 (though IETF participants do develop many implementations), nor does 156 the IETF standardise all layers of the protocol stack. Moreover, the 157 non-technical (e.g. legal and political) aspects of mitigating 158 pervasive monitoring are outside of the scope of the IETF. The 159 broader Internet community will need to step forward to tackle PM, if 160 it is to be fully addressed. 162 To summarise: current capabilities permit some actors to monitor 163 content and meta-data across the Internet at a scale never before 164 seen. This pervasive monitoring is an attack on Internet privacy. 165 The IETF will strive to produce specifications that mitigate 166 pervasive monitoring attacks. 168 3. Process Note 170 In the past, architectural statements of this sort, e.g., [RFC1984] 171 and [RFC2804] have been published as joint products of the Internet 172 Engineering Steering Group (IESG) and the Internet Architecture Board 173 (IAB). However, since those documents were published, the IETF and 174 IAB have separated their publication "streams" as described in 175 [RFC4844] and [RFC5741]. This document was initiated by both the 176 IESG and IAB, but is published as an IETF-stream consensus document, 177 in order to ensure that it properly reflects the consensus of the 178 IETF community as a whole. 180 [[Note (to be removed before publication): This draft is written as 181 if IETF consensus has been established for the text.]] 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 Brussels, 259 Belgium 261 Phone: 262 Email: hannes.tschofenig@gmx.net