perpass non-WG B. Trammell
Internet-Draft ETH Zurich
Intended status: Informational D. Borkmann
Expires: May 17, 2014 Red Hat
C. Huitema
Microsoft Corporation
November 13, 2013
A Threat Model for Pervasive Passive Surveillance
draft-trammell-perpass-ppa-01.txt
Abstract
This document elaborates a threat model for pervasive surveillance.
We assume an adversary with an interest in indiscriminate
eavesdropping that can passively observe network traffic at every
layer at every point in the network between the endpoints. It is
intended to demonstrate to protocol designers and implementors the
observability and inferability of information and metainformation
transported over their respective protocols, to assist in the
evaluation of the performance of these protocols and the
effectiveness of their protection mechanisms under pervasive passive
surveillance.
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 http://datatracker.ietf.org/drafts/current/.
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 May 17, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Trammell, et al. Expires May 17, 2014 [Page 1]
Internet-Draft Pervasive Passive Adversary November 2013
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. 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Pervasive Passive Adversary . . . . . . . . . . . . . . . 4
4. Threat analysis . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Information subject to direct observation . . . . . . . . 6
4.2. Information useful for inference . . . . . . . . . . . . 6
4.3. On the Non-Anonymity of IP Addresses . . . . . . . . . . 7
4.3.1. Analysis of IP headers . . . . . . . . . . . . . . . 7
4.3.2. Correlation of IP addresses to user identities . . . 8
4.3.3. Monitoring messaging clients for IP address
correlation . . . . . . . . . . . . . . . . . . . . . 9
4.3.4. Retrieving IP addresses from mail headers . . . . . . 9
4.3.5. Tracking address use with web cookies . . . . . . . . 10
4.3.6. Tracking address use with network graphs . . . . . . 10
5. Evaluating protocols for PPA resistance . . . . . . . . . . . 11
6. General protocol design recommendations for PPA resistance . 11
6.1. Encrypt everything you can . . . . . . . . . . . . . . . 11
6.2. Design and implement for simplicity and auditability . . 12
6.3. Allow for fingerprinting resistance in protocol designs . 12
6.4. Do not rely on static IP addresses . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Surveillance is defined in [RFC6973], Section 5.1.1, as "the
observation or monitoring of an individual's communications or
activities". Pervasive passive surveillance in the Internet is the
practice of surveillance at widespread observation points, without
any particular target in mind at time of surveillance, and without
any modification or injection of of network traffic. Pervasive
Trammell, et al. Expires May 17, 2014 [Page 2]
Internet-Draft Pervasive Passive Adversary November 2013
passive surveillance allows subsequent analysis and inference to be
applied to the collected data to achieve surveillance aims on a
target to be identified later, or to analyze general communications
patterns and/or behaviors without a specified target individual or
group.
This differentiates privacy in the face of pervasive surveillance
from privacy as addressed in the literature, in that threats to
privacy are generally (as in [RFC6973]) taken to have as a specific
goal revealing the identity and/or associations of a specified
individual; defeating pervasive surveillance of a large population is
therefore more difficult than protecting the privacy of a single
individual within a larger population.
In this document, we take as given that communications systems should
aim to provide privacy guarantees to their users, and that
susceptibility to pervasive surveillance should be avoided to the
extent possible as a design goal in protocol design. From these
assumptions we take the very act of pervasive surveillance to be
adversarial by definition.
This document outlines a threat model for an entity performing
pervasive passive surveillance, termed the Pervasive Passive
Adversary (PPA), and explores how to apply this model to the
evaluation of protocols. As the primary threat posed by pervasive
surveillance is a threat to the privacy of the parties to a given
communication, this document is heavily based on [RFC6973].
2. Terminology
[EDITOR'S NOTE: Check to see whether we actually use these...]
The terms Anonymity, Anonymity Set, Anonymous, Attacker,
Eavesdropper, Fingerprint, Fingerprinting, Identifier, Identity,
Individual, Initiator, Intermediary, Observer, Pseudonym,
Pseudonymity, Pseudonymous, Recipient, and Traffic Analysis are used
in this document as defined by Section 3, Terminology, of [RFC6973].
In addition, this document defines the following terms:
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 extracted from analysis of information
collected directly from communications by an eavesdropper or
observer. For example, the knowledge that a given web page was
Trammell, et al. Expires May 17, 2014 [Page 3]
Internet-Draft Pervasive Passive Adversary November 2013
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.
3. The Pervasive Passive Adversary
The pervasive passive adversary (PPA) is an indiscriminate
eavesdropper on a computer network that can:
o observe every packet of all communications at any or every hop in
any network path between an initiator and a recipient; and can
o observe data at rest in intermediate systems between the endpoints
controlled by the initiator and recipient; but
o takes no other action with respect to these communications (i.e.,
blocking, modification, injection, etc.).
We note that a threat model that limits the adversary to being
completely passive may under-represent the threat to communications
privacy posed especially by well-resourced adversaries, but submit
that it represents the maximum capability of a single entity
interested in remaining undetectable.
The techniques available to the PPA are direct observation and
inference. Direct observation involves taking information directly
from eavesdropped communications - e.g., URLs identifying content or
email addresses identifying individuals from application-layer
headers. Inference, on the other hand involves analyzing
eavesdropped information to derive new information from it; e.g.,
searching for application or behavioral fingerprints in observed
traffic to derive information about the observed individual from
them, in absence of directly-observed sources of the same
information.
We would like to assume that the PPA does not have the ability to
observe communications on trusted systems at either the initiator or
a recipient of a communication, as there would seem to be little that
a protocol designer could do in the case of compromised endpoints.
However, given the state of vulnerability of many endpoints to
various security exploits, we would encourage protocol designers to
consider the protections their protocols afford to the privacy of
their users even in the face of partially compromised endpoints.
The PPA may additionally have have privileged information allowing
the reversal of strong encryption -- e.g. compromised key material or
knowledge of weaknesses in the design or implementation of
Trammell, et al. Expires May 17, 2014 [Page 4]
Internet-Draft Pervasive Passive Adversary November 2013
cryptographic algorithms or random number generators at the
initiator, recipient, and/or intermediaries. However, we consider
the evaluation and improvement of cryptographic protections, while
important to improving the security of the Internet in the face of
pervasive surveillance, to be out of scope for this work: here, we
will assume that a given cryptographic protection for a protocol
works as advertised.
4. Threat analysis
On initial examination, the PPA would appear to be trivially
impossible to defend against. If the PPA has access to every byte of
every packet of a communication, then full application payload and
content is available for applications which do not provide
encryption.
Guidance to protocol designers [RFC3365] to provide cryptographic
protection of confidentiality in their protocols improves this
situation a great deal. The use of TLS [RFC5246] reduces the
information available for correlation to the network and transport
layer headers (e.g. source and destination IP addresses and ports) on
each hop, but leaves any data at rest used by a protocol on
intermediate systems vulnerable to intermediate system compromise.
End-to-end approaches (e.g. S/MIME [RFC3851]) help defend against
this threat. However, protocols that route messages based on
recipient identifier or pseudonym, such as SMTP [RFC2821] and XMPP
[RFC6120], still require intermediate systems to handle these in the
clear, and may leak additional metadata as well (e.g., in the S/MIME
example, the SMTP headers), making this available to the PPA if it is
has compromised these intermediate systems.
We can assume that the PPA does not have unlimited resources, i.e.,
that it will attempt to eavesdrop at the most efficient observation
point(s) available to it, and will collect as little raw data as
necessary to support its aims. This allows us to back away from this
worst-case scenario. Storing full packet information for a fully-
loaded 10 Gigabit Ethernet link will fill one 4TB hard disk (the
largest commodity hard disk available as of this writing) in less
than an hour; storing network flow data from the same link, e.g. as
IPFIX Files [RFC5655], requires on the order of 1/1000 the storage
(i.e., 4GB an hour). Metadata-based surveillance approaches are
therefore more scalable for pervasive surveillance, so it is
worthwhile to analyze information which can be inferred from various
network traffic capture and analysis techniques other than full
packet observation.
Trammell, et al. Expires May 17, 2014 [Page 5]
Internet-Draft Pervasive Passive Adversary November 2013
In the remainder of this analysis, we categorize the ways that
information radiates off of protocols on the Internet. First, we
list kinds of information that can be directly observed; this may
seem somewhat obvious, but is included for completeness. We then
explore the types of information which may be useful for drawing
inferences about user behavior, then go into practical detail on
inference attacks against just information available in the IP
header, to better illustrate the extent of the problem.
4.1. Information subject to direct observation
Protocols which do not encrypt their payload make the entire content
of the communication available to a PPA along their path. Following
the advice in [RFC3365], most such protocols have a secure variant
which encrypts 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 all DNS queries and answers generated
by the activities of any protocol are available to a PPA.
Protocols which encrypt their payload using an application- or
transport-layer encryption scheme (e.g. TLS [RFC5246]) still expose
all the information in their network and transport layer headers to a
PPA, including source and destination addresses and ports. IPsec 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. Cryptographic
protocols themselves, e.g. the TLS session identifier, may leak
information that can be used for correlation and inference. While
this information is much less semantically rich than the application
payload, it can still be useful for the inferring an individual's
activities.
Protocols which imply the storage of some data at rest in
intermediaries leave this data subject to observation at a PPA 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.
4.2. Information useful for inference
Inference is information extracted from later analysis of an observed
communication, and/or correlation of observed information with
information available from other sources. Indeed, most useful
inference performed by a PPA 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 can give access to information
Trammell, et al. Expires May 17, 2014 [Page 6]
Internet-Draft Pervasive Passive Adversary November 2013
otherwise not available from encrypted application payloads (e.g.,
the Host: HTTP/1.1 request header when HTTP is used with TLS).
Inference can also leverage information obtained from sources other
than direct traffic observation. Geolocation databases, for example,
have been developed 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 which the individuals are not necessarily interested in
protecting for privascy 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 from the protocol design side
to limit such correlation by a PPA, and that the existence of such
data sources in many cases greatly complicates the problem of
protecting privacy by hardening protocols alone.
4.3. On the Non-Anonymity of IP Addresses
In this section, we explore the non-anonymity of even encrypted IP
traffic by examining some inference techniques for associating a set
of addresses with an individual, in order to illustrate the
difficulty of defending communications against a PPA. Here, the
basic problem is that information radiated even from protocols which
have no obvious connection with personal data can be correlated with
other information which can paint a very rich behavioral picture,
that only takes one unprotected link in the chain to associate with
an identity.
4.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
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.
Trammell, et al. Expires May 17, 2014 [Page 7]
Internet-Draft Pervasive Passive Adversary November 2013
Tools like IPFIX [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.
4.3.2. Correlation of IP addresses to user identities
In Section 4.3.1, we have assumed that IP addresses can be correlated
with specific user identities. This can be done in various ways.
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, a PPA
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.
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. A PPA that
could secure the cooperation of the ISP could correlate IP addresses
and user identities automatically.
Even if the ISP does not cooperate, identity can often be obtained
via inference. We will discuss in the next section how SMTP and HTTP
can leak information that links the IP address to the identity of the
user.
Trammell, et al. Expires May 17, 2014 [Page 8]
Internet-Draft Pervasive Passive Adversary November 2013
4.3.3. Monitoring messaging clients for IP address correlation
POP3 [RFC1939] and IMAP [RFC3501] are used to retrieve mail from mail
servers, while a variant of SMTP [RFC5321] 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.
If the protocol is executed in clear text, monitoring services can
"tap" the links to the mail server, retrieve the user name provided
by the client, and associate it with the IP address used to establish
the connection.
The same attack can be executed against the SIP [RFC3261] protocol,
if the connection between the SIP UA and the SIP server operates in
clear text
In addition, there are many instant messaging services operating over
the Internet using proprietary protocols. If any of these
proprietary protocols includes clear-text transmission of the user
identity, these can be observed to provide an association between the
user identity and the IP address.
4.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>
Trammell, et al. Expires May 17, 2014 [Page 9]
Internet-Draft Pervasive Passive Adversary November 2013
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 PPA that sees at least one
copy of the message.
A PPA 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 PPA can still receive a copy of public mailing lists
like "perpass".
Similar information is available in the SIP headers [RFC3261].
4.3.5. Tracking address use with web cookies
Many web sites only encrypt a small fraction of their transactions.
A popular pattern was to use HTTPS for the login information, and
then use a "cookie" to associate following clear-text 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 clear text, a PPA 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
pre-determined identity.
4.3.6. Tracking address use with network graphs
A PPA can track traffic from an IP address not yet associated with an
individual to various public services (e.g. websites, 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 websites,
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.
Trammell, et al. Expires May 17, 2014 [Page 10]
Internet-Draft Pervasive Passive Adversary November 2013
5. Evaluating protocols for PPA resistance
Though inference by a PPA makes the problem of guaranteeing privacy
in the face of passive surveillance difficult, it is possible to
strengthen each link in the chain in order to increase their
resistance. PPA resistent protocols have the following properties:
o The confidentiality of all information not absolutely required for
the operation of the protocol at intermediate systems is
cryptographically protected.
o The confidentiality of all identifiers which can be associated
with specific individuals through observation or inference are
cryptographically protected on a hop-by-hop basis, even if they
are required for the operation of the protocol at intermediate
systems.
o Identifiers required for the operation of the protocol are non-
persistent and non-specific to individuals to the extent possible.
o The protocol radiates as little information as possible which can
be used to fingerprint specific instances of the protocol.
Clearly, the messaging protocols examined in Section 4.3 are, by
these criteria, not particularly resistent to a PPA. In evaluating a
protocol for PPA resistance, tradeoffs in efficiency, latency,
manageability, and other application requirements will need to be
evaluated, as well. More detailed information on privacy
considerations for protocol design are given in
[I-D.cooper-ietf-privacy-requirements].
6. General protocol design recommendations for PPA resistance
The following general recommendations are intended to guide
discussions about improving the resistance of IETF protocols to a
PPA; specific recommendations are the subject of a separate
specification.
6.1. Encrypt everything you can
Though IETF protocols have been long moving in the direction of more
and better cryptographic protection [RFC3365], there is continued
room for improvement. Approaches such as opportunistic encryption,
while not providing identity guarantees, may have benefits in
confidentiality that reduce the information radiated from protocols,
increasing the costs for pervasive surveillance. To some extent
encryption is a deployment problem rather than a protocol design and
implementation problem; improvements in usability may be useful here.
Trammell, et al. Expires May 17, 2014 [Page 11]
Internet-Draft Pervasive Passive Adversary November 2013
The design and deployment of end-to-end encryption for a protocol,
especially for messaging applications, can reduce the ability of a
PPA to observe application-layer information and identifiers at a
compromised intermediate system.
6.2. Design and implement for simplicity and auditability
This would seem to be common sense, but in practice it is not really
the case that protocol design processes naturally have simplicity as
a goal. Simplicity of a design is directly related to the
auditability of the design and implementations thereof. Privacy and
security features designed into a protocol which are too complex to
understand will suffer from limited implementation and deployment. A
good example of such a case is IPsec where primary complaints are
related to its complexity [Ferguson03].
The auditability of a protocol is directly related to the ability to
measure and reason about the information that it radiates that could
be used for inference by a PPA. Audits of designs and
implementations can also reduce the risk of hidden side channels
which could carry additional information useful to a PPA. One
approach for improving auditability is the release of implementations
as open source.
6.3. Allow for fingerprinting resistance in protocol designs
Fingerprinting provides a source of information for inference, and
can rely on packet and flow size and timing information. The
inclusion of null information in packets, or grouping information
into more/fewer packets can reduce this risk. Since protocols tend
to be optimized for minimum bandwidth usage and minumum latency, the
only way to go is up, so this resistance comes at the expense of
usable bandwidth and increased latency. While not necessarily
applicable in the general case, protocol designs can make it possible
do to this.
6.4. Do not rely on static IP addresses
Always on broadband connections may or may not provide the
subscribers with static IP addresses. Some users pay extra for the
convenience of a stable address. Of course, stable addresses greatly
facilitate IP header monitoring.
Trammell, et al. Expires May 17, 2014 [Page 12]
Internet-Draft Pervasive Passive Adversary November 2013
In contrast, we could imagine that the broadband modem is re-
provisioned at regular interval with a new IPv4 address, or with a
new IPv6 address prefix. Some convenience will be lost, and TCP
connections active before the renumbering will have to be
reestablished. However, the renumbering will significantly
complicate the task of IP header monitoring.
Similarly, the Privacy Extensions for Stateless Address
Autoconfiguration in IPv6 [RFC4941] allow users to configure
temporary IPv6 addresses out of a global prefix. Privacy addresses
are meant to be used for a short time, typically no more than a day,
and are specifically designed to render monitoring based on IPv6
addresses harder.
7. IANA Considerations
This document has no actions for IANA
8. Security Considerations
This document explores the capabilities of an adversary with an
interest in undermining the security of the Internet to enable
pervasive surveillance activities. It does not provide any specific
protocol guidance that may impact the security of those protocols,
but it is hoped that the awareness of this threat will end up being a
metacontribution to Internet security.
9. Acknowledgments
Thanks to Dilip Many and Stephan Neuhaus, who contributed to an
initial version of this work. Thanks to Mark Townsley, Stephen
Farrell, Chris Inacio, and others in the anonymity set of "people
we've forgotten to thank" for feedback and input to this draft.
10. References
10.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, July
2013.
[I-D.cooper-ietf-privacy-requirements]
Cooper, A., Farrell, S., and S. Turner, "Privacy
Requirements for IETF Protocols", draft-cooper-ietf-
privacy-requirements-01 (work in progress), October 2013.
Trammell, et al. Expires May 17, 2014 [Page 13]
Internet-Draft Pervasive Passive Adversary November 2013
10.2. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61, RFC
3365, August 2002.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
Trammell, et al. Expires May 17, 2014 [Page 14]
Internet-Draft Pervasive Passive Adversary November 2013
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
Wagner, "Specification of the IP Flow Information Export
(IPFIX) File Format", RFC 5655, October 2009.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September
2013.
[Ferguson03]
Ferguson, D. and B. Schneier, "A Cryptographic Evaluation
of IPsec (https://www.schneier.com/paper-ipsec.pdf)",
December 2003.
Authors' Addresses
Brian Trammell
Swiss Federal Institute of Technology Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 632 70 13
Email: trammell@tik.ee.ethz.ch
Daniel Borkmann
Red Hat
Seefeldstrasse 69
8008 Zurich
Switzerland
Email: dborkman@redhat.com
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
U.S.A.
Email: huitema@huitema.net
Trammell, et al. Expires May 17, 2014 [Page 15]