RFC 7624

Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement

📅 published August 2015, from ietf

Title Block: RFC 7624 🎀

Okay bestie, this is RFC 7624 from the Internet Architecture Board (IAB), and it's titled Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement 💜. Authors: R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, and D. Borkmann. It's Informational (not a standards-track spec 🙈), published August 2015, ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates.

Abstract ✨

Okay so, ever since the first big reveals about pervasive surveillance in 2013, people have found several classes of attacks on Internet communications 😭. This doc builds a threat model that describes those attacks on Internet confidentiality. The attacker it has in mind wants to eavesdrop on everything, indiscriminately, and never get caught 🕵️‍♀️. The threat model is based on published, verified attacks, so none of this is vibes-based, it's receipts 🧾.

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes, just for the record 🗂️.

It's a product of the Internet Architecture Board (IAB) and it's info the IAB decided was worth keeping on permanent record. It represents the consensus of the IAB. Documents the IAB approves for publication are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💅.

Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7624 🔗.

Copyright Notice ©️

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 in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 🙏.

Table of Contents 🗺️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  An Idealized Passive Pervasive Attacker . . . . . . . . . . .   5
     3.1.  Information Subject to Direct Observation . . . . . . . .   6
     3.2.  Information Useful for Inference  . . . . . . . . . . . .   6
     3.3.  An Illustration of an Ideal Passive Pervasive Attack  . .   7
       3.3.1.  Analysis of IP Headers  . . . . . . . . . . . . . . .   7
       3.3.2.  Correlation of IP Addresses to User Identities  . . .   8
       3.3.3.  Monitoring Messaging Clients for IP Address
               Correlation . . . . . . . . . . . . . . . . . . . . .   9
       3.3.4.  Retrieving IP Addresses from Mail Headers . . . . . .   9
       3.3.5.  Tracking Address Usage with Web Cookies . . . . . . .  10
       3.3.6.  Graph-Based Approaches to Address Correlation . . . .  10
       3.3.7.  Tracking of Link-Layer Identifiers  . . . . . . . . .  10
   4.  Reported Instances of Large-Scale Attacks . . . . . . . . . .  11
   5.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Attacker Capabilities . . . . . . . . . . . . . . . . . .  14
     5.2.  Attacker Costs  . . . . . . . . . . . . . . . . . . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   IAB Members at the Time of Approval . . . . . . . . . . . . . . .  23
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1. Introduction ✨

Starting in June 2013, documents Edward Snowden gave to the press revealed several operations where intelligence agencies exploited Internet communications for intel 🕵️. These attacks were mostly based on protocol vulnerabilities that were already known. What made them so striking was how pervasive they were, both in how much Internet traffic got targeted and in how many different attack techniques got used 😳.

To make sure users can trust the Internet, the Internet technical community needs to fix the vulnerabilities these attacks exploited [RFC7258] 🛠️. The goal of this doc is to describe the threats from these pervasive attacks more precisely, and then, based on those threats, lay out the problems that need solving to secure the Internet against them 🔐.

Here's the lay of the land. In Section 3, we meet an idealized passive pervasive attacker, one that could completely undetectably compromise communications at Internet scale 👀. In Section 4, we briefly cover some attacks that have been disclosed, and use them to expand what our idealized attacker can do 📈. Note that we're not trying to describe every possible attack, just the ones that result in undetected eavesdropping 🙅‍♀️. Section 5 then describes a threat model based on these attacks, focusing on classes of attack that Internet engineering hasn't really been focused on so far 🎯.

2. Terminology 📚

This doc uses a lot of standard security and privacy terminology, see [RFC4949] and [RFC6973] 🤓. Terms taken from [RFC6973] include Eavesdropper, Observer, Initiator, Intermediary, Recipient, Attack (in a privacy context), Correlation, Fingerprint, Traffic Analysis, and Identifiability (and related terms) 💖.

We also use a few terms specific to the attacks in this doc. Important tea: "passive" and "active" here do not refer to how much effort went into the attack ☕. A "passive attack" is any attack that accesses a flow but doesn't modify it. An "active attack" is any attack that modifies a flow. Some passive attacks involve actively intercepting and modifying devices, instead of just getting access to the medium, so it's not as simple as it sounds 🙃. The new terms are below 👇.

Pervasive Attack: An attack on Internet communications that uses access at a large number of points in the network, or otherwise gives the attacker access to a large amount of Internet traffic. See [RFC7258] 🌐.

Passive Pervasive Attack: An eavesdropping attack run by a pervasive attacker, where the packets in a traffic stream between two endpoints get intercepted. The attacker doesn't modify those packets, doesn't change how they're treated (like delaying them or messing with routing), and doesn't add or remove packets in the stream 🤫. Passive pervasive attacks are undetectable from the endpoints 👻. This is equivalent to passive wiretapping as defined in [RFC4949], but we use a different term because the methods are wider than "wiretapping" implies, including actively compromising intermediate systems 🧠.

Active Pervasive Attack: An attack run by a pervasive attacker that, on top of everything in a passive pervasive attack, also modifies, adds, or removes packets in a traffic stream, or changes how packets in the stream are treated 😈. Active pervasive attacks give the attacker more capabilities, but they risk being detected at the endpoints 🚨. This is equivalent to active wiretapping as defined in [RFC4949] 🔁.

Observation: Information collected directly from communications by an eavesdropper or observer. For example, learning that <alice@example.com> sent a message to <bob@example.com> via SMTP, taken from the headers of an observed SMTP message, would be an observation 👀💌.

Inference: Information derived from analyzing information collected directly from communications by an eavesdropper or observer. For example, learning that a given web page was accessed by a given IP address, by comparing the size in octets of measured network flow records to fingerprints derived from known sizes of linked resources on the web servers involved, would be an inference 🧩.

Collaborator: An entity that's a legit participant in a communication and gives info about that communication to an attacker 🤝. Collaborators may cooperate with the attacker deliberately or unwittingly. In the unwitting case, it's because the attacker has subverted the collaborator through technical, social, or other means 😬.

Key Exfiltration: The transmission of cryptographic keying material for an encrypted communication from a collaborator to an attacker, deliberately or unwittingly 🔑💀.

Content Exfiltration: The transmission of the content of a communication from a collaborator to an attacker, deliberately or unwittingly 📤.

3. An Idealized Passive Pervasive Attacker 😈

Okay, so to think about how scary pervasive surveillance is, we start by defining an idealized passive pervasive attacker 🧁. This attacker is less capable than the ones we now know have compromised the Internet from press reports (more on that in Section 4). But it still sets a lower bound on what an attacker interested in indiscriminate passive surveillance can do while staying undetectable 🫣. Also, fun fact: before the Snowden revelations in 2013, the attacker assumptions here would've been considered on the border of paranoia outside the network security community 😭🙈.

Our idealized attacker is an indiscriminate eavesdropper on an Internet-attached computer network, and it:

can observe every packet of all communications at any hop in any network path between an initiator and a recipient;
can observe data at rest in any intermediate system between the endpoints controlled by the initiator and recipient; and
can share information with other such attackers; but
takes no other action with respect to these communications (i.e., blocking, modification, injection, etc.).

The techniques our ideal attacker has are direct observation and inference 🔍. Direct observation means taking information straight from eavesdropped communications, like URLs that identify content or email addresses that identify individuals from application-layer headers 📩. Inference is analyzing observed information to derive new information, like searching for application or behavioral fingerprints in observed traffic to learn about the person being observed 🕵️‍♀️🧠.

Encryption is generally enough to give confidentiality by preventing direct observation of content, assuming (of course!) uncompromised encryption implementations and cryptographic keying material 🔐✨. But encryption gives less complete protection against inference. This is especially true for inferences based only on the plaintext parts of communications, like IP and TCP headers for TLS-protected traffic [RFC5246] 🫠.

Heads up, this is the end of part 1 of 6! Part 2 picks up the rest of Section 3 and keeps going, so stay tuned 💖🦋

3.1. Information Subject to Direct Observation ✨

Okay so, protocols that don't encrypt their payload basically hand the idealized attacker the whole conversation on a silver platter 🍽️💀. Following the advice in [RFC3365], most of these protocols have a secure variant that encrypts the payload for confidentiality, and those secure versions are getting more and more popular 💖. The main exception is DNS [RFC1035], because DNSSEC [RFC4033] doesn't have confidentiality as a requirement 🙈.

That means, unless the protocol changes that the IETF's DNS Private Exchange (DPRIVE) working group is cooking up [DPRIVE] land, every DNS query and answer produced by any protocol's activity is visible to the attacker 👀🔥.

Store-and-forward protocols like SMTP [RFC5321] are a whole other vibe 🌸. The intermediaries hold onto the data and pass it along, so an attacker that has compromised those intermediaries can observe it too. The only exceptions are when the application-layer protocol encrypts the data end-to-end, or when the implementation keeps the data in an encrypted store ✨.

3.2. Information Useful for Inference 🦋

Okay, inference is basically what you get when you analyze an observed or eavesdropped communication later, and/or when you match what you saw against info from other sources 🧠. Honestly, most of the useful inference the attacker does is correlation, and the simplest example is watching the DNS queries and answers from a source and matching them up with the IP addresses that source talks to 🔍. That can reveal stuff that's hidden inside encrypted application payloads, like the "Host:" HTTP/1.1 request header when HTTP runs over TLS 👑.

Protocols that encrypt their payload with an application- or transport-layer scheme (like TLS) still expose everything in their network- and transport-layer headers. That means source and destination addresses and ports are all visible to the attacker 😭. IPsec Encapsulating Security Payload (ESP) [RFC4303] goes a step further and encrypts the transport-layer headers, but the IP address info is still unencrypted. In tunnel mode, those addresses correspond to the tunnel endpoints 🎀. Even features of the security protocols themselves, like the TLS session identifier, can leak info that's useful for correlation and inference 🫣. It's way less semantically rich than the application payload, but it can still help figure out what an individual is up to 💅.

Inference doesn't only come from watching traffic, either 🌈. Geolocation databases map IP addresses to locations so services can be location-aware, like targeted advertising 📍. That location info is often detailed enough to make further inferences toward identifying or profiling someone 😳.

Social media is another source of info that's more or less public 📱. It can be extremely semantically rich, covering someone's location, their associations with other people and groups, and their activities ✨. The kicker is that people contribute and curate it voluntarily, so it's info they're not necessarily trying to protect for privacy reasons 🙃. Correlating social networking data with directly observed network traffic gives a much richer picture of someone's activities than either source could alone 🚨.

We have to note with some alarm that there's very little that can be done at protocol design time to limit this kind of correlation by the attacker 😱. The existence of these data sources also greatly complicates the problem of protecting privacy by hardening protocols alone.

3.3. An Illustration of an Ideal Passive Pervasive Attack 🕵️‍♀️

Let's see how capable the idealized attacker is, even with its limitations 💪. In this section we look at the non-anonymity of encrypted IP traffic. We'll go through some inference techniques for linking a set of addresses to an individual, so you can see how hard it is to defend communications against this attacker 🫶. The core problem is that even protocols with no obvious connection to personal data can leak info that gets correlated with other info to paint a super rich behavioral picture 🎨. It only takes one unprotected link in the chain to tie things to an identity 🔗💀.

3.3.1. Analysis of IP Headers 📦

Internet traffic can be monitored by tapping Internet links or by installing monitoring tools in Internet routers 🔌. A single link or single router only sees a fraction of global Internet traffic, though 😅. Monitoring a number of high-capacity links, or a set of routers in strategic spots, gives access to a good sampling of Internet traffic 🍓.

Tools like the IP Flow Information Export (IPFIX) Protocol [RFC7011] let administrators collect statistics about sequences of packets that share some common properties and pass through a network device 📊. The most common set of properties used in flow measurement is the "five-tuple": source and destination addresses, protocol type, and source and destination ports 🧚. These stats are commonly used for network engineering, but they could definitely be used for other purposes too 👀.

Let's pretend for a moment that IP addresses can be correlated with specific services or specific users 🤭. Analyzing sequences of packets will quickly reveal which users use what services, and which users have peer-to-peer connections with other users 💜. Analyzing traffic variations over time can detect increased activity by particular users or, for peer-to-peer connections, increased activity within groups of users 📈.

3.3.2. Correlation of IP Addresses to User Identities 🪪

There are lots of ways to correlate IP addresses with specific users 🔎. For example, tools like reverse DNS lookup can retrieve the DNS names of servers 🖥️. Server addresses tend to be really stable, and servers are way less numerous than users, so an attacker could easily keep its own copy of the DNS for well-known or popular servers to speed up these lookups 🏃‍♀️.

Reverse lookups of user IP addresses are usually less informative, though 🙄. For example, looking up the address currently used by one author's home network returns a name like c-192-000-002-033.hsd1.wa.comcast.net. This type of reverse DNS lookup generally only reveals coarse-grained location or provider info, which is about the same as what geolocation databases give you 🗺️.

In many jurisdictions, Internet Service Providers (ISPs) have to identify the "owner" of a specific IP address on a case-by-case basis for law enforcement purposes ⚖️. That's a pretty expedient process for targeted investigations, but pervasive surveillance needs something more efficient 😤. So the attacker has an incentive to get the ISP to cooperate and automate this correlation 🤝.

3.3.3. Monitoring Messaging Clients for IP Address Correlation 💬

Even if the ISP doesn't cooperate, user identity can often be inferred anyway 🫠. POP3 [RFC1939] and IMAP [RFC3501] are used to retrieve mail from mail servers, and a variant of SMTP is used to submit messages through mail servers 📬. IMAP connections come from the client and usually start with an authentication exchange, where the client proves its identity by answering a password challenge 🔐. The same goes for the SIP protocol [RFC3261] and lots of instant messaging services that run over the Internet using proprietary protocols 💌.

If any of these protocols run in cleartext, the username is directly observable 👁️. The username can then be directly tied to the source address 💅.

3.3.4. Retrieving IP Addresses from Mail Headers 💌

SMTP [RFC5321] requires that each successive SMTP relay adds a "Received" header to the mail headers 📨. These headers exist to enable auditing of mail transmission, and maybe to tell regular mail apart from spam 🗑️. Here's an extract from the headers of a message recently received from the perpass mailing list 👇:

Received: from 192-000-002-044.zone13.example.org (HELO
?192.168.1.100?) (xxx.xxx.xxx.xxx) by lvps192-000-002-219.example.net
with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Oct
2013 21:47:14 +0100 Message-ID: <526D7BD2.7070908@example.org> Date:
Sun, 27 Oct 2013 20:47:14 +0000 From: Some One <some.one@example.org>

This is the first "Received" header added to the message by the first SMTP relay. The field values have been anonymized for privacy reasons 🫶. From it we learn that the message was submitted by "Some One" on October 27, from a host behind a NAT (192.168.1.100) [RFC1918] that used the IP address 192.0.2.44 🕵️‍♀️. That info stays in the message and is accessible to every recipient of the perpass mailing list, or to any attacker that sees at least one copy of the message 😬.

An attacker that can observe enough email traffic can keep updating the mapping between public IP addresses and individual email identities 🔄. Even if the SMTP traffic was encrypted on submission and relaying, the attacker can still receive a copy of public mailing lists like perpass 📣.

3.3.5. Tracking Address Usage with Web Cookies 🍪

Lots of websites only encrypt a small fraction of their transactions 🥲. A popular pattern is to use HTTPS for login info, then use a "cookie" to link the following cleartext transactions to the user's identity 🎟️. Advertising services use cookies too, to quickly identify users and serve them "personalized" ads 🛍️. Cookies are especially useful if the advertising services want to keep tracking someone across multiple sessions that might use different IP addresses 👀.

Cookies are sent in cleartext, so an attacker can build a database that links cookies to IP addresses for non-HTTPS traffic 🗄️. If the IP address is already identified, the cookie can be linked to the user's identity 🔗. After that, if the same cookie shows up on a new IP address, that new address can be instantly associated with the already-known identity ⚡.

3.3.6. Graph-Based Approaches to Address Correlation 🕸️

An attacker can track traffic from an IP address that isn't yet tied to an individual, going to various public services (like web sites, mail servers, and game servers) 🎮. Then it can look for patterns in that traffic and correlate the address with other addresses that show similar patterns 🧩. For example, any two addresses that connect to the same IMAP or webmail services, the same set of favorite web sites, and game servers at similar times of day might belong to the same individual 💖. Once correlated addresses are tied to an individual through one of the techniques above, the attacker can walk the "network graph" to expand the set of attributable traffic 🌟.

3.3.7. Tracking of Link-Layer Identifiers 🦋

okay so moving back down the stack 🧚 technologies like Ethernet or Wi-Fi use MAC (Media Access Control) addresses to identify link-level destinations. MAC addresses assigned according to IEEE 802 standards are globally unique identifiers for the device 💖. If the link is publicly accessible, an attacker can eavesdrop and perform tracking. For example, the attacker can track the wireless traffic at publicly accessible Wi-Fi networks. Simple devices can monitor the traffic and reveal which MAC addresses are present 👀. Also, devices do not need to be connected to a network to expose link-layer identifiers 😭.

Active service discovery always discloses the MAC address of the user, and sometimes the Service Set Identifiers (SSIDs) of previously visited networks 💅. For instance, certain techniques such as the use of "hidden SSIDs" require the mobile device to broadcast the network identifier together with the device identifier. This combination can further expose the user to inference attacks, as more information can be derived from the combination of MAC address, SSID being probed, time, and current location 🙈. For example, a user actively probing for a semi-unique SSID on a flight out of a certain city can imply that the user is no longer at the physical location of the corresponding AP ✈️.

Given that large-scale databases of the MAC addresses of wireless access points for geolocation purposes have been known to exist for some time, the attacker could easily build a database that maps link-layer identifiers and time with device or user identities, and use it to track the movement of devices and of their owners 🗺️. On the other hand, if the network does not use some form of Wi-Fi encryption, or if the attacker can access the decrypted traffic, the analysis will also provide the correlation between link-layer identifiers such as MAC addresses and IP addresses 🔥. Additional monitoring using techniques exposed in the previous sections will reveal the correlation between MAC addresses, IP addresses, and user identity. For instance, similarly to the use of web cookies, MAC addresses provide identity information that can be used to associate a user to different IP addresses 💜.

4. Reported Instances of Large-Scale Attacks ✨

The situation in reality is more bleak than that suggested by an analysis of our idealized attacker 😱. Through revelations of sensitive documents in several media outlets, the Internet community has been made aware of several intelligence activities conducted by US and UK national intelligence agencies, particularly the US National Security Agency (NSA) and the UK Government Communications Headquarters (GCHQ). These documents have revealed methods that these agencies use to attack Internet applications and obtain sensitive user information. There is little reason to suppose that only the US or UK governments are involved in these sorts of activities; the examples are just ones that were disclosed. We note that these reports are primarily useful as an illustration of the types of capabilities fielded by pervasive attackers as of the date of the Snowden leaks in 2013 📰.

First, they confirm the deployment of large-scale passive collection of Internet traffic, which confirms the existence of pervasive passive attackers with at least the capabilities of our idealized attacker. For example, as described in [pass1], [pass2], [pass3], and [pass4]:

NSA's XKEYSCORE system accesses data from multiple access points and searches for "selectors" such as email addresses, at the scale of tens of terabytes of data per day 💻.
GCHQ's Tempora system appears to have access to around 1,500 major cables passing through the UK 🔌.
NSA's MUSCULAR program has tapped cables between data centers belonging to major service providers 🫣.
Several programs appear to perform wide-scale collection of cookies in web traffic and location data from location-aware portable devices such as smartphones 📱.

However, the capabilities described by these reports go beyond those of our idealized attacker. They include the compromise of cryptographic protocols, including decryption of TLS-protected Internet sessions [dec1] [dec2] [dec3]. For example, the NSA BULLRUN project worked to undermine encryption through multiple approaches, including covert modifications to cryptographic software on end systems 🔐.

Reported capabilities include the direct compromise of intermediate systems and arrangements with service providers for bulk data and metadata access [dir1] [dir2] [dir3], bypassing the need to capture traffic on the wire. For example, the NSA PRISM program provides the agency with access to many types of user data (e.g., email, chat, VoIP) 😤.

The reported capabilities also include elements of active pervasive attack, including:

Insertion of devices as a man-in-the-middle of Internet transactions [TOR1] [TOR2]. For example, NSA's QUANTUM system appears to use several different techniques to hijack HTTP connections, ranging from DNS response injection to HTTP 302 redirects 🪤.
Use of implants on end systems to undermine security and anonymity features [dec2] [TOR1] [TOR2]. For example, QUANTUM is used to direct users to a FOXACID server, which in turn delivers an implant to compromise browsers of Tor users 💀.
Use of implants on network elements from many major equipment providers, including Cisco, Juniper, Huawei, Dell, and HP, as provided by the NSA's Advanced Network Technology group [spiegel1] 🤯.
Use of botnet-scale collections of compromised hosts [spiegel2] 🕸️.

The scale of the compromise extends beyond the network to include subversion of the technical standards process itself. For example, there is suspicion that NSA modifications to the DUAL_EC_DRBG random number generator (RNG) were made to ensure that keys generated using that generator could be predicted by NSA. This RNG was made part of NIST's SP 800-90A, for which NIST acknowledges the NSA's assistance. There have also been reports that the NSA paid RSA Security for a related contract with the result that the curve became the default in the RSA BSAFE product line 🥲.

We use the term "pervasive attack" [RFC7258] to collectively describe these operations. The term "pervasive" is used because the attacks are designed to indiscriminately gather as much data as possible and to apply selective analysis on targets after the fact. This means that all, or nearly all, Internet communications are targets for these attacks. To achieve this scale, the attacks are physically pervasive; they affect a large number of Internet communications. They are pervasive in content, consuming and exploiting any information revealed by the protocol. And they are pervasive in technology, exploiting many different vulnerabilities in many different protocols 🌍.

Again, it's important to note that, although the attacks mentioned above were executed by the NSA and GCHQ, there are many other organizations that can mount pervasive surveillance attacks. Because of the resources required to achieve pervasive scale, these attacks are most commonly undertaken by nation-state actors 🏛️. For example, the Chinese Internet filtering system known as the "Great Firewall of China" uses several techniques that are similar to the QUANTUM program and that have a high degree of pervasiveness with regard to the Internet in China. Therefore, legal restrictions in any one jurisdiction on pervasive monitoring activities cannot eliminate the risk of pervasive attack to the Internet as a whole 🫶.

5. Threat Model 🎀

Given these disclosures, we must consider a broader threat model 🧐.

Pervasive surveillance aims to collect information across a large number of Internet communications, analyzing the collected communications to identify information of interest within individual communications, or inferring information from correlated communications. This analysis sometimes benefits from decryption of encrypted communications and deanonymization of anonymized communications. As a result, these attackers desire both access to the bulk of Internet traffic and to the keying material required to decrypt any traffic that has been encrypted. Even if keys are not available, note that the presence of a communication and the fact that it is encrypted may both be inputs to an analysis, even if the attacker cannot decrypt the communication 🔍.

The attacks listed above highlight new avenues both for access to traffic and for access to relevant encryption keys. They further indicate that the scale of surveillance is sufficient to provide a general capability to cross-correlate communications, a threat not previously thought to be relevant at the scale of the Internet 🌈.

5.1. Attacker Capabilities 💅

Okay bestie, let's talk about the baddies and what they can actually do 👀. First, the big table of attack classes and what each one can pull off:

+--------------------------+-------------------------------------+
| Attack Class             | Capability                          |
+--------------------------+-------------------------------------+
| Passive observation      | Directly capture data in transit    |
|                          |                                     |
| Passive inference        | Infer from reduced/encrypted data   |
|                          |                                     |
| Active                   | Manipulate / inject data in transit |
|                          |                                     |
| Static key exfiltration  | Obtain key material once / rarely   |
|                          |                                     |
| Dynamic key exfiltration | Obtain per-session key material     |
|                          |                                     |
| Content exfiltration     | Access data at rest                 |
+--------------------------+-------------------------------------+

So security folks usually think about two kinds of attacker 🕵️. The first is the passive pervasive attacker, who just lurks and listens to comms as they travel across the network. The second is the active pervasive attacker, who can do all of that and modify or delete packets 😭.

Now here's the spicy part 🌶️. Pervasive surveillance makes these attacks way scarier. Back in the day, attackers mostly hung out at the edge of the network, because attacks were simpler there. Like, on some LANs it's super easy for any node to listen in on everyone else's traffic or inject packets for an active pervasive attack. But as we now know, both passive and active pervasive attackers are operating closer to the core of the network, which seriously blows up how much they can see and do 🌈.

Big-scale eavesdropping makes passive inference attacks way easier to pull off 🔍. A passive pervasive attacker with access to a huge chunk of the Internet can analyze collected traffic and build a much more detailed picture of individual behavior than someone collecting at just one point. Even the usual "encryption defeats passive pervasive attackers" line gets weakened, because a pervasive flow access attacker can infer relationships from correlations across lots of sessions. For example, they can pair encrypted sessions with unencrypted sessions from the same host, or do traffic fingerprinting between known and unknown encrypted sessions. Reports on the NSA XKEYSCORE system suggest it's an example of this kind of attacker 👀.

Active pervasive attackers are also next level compared to localized active ones 💥. Flow modification attacks are usually limited by topology. For instance, the attacker needs to be able to see a targeted session and inject packets into it. A pervasive flow modification attacker with access at multiple points within the core of the Internet can blow past those limits and attack a much wider scope. Being in the core instead of the edge can also let an active pervasive attacker reroute targeted traffic, which boosts both their eavesdropping and their traffic injection powers. Active pervasive attackers can even use passive pervasive collection to find vulnerable hosts 🎯.

Not directly about pervasiveness, but still tea ☕: attackers who can mount an active pervasive attack are often also able to subvert authentication, which is a traditional defense against this stuff 😤. On the Internet, authentication usually relies on trusted third-party authorities, like the Certificate Authorities (CAs) that hand web sites their authentication credentials. An attacker with enough resources might be able to convince an authority to grant credentials for an identity the attacker picked. If the parties to a communication trust multiple authorities to certify a specific identity, the attacker can go after any one of them, the proverbial "weakest link" 🔗. Subverting an authority like this can let an active attack succeed even when the authentication check passes.

Okay, so beyond those three classes (observation, inference, and active), reports on the BULLRUN effort to defeat encryption and the PRISM effort to get data from service providers suggest three more classes of attack 🫣:

Static key exfiltration
Dynamic key exfiltration
Content exfiltration

All of these depend on a collaborator handing the attacker something, either keys or data 🤝. Traditionally, these attacks haven't been considered in scope for the Security Considerations sections of IETF protocols, since they happen outside the protocol itself 🙈.

"Key exfiltration" means the transfer of keying material for an encrypted communication from the collaborator to the attacker 🔑. "Static" means the keys move once or rarely, and the transferred key is usually long-lived. For example, a web site operator handing over the private key for its HTTPS certificate to an intelligence agency would count 🕵️.

"Dynamic" key exfiltration is the frequent version, where the collaborator delivers keying material to the attacker on a per-session basis, or pretty often 🔄. That doesn't necessarily mean lots of back-and-forth with the attacker, though, because the transfer can be virtual. For example, if an endpoint were modified so the attacker could predict the state of its pseudorandom number generator, the attacker could derive per-session keys without any per-session communication at all 🤯.

Last one: content exfiltration is when the collaborator just gives the attacker the data or metadata they want 📦. Unlike the key exfiltration cases, the attacker doesn't have to capture the data as it flows through the network. This is data at rest, not data in transit. That makes the scope way bigger, because the attacker can grab historical data. They don't have to be listening at the moment the communication happens 🕰️.

Exfiltration can also happen through attacks on one of the parties to a communication. The attacker steals the keys or content instead of the party handing them over willingly. In these cases, the party may not know, at least on a human level, that they're collaborating. The subverted technical assets are "collaborating" with the attacker by providing keys or content, without their owner's knowledge or consent 😱.

Any party with access to encryption keys or unencrypted data can be a collaborator 🫶. Usually collaborators are the endpoints of a communication, with encryption protecting the links. But intermediaries in an unencrypted communication can also help with content exfiltration by giving the attacker access to those communications. For example, documents describing the NSA PRISM program claim that NSA can access user data directly from servers, where it's stored unencrypted. In that case, the server operator would be a collaborator, even an unwitting one 🖥️. On the flip side, in the NSA MUSCULAR program, a set of collaborators let attackers access the cables connecting data centers used by service providers such as Google and Yahoo. Since communications among those data centers weren't encrypted, the collaboration by that intermediate entity let the NSA collect unencrypted user data 🧵. Iconic behavior from the surveillance world, honestly 💀.

5.2. Attacker Costs

     +--------------------------+-----------------------------------+
     | Attack Class             | Cost / Risk to Attacker           |
     +--------------------------+-----------------------------------+
     | Passive observation      | Passive data access               |
     |                          |                                   |
     | Passive inference        | Passive data access + processing  |
     |                          |                                   |
     | Active                   | Active data access + processing   |
     |                          |                                   |
     | Static key exfiltration  | One-time interaction              |
     |                          |                                   |
     | Dynamic key exfiltration | Ongoing interaction / code change |
     |                          |                                   |
     | Content exfiltration     | Ongoing, bulk interaction         |
     +--------------------------+-----------------------------------+

okay so let's talk about what it actually costs the attacker to pull these off 💅 every attack in the previous section comes with its own price tag and its own risk, and knowing those prices is super helpful when you're figuring out how to respond to a pervasive attack 🎀 the table above is the quick cheat sheet, and now we get the juicy details ✨

so the biggest risk for an attacker isn't just getting kicked off the network 😭 it can go all the way to arrest or prosecution 💀 but none of that can happen unless the attacker first gets discovered and identified. so yeah, the main risk we're focusing on here is discovery and attribution 🦋

passive pervasive attacks are kinda the easiest to mount, ngl 🌸 the basic requirement is just getting physical access to a communications medium and pulling the communications off it. like, the attacker could tap a fiber-optic cable, grab a mirror port on a switch, or just listen to a wireless signal 🧚 but that physical access or closeness to the link is exactly what exposes them to getting caught 🙈 a fiber tap or mirror port could get noticed because operators see more attenuation in the fiber or a switch config that changed 👀 and of course, a passive pervasive attack can also happen with the network operator's cooperation, in which case the attacker's interactions with that operator could get exposed too 💜

active pervasive attacks have a lot of the same costs and risks as passive ones, plus some extra drama 💅 an active attacker needs stronger network access than a passive one, because they usually have to transmit as well as receive 🔥 in the wireless example, the attacker would be a transmitter and a receiver, which seriously ups the chance they get found (direction-finding tech, anyone? 😬). active attacks are also way more observable at higher layers of the network 🫶 like, an active attacker trying to use a mis-issued certificate could get detected through Certificate Transparency [RFC6962] 👑

in terms of raw implementation complexity, passive pervasive attacks only need enough processing to extract information from the network and store it 🌈 active pervasive attacks are more of a mess, since they often depend on winning race conditions to inject packets into active connections 😭 so active pervasive attacks in the core of the network need hardware that can operate at line speed (roughly 100 Gbps to 1 Tbps in the core) to spot attack opportunities and slip attack traffic into high-volume flows 🚀 and key exfiltration attacks depend on passive pervasive attacks to get access to encrypted data, with the collaborator handing over the keys to decrypt it 🔐 so the attacker takes on the cost and risk of a passive pervasive attack plus the extra risk of getting discovered through their interactions with the collaborator 💀

some active attacks are pricier than others, tho 🎀 for example, active man-in-the-middle (MITM) attacks need access to one or more points on a communication's network path that let them see the entire session and modify or drop legitimate packets in favor of their own 👑 a similar but weaker version, called an active man-on-the-side (MOTS), only needs access to part of the session 🦋 in an active MOTS attack, the attacker only needs to be able to inject or modify traffic on the network element they can reach 🌸 this doesn't give them full control like an MITM attack does, but they can still pull off a bunch of powerful stuff, including (but not limited to):

injecting packets that could terminate the session (e.g., TCP RST packets) 💀
sending a fake DNS reply to redirect the TCP connections that follow to an address of the attacker's choice (aka winning a "DNS response race") 🙈
running an HTTP redirect attack by watching a TCP/HTTP connection to a target address and injecting a TCP data packet containing an HTTP redirect 🧚

for example, the system researchers nicknamed China's "Great Cannon" [great-cannon] can work in full MITM mode for super complex attacks that modify content in transit ✨ meanwhile, the well-known Great Firewall of China is a MOTS system that mostly focuses on blocking certain kinds of traffic and destinations by injecting TCP RST packets 🔥

so yeah, static exfiltration has a lower risk profile than dynamic exfiltration 💅 in the static case, the attacker only needs to interact with the collaborator a small number of times, maybe just once, like to swap a private key 🫶 in the dynamic case, the attacker has to keep interacting with the collaborator over and over 😬 and like we said earlier, those interactions can be real (in-person meetings) or virtual (software changes that make keys available to the attacker) 🌈 both kinds carry a risk of discovery, like employees at the collaborator's org noticing sketchy meetings or sketchy code changes 👀

content exfiltration has a similar risk profile to dynamic key exfiltration 🍓 in a content exfiltration attack, the attacker skips the cost and risk of running a passive pervasive attack 🎀 but the risk of discovery through interactions with the collaborator is still there, and might even be higher 😭 the content of a communication is obviously way bigger than the key used to encrypt it, often by several orders of magnitude 🔥 so the attacker and collaborator need a much higher-bandwidth channel than in the key exfiltration cases, and that bigger channel comes with a bigger risk of getting discovered 🚨

also, in these last three exfiltration cases, the collaborator takes a risk too, because their collaboration with the attacker could get discovered 💅 so the attacker may have to pay extra to convince the collaborator to join in 🫶 and the scope of these attacks is limited to cases where the attacker can actually recruit a collaborator 🦋 like, if the attacker is a national government, it may be able to compel participation within its own borders, but it'd have a much harder time recruiting foreign collaborators 🌍

as mentioned above, the collaborator in an exfiltration attack can also be unwitting, meaning the attacker just steals the keys or data to make the attack happen 💜 in some ways, the risks here are similar to working with an active collaborator ✨ in the static case, the attacker only has to steal information from the collaborator once 🧚 in the dynamic case, the attacker needs to stay continuously present inside the collaborator's systems 😈 the big difference is that the risk here is automated discovery (like by intrusion detection systems) instead of discovery by humans 🤖

6. Security Considerations 🚨

This document describes a threat model for pervasive surveillance attacks 😭 Mitigations are to be given in a future document 🔮

7. References 📚

7.1. Normative References

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>. 🌸

7.2. Informative References 📚✨

okay bestie, these are the "extra reading" sources, so no cap they're kind of wild 💀 they're mostly news articles about the 2013 leaks (the big surveillance reveals), plus some protocol docs that are still on the table. they're here for context, and nothing in the spec depends on them 🫶

[dec1] Perlroth, N., Larson, J., and S. Shane, "N.S.A. Able to Foil Basic Safeguards of Privacy on Web", The New York Times, September 2013, http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html.

[dec2] The Guardian, "Project Bullrun -- classification guide to the NSA's decryption program", September 2013, http://www.theguardian.com/world/interactive/2013/sep/05/nsa-project-bullrun-classification-guide.

[dec3] Ball, J., Borger, J., and G. Greenwald, "Revealed: how US and UK spy agencies defeat internet privacy and security", The Guardian, September 2013, http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security.

[dir1] Greenwald, G., "NSA collecting phone records of millions of Verizon customers daily", The Guardian, June 2013, http://www.theguardian.com/world/2013/jun/06/nsa-phone-records-verizon-court-order.

[dir2] Greenwald, G. and E. MacAskill, "NSA Prism program taps in to user data of Apple, Google and others", The Guardian, June 2013, http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data.

[dir3] The Guardian, "Sigint -- how the NSA collaborates with technology companies", September 2013, http://www.theguardian.com/world/interactive/2013/sep/05/sigint-nsa-collaborates-technology-companies.

[DPRIVE] Bortzmeyer, S., "DNS privacy considerations", Work in Progress, draft-ietf-dprive-problem-statement-06, June 2015.

[great-cannon] Marczak, B., Weaver, N., Dalek, J., Ensafi, R., Fifield, D., McKune, S., Rey, A., Scott-Railton, J., Deibert, R., and V. Paxson, "China's Great Cannon", The Citizen Lab, University of Toronto, 2015, https://citizenlab.org/2015/04/chinas-great-cannon/.

[pass1] Greenwald, G. and S. Ackerman, "How the NSA is still harvesting your online data", The Guardian, June 2013, http://www.theguardian.com/world/2013/jun/27/nsa-online-metadata-collection.

[pass2] Ball, J., "NSA's Prism surveillance program: how it works and what it can do", The Guardian, June 2013, http://www.theguardian.com/world/2013/jun/08/nsa-prism-server-collection-facebook-google.

[pass3] Greenwald, G., "XKeyscore: NSA tool collects 'nearly everything a user does on the internet'", The Guardian, July 2013, http://www.theguardian.com/world/2013/jul/31/nsa-top-secret-program-online-data.

[pass4] MacAskill, E., Borger, J., Hopkins, N., Davies, N., and J. Ball, "How does GCHQ's internet surveillance work?", The Guardian, June 2013, http://www.theguardian.com/uk/2013/jun/21/how-does-gchq-internet-surveillance-work.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, http://www.rfc-editor.org/info/rfc1035.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, http://www.rfc-editor.org/info/rfc1918.

[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, http://www.rfc-editor.org/info/rfc1939.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, http://www.rfc-editor.org/info/rfc3261.

[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, http://www.rfc-editor.org/info/rfc3365.

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, http://www.rfc-editor.org/info/rfc3501.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, http://www.rfc-editor.org/info/rfc4033.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, http://www.rfc-editor.org/info/rfc4303.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, http://www.rfc-editor.org/info/rfc4949.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, http://www.rfc-editor.org/info/rfc5246.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, http://www.rfc-editor.org/info/rfc5321.

[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, http://www.rfc-editor.org/info/rfc6962.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, http://www.rfc-editor.org/info/rfc7011.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, http://www.rfc-editor.org/info/rfc7258.

[spiegel1] Appelbaum, J., Horchert, J., Reissmann, O., Rosenbach, M., Schindler, J., and C. Stocker, "NSA's Secret Toolbox: Unit Offers Spy Gadgets for Every Need", Spiegel Online, December 2013, http://www.spiegel.de/international/world/nsa-secret-toolbox-ant-unit-offers-spy-gadgets-for-every-need-a-941006.html.

[spiegel2] Appelbaum, J., Gibson, A., Guarnieri, C., Muller-Maguhn, A., Poitras, L., Rosenbach, M., Schmundt, H., and M. Sontheimer, "The Digital Arms Race: NSA Preps America for Future Battle", Spiegel Online, January 2015, http://www.spiegel.de/international/world/new-snowden-docs-indicate-scope-of-nsa-preparations-for-cyber-battle-a-1013409.html.

[TOR1] Schneier, B., "How the NSA Attacks Tor/Firefox Users With QUANTUM and FOXACID", Schneier on Security, October 2013, https://www.schneier.com/blog/archives/2013/10/how_the_nsa_att.html.

[TOR2] The Guardian, "'Tor Stinks' presentation -- read the full document", October 2013, http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document.

IAB Members at the Time of Approval 🎀

these are the IAB folks who were around when this got the green light 💅 the squad list:

Jari Arkko (IETF Chair)
Mary Barnes
Marc Blanchet
Ralph Droms
Ted Hardie
Joe Hildebrand
Russ Housley
Erik Nordmark
Robert Sparks
Andrew Sullivan
Dave Thaler
Brian Trammell
Suzanne Woolf

Acknowledgements 🫶

okay the thank-you section is so sweet 🥹 huge shoutout to Dave Thaler for the list of attacks and the taxonomy 👑 and to the Security Area Directors Stephen Farrell, Sean Turner, and Kathleen Moriarty for kicking off and running the IETF's whole conversation about pervasive attack 🔥 then a big group hug for Stephan Neuhaus, Mark Townsley, Chris Inacio, Evangelos Halepilidis, Bjoern Hoehrmann, Aziz Mohaisen, Russ Housley, Joe Hall, Andrew Sullivan, the IEEE 802 Privacy Executive Committee SG, and the IAB Privacy and Security Program for all their input 💖

Authors' Addresses 💜

the people who wrote this, and how to reach them 🦋

Richard Barnes Email: rlb@ipv.sx
Bruce Schneier Email: schneier@schneier.com
Cullen Jennings Email: fluffy@cisco.com
Ted Hardie Email: ted.ietf@gmail.com
Brian Trammell Email: ietf@trammell.ch
Christian Huitema Email: huitema@huitema.net
Daniel Borkmann Email: dborkman@iogearbox.net

📦 where this page comes from

ietf: rfc7624 2015-08
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms