Skip to main content

Pervasive Monitoring is an Attack

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7258.
Authors Stephen Farrell , Hannes Tschofenig
Last updated 2014-02-06 (Latest revision 2014-01-20)
RFC stream Internet Engineering Task Force (IETF)
Stream WG state Submitted to IESG for Publication
Document shepherd Sean Turner
Shepherd write-up Show Last changed 2014-01-22
IESG IESG state Became RFC 7258 (Best Current Practice)
Consensus boilerplate Unknown
Telechat date (None)
Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.
Responsible AD Jari Arkko
Send notices to,,
IANA IANA review state IANA OK - No Actions Needed
Network Working Group                                         S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: BCP                                       H. Tschofenig
Expires: July 24, 2014                                  January 20, 2014

                   Pervasive Monitoring is an Attack


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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 24, 2014.

Copyright Notice

   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
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Farrell & Tschofenig      Expires July 24, 2014                 [Page 1]
Internet-Draft      Pervasive Monitoring is an Attack       January 2014

1.  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 meta-data 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

   The IETF community's technical assessment is that PM is an attack on
   the privacy of Internet users and organizations.  PM is distinguished
   by being indiscriminate and very large-scale, rather than by
   introducing new types of technical compromise.  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 require a multi-faceted 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 is not relevant for this document, but 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 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 are
   indistinguishable from other attacks.

Farrell & Tschofenig      Expires July 24, 2014                 [Page 2]
Internet-Draft      Pervasive Monitoring is an Attack       January 2014

2.  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 generally do not consider PM, the
   confidentiality of protocol meta-data, countering traffic analysis
   nor data minimisation.  [RFC6973] 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

   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 re-used, may significantly impact the vulnerability of
   a protocol to PM.  Those developing IETF specifications therefore
   need to consider mitigating PM when making these 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 can be beneficial
   and not part of any attack, e.g. network management functions monitor
   packets or flows and anti-spam mechanisms need to see mail message

Farrell & Tschofenig      Expires July 24, 2014                 [Page 3]
Internet-Draft      Pervasive Monitoring is an Attack       January 2014

   content.  Some monitoring can 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.  There is though a 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 meta-data 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.

3.  Process Note

   In the past, architectural statements of this sort, e.g., [RFC1984]
   and [RFC2804] have been published as joint products of the Internet
   Engineering Steering Group (IESG) and the Internet Architecture Board
   (IAB).  However, since those documents were published, the IETF and
   IAB have separated their publication "streams" as described in
   [RFC4844] and [RFC5741].  This document was initiated by both the
   IESG and IAB, but is published as an IETF-stream consensus document,
   in order to ensure that it properly reflects the consensus of the
   IETF community as a whole.

   [[Note (to be removed before publication): This draft is written as
   if IETF consensus has been established for the text.]]

4.  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.

Farrell & Tschofenig      Expires July 24, 2014                 [Page 4]
Internet-Draft      Pervasive Monitoring is an Attack       January 2014

5.  IANA Considerations

   There are none.  We hope the RFC editor deletes this section before

6.  Acknowledgements

   We would like to thank the participants of the IETF 88 technical
   plenary for their feedback.  Thanks in particular to the following
   for useful suggestions or comments: Jari Arkko, Fred Baker, Marc
   Blanchet, Tim Bray, Scott Brim, Randy Bush, Brian Carpenter, Benoit
   Claise, Alissa Cooper, Dave Crocker, Spencer Dawkins, Avri Doria,
   Wesley Eddy, Adrian Farrel, Joseph Lorenzo Hall, Ted Hardie, Sam
   Hartmann, Paul Hoffman, Bjoern Hoehrmann, Phillip Hallam-Baker, Russ
   Housley, Joel Jaeggli, Stephen Kent, Eliot Lear, Barry Leiba, Ted
   Lemon, Subramanian Moonesamy, Erik Nordmark, Pete Resnick, Peter
   Saint-Andre, Andrew Sullivan, Sean Turner, Nicholas Weaver, Stefan
   Winter, and Lloyd Wood.  Additionally, we would like to thank all
   those who contributed suggestions on how to improve Internet security
   and privacy or who commented on this on various IETF mailing lists,
   such as the and the lists.

7.  Informative References

              IETF, "IETF 88 Plenary Meeting Materials",  URL:
              Nov 2013.

   [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.

Farrell & Tschofenig      Expires July 24, 2014                 [Page 5]
Internet-Draft      Pervasive Monitoring is an Attack       January 2014

   [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

   Stephen Farrell
   Trinity College Dublin
   Dublin,   2

   Phone: +353-1-896-2354

   Hannes Tschofenig


Farrell & Tschofenig      Expires July 24, 2014                 [Page 6]