Pervasive Monitoring is an Attack (monospace no more)

Snowden’s impact on Internet standards, pretty printed

The written text of Internet standards is dense and arcane, like the written text of laws. This document is my translation of an Internet standard named RFC 7258. I have reformatted and edited for readability — I welcome comments on specific ways in which meaning was lost or altered.

Internet standards sometimes contain profound and subtle thinking, and potentially have a lot of value as reading. But the standard formatting is painful to read. Open RFC 7258 on a phone to see for yourself. This Medium article is an experiment in improving the readability of standards.

I chose this specific standard because of the potency of the underlying idea. It is a reaction to the Snowden revelations, which showed security weaknesses in Internet Standards are deep and wide, and that these weaknesses are enabling massive attacks on the users of the Internet by criminals and governments alike. The people who work on Internet standards are directly responsible for these flaws. This document may well lead to years if not decades of followup work.

—Lucas Gonze, July 10, 2014

Authors

The Internet standard was written by Stephen Farrell of Trinity College Dublin and Hannes Tschofenig of ARM Ltd. wrote the RFC. (The edited version on Medium was created by Lucas Gonze).

Abstract

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

Pervasive Monitoring is a Widespread Attack on Privacy

Pervasive Monitoring (PM) is widespread (and often covert) surveillance through intrusive gathering of protocol artefacts, including application content, or protocol metadata such as headers. Active or passive wiretaps and traffic analysis, (e.g., correlation, timing or measuring packet sizes), or subverting the cryptographic keys used to secure protocols can also be used as part of pervasive monitoring. PM is distinguished by being indiscriminate and very large scale, rather than by introducing new types of technical compromise.

The IETF community’s technical assessment is that PM is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Pervasive monitoring was discussed at the technical plenary of the November 2013 IETF meeting [IETF88Plenary] and then through extensive exchanges on IETF mailing lists. This document records the IETF community’s consensus and establishes the technical nature of PM.

The term “attack” is used here in a technical sense that differs somewhat from common English usage. In common English usage, an attack is an aggressive action perpetrated by an opponent, intended to enforce the opponent’s will on the attacked party. The term is used here to refer to behavior that subverts the intent of communicating parties without the agreement of those parties. An attack may change the content of the communication, record the content or external characteristics of the communication, or through correlation with other communication events, reveal information the parties did not intend to be revealed. It may also have other effects that similarly subvert the intent of a communicator. [RFC4949] contains a more complete definition for the term “attack”. We also use the term in the singular here, even though PM in reality may consist of a multifaceted set of coordinated attacks.

In particular, the term “attack”, used technically, implies nothing about the motivation of the actor mounting the attack. The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation. Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required of the attacker are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols.

The IETF will work to Mitigate Pervasive Monitoring

“Mitigation” is a technical term that does not imply an ability to completely prevent or thwart an attack. Protocols that mitigate PM will not prevent the attack but can significantly change the threat. (See the diagram on page 24 of RFC 4949 for how the terms “attack” and “threat” are related.) This can significantly increase the cost of attacking, force what was covert to be overt, or make the attack more likely to be detected, possibly later.

IETF standards already provide mechanisms to protect Internet communications and there are guidelines [RFC3552] for applying these in protocol design. But those standards generally do not address PM, the confidentiality of protocol metadata, countering traffic analysis, or data minimisation. In all cases, there will remain some privacy-relevant information that is inevitably disclosed by protocols. As technology advances, techniques that were once only available to extremely well-funded actors become more widely accessible. Mitigating PM is therefore a protection against a wide range of similar attacks.

It is therefore timely to revisit the security and privacy properties of our standards. The IETF will work to mitigate the technical aspects of PM, just as we do for protocol vulnerabilities in general. The ways in which IETF protocols mitigate PM will change over time as mitigation and attack techniques evolve and so are not described here.

Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions. This does not mean a new “pervasive monitoring considerations” section is needed in IETF documentation. It means that, if asked, 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?”

In particular, architectural decisions, including which existing technology is reused, may significantly impact the vulnerability of a protocol to PM. Those developing IETF specifications therefore need to consider mitigating PM when making architectural decisions. Getting adequate, early review of architectural decisions including whether appropriate mitigation of PM can be made is important. Revisiting these architectural decisions late in the process is very costly.

While PM is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam even be part of the mitigation for PM, for example, certificate transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms 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. An appropriate balance will emerge over time as real instances of this tension are considered.

Finally, the IETF, as a standards development organisation, does not control the implementation or deployment of our specifications (though IETF participants do develop many implementations), nor does the IETF standardise all layers of the protocol stack. Moreover, the non-technical (e.g., legal and political) aspects of mitigating pervasive monitoring are outside of the scope of the IETF. The broader Internet community will need to step forward to tackle PM, if it is to be fully addressed.

To summarise: current capabilities permit some actors to monitor content and metadata across the Internet at a scale never before seen. This pervasive monitoring is an attack on Internet privacy. The IETF will strive to produce specifications that mitigate pervasive monitoring attacks.

Security Considerations

This document is entirely about privacy. More information about the relationship between security and privacy threats can be found in RFC6973. Section 5.1.1 of RFC6973 specifically addresses surveillance as a combined security-privacy threat.