doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc7624.txt b/doc/rfc/rfc7624.txt
new file mode 100644
index 0000000..87fbff3
--- /dev/null
+++ b/doc/rfc/rfc7624.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                              R. Barnes
+Request for Comments: 7624                                   B. Schneier
+Category: Informational                                      C. Jennings
+ISSN: 2070-1721                                                T. Hardie
+                                                             B. Trammell
+                                                              C. Huitema
+                                                             D. Borkmann
+                                                             August 2015
+
+
+         Confidentiality in the Face of Pervasive Surveillance:
+                  A Threat Model and Problem Statement
+
+Abstract
+
+   Since the initial revelations of pervasive surveillance in 2013,
+   several classes of attacks on Internet communications have been
+   discovered.  In this document, we develop a threat model that
+   describes these attacks on Internet confidentiality.  We assume an
+   attacker that is interested in undetected, indiscriminate
+   eavesdropping.  The threat model is based on published, verified
+   attacks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  It represents the consensus of the
+   Internet Architecture Board (IAB).  Documents approved for
+   publication by the IAB are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7624.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.                Informational                     [Page 1]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+Copyright Notice
+
+   Copyright (c) 2015 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) 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.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.                Informational                     [Page 2]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+1.  Introduction
+
+   Starting in June 2013, documents released to the press by Edward
+   Snowden have revealed several operations undertaken by intelligence
+   agencies to exploit Internet communications for intelligence
+   purposes.  These attacks were largely based on protocol
+   vulnerabilities that were already known to exist.  The attacks were
+   nonetheless striking in their pervasive nature, in terms of both the
+   volume of Internet traffic targeted and the diversity of attack
+   techniques employed.
+
+   To ensure that the Internet can be trusted by users, it is necessary
+   for the Internet technical community to address the vulnerabilities
+   exploited in these attacks [RFC7258].  The goal of this document is
+   to describe more precisely the threats posed by these pervasive
+   attacks, and based on those threats, lay out the problems that need
+   to be solved in order to secure the Internet in the face of those
+   threats.
+
+   The remainder of this document is structured as follows.  In
+   Section 3, we describe an idealized passive pervasive attacker, one
+   which could completely undetectably compromise communications at
+   Internet scale.  In Section 4, we provide a brief summary of some
+   attacks that have been disclosed, and use these to expand the assumed
+   capabilities of our idealized attacker.  Note that we do not attempt
+   to describe all possible attacks, but focus on those that result in
+   undetected eavesdropping.  Section 5 describes a threat model based
+   on these attacks, focusing on classes of attack that have not been a
+   focus of Internet engineering to date.
+
+2.  Terminology
+
+   This document makes extensive use of standard security and privacy
+   terminology; see [RFC4949] and [RFC6973].  Terms used from [RFC6973]
+   include Eavesdropper, Observer, Initiator, Intermediary, Recipient,
+   Attack (in a privacy context), Correlation, Fingerprint, Traffic
+   Analysis, and Identifiability (and related terms).  In addition, we
+   use a few terms that are specific to the attacks discussed in this
+   document.  Note especially that "passive" and "active" below do not
+   refer to the effort used to mount the attack; a "passive attack" is
+   any attack that accesses a flow but does not modify it, while an
+   "active attack" is any attack that modifies a flow.  Some passive
+   attacks involve active interception and modifications of devices,
+   rather than simple access to the medium.  The introduced terms are:
+
+
+
+
+
+
+
+Barnes, et al.                Informational                     [Page 3]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   Pervasive Attack:  An attack on Internet communications that makes
+      use of access at a large number of points in the network, or
+      otherwise provides the attacker with access to a large amount of
+      Internet traffic; see [RFC7258].
+
+   Passive Pervasive Attack:  An eavesdropping attack undertaken by a
+      pervasive attacker, in which the packets in a traffic stream
+      between two endpoints are intercepted, but in which the attacker
+      does not modify the packets in the traffic stream between two
+      endpoints, modify the treatment of packets in the traffic stream
+      (e.g., delay, routing), or add or remove packets in the traffic
+      stream.  Passive pervasive attacks are undetectable from the
+      endpoints.  Equivalent to passive wiretapping as defined in
+      [RFC4949]; we use an alternate term here since the methods
+      employed are wider than those implied by the word "wiretapping",
+      including the active compromise of intermediate systems.
+
+   Active Pervasive Attack:  An attack that is undertaken by a pervasive
+      attacker and, in addition to the elements of a passive pervasive
+      attack, also includes modification, addition, or removal of
+      packets in a traffic stream, or modification of treatment of
+      packets in the traffic stream.  Active pervasive attacks provide
+      more capabilities to the attacker at the risk of possible
+      detection at the endpoints.  Equivalent to active wiretapping as
+      defined in [RFC4949].
+
+   Observation:  Information collected directly from communications by
+      an eavesdropper or observer.  For example, the knowledge 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 analysis of information
+      collected directly from communications by an eavesdropper or
+      observer.  For example, the knowledge 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 is a legitimate participant in a
+      communication, and provides information about that communication
+      to an attacker.  Collaborators may either deliberately or
+      unwittingly cooperate with the attacker, in the latter case
+      because the attacker has subverted the collaborator through
+      technical, social, or other means.
+
+
+
+
+
+Barnes, et al.                Informational                     [Page 4]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   Key Exfiltration:  The transmission of cryptographic keying material
+      for an encrypted communication from a collaborator, deliberately
+      or unwittingly, to an attacker.
+
+   Content Exfiltration:  The transmission of the content of a
+      communication from a collaborator, deliberately or unwittingly, to
+      an attacker
+
+3.  An Idealized Passive Pervasive Attacker
+
+   In considering the threat posed by pervasive surveillance, we begin
+   by defining an idealized passive pervasive attacker.  While this
+   attacker is less capable than those that we now know to have
+   compromised the Internet from press reports, as elaborated in
+   Section 4, it does set a lower bound on the capabilities of an
+   attacker interested in indiscriminate passive surveillance while
+   interested in remaining undetectable.  We note that, prior to the
+   Snowden revelations in 2013, the assumptions of attacker capability
+   presented here would be considered on the border of paranoia outside
+   the network security community.
+
+   Our idealized attacker is an indiscriminate eavesdropper that is on
+   an Internet-attached computer network and:
+
+   o  can observe every packet of all communications at any hop in any
+      network path between an initiator and a recipient;
+
+   o  can observe data at rest in any intermediate system between the
+      endpoints controlled by the initiator and recipient; and
+
+   o  can share information with other such attackers; but
+
+   o  takes no other action with respect to these communications (i.e.,
+      blocking, modification, injection, etc.).
+
+   The techniques available to our ideal attacker are direct observation
+   and inference.  Direct observation involves taking information
+   directly from eavesdropped communications, such as URLs identifying
+   content or email addresses identifying individuals from application-
+   layer headers.  Inference, on the other hand, involves analyzing
+   observed information to derive new information, such as searching for
+   application or behavioral fingerprints in observed traffic to derive
+   information about the observed individual.  The use of encryption is
+   generally sufficient to provide confidentiality by preventing direct
+   observation of content, assuming of course, uncompromised encryption
+   implementations and cryptographic keying material.  However,
+   encryption provides less complete protection against inference,
+
+
+
+
+Barnes, et al.                Informational                     [Page 5]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   especially inferences based only on plaintext portions of
+   communications, such as IP and TCP headers for TLS-protected traffic
+   [RFC5246].
+
+3.1.  Information Subject to Direct Observation
+
+   Protocols that do not encrypt their payload make the entire content
+   of the communication available to the idealized attacker along their
+   path.  Following the advice in [RFC3365], most such protocols have a
+   secure variant that encrypts the payload for confidentiality, and
+   these secure variants are seeing ever-wider deployment.  A noteworthy
+   exception is DNS [RFC1035], as DNSSEC [RFC4033] does not have
+   confidentiality as a requirement.
+
+   This implies that, in the absence of changes to the protocol as
+   presently under development in the IETF's DNS Private Exchange
+   (DPRIVE) working group [DPRIVE], all DNS queries and answers
+   generated by the activities of any protocol are available to the
+   attacker.
+
+   When store-and-forward protocols are used (e.g., SMTP [RFC5321]),
+   intermediaries leave this data subject to observation by an attacker
+   that has compromised these intermediaries, unless the data is
+   encrypted end-to-end by the application-layer protocol or the
+   implementation uses an encrypted store for this data.
+
+3.2.  Information Useful for Inference
+
+   Inference is information extracted from later analysis of an observed
+   or eavesdropped communication, and/or correlation of observed or
+   eavesdropped information with information available from other
+   sources.  Indeed, most useful inference performed by the attacker
+   falls under the rubric of correlation.  The simplest example of this
+   is the observation of DNS queries and answers from and to a source
+   and correlating those with IP addresses with which that source
+   communicates.  This can give access to information otherwise not
+   available from encrypted application payloads (e.g., the "Host:"
+   HTTP/1.1 request header when HTTP is used with TLS).
+
+   Protocols that encrypt their payload using an application- or
+   transport-layer encryption scheme (e.g., TLS) still expose all the
+   information in their network- and transport-layer headers to the
+   attacker, including source and destination addresses and ports.
+   IPsec Encapsulating Security Payload (ESP) [RFC4303] further encrypts
+   the transport-layer headers but still leaves IP address information
+   unencrypted; in tunnel mode, these addresses correspond to the tunnel
+   endpoints.  Features of the security protocols themselves, e.g., the
+   TLS session identifier, may leak information that can be used for
+
+
+
+Barnes, et al.                Informational                     [Page 6]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   correlation and inference.  While this information is much less
+   semantically rich than the application payload, it can still be
+   useful for inferring an individual's activities.
+
+   Inference can also leverage information obtained from sources other
+   than direct traffic observation.  Geolocation databases, for example,
+   have been developed that map IP addresses to a location, in order to
+   provide location-aware services such as targeted advertising.  This
+   location information is often of sufficient resolution that it can be
+   used to draw further inferences toward identifying or profiling an
+   individual.
+
+   Social media provide another source of more or less publicly
+   accessible information.  This information can be extremely
+   semantically rich, including information about an individual's
+   location, associations with other individuals and groups, and
+   activities.  Further, this information is generally contributed and
+   curated voluntarily by the individuals themselves: it represents
+   information that the individuals are not necessarily interested in
+   protecting for privacy reasons.  However, correlation of this social
+   networking data with information available from direct observation of
+   network traffic allows the creation of a much richer picture of an
+   individual's activities than either alone.
+
+   We note with some alarm that there is little that can be done at
+   protocol design time to limit such correlation by the attacker, and
+   that the existence of such data sources in many cases greatly
+   complicates the problem of protecting privacy by hardening protocols
+   alone.
+
+3.3.  An Illustration of an Ideal Passive Pervasive Attack
+
+   To illustrate how capable the idealized attacker is even given its
+   limitations, we explore the non-anonymity of encrypted IP traffic in
+   this section.  Here, we examine in detail some inference techniques
+   for associating a set of addresses with an individual, in order to
+   illustrate the difficulty of defending communications against our
+   idealized attacker.  Here, the basic problem is that information
+   radiated even from protocols that have no obvious connection with
+   personal data can be correlated with other information that can paint
+   a very rich behavioral picture; it only takes one unprotected link in
+   the chain to associate with 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.  Of course, a single
+   link or a single router only provides access to a fraction of the
+
+
+
+Barnes, et al.                Informational                     [Page 7]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   global Internet traffic.  However, monitoring a number of high-
+   capacity links or a set of routers placed at strategic locations
+   provides access to a good sampling of Internet traffic.
+
+   Tools like the IP Flow Information Export (IPFIX) Protocol [RFC7011]
+   allow administrators to acquire statistics about sequences of packets
+   with some common properties that pass through a network device.  The
+   most common set of properties used in flow measurement is the "five-
+   tuple" of source and destination addresses, protocol type, and source
+   and destination ports.  These statistics are commonly used for
+   network engineering but could certainly be used for other purposes.
+
+   Let's assume for a moment that IP addresses can be correlated to
+   specific services or specific users.  Analysis of the sequences of
+   packets will quickly reveal which users use what services, and also
+   which users engage in peer-to-peer connections with other users.
+   Analysis of traffic variations over time can be used to detect
+   increased activity by particular users or, in the case of peer-to-
+   peer connections, increased activity within groups of users.
+
+3.3.2.  Correlation of IP Addresses to User Identities
+
+   The correlation of IP addresses with specific users can be done in
+   various ways.  For example, tools like reverse DNS lookup can be used
+   to retrieve the DNS names of servers.  Since the addresses of servers
+   tend to be quite stable and since servers are relatively less
+   numerous than users, an attacker could easily maintain its own copy
+   of the DNS for well-known or popular servers to accelerate such
+   lookups.
+
+   On the other hand, the reverse lookup of IP addresses of users is
+   generally less informative.  For example, a lookup of the address
+   currently used by one author's home network returns a name of the
+   form "c-192-000-002-033.hsd1.wa.comcast.net".  This particular type
+   of reverse DNS lookup generally reveals only coarse-grained location
+   or provider information, equivalent to that available from
+   geolocation databases.
+
+   In many jurisdictions, Internet Service Providers (ISPs) are required
+   to provide identification on a case-by-case basis of the "owner" of a
+   specific IP address for law enforcement purposes.  This is a
+   reasonably expedient process for targeted investigations, but
+   pervasive surveillance requires something more efficient.  This
+   provides an incentive for the attacker to secure the cooperation of
+   the ISP in order to automate this correlation.
+
+
+
+
+
+
+Barnes, et al.                Informational                     [Page 8]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+3.3.3.  Monitoring Messaging Clients for IP Address Correlation
+
+   Even if the ISP does not cooperate, user identity can often be
+   obtained via inference.  POP3 [RFC1939] and IMAP [RFC3501] are used
+   to retrieve mail from mail servers, while a variant of SMTP is used
+   to submit messages through mail servers.  IMAP connections originate
+   from the client, and typically start with an authentication exchange
+   in which the client proves its identity by answering a password
+   challenge.  The same holds for the SIP protocol [RFC3261] and many
+   instant messaging services operating over the Internet using
+   proprietary protocols.
+
+   The username is directly observable if any of these protocols operate
+   in cleartext; the username can then be directly associated with 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.  The purpose of these headers
+   is to enable audit of mail transmission, and perhaps to distinguish
+   between regular mail and spam.  Here is 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 attached to the message by the
+   first SMTP relay; for privacy reasons, the field values have been
+   anonymized.  We learn here 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.  The information
+   remained in the message and is accessible by all recipients of the
+   perpass mailing list, or indeed by any attacker that sees at least
+   one copy of the message.
+
+   An attacker that can observe sufficient email traffic can regularly
+   update 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.
+
+
+
+
+
+
+
+Barnes, et al.                Informational                     [Page 9]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+3.3.5.  Tracking Address Usage with Web Cookies
+
+   Many web sites only encrypt a small fraction of their transactions.
+   A popular pattern is to use HTTPS for the login information, and then
+   use a "cookie" to associate following cleartext transactions with the
+   user's identity.  Cookies are also used by various advertisement
+   services to quickly identify the users and serve them with
+   "personalized" advertisements.  Such cookies are particularly useful
+   if the advertisement services want to keep tracking the user across
+   multiple sessions that may use different IP addresses.
+
+   As cookies are sent in cleartext, an attacker can build a database
+   that associates cookies to IP addresses for non-HTTPS traffic.  If
+   the IP address is already identified, the cookie can be linked to the
+   user identify.  After that, if the same cookie appears on a new IP
+   address, the new IP address can be immediately associated with the
+   predetermined identity.
+
+3.3.6.  Graph-Based Approaches to Address Correlation
+
+   An attacker can track traffic from an IP address not yet associated
+   with an individual to various public services (e.g., web sites, mail
+   servers, game servers) and exploit patterns in the observed traffic
+   to correlate this address with other addresses that show similar
+   patterns.  For example, any two addresses that show connections to
+   the same IMAP or webmail services, the same set of favorite web
+   sites, and game servers at similar times of day may be associated
+   with the same individual.  Correlated addresses can then be tied to
+   an individual through one of the techniques above, walking the
+   "network graph" to expand the set of attributable traffic.
+
+3.3.7.  Tracking of Link-Layer Identifiers
+
+   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
+
+
+
+Barnes, et al.                Informational                    [Page 10]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   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]:
+
+   o  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.
+
+   o  GCHQ's Tempora system appears to have access to around 1,500 major
+      cables passing through the UK.
+
+
+
+Barnes, et al.                Informational                    [Page 11]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   o  NSA's MUSCULAR program has tapped cables between data centers
+      belonging to major service providers.
+
+   o  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:
+
+   o  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.
+
+   o  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.
+
+   o  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].
+
+   o  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
+
+
+
+Barnes, et al.                Informational                    [Page 12]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   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.
+
+
+
+
+
+
+Barnes, et al.                Informational                    [Page 13]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   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
+
+    +--------------------------+-------------------------------------+
+    | 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                 |
+    +--------------------------+-------------------------------------+
+
+   Security analyses of Internet protocols commonly consider two classes
+   of attacker: passive pervasive attackers, who can simply listen in on
+   communications as they transit the network, and active pervasive
+   attackers, who can modify or delete packets in addition to simply
+   collecting them.
+
+   In the context of pervasive passive surveillance, these attacks take
+   on an even greater significance.  In the past, these attackers were
+   often assumed to operate near the edge of the network, where attacks
+   can be simpler.  For example, in some LANs, it is simple for any node
+   to engage in passive listening to other nodes' traffic or inject
+   packets to accomplish active pervasive attacks.  However, as we now
+   know, both passive and active pervasive attacks are undertaken by
+   pervasive attackers closer to the core of the network, greatly
+   expanding the scope and capability of the attacker.
+
+   Eavesdropping and observation at a larger scale make passive
+   inference attacks easier to carry out: a passive pervasive attacker
+   with access to a large portion of the Internet can analyze collected
+   traffic to create a much more detailed view of individual behavior
+   than an attacker that collects at a single point.  Even the usual
+   claim that encryption defeats passive pervasive attackers is
+   weakened, since a pervasive flow access attacker can infer
+   relationships from correlations over large numbers of sessions, e.g.,
+
+
+
+Barnes, et al.                Informational                    [Page 14]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   pairing encrypted sessions with unencrypted sessions from the same
+   host, or performing traffic fingerprinting between known and unknown
+   encrypted sessions.  Reports on the NSA XKEYSCORE system would
+   indicate it is an example of such an attacker.
+
+   An active pervasive attacker likewise has capabilities beyond those
+   of a localized active attacker.  Flow modification attacks are often
+   limited by network topology, for example, by a requirement that the
+   attacker be able to see a targeted session as well as inject packets
+   into it.  A pervasive flow modification attacker with access at
+   multiple points within the core of the Internet is able to overcome
+   these topological limitations and perform attacks over a much broader
+   scope.  Being positioned in the core of the network rather than the
+   edge can also enable an active pervasive attacker to reroute targeted
+   traffic, amplifying the ability to perform both eavesdropping and
+   traffic injection.  Active pervasive attackers can also benefit from
+   passive pervasive collection to identify vulnerable hosts.
+
+   While not directly related to pervasiveness, attackers that are in a
+   position to mount an active pervasive attack are also often in a
+   position to subvert authentication, a traditional protection against
+   such attacks.  Authentication in the Internet is often achieved via
+   trusted third-party authorities such as the Certificate Authorities
+   (CAs) that provide web sites with authentication credentials.  An
+   attacker with sufficient resources may also be able to induce an
+   authority to grant credentials for an identity of the attacker's
+   choosing.  If the parties to a communication will trust multiple
+   authorities to certify a specific identity, this attack may be
+   mounted by suborning any one of the authorities (the proverbial
+   "weakest link").  Subversion of authorities in this way can allow an
+   active attack to succeed in spite of an authentication check.
+
+   Beyond these three classes (observation, inference, and active),
+   reports on the BULLRUN effort to defeat encryption and the PRISM
+   effort to obtain data from service providers suggest three more
+   classes of attack:
+
+   o  Static key exfiltration
+
+   o  Dynamic key exfiltration
+
+   o  Content exfiltration
+
+   These attacks all rely on a collaborator providing the attacker with
+   some information, either keys or data.  These attacks have not
+   traditionally been considered in scope for the Security
+   Considerations sections of IETF protocols, as they occur outside the
+   protocol.
+
+
+
+Barnes, et al.                Informational                    [Page 15]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   The term "key exfiltration" refers to the transfer of keying material
+   for an encrypted communication from the collaborator to the attacker.
+   By "static", we mean that the transfer of keys happens once or rarely
+   and that the transferred key is typically long-lived.  For example,
+   this case would cover a web site operator that provides the private
+   key corresponding to its HTTPS certificate to an intelligence agency.
+
+   "Dynamic" key exfiltration, by contrast, refers to attacks in which
+   the collaborator delivers keying material to the attacker frequently,
+   e.g., on a per-session basis.  This does not necessarily imply
+   frequent communications with the attacker; the transfer of keying
+   material may be virtual.  For example, if an endpoint were modified
+   in such a way that the attacker could predict the state of its
+   pseudorandom number generator, then the attacker would be able to
+   derive per-session keys even without per-session communications.
+
+   Finally, content exfiltration is the attack in which the collaborator
+   simply provides the attacker with the desired data or metadata.
+   Unlike the key exfiltration cases, this attack does not require the
+   attacker to capture the desired data as it flows through the network.
+   The exfiltration is of data at rest, rather than data in transit.
+   This increases the scope of data that the attacker can obtain, since
+   the attacker can access historical data -- the attacker does not have
+   to be listening at the time the communication happens.
+
+   Exfiltration attacks can be accomplished via attacks against one of
+   the parties to a communication, i.e., by the attacker stealing the
+   keys or content rather than the party providing them willingly.  In
+   these cases, the party may not be aware, at least at a human level,
+   that they are collaborating.  Rather, the subverted technical assets
+   are "collaborating" with the attacker (by providing keys/content)
+   without their owner's knowledge or consent.
+
+   Any party that has access to encryption keys or unencrypted data can
+   be a collaborator.  While collaborators are typically the endpoints
+   of a communication (with encryption securing the links),
+   intermediaries in an unencrypted communication can also facilitate
+   content exfiltration attacks as collaborators by providing the
+   attacker access to those communications.  For example, documents
+   describing the NSA PRISM program claim that NSA is able to access
+   user data directly from servers, where it is stored unencrypted.  In
+   these cases, the operator of the server would be a collaborator, if
+   an unwitting one.  By contrast, in the NSA MUSCULAR program, a set of
+   collaborators enabled attackers to access the cables connecting data
+   centers used by service providers such as Google and Yahoo.  Because
+   communications among these data centers were not encrypted, the
+   collaboration by an intermediate entity allowed the NSA to collect
+   unencrypted user data.
+
+
+
+Barnes, et al.                Informational                    [Page 16]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+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         |
+     +--------------------------+-----------------------------------+
+
+   Each of the attack types discussed in the previous section entails
+   certain costs and risks.  These costs differ by attack and can be
+   helpful in guiding response to pervasive attack.
+
+   Depending on the attack, the attacker may be exposed to several types
+   of risk, ranging from simply losing access to arrest or prosecution.
+   In order for any of these negative consequences to occur, however,
+   the attacker must first be discovered and identified.  So, the
+   primary risk we focus on here is the risk of discovery and
+   attribution.
+
+   A passive pervasive attack is the simplest to mount in some ways.
+   The base requirement is that the attacker obtain physical access to a
+   communications medium and extract communications from it.  For
+   example, the attacker might tap a fiber-optic cable, acquire a mirror
+   port on a switch, or listen to a wireless signal.  The need for these
+   taps to have physical access or proximity to a link exposes the
+   attacker to the risk that the taps will be discovered.  For example,
+   a fiber tap or mirror port might be discovered by network operators
+   noticing increased attenuation in the fiber or a change in switch
+   configuration.  Of course, passive pervasive attacks may be
+   accomplished with the cooperation of the network operator, in which
+   case there is a risk that the attacker's interactions with the
+   network operator will be exposed.
+
+   In many ways, the costs and risks for an active pervasive attack are
+   similar to those for a passive pervasive attack, with a few
+   additions.  An active attacker requires more robust network access
+   than a passive attacker, since, for example, they will often need to
+   transmit data as well as receive it.  In the wireless example above,
+
+
+
+Barnes, et al.                Informational                    [Page 17]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   the attacker would need to act as a transmitter as well as a
+   receiver, greatly increasing the probability the attacker will be
+   discovered (e.g., using direction-finding technology).  Active
+   attacks are also much more observable at higher layers of the
+   network.  For example, an active attacker that attempts to use a mis-
+   issued certificate could be detected via Certificate Transparency
+   [RFC6962].
+
+   In terms of raw implementation complexity, passive pervasive attacks
+   require only enough processing to extract information from the
+   network and store it.  Active pervasive attacks, by contrast, often
+   depend on winning race conditions to inject packets into active
+   connections.  So, active pervasive attacks in the core of the network
+   require processing hardware that can operate at line speed (roughly
+   100 Gbps to 1 Tbps in the core) to identify opportunities for attack
+   and insert attack traffic in high-volume traffic.  Key exfiltration
+   attacks rely on passive pervasive attack for access to encrypted
+   data, with the collaborator providing keys to decrypt the data.  So,
+   the attacker undertakes the cost and risk of a passive pervasive
+   attack, as well as additional risk of discovery via the interactions
+   that the attacker has with the collaborator.
+
+   Some active attacks are more expensive than others.  For example,
+   active man-in-the-middle (MITM) attacks require access to one or more
+   points on a communication's network path that allow visibility of the
+   entire session and the ability to modify or drop legitimate packets
+   in favor of the attacker's packets.  A similar but weaker form of
+   attack, called an active man-on-the-side (MOTS), requires access to
+   only part of the session.  In an active MOTS attack, the attacker
+   need only be able to inject or modify traffic on the network element
+   the attacker has access to.  While this may not allow for full
+   control of a communication session (as in an MITM attack), the
+   attacker can perform a number of powerful attacks, including but not
+   limited to: injecting packets that could terminate the session (e.g.,
+   TCP RST packets), sending a fake DNS reply to redirect ensuing TCP
+   connections to an address of the attacker's choice (i.e., winning a
+   "DNS response race"), and mounting an HTTP redirect attack by
+   observing a TCP/HTTP connection to a target address and injecting a
+   TCP data packet containing an HTTP redirect.  For example, the system
+   dubbed by researchers as China's "Great Cannon" [great-cannon] can
+   operate in full MITM mode to accomplish very complex attacks that can
+   modify content in transit, while the well-known Great Firewall of
+   China is a MOTS system that focuses on blocking access to certain
+   kinds of traffic and destinations via TCP RST packet injection.
+
+   In this sense, static exfiltration has a lower risk profile than
+   dynamic.  In the static case, the attacker need only interact with
+   the collaborator a small number of times, possibly only once -- say,
+
+
+
+Barnes, et al.                Informational                    [Page 18]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   to exchange a private key.  In the dynamic case, the attacker must
+   have continuing interactions with the collaborator.  As noted above,
+   these interactions may be real, such as in-person meetings, or
+   virtual, such as software modifications that render keys available to
+   the attacker.  Both of these types of interactions introduce a risk
+   that they will be discovered, e.g., by employees of the collaborator
+   organization noticing suspicious meetings or suspicious code changes.
+
+   Content exfiltration has a similar risk profile to dynamic key
+   exfiltration.  In a content exfiltration attack, the attacker saves
+   the cost and risk of conducting a passive pervasive attack.  The risk
+   of discovery through interactions with the collaborator, however, is
+   still present, and may be higher.  The content of a communication is
+   obviously larger than the key used to encrypt it, often by several
+   orders of magnitude.  So, in the content exfiltration case, the
+   interactions between the collaborator and the attacker need to be
+   much higher bandwidth than in the key exfiltration cases, with a
+   corresponding increase in the risk that this high-bandwidth channel
+   will be discovered.
+
+   It should also be noted that in these latter three exfiltration
+   cases, the collaborator also undertakes a risk that his collaboration
+   with the attacker will be discovered.  Thus, the attacker may have to
+   incur additional cost in order to convince the collaborator to
+   participate in the attack.  Likewise, the scope of these attacks is
+   limited to cases where the attacker can convince a collaborator to
+   participate.  If the attacker is a national government, for example,
+   it may be able to compel participation within its borders, but have a
+   much more difficult time recruiting foreign collaborators.
+
+   As noted above, the collaborator in an exfiltration attack can be
+   unwitting; the attacker can steal keys or data to enable the attack.
+   In some ways, the risks of this approach are similar to the case of
+   an active collaborator.  In the static case, the attacker needs to
+   steal information from the collaborator once; in the dynamic case,
+   the attacker needs continued presence inside the collaborators'
+   systems.  The main difference is that the risk in this case is of
+   automated discovery (e.g., by intrusion detection systems) rather
+   than 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.
+
+
+
+
+
+
+
+Barnes, et al.                Informational                    [Page 19]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+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
+
+   [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.
+
+
+
+
+Barnes, et al.                Informational                    [Page 20]
+
+RFC 7624              Confidentiality Threat Model           August 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>.
+
+
+
+
+
+Barnes, et al.                Informational                    [Page 21]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   [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>.
+
+
+
+
+
+
+
+Barnes, et al.                Informational                    [Page 22]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+   [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
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.                Informational                    [Page 23]
+
+RFC 7624              Confidentiality Threat Model           August 2015
+
+
+Acknowledgements
+
+   Thanks to Dave Thaler for the list of attacks and taxonomy; to
+   Security Area Directors Stephen Farrell, Sean Turner, and Kathleen
+   Moriarty for starting and managing the IETF's discussion on pervasive
+   attack; and to 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 their input.
+
+Authors' Addresses
+
+   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
+
+
+
+
+
+
+Barnes, et al.                Informational                    [Page 24]
+