idnits 2.17.00 (12 Aug 2021) /tmp/idnits21273/draft-farrell-perpass-attack-03.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 20, 2013) is 3074 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: June 23, 2014 December 20, 2013 7 Pervasive Monitoring is an Attack 8 draft-farrell-perpass-attack-03.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 June 23, 2014. 32 Copyright Notice 34 Copyright (c) 2013 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 Indistinguishable from an Attack 49 The technical plenary of the November 2013 IETF meeting 50 [IETF88Plenary] discussed pervasive monitoring (or surveillance) 51 which requires the monitoring party to take actions that are 52 indistinguishable from an attack on Internet communications. 53 Participants at that meeting therefore expressed strong agreement 54 that this was an attack that should be mitigated where possible via 55 the design of protocols that make pervasive monitoring significantly 56 more expensive or infeasible. This Best Current Practice (BCP, see 57 [RFC2026] Section 5) formally documents that consensus. 59 For the purposes of this document "pervasive monitoring" means often 60 covert and very widespread intrusive gathering of protocol artefacts 61 including application content, protocol meta-data such as headers, or 62 cryptographic keys used to secure protocols. Active or passive 63 wiretaps, traffic analysis, correlation, timing or measuring packet 64 sizes can also be used as part of pervasive monitoring. 66 The term "attack" is used here in a technical sense that differs 67 somewhat from common English usage. In common English usage, an 68 "attack" is an aggressive action perpetrated by an opponent, intended 69 to enforce the opponent's will on the attacked party. Here, the term 70 is used to refer to a behavior that subverts the intent of a 71 communicator without the agreement of the parties to the 72 communication. It may change the content of the communication, 73 record the content of the communication, or through correlation with 74 other communication events, reveal information the communicator did 75 not intend to be revealed. It may also have other effects that 76 similarly subvert the intent of a communicator. [RFC4949] contains a 77 more complete definition for the term "attack." We also use the term 78 in the singular here, even though pervasive monitoring in reality may 79 require a multi-faceted set of coordinated attacks. 81 In particular, the term "attack", when used technically, implies 82 nothing about the motivation of the actor mounting the attack. The 83 motivation behind pervasive monitoring is not relevant for this 84 document, but can range from non-targeted nation-state surveillance, 85 to legal but privacy-unfriendly purposes by commercial enterprises, 86 to illegal purposes by criminals. The same techniques can be used 87 regardless of motivation and we cannot defend against the most 88 nefarious actors while allowing monitoring by other actors no matter 89 how benevolent some might consider them to be. As technology 90 advances, techniques that were once only available to extremely well 91 funded actors become more widely accessible. Mitigating this attack 92 is therefore a protection against wider usage of pervasive 93 monitoring. 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 99 pervasive monitoring will not prevent the attack, but can 100 significantly change the threat. (See the diagram on page 24 of RFC 101 4949 for how the terms attack and threat are related.) This can 102 significantly increase the cost of attacking, force what was covert 103 to be overt, or make the attack more likely to be detected, possibly 104 later. 106 IETF standards already provide mechanisms to protect Internet 107 communications and there are guidelines [RFC3552] for applying these 108 in protocol design. But those generally do not consider pervasive 109 monitoring, the confidentiality of protocol meta-data, countering 110 traffic analysis nor data minimisation. [RFC6973] And in all cases, 111 there will remain some privacy-relevant information that is 112 inevitably disclosed by protocols. 114 It is nonetheless timely to revisit the security and privacy 115 properties of our standards. The IETF will work to mitigate the 116 technical parts of the pervasive monitoring threat, just as we do for 117 other protocol vulnerabilities. The ways in which IETF protocols 118 mitigate pervasive monitoring will change over time as mitigation and 119 attack techniques evolve and so are not described here. 121 Those developing IETF specifications need to be able to describe how 122 they have considered pervasive monitoring, and, if the attack is 123 relevant to the work to be published, be able to justify related 124 design decisions. This does not mean a new "pervasive monitoring 125 considerations" section is needed in IETF documentation. It means 126 that, if asked, there needs to be a good answer to the question "is 127 pervasive monitoring relevant to this work and if so how has it been 128 addressed?" 130 While pervasive monitoring is an attack, other forms of monitoring 131 can be beneficial and not part of any attack, e.g. network management 132 functions monitor packets or flows, anti-spam mechanisms see mail 133 message content and monitoring can even be a mitigation for pervasive 134 monitoring in the case of Certificate Transparency. [RFC6962] There 135 is though a clear potential for monitoring mechanisms to be abused 136 for pervasive monitoring, so this tension needs careful consideration 137 in protocol design. Making networks unmanageable to mitigate 138 pervasive monitoring is not an acceptable outcome, but ignoring 139 pervasive monitoring would go against the consensus documented in 140 this BCP. An appropriate balance will likely emerge over time as 141 real instances of this tension are considered. 143 Finally, the IETF, as a standards development organisation, does not 144 control the implementation or deployment of our specifications 145 (though IETF participants do develop many implementations), nor does 146 the IETF specify all layers of the protocol stack. And the non- 147 technical (e.g. legal and political) aspects of mitigating pervasive 148 monitoring are outside of the scope of the IETF. The broader 149 Internet community will need to step forward to tackle pervasive 150 monitoring, if it is to be fully addressed. 152 3. Process Note 154 In the past, architectural statements of this sort, e.g., [RFC1984] 155 and [RFC2804] have been published as joint products of the Internet 156 Engineering Steering Group (IESG) and the Internet Architecture Board 157 (IAB). However, since those documents were published, the IETF and 158 IAB have separated their publication "streams" as described in 159 [RFC4844] and [RFC5741]. This document was initiated by both the 160 IESG and IAB, but is published as an IETF-stream consensus document, 161 in order to ensure that it properly reflects the consensus of the 162 IETF community as a whole. 164 [[Note (to be removed before publication): This draft is written as 165 if IETF consensus has been established for the text.]] 167 4. Security Considerations 169 This BCP is entirely about privacy. More information about the 170 relationship between security and privacy threats can be found in 171 [RFC6973]. Section 5.1.1 of [RFC6973] specifically addresses 172 surveillance as a combined security-privacy threat. 174 5. IANA Considerations 176 There are none. We hope the RFC editor deletes this section before 177 publication. 179 6. Acknowledgements 181 We would like to thank the participants of the IETF 88 technical 182 plenary for their feedback. Thanks in particular to the following 183 for useful suggestions or comments: Jari Arkko, Fred Baker, Marc 184 Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit 185 Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria, 186 Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Ted Hardie, Sam 187 Hartmann, Bjoern Hoehrmann, Phillip Hallam-Baker, Russ Housley, Joel 188 Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted Lemon, 189 Subrahamian Moonesamy, Erik Nordmark, Pete Resnick, Peter Saint- 190 Andre, Andrew Sullivan, Sean Turner, and Stefan Winter. 191 Additionally, we would like to thank all those who contributed 192 suggestions on how to improve Internet security and privacy or who 193 commented on this on various IETF mailing lists, such as the 194 ietf@ietf.org and the perpass@ietf.org lists. 196 7. Informative References 198 [IETF88Plenary] 199 IETF, "IETF 88 Plenary Meeting Materials", URL: 200 https://datatracker.ietf.org/meeting/88/materials.html, 201 Nov 2013. 203 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 204 Statement on Cryptographic Technology and the Internet", 205 RFC 1984, August 1996. 207 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 208 3", BCP 9, RFC 2026, October 1996. 210 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 211 May 2000. 213 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 214 Text on Security Considerations", BCP 72, RFC 3552, 215 July 2003. 217 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 218 Series and RFC Editor", RFC 4844, July 2007. 220 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 221 RFC 4949, August 2007. 223 [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, 224 and Boilerplates", RFC 5741, December 2009. 226 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 227 Transparency", RFC 6962, June 2013. 229 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 230 Morris, J., Hansen, M., and R. Smith, "Privacy 231 Considerations for Internet Protocols", RFC 6973, 232 July 2013. 234 Authors' Addresses 236 Stephen Farrell 237 Trinity College Dublin 238 Dublin, 2 239 Ireland 241 Phone: +353-1-896-2354 242 Email: stephen.farrell@cs.tcd.ie 244 Hannes Tschofenig 245 Brussels, 246 Belgium 248 Phone: 249 Email: hannes.tschofenig@gmx.net