RFC 7258

Pervasive Monitoring Is an Attack

📅 published May 2014, from ietf

RFC 7258: Pervasive Monitoring Is an Attack 🎀

Okay bestie, this one is a Best Current Practice (that's BCP 188 in the header 💅), written by S. Farrell from Trinity College Dublin and H. Tschofenig from ARM Ltd. It came out in May 2014 and has ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract 🌸

Pervasive monitoring is a technical attack, and IETF protocols should try to mitigate it in their design wherever that's possible 🦋

Status of This Memo 📜

This memo documents an Internet Best Current Practice 💖

This document is a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the whole IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, check out Section 2 of RFC 5741 🌈

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7258 🍓

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this was published. Please actually read these, because they lay out your rights and restrictions for this document 🙈 If you pull Code Components out of this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

1. Pervasive Monitoring Is a Widespread Attack on Privacy 💅

Pervasive Monitoring (PM) is widespread surveillance, and it's often covert 👀 It works by intrusively gathering protocol artefacts, which means application content or protocol metadata like headers. Active or passive wiretaps and traffic analysis count too, like correlation, timing, or measuring packet sizes. Subverting the cryptographic keys used to secure protocols can be part of it as well. What makes PM so scary isn't some brand-new kind of technical trick. It's that it's indiscriminate and happens at a massive scale 😭

The IETF community's technical assessment is that PM is an attack on the privacy of Internet users and organisations, full stop 🔥 The community has strongly agreed that PM needs to be mitigated where possible, through protocol design that makes PM significantly more expensive or completely infeasible 💜 PM came up at the technical plenary of the November 2013 IETF meeting [IETF88Plenary], and then got talked through in loads of IETF mailing list exchanges. This document writes down the community's consensus and establishes the technical nature of PM 🎀

The word "attack" is used here in a technical sense, which is a little different from everyday English. In normal talk, an attack is an aggressive action by an opponent to force their will on the attacked party. Here, it means behavior that subverts the intent of communicating parties without those parties agreeing to it. An attack might change the content of a communication, record its content or external characteristics, or reveal information the parties never meant to share through correlation with other communication events. It can also have other effects that subvert a communicator's intent in similar ways 🦋 [RFC4949] has a more complete definition of "attack" if you're curious. We also talk about it in the singular, even though PM in reality might be a whole multifaceted set of coordinated attacks 🧚

Here's the big one: when we say "attack" in this technical sense, it says nothing about the motivation of whoever's doing it 💀 PM can be motivated by anything from non-targeted nation-state surveillance, to legal but privacy-unfriendly stuff from commercial enterprises, to illegal actions by criminals. The same techniques work no matter the motivation. So we can't defend against the most nefarious actors while still letting other actors monitor, no matter how benevolent somebody thinks they are, because the actions the attacker takes look exactly the same as other attacks. That's why motivation isn't relevant to how PM gets mitigated in IETF protocols 🫶

2. The IETF Will Work to Mitigate Pervasive Monitoring 🌸

"Mitigation" is a technical term, and it doesn't mean we can completely prevent or thwart an attack 💅 Protocols that mitigate PM won't stop the attack, but they can seriously change the threat. (See the diagram on page 24 of RFC 4949 to see how "attack" and "threat" are related 🌈) Mitigation can really increase the cost of attacking, force what was covert to become overt, or make the attack more likely to get caught, maybe later 👑

IETF standards already give us mechanisms to protect Internet communications, and there are guidelines [RFC3552] for using them in protocol design. But those standards generally don't deal with PM, the confidentiality of protocol metadata, countering traffic analysis, or data minimisation 😭 Every time, some privacy-relevant information is going to get disclosed by protocols no matter what. Also, as technology gets better, techniques that used to be only for super well-funded actors become way more accessible. So mitigating PM protects us against a whole bunch of similar attacks 🧚

That's why it's timely to revisit the security and privacy properties of our standards 🔥 The IETF will work on the technical side of PM, the same way we already handle protocol vulnerabilities in general. How IETF protocols mitigate PM will keep changing as mitigation and attack techniques evolve, so this document doesn't describe them 🦋

Anyone developing IETF specifications needs to be able to explain how they've considered PM. If the attack is relevant to the work being published, they also need to justify the related design decisions 💖 This does not mean a new "pervasive monitoring considerations" section is needed in IETF documentation. It just means that if someone asks, there needs to be a good answer to the question "Is pervasive monitoring relevant to this work and if so, how has it been considered?" 🙈

Architectural decisions are a big deal here, including which existing technology gets reused, because they can massively affect how vulnerable a protocol is to PM 👀 So the people developing IETF specifications need to consider mitigating PM when they make architectural decisions. Getting adequate, early review of those decisions, including whether appropriate PM mitigation can be done, is important. Revisiting architectural decisions late in the process is extremely costly 💀

Other forms of monitoring might fit the definition of PM but still be beneficial and not part of any attack. For example, network management functions monitor packets or flows, and anti-spam mechanisms need to see mail message content 🌈 Some monitoring can even be part of the mitigation for PM. Certificate transparency [RFC6962] is one example, since it involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques ✨ However, monitoring mechanisms have a clear potential to be abused for PM, so this tension needs careful consideration in protocol design. Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. The right balance will emerge over time as real instances of this tension get considered 🫶

Finally, the IETF is a standards development organisation, so it doesn't control how our specifications get implemented or deployed. IETF participants do develop plenty of implementations, though 🧚 The IETF also doesn't standardise every layer of the protocol stack. And the non-technical stuff, like legal and political aspects of mitigating pervasive monitoring, is outside the IETF's scope 😭 The broader Internet community will need to step up and tackle PM if it's going to be fully addressed 💜

To sum it all up: current capabilities let some actors monitor content and metadata across the Internet at a scale we've never seen before. This pervasive monitoring is an attack on Internet privacy, and the IETF will strive to produce specifications that mitigate pervasive monitoring attacks 👑✨

3. Process Note 🧚

In the past, architectural statements like this one, for example [RFC1984] and [RFC2804], were published as joint products of the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB) 💅 But since those documents came out, the IETF and IAB have separated their publication "streams," as described in [RFC4844] and [RFC5741]. This document started after discussions in both the IESG and the IAB, but it's published as an IETF-stream consensus document 🌸 The reason is to make sure it properly reflects the consensus of the IETF community as a whole 🎀

6. Informative References ✨

Okay bestie, here's the reading list 📚💖 These are the extra references that back up the story. Every label, title, date and number is exactly as it was in the original:

  • [IETF88Plenary] IETF, "IETF 88 Plenary Meeting Materials", November 2013, <http://www.ietf.org/proceedings/88/>.
  • [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996.
  • [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
  • [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
  • [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007.
  • [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
  • [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
  • [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, June 2013.
  • [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013.

Authors' Addresses 🎀

Here's where you can find the authors. Stephen and Hannes, the brains behind this one, are both reachable at the details below 🫶

Stephen Farrell
Trinity College Dublin
Dublin  2
Ireland

Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie


Hannes Tschofenig
ARM Ltd.
6060 Hall in Tirol
Austria

EMail: Hannes.tschofenig@gmx.net
URI:   http://www.tschofenig.priv.at
📦 where this page comes from