draft-arkko-farrell-arch-model-t-02.txt   draft-arkko-farrell-arch-model-t.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational S. Farrell Intended status: Informational S. Farrell
Expires: 9 August 2020 Trinity College Dublin Expires: September 10, 2020 Trinity College Dublin
6 February 2020 March 09, 2020
Challenges and Changes in the Internet Threat Model Challenges and Changes in the Internet Threat Model
draft-arkko-farrell-arch-model-t-02 draft-arkko-farrell-arch-model-t-03
Abstract Abstract
Communications security has been at the center of many security Communications security has been at the center of many security
improvements in the Internet. The goal has been to ensure that improvements in the Internet. The goal has been to ensure that
communications are protected against outside observers and attackers. communications are protected against outside observers and attackers.
This memo suggests that the existing RFC 3552 threat model, while This memo suggests that the existing RFC 3552 threat model, while
important and still valid, is no longer alone sufficient to cater for important and still valid, is no longer alone sufficient to cater for
the pressing security and privacy issues seen on the Internet today. the pressing security and privacy issues seen on the Internet today.
skipping to change at line 45 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 August 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Observations 2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Communications Security Improvements 2.1. Communications Security Improvements . . . . . . . . . . 5
2.2. Beyond Communications Security 2.2. Beyond Communications Security . . . . . . . . . . . . . 6
2.3. Examples 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Deliberate adversarial behaviour in 2.3.1. Deliberate adversarial behaviour in applications . . 9
applications 2.3.2. Inadvertent adversarial behaviours . . . . . . . . . 15
2.3.2. Inadvertent adversarial behaviours 3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3. Analysis 3.1. The Role of End-to-end . . . . . . . . . . . . . . . . . 16
3.1. The Role of End-to-end 3.2. Trusted networks . . . . . . . . . . . . . . . . . . . . 18
3.2. Trusted networks 3.2.1. Even closed networks can have compromised nodes . . . 19
3.2.1. Even closed networks can have compromised 3.3. Balancing Threats . . . . . . . . . . . . . . . . . . . . 20
nodes 4. Areas requiring more study . . . . . . . . . . . . . . . . . 21
3.3. Balancing Threats 5. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. Areas requiring more study 6. Potential changes in BCP 72/RFC 3552 . . . . . . . . . . . . 27
5. Guidelines 6.1. Simple change . . . . . . . . . . . . . . . . . . . . . . 28
6. Potential changes in BCP 72/RFC 3552 6.2. Additional discussion of compromises . . . . . . . . . . 29
7. Potential Changes in BCP 188/RFC 7258 6.3. Guidance with regards to communications security . . . . 29
8. Conclusions 6.3.1. Limiting time scope of compromise . . . . . . . . . . 29
9. Informative References 6.3.2. Forcing active attack . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgements 6.3.3. Traffic analysis . . . . . . . . . . . . . . . . . . 31
Authors' Addresses 6.3.4. Containing compromise of trust points . . . . . . . . 31
7. Potential Changes in BCP 188/RFC 7258 . . . . . . . . . . . . 32
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 32
9. Informative References . . . . . . . . . . . . . . . . . . . 33
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
Communications security has been at the center of many security Communications security has been at the center of many security
improvements in the Internet. The goal has been to ensure that improvements in the Internet. The goal has been to ensure that
communications are protected against outside observers and attackers. communications are protected against outside observers and attackers.
At the IETF, this approach has been formalized in BCP 72 [RFC3552], At the IETF, this approach has been formalized in BCP 72 [RFC3552],
which defined the Internet threat model in 2003. which defined the Internet threat model in 2003.
The purpose of a threat model is to outline what threats exist in The purpose of a threat model is to outline what threats exist in
skipping to change at line 116 skipping to change at page 3, line 35
By contrast, we assume that the attacker has nearly complete By contrast, we assume that the attacker has nearly complete
control of the communications channel over which the end-systems control of the communications channel over which the end-systems
communicate. This means that the attacker can read any PDU communicate. This means that the attacker can read any PDU
(Protocol Data Unit) on the network and undetectably remove, (Protocol Data Unit) on the network and undetectably remove,
change, or inject forged packets onto the wire. change, or inject forged packets onto the wire.
However, the communications-security -only threat model is becoming However, the communications-security -only threat model is becoming
outdated. Some of the causes for this are: outdated. Some of the causes for this are:
* Success! Advances in protecting most of our communications with o Success! Advances in protecting most of our communications with
strong cryptographic means. This has resulted in much improved strong cryptographic means. This has resulted in much improved
communications security, but also highlights the need for communications security, but also highlights the need for
addressing other, remaining issues. This is not to say that addressing other, remaining issues. This is not to say that
communications security is not important, it still is: communications security is not important, it still is:
improvements are still needed. Not all communications have been improvements are still needed. Not all communications have been
protected, and even out of the already protected communications, protected, and even out of the already protected communications,
not all of their aspects have been fully protected. Fortunately, not all of their aspects have been fully protected. Fortunately,
there are ongoing projects working on improvements. there are ongoing projects working on improvements.
* Adversaries have increased their pressure against other avenues of o Adversaries have increased their pressure against other avenues of
attack, from supply-channel attacks, to compromising devices to attack, from supply-channel attacks, to compromising devices to
legal coercion of centralized endpoints in conversations. legal coercion of centralized endpoints in conversations.
* New adversaries and risks have arisen, e.g., due to creation of o New adversaries and risks have arisen, e.g., due to creation of
large centralized information sources. large centralized information sources.
* While communications-security does seem to be required to protect o While communications-security does seem to be required to protect
privacy, more is needed, especially if endpoints choose to act privacy, more is needed, especially if endpoints choose to act
against the interests of their peers or users. against the interests of their peers or users.
In short, attacks are migrating towards the currently easier targets, In short, attacks are migrating towards the currently easier targets,
which no longer necessarily include direct attacks on traffic flows. which no longer necessarily include direct attacks on traffic flows.
In addition, trading information about users and ability to influence In addition, trading information about users and ability to influence
them has become a common practice for many Internet services, often them has become a common practice for many Internet services, often
without users understanding those practices. without users understanding those practices.
This memo suggests that the existing threat model, while important This memo suggests that the existing threat model, while important
skipping to change at line 182 skipping to change at page 5, line 6
design and architecture affect security. The sole consideration of design and architecture affect security. The sole consideration of
communications security aspects in designing Internet protocols may communications security aspects in designing Internet protocols may
lead to accidental or increased impact of security issues elsewhere. lead to accidental or increased impact of security issues elsewhere.
For instance, allowing a participant to unnecessarily collect or For instance, allowing a participant to unnecessarily collect or
receive information may lead to a similar effect as described in receive information may lead to a similar effect as described in
[RFC8546] for protocols: over time, unnecessary information will get [RFC8546] for protocols: over time, unnecessary information will get
used with all the associated downsides, regardless of what deployment used with all the associated downsides, regardless of what deployment
expectations there were during protocol design. expectations there were during protocol design.
This memo does not stand alone. To begin with, it is a merge of This memo does not stand alone. To begin with, it is a merge of
earlier work by the two authors [I-D.farrell-etm] [I-D.arkko-arch- earlier work by the two authors [I-D.farrell-etm]
internet-threat-model]. There are also other documents discussing [I-D.arkko-arch-internet-threat-model]. There are also other
this overall space, e.g. [I-D.lazanski-smart-users-internet] [I- documents discussing this overall space, e.g.
D.arkko-arch-dedr-report]. [I-D.lazanski-smart-users-internet] [I-D.arkko-arch-dedr-report].
The authors of this memo envisage independent development of each of The authors of this memo envisage independent development of each of
those (and other work) with an eventual goal to extract an updated those (and other work) with an eventual goal to extract an updated
(but usefully brief!) description of an extended threat model from (but usefully brief!) description of an extended threat model from
the collection of works. We consider it an open question whether the collection of works. We consider it an open question whether
this memo, or any of the others, would be usefully published as an this memo, or any of the others, would be usefully published as an
RFC. RFC.
The rest of this memo is organized as follows. Section 2 makes some The rest of this memo is organized as follows. Section 2 makes some
observations about the situation, with respect to communications observations about the situation, with respect to communications
skipping to change at line 226 skipping to change at page 5, line 50
2. Observations 2. Observations
2.1. Communications Security Improvements 2.1. Communications Security Improvements
Being able to ask about threat model improvements is due to progress Being able to ask about threat model improvements is due to progress
already made: The fraction of Internet traffic that is already made: The fraction of Internet traffic that is
cryptographically protected has grown tremendously in the last few cryptographically protected has grown tremendously in the last few
years. Several factors have contributed to this change, from Snowden years. Several factors have contributed to this change, from Snowden
revelations to business reasons and to better available technology revelations to business reasons and to better available technology
such as HTTP/2 [RFC7540], TLS 1.3 [RFC8446], QUIC [I-D.ietf-quic- such as HTTP/2 [RFC7540], TLS 1.3 [RFC8446], QUIC
transport]. [I-D.ietf-quic-transport].
In many networks, the majority of traffic has flipped from being In many networks, the majority of traffic has flipped from being
cleartext to being encrypted. Reaching the level of (almost) all cleartext to being encrypted. Reaching the level of (almost) all
traffic being encrypted is no longer something unthinkable but rather traffic being encrypted is no longer something unthinkable but rather
a likely outcome in a few years. a likely outcome in a few years.
At the same time, technology developments and policy choices have At the same time, technology developments and policy choices have
driven the scope of cryptographic protection from protecting only the driven the scope of cryptographic protection from protecting only the
pure payload to protecting much of the rest as well, including far pure payload to protecting much of the rest as well, including far
more header and meta-data information than was protected before. For more header and meta-data information than was protected before. For
instance, efforts are ongoing in the IETF to assist encrypting instance, efforts are ongoing in the IETF to assist encrypting
transport headers [I-D.ietf-quic-transport], server domain name transport headers [I-D.ietf-quic-transport], server domain name
information in TLS [I-D.ietf-tls-esni], and domain name queries information in TLS [I-D.ietf-tls-esni], and domain name queries
[RFC8484]. [RFC8484].
There have also been improvements to ensure that the security There have also been improvements to ensure that the security
protocols that are in use actually have suitable credentials and that protocols that are in use actually have suitable credentials and that
those credentials have not been compromised, see, for instance, Let's those credentials have not been compromised, see, for instance, Let's
Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT [I- Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT
D.ietf-httpbis-expect-ct]. [I-D.ietf-httpbis-expect-ct].
This is not to say that all problems in communications security have This is not to say that all problems in communications security have
been resolved - far from it. But the situation is definitely been resolved - far from it. But the situation is definitely
different from what it was a few years ago. Remaining issues will be different from what it was a few years ago. Remaining issues will be
and are worked on; the fight between defense and attack will also and are worked on; the fight between defense and attack will also
continue. Communications security will stay at the top of the agenda continue. Communications security will stay at the top of the agenda
in any Internet technology development. in any Internet technology development.
2.2. Beyond Communications Security 2.2. Beyond Communications Security
There are, however, significant issues beyond communications security There are, however, significant issues beyond communications security
in the Internet. To begin with, it is not necessarily clear that one in the Internet. To begin with, it is not necessarily clear that one
can trust all the endpoints in any protocol interaction. can trust all the endpoints in any protocol interaction.
Of course, client endpoint implemententations were never fully Of course, client endpoint implementations were never fully trusted,
trusted, but the environments in which those endpoints exist are but the environments in which those endpoints exist are changing.
changing. For instance, users may have as much control over their For instance, users may not have as much control over their own
own devices as they used to, due to manufacturer-controlled operating devices as they used to, due to manufacturer-controlled operating
system installations and locked device ecosystems. And within those system installations and locked device ecosystems. And within those
ecosystems, even the applications that are available tend to have ecosystems, even the applications that are available tend to have
privileges that users by themselves might not desire those privileges that users by themselves might not desire those
applications be granted, such as excessive rights to media, location, applications be granted, such as excessive rights to media, location,
and peripherals. There are also designated efforts by various and peripherals. There are also designated efforts by various
authorities to hack end-user devices as a means of intercepting data authorities to hack end-user devices as a means of intercepting data
about the user. about the user.
The situation is different, but not necessarily better on the side of The situation is different, but not necessarily better on the side of
servers. The pattern of communications in today's Internet is almost servers. The pattern of communications in today's Internet is almost
always via a third party that has at least as much information as the always via a third party that has at least as much information as the
other parties have. For instance, these third parties are typically other parties have. For instance, these third parties are typically
endpoints for any transport layer security connections, and able to endpoints for any transport layer security connections, and able to
see much communications or other messaging in cleartext. There are see much communications or other messaging in cleartext. There are
some exceptions, of course, e.g., messaging applications with end-to- some exceptions, of course, e.g., messaging applications with end-to-
end confidentiatlity protection. end confidentiality protection.
With the growth of trading users' information by many of these third With the growth of trading users' information by many of these third
parties, it becomes necessary to take precautions against endpoints parties, it becomes necessary to take precautions against endpoints
that are compromised, malicious, or whose interests simply do not that are compromised, malicious, or whose interests simply do not
align with the interests of the users. align with the interests of the users.
Specifically, the following issues need attention: Specifically, the following issues need attention:
* Security of users' devices and the ability of the user to control o Security of users' devices and the ability of the user to control
their own equipment. their own equipment.
* Leaks and attacks related to data at rest. o Leaks and attacks related to data at rest.
* Coercion of some endpoints to reveal information to authorities or o Coercion of some endpoints to reveal information to authorities or
surveillance organizations, sometimes even in an extra-territorial surveillance organizations, sometimes even in an extra-territorial
fashion. fashion.
* Application design patterns that result in cleartext information o Application design patterns that result in cleartext information
passing through a third party or the application owner. passing through a third party or the application owner.
* Involvement of entities that have no direct need for involvement o Involvement of entities that have no direct need for involvement
for the sake of providing the service that the user is after. for the sake of providing the service that the user is after.
* Network and application architectures that result in a lot of o Network and application architectures that result in a lot of
information collected in a (logically) central location. information collected in a (logically) central location.
* Leverage and control points outside the hands of the users or end- o Leverage and control points outside the hands of the users or end-
user device owners. user device owners.
For instance, while e-mail transport security [RFC7817] has become For instance, while e-mail transport security [RFC7817] has become
much more widely deployed in recent years, progress in securing much more widely deployed in recent years, progress in securing
e-mail messages between users has been much slower. This has lead to e-mail messages between users has been much slower. This has lead to
a situation where e-mail content is considered a critical resource by a situation where e-mail content is considered a critical resource by
some mail service providers who use the content for machine learning, some mail service providers who use the content for machine learning,
advertisement targeting, and other purposes unrelated to message advertisement targeting, and other purposes unrelated to message
delivery. Equally however, it is unclear how some useful anti-spam delivery. Equally however, it is unclear how some useful anti-spam
techniques could be deployed in an end-to-end encrypted mail universe techniques could be deployed in an end-to-end encrypted mail universe
(with today's end-to-end mail sercurity protocols) and there are many (with today's end-to-end mail security protocols) and there are many
significant challenges should one desire to deploy end-to-end email significant challenges should one desire to deploy end-to-end email
security at scale. security at scale.
The Domain Name System (DNS) shows signs of ageing but due to the The Domain Name System (DNS) shows signs of ageing but due to the
legacy of deployed systems has changed very slowly. Newer technology legacy of deployed systems has changed very slowly. Newer technology
[RFC8484] developed at the IETF enables DNS queries to be performed [RFC8484] developed at the IETF enables DNS queries to be performed
with confidentiality and authentication (of a recursive resolver), with confidentiality and authentication (of a recursive resolver),
but its initial deployment is happening mostly in browsers that use but its initial deployment is happening mostly in browsers that use
global DNS resolver services, such as Cloudflare's 1.1.1.1 or global DNS resolver services, such as Cloudflare's 1.1.1.1 or
Google's 8.8.8.8. This results in faster evolution and better Google's 8.8.8.8. This results in faster evolution and better
skipping to change at line 349 skipping to change at page 8, line 28
are very well maintained (and a great service), they are potential are very well maintained (and a great service), they are potential
high-value targets for pervasive monitoring and Denial-of-Service high-value targets for pervasive monitoring and Denial-of-Service
(DoS) attacks. In 2016, for example, DoS attacks were launched (DoS) attacks. In 2016, for example, DoS attacks were launched
against Dyn, [DynDDoS] then one of the largest DNS providers, leading against Dyn, [DynDDoS] then one of the largest DNS providers, leading
to some outages. It is difficult to imagine that DNS resolvers to some outages. It is difficult to imagine that DNS resolvers
wouldn't be a target in many future attacks or pervasive monitoring wouldn't be a target in many future attacks or pervasive monitoring
projects. projects.
Unfortunately, there is little that even large service providers can Unfortunately, there is little that even large service providers can
do to not be a DDoS target, (though anycast and other DDoS do to not be a DDoS target, (though anycast and other DDoS
mitigations can certainly help when one is targetted), nor to refuse mitigations can certainly help when one is targeted), nor to refuse
authority-sanctioned pervasive monitoring. As a result it seems that authority-sanctioned pervasive monitoring. As a result it seems that
a reasonable defense strategy may be to aim for outcomes where such a reasonable defense strategy may be to aim for outcomes where such
highly centralised control points are unecessary or don't handle highly centralised control points are unnecessary or don't handle
sensitive data. (Recalling that with the DNS, meta-data about the sensitive data. (Recalling that with the DNS, meta-data about the
requestor and the act of requesting an answer are what is potentially requestor and the act of requesting an answer are what is potentially
sensitive, rather than the content of the answer.) sensitive, rather than the content of the answer.)
There are other examples of the perils of centralised solutions in There are other examples of the perils of centralised solutions in
Internet infrastructure. The DNS example involves an interesting Internet infrastructure. The DNS example involves an interesting
combination of information flows (who is asking for what domain combination of information flows (who is asking for what domain
names) as well as a potential ability to exert control (what domains names) as well as a potential ability to exert control (what domains
will actually resolve to an address). Routing systems are primarily will actually resolve to an address). Routing systems are primarily
about control. While there are intra-domain centralized routing about control. While there are intra-domain centralized routing
skipping to change at line 413 skipping to change at page 9, line 44
network operators who do act primarily in the best interests of their network operators who do act primarily in the best interests of their
users. users.
2.3.1.1. Malware in curated application stores 2.3.1.1. Malware in curated application stores
Despite the best efforts of curators, so-called App-Stores frequently Despite the best efforts of curators, so-called App-Stores frequently
distribute malware of many kinds and one recent study [Curated] distribute malware of many kinds and one recent study [Curated]
claims that simple obfuscation enables malware to avoid detection by claims that simple obfuscation enables malware to avoid detection by
even sophisticated operators. Given the scale of these deployments, even sophisticated operators. Given the scale of these deployments,
distribution of even a small percentage of malware-infected distribution of even a small percentage of malware-infected
applictions can affect a huge number of people. applications can affect a huge number of people.
2.3.1.2. Virtual private networks (VPNs) 2.3.1.2. Virtual private networks (VPNs)
Virtual private networks (VPNs) are supposed to hide user traffic to Virtual private networks (VPNs) are supposed to hide user traffic to
various degrees depending on the particular technology chosen by the various degrees depending on the particular technology chosen by the
VPN provider. However, not all VPNs do what they say, some for VPN provider. However, not all VPNs do what they say, some for
example misrepresenting the countries in which they provide vantage example misrepresenting the countries in which they provide vantage
points [Vpns]. points [Vpns].
2.3.1.3. Compromised (home) networks 2.3.1.3. Compromised (home) networks
What we normally might consider network devices such as home routers What we normally might consider network devices such as home routers
do also run applications that can end up being adversarial, for do also run applications that can end up being adversarial, for
example running DNS and DHCP attacks from home routers targeting example running DNS and DHCP attacks from home routers targeting
other devices in the home. One study [Home] reports on a 2011 attack other devices in the home. One study [Home] reports on a 2011 attack
that affected 4.5 million DSL modems in Brazil. The absence of that affected 4.5 million DSL modems in Brazil. The absence of
software update [RFC8240] has been a major cause of these issues and software update [RFC8240] has been a major cause of these issues and
rises to the level that considering this as intentional behaviour by rises to the level that considering this as intentional behaviour by
device vendors who have chosen this path is warranted. device vendors who have chosen this path is warranted.
2.3.1.4. Web browsers 2.3.1.4. Web tracking
Tracking of users in order to support advertising based business One of the biggest threats to user privacy on the Web is ubiquitous
models is ubiquitous on the Internet today. HTTP header fields (such tracking. This is often done to support advertising based business
as cookies) are commonly used for such tracking, as are structures models.
within the content of HTTP responses such as links to 1x1 pixel
images and (ab)use of Javascript APIs offered by browsers [Tracking].
While some people may be sanguine about this kind of tracking, others While some people may be sanguine about this kind of tracking, others
consider this behaviour unwelcome, when or if they are informed that consider this behaviour unwelcome, when or if they are informed that
it happens, [Attitude] though the evidence here seems somewhat harder it happens, [Attitude] though the evidence here seems somewhat harder
to interpret and many studies (that we have found to date) involve to interpret and many studies (that we have found to date) involve
small numbers of users. Historically, browsers have not made this small numbers of users. Historically, browsers have not made this
kind of tracking visible and have enabled it by default, though some kind of tracking visible and have enabled it by default, though some
recent browser versions are starting to enable visibility and recent browser versions are starting to enable visibility and
blocking of some kinds of tracking. Browsers are also increasingly blocking of some kinds of tracking. Browsers are also increasingly
imposing more stringent requirements on plug-ins for varied security imposing more stringent requirements on plug-ins for varied security
reasons. reasons.
Third party tracking
One form of tracking is by third parties. HTTP header fields (such
as cookies, [RFC6265]) are commonly used for such tracking, as are
structures within the content of HTTP responses such as links to 1x1
pixel images and (ab)use of Javascript APIs offered by browsers
[Tracking].
Whenever a resource is loaded from a server, that server can include
a cookie which will be sent back to the server on future loads. This
includes situations where the resource is loaded as a resource on a
page, such as an image or a JavaScript module. When loading a
resource, the server is aware of the top-level page that the resource
is used on, through the use of the Referer HTTP header [RFC7231].
those loads include a Referer header which contains the top-level
page from which that subresource is being loaded.
The combination of these features makes it possible to track a user
across the Web. The tracker convinces a number of content sites
("first parties") to include a resource from the tracker site. This
resource can perform some function such as displaying an
advertisement or providing analytics to the first party site. But
the resource may also be simply a tracker. When the user visits one
of the content sites, the tracker receives both a Referer header and
the cookie. For an individual user with a particular browser, the
cookie is the same regardless of which site the tracker is on. This
allows the tracker to observe what pages within the set of content
sites the user visits. The resulting information is commonly used
for targeting advertisements, but it can also be used for other
purposes.
This capability itself constitutes a major threat to user privacy.
Additional techniques such as cookie syncing, identifier correlation,
and fingerprinting make the problem even worse.
As a given tracker will not be on all sites, that tracker has
incomplete coverage. However, trackers often collude (a practice
called "cookie syncing") to combine the information from different
tracking cookies.
Sometimes trackers will be embedded on a site which collects a user
identifier, such as social media identity or an e-mail address. If
the site can inform the tracker of the identifier, that allows the
tracker to tie the identifier to the cookie.
While a browser may block cookies, fingerprinting browsers often
allows tracking the users. For instance, features such as User-Agent
string, plugin and font support, screen resolution, and timezone can
yield a fingerprint that is sometimes unique to a single user
[AmIUnique] and which persists beyond cookie scope and lifetime.
Even in cases where this fingerprint is not unique, the anonymity set
may be sufficiently small that, coupled with other data, this yields
a unique, per-user identifier. Fingerprinting of this type is more
prevalent on systems and platforms where data-set features are
flexible, such as desktops, where plugins are more commonly in use.
Fingerprinting prevention is an active research area; see [Boix2018]
for more information.
Other types of tracking linked to web tracking
Third party web tracking is not the only concern. An obvious
tracking danger exists also in popular ecosystems - such as social
media networks - that house a large part of many users' online
existence. There is no need for a third party to track the user's
browsing as all actions are performed within a single site, where
most messaging, viewing, and sharing activities happen.
Browsers themselves or services used by the browser can also become a
potential source of tracking users. For instance, the URL/search bar
service may leak information about the user's actions to a search
provider via an "autocomplete" feature. [Leith2020]
Tracking through users' IP addresses or DNS queries is also a danger.
This may happen by directly observing the cleartext IP or DNS
traffic, though DNS tracking may be preventable via DNS protocols
that are secured end-to-end. But the DNS queries are also (by
definition) seen by the used DNS recursive resolver service, which
may accidentally or otherwise track the users' activities. This is
particularly problematic if a large number of users employ either a
commonly used ISP service or an Internet-based resolver service
[I-D.arkko-arch-infrastructure-centralisation]. In contrast, use of
a DNS recursive that sees little traffic could equally be used for
tracking. Similarly, other applications, such an mail or instant
messaging protocols, that can carry HTML content can be integrated
with web tracking. (See Section 2.3.1.6.)
2.3.1.5. Web site policy deception 2.3.1.5. Web site policy deception
Many web sites today provide some form of privacy policy and terms of Many web sites today provide some form of privacy policy and terms of
service, that are known to be mostly unread [Unread]. This implies service, that are known to be mostly unread [Unread]. This implies
that, legal fiction aside, users of those sites have not in reality that, legal fiction aside, users of those sites have not in reality
agreed to the specific terms published and so users are therefore agreed to the specific terms published and so users are therefore
highly exposed to being exploited by web sites, for example highly exposed to being exploited by web sites, for example
[Cambridge] is a recent well-publicised case where a service provider [Cambridge] is a recent well-publicised case where a service provider
abused the data of 87 million users via a partnership. While many abused the data of 87 million users via a partnership. While many
web site operators claim that they care deeply about privacy, it web site operators claim that they care deeply about privacy, it
skipping to change at line 525 skipping to change at page 13, line 50
of Things" as all devices were already things:-) have been found of Things" as all devices were already things:-) have been found
deficient when their security and privacy aspects were analysed, for deficient when their security and privacy aspects were analysed, for
example children's toys [Toys]. While in some cases this may be due example children's toys [Toys]. While in some cases this may be due
to incompetence rather than being deliberately adversarial behaviour, to incompetence rather than being deliberately adversarial behaviour,
the levels of incompetence frequently seen imply these aspects have the levels of incompetence frequently seen imply these aspects have
simply not been considered a priority. simply not been considered a priority.
2.3.1.10. Attacks leveraging compromised high-level DNS infrastructure 2.3.1.10. Attacks leveraging compromised high-level DNS infrastructure
Recent attacks [DeepDive] against DNS infrastructure enable Recent attacks [DeepDive] against DNS infrastructure enable
subsequent targetted attacks on specific application layer sources or subsequent targeted attacks on specific application layer sources or
destinations. The general method appears to be to attack DNS destinations. The general method appears to be to attack DNS
infrastructure, in these cases infrastructure that is towards the top infrastructure, in these cases infrastructure that is towards the top
of the DNS naming hierarchy and "far" from the presumed targets, in of the DNS naming hierarchy and "far" from the presumed targets, in
order to be able to fake DNS responses to a PKI, thereby acquiring order to be able to fake DNS responses to a PKI, thereby acquiring
TLS server certificates so as to subsequently attack TLS connections TLS server certificates so as to subsequently attack TLS connections
from clients to services (with clients directed to an attacker-owned from clients to services (with clients directed to an attacker-owned
server via additional fake DNS responses). server via additional fake DNS responses).
Attackers in these cases seem well resourced and patient - with Attackers in these cases seem well resourced and patient - with
"practice" runs over months and with attack durations being "practice" runs over months and with attack durations being
skipping to change at line 583 skipping to change at page 15, line 13
currently most important security protocol (TLS). currently most important security protocol (TLS).
2.3.1.11. BGP hijacking 2.3.1.11. BGP hijacking
There is a clear history of BGP hijacking [BgpHijack] being used to There is a clear history of BGP hijacking [BgpHijack] being used to
ensure endpoints connect to adversarial applications. As in the ensure endpoints connect to adversarial applications. As in the
previous example, such hijacks can be used to trick a PKI into previous example, such hijacks can be used to trick a PKI into
issuing a certificate for a fake entity. Indeed one study issuing a certificate for a fake entity. Indeed one study
[HijackDet] used the emergence of new web server TLS key pairs during [HijackDet] used the emergence of new web server TLS key pairs during
the event, (detected via Internet-wide scans), as a distinguisher the event, (detected via Internet-wide scans), as a distinguisher
between one form of deliberate BGP hijacking and indadvertent route between one form of deliberate BGP hijacking and inadvertent route
leaks. leaks.
2.3.1.12. Anti-virus vendor selling user clickstream data 2.3.1.12. Anti-virus vendor selling user clickstream data
An anti-virus product vendor was feeding user clickstream data to a An anti-virus product vendor was feeding user clickstream data to a
subsidiary that then sold on supposedly "anonymised" but highly subsidiary that then sold on supposedly "anonymised" but highly
detailed data to unrelated parties. [avleak] After browser makers detailed data to unrelated parties. [avleak] After browser makers
had removed that vendor's browser extension from their online stores, had removed that vendor's browser extension from their online stores,
the anti-virus product itself apparently took over data collection the anti-virus product itself apparently took over data collection
initially only offering users an opt-out, with the result that initially only offering users an opt-out, with the result that
skipping to change at line 608 skipping to change at page 15, line 38
2.3.2. Inadvertent adversarial behaviours 2.3.2. Inadvertent adversarial behaviours
Not all adversarial behaviour by applications is deliberate, some is Not all adversarial behaviour by applications is deliberate, some is
likely due to various levels of carelessness (some quite likely due to various levels of carelessness (some quite
understandable, others not) and/or due to erroneous assumptions about understandable, others not) and/or due to erroneous assumptions about
the environments in which those applications (now) run. the environments in which those applications (now) run.
We very briefly list some such cases: We very briefly list some such cases:
* Application abuse for command and control, for example, use of IRC o Application abuse for command and control, for example, use of IRC
or apache logs for [CommandAndControl] or apache logs for [CommandAndControl]
* Carelessly leaky data stores [LeakyBuckets], for example, lots of o Carelessly leaky data stores [LeakyBuckets], for example, lots of
Amazon S3 leaks showing that careless admins can too easily cause Amazon S3 leaks showing that careless admins can too easily cause
application server data to become available to adversaries application server data to become available to adversaries
* Virtualisation exposing secrets, for example, Meltdown and Spectre o Virtualisation exposing secrets, for example, Meltdown and Spectre
[MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar [MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar
side-channel attacks. side-channel attacks.
* Compromised badly-maintained web sites, that for example, have led o Compromised badly-maintained web sites, that for example, have led
to massive online [Passwords]. to massive online [Passwords].
* Supply-chain attacks, for example, the [TargetAttack] or malware o Supply-chain attacks, for example, the [TargetAttack] or malware
within pre-installed applications on Android phones [Bloatware]. within pre-installed applications on Android phones [Bloatware].
* Breaches of major service providers, that many of us might have o Breaches of major service providers, that many of us might have
assumed would be sufficiently capable to be the best large-scale assumed would be sufficiently capable to be the best large-scale
"Identity providers", for example: "Identity providers", for example:
- 3 billion accounts: https://www.wired.com/story/yahoo-breach- * 3 billion accounts: https://www.wired.com/story/yahoo-breach-
three-billion-accounts/ three-billion-accounts/
- "up to 600M" account passwords stored in clear: * "up to 600M" account passwords stored in clear:
https://www.pcmag.com/news/367319/facebook-stored-up-to-600m- https://www.pcmag.com/news/367319/facebook-stored-up-to-600m-
user-passwords-in-plain-text user-passwords-in-plain-text
- many millions at risk: https://www.zdnet.com/article/us-telcos- * many millions at risk: https://www.zdnet.com/article/us-telcos-
caught-selling-your-location-data-again-senator-demands-new- caught-selling-your-location-data-again-senator-demands-new-
laws/ laws/
- 50 million accounts: https://www.cnet.com/news/facebook-breach- * 50 million accounts: https://www.cnet.com/news/facebook-breach-
affected-50-million-people/ affected-50-million-people/
- 14 million accounts: https://www.zdnet.com/article/millions- * 14 million accounts: https://www.zdnet.com/article/millions-
verizon-customer-records-israeli-data/ verizon-customer-records-israeli-data/
- "hundreds of thousands" of accounts: * "hundreds of thousands" of accounts:
https://www.wsj.com/articles/google-exposed-user-data-feared- https://www.wsj.com/articles/google-exposed-user-data-feared-
repercussions-of-disclosing-to-public-1539017194 repercussions-of-disclosing-to-public-1539017194
- unknown numbers, some email content exposed: * unknown numbers, some email content exposed:
https://motherboard.vice.com/en_us/article/ywyz3x/hackers- https://motherboard.vice.com/en_us/article/ywyz3x/hackers-
could-read-your-hotmail-msn-outlook-microsoft-customer-support could-read-your-hotmail-msn-outlook-microsoft-customer-support
* Breaches of smaller service providers: Too many to enumerate, o Breaches of smaller service providers: Too many to enumerate,
sadly sadly
3. Analysis 3. Analysis
3.1. The Role of End-to-end 3.1. The Role of End-to-end
[RFC1958] notes that "end-to-end functions can best be realised by [RFC1958] notes that "end-to-end functions can best be realised by
end-to-end protocols": end-to-end protocols":
The basic argument is that, as a first principle, certain required The basic argument is that, as a first principle, certain required
skipping to change at line 842 skipping to change at page 20, line 33
proprietary programs, firmware, or even innocent-looking components proprietary programs, firmware, or even innocent-looking components
on a circuit board can be suspect. In addition, complex underlying on a circuit board can be suspect. In addition, complex underlying
computing platforms, such as modern CPUs with underlying security and computing platforms, such as modern CPUs with underlying security and
management tools are prone to problems. management tools are prone to problems.
In general, this means that one cannot entirely trust even a closed In general, this means that one cannot entirely trust even a closed
system where you picked all the components yourself. Analysis for system where you picked all the components yourself. Analysis for
the security of many interesting real-world systems now commonly the security of many interesting real-world systems now commonly
needs to include cross-component attacks, e.g., the use of car radios needs to include cross-component attacks, e.g., the use of car radios
and other externally communicating devices as part of attacks and other externally communicating devices as part of attacks
launched against the control components such as breaks in a car launched against the control components such as brakes in a car
[Savage]. [Savage].
3.3. Balancing Threats 3.3. Balancing Threats
Note that not all information needs to be protected, and not all Note that not all information needs to be protected, and not all
threats can be protected against. But it is important that the main threats can be protected against. But it is important that the main
threats are understood and protected against. threats are understood and protected against.
Sometimes there are higher-level mechanisms that provide safeguards Sometimes there are higher-level mechanisms that provide safeguards
for failures. For instance, it is very difficult in general to for failures. For instance, it is very difficult in general to
skipping to change at line 869 skipping to change at page 21, line 11
much value to an attacker. For instance, it does not always make much value to an attacker. For instance, it does not always make
sense to encrypt every packet transmission in a packet-carrying sense to encrypt every packet transmission in a packet-carrying
system where the traffic is already encrypted at other layers. But system where the traffic is already encrypted at other layers. But
it almost always makes sense to protect control communications and to it almost always makes sense to protect control communications and to
understand the impacts of compromised nodes, particularly control understand the impacts of compromised nodes, particularly control
nodes. nodes.
4. Areas requiring more study 4. Areas requiring more study
In addition to the guidelines in (Section 5), we suggest there may be In addition to the guidelines in (Section 5), we suggest there may be
value in further study on the topics balow, with the goal of value in further study on the topics below, with the goal of
producing more concrete guidelines. producing more concrete guidelines.
1. Isolation: Sophisticated users can sometimes deal with 1. Isolation: Sophisticated users can sometimes deal with
adversarial behaviours in applications by using different adversarial behaviours in applications by using different
instances of those applications, for example, differently instances of those applications, for example, differently
configured web browsers for use in different contexts. configured web browsers for use in different contexts.
Applications (including web browsers) and operating systems are Applications (including web browsers) and operating systems are
also building in isolation via use of different processes or also building in isolation via use of different processes or
sandboxing. Protocol artefacts that relate to uses of such sandboxing. Protocol artefacts that relate to uses of such
isolation mechanisms might be worth considering. To an extent, isolation mechanisms might be worth considering. To an extent,
the IETF has in practice already recognised some of these issues the IETF has in practice already recognised some of these issues
as being in-scope, e.g. when considering the linkability issues as being in-scope, e.g. when considering the linkability issues
with mechanisms such as TLS session tickets, or QUIC connection with mechanisms such as TLS session tickets, or QUIC connection
identifiers. identifiers.
2. Transparency: Certificate transparency (CT) [RFC6962] has been 2. Controlling Tracking: Web browsers have a central role in terms
of the deployment of anti-tracking technologies. A number of
browsers have started adding these technologies [Mozilla2019]
but this is a rapidly moving field, so is difficult to fully
characterize in this memo. The mechanisms used can be as simple
as blocking communication with known trackers, or more complex,
such identifying trackers and suppressing their ability to store
and access cookies and other state. Browsers may also treat
each third party load on different first party sites as a
different context, thereby isolating cookies and other state,
such as TLS layer information (this technique is called "Double
Keying" [DoubleKey]). The further development of browser-based
anti-tracking technology is important, but it is also important
to ensure that browsers themselves do not themselves enable new
data collection points, e.g., via search, DNS, or other
functions.
3. Transparency: Certificate transparency (CT) [RFC6962] has been
an effective countermeasure for X.509 certificate mis-issuance, an effective countermeasure for X.509 certificate mis-issuance,
which used be a known application layer misbehaviour in the which used be a known application layer misbehaviour in the
public web PKI. CT can also help with post-facto detection of public web PKI. CT can also help with post-facto detection of
some infrastructure attacks where BGP or DNS weakenesses have some infrastructure attacks where BGP or DNS weaknesses have
been leveraged so that some certification authority is tricked been leveraged so that some certification authority is tricked
into issuing a certificate for the wrong entity. While the into issuing a certificate for the wrong entity. While the
context in which CT operates is very constrained (essentially to context in which CT operates is very constrained (essentially to
the public CAs trusted by web browsers), similar approaches the public CAs trusted by web browsers), similar approaches
could perhaps be useful for other protocols or technologies. In could perhaps be useful for other protocols or technologies. In
addition, legislative requirements such as those imposed by the addition, legislative requirements such as those imposed by the
GDPR [GDPRAccess] could lead to a desire to handle internal data GDPR [GDPRAccess] could lead to a desire to handle internal data
structures and databases in ways that are reminiscent of CT, structures and databases in ways that are reminiscent of CT,
though clearly with significant authorisation being required and though clearly with significant authorisation being required and
without the append-only nature of a CT log. without the append-only nature of a CT log.
3. Same-Origin Policy: The Same-Origin Policy (SOP) [RFC6454] 4. Same-Origin Policy: The Same-Origin Policy (SOP) [RFC6454]
perhaps already provides an example of how going beyond the RFC perhaps already provides an example of how going beyond the RFC
3552 threat model can be useful. Arguably, the existence of the 3552 threat model can be useful. Arguably, the existence of the
SOP demonstrates that at least web browsers already consider the SOP demonstrates that at least web browsers already consider the
3552 model as being too limited. (Clearly, differentiating 3552 model as being too limited. (Clearly, differentiating
between same and not-same origins implicitly assumes that some between same and not-same origins implicitly assumes that some
origins are not as trustworthy as others.) origins are not as trustworthy as others.)
4. Greasing: The TLS protocol [RFC8446] now supports the use of 5. Greasing: The TLS protocol [RFC8446] now supports the use of
GREASE [I-D.ietf-tls-grease] as a way to mitigate on-path GREASE [I-D.ietf-tls-grease] as a way to mitigate on-path
ossification. While this technique is not likely to prevent any ossification. While this technique is not likely to prevent any
deliberate misbehaviours, it may provide a proof-of-concept that deliberate misbehaviours, it may provide a proof-of-concept that
network protocol mechanisms can have impact in this space, if we network protocol mechanisms can have impact in this space, if we
spend the time to try analyse the incentives of the various spend the time to try analyse the incentives of the various
parties. parties.
5. Generalise OAuth Threat Model: The OAuth threat model [RFC6819] 6. Generalise OAuth Threat Model: The OAuth threat model [RFC6819]
provides an extensive list of threats and security provides an extensive list of threats and security
considerations for those implementing and deploying OAuth considerations for those implementing and deploying OAuth
version 2.0 [RFC6749]. It could be useful to attempt to derive version 2.0 [RFC6749]. It could be useful to attempt to derive
a more abstract threat model from that RFC that considers a more abstract threat model from that RFC that considers
threats in more generic multi-party contexts. That document is threats in more generic multi-party contexts. That document is
perhaps too detailed to serve as useful generic guidance but perhaps too detailed to serve as useful generic guidance but
does go beyond the Internet threat model from RFC3552, for does go beyond the Internet threat model from RFC3552, for
example it says: example it says:
two of the three parties involved in the OAuth protocol may two of the three parties involved in the OAuth protocol may
collude to mount an attack against the 3rd party. For collude to mount an attack against the 3rd party. For
example, the client and authorization server may be under example, the client and authorization server may be under
control of an attacker and collude to trick a user to gain control of an attacker and collude to trick a user to gain
access to resources. access to resources.
6. Look again at how well we're securing infrastructure: Some 7. Look again at how well we're securing infrastructure: Some
attacks (e.g. against DNS or routing infrastructure) appear to attacks (e.g. against DNS or routing infrastructure) appear to
benefit from current infrastructure mechanisms not being benefit from current infrastructure mechanisms not being
deployed, e.g. DNSSEC, RPKI. In the case of DNSSEC, deployment deployed, e.g. DNSSEC, RPKI. In the case of DNSSEC, deployment
is still minimal despite much time having elapsed. This is still minimal despite much time having elapsed. This
suggests a number of different possible avenues for suggests a number of different possible avenues for
investigation: investigation:
* For any protocol dependent on infrastructure like DNS or BGP, * For any protocol dependent on infrastructure like DNS or BGP,
we ought analysse potential outcomes in the event the we ought analyse potential outcomes in the event the relevant
relevant infrastructure has been compromised infrastructure has been compromised
* Protocol designers perhaps ought consider post-facto * Protocol designers perhaps ought consider post-facto
detection compromise mechanisms in the event that it is detection compromise mechanisms in the event that it is
infeasible to mitigate attacks on infrastructure that is not infeasible to mitigate attacks on infrastructure that is not
under local control under local control
* Despite the sunk costs, it may be worth re-considering * Despite the sunk costs, it may be worth re-considering
infrastructure security mechanisms that have not been infrastructure security mechanisms that have not been
deployed, and hence are ineffective. deployed, and hence are ineffective.
7. Trusted Computing: Various trusted computing mechanisms allow 8. Trusted Computing: Various trusted computing mechanisms allow
placing some additional trust on a particular endpoint. This placing some additional trust on a particular endpoint. This
can be useful to address some of the issues in this memo: can be useful to address some of the issues in this memo:
* A network manager of a set of devices may be assured that the * A network manager of a set of devices may be assured that the
devices have not been compromised. devices have not been compromised.
* An outside party may be assured that someone who runs a * An outside party may be assured that someone who runs a
device employs a particular software installation in that device employs a particular software installation in that
device, and that the software runs in a protected device, and that the software runs in a protected
environment. environment.
IETF work such as TEEP [I-D.ietf-teep-architecture] [I-D.ietf- IETF work such as TEEP [I-D.ietf-teep-architecture]
teep-protocol] and RATS [I-D.ietf-rats-eat] may be helpful in [I-D.ietf-teep-protocol] and RATS [I-D.ietf-rats-eat] may be
providing attestations to other nodes about a particular helpful in providing attestations to other nodes about a
endpoint, or lifecycle management of such endpoints. particular endpoint, or lifecycle management of such endpoints.
One should note, however, that it is often not possible to fully One should note, however, that it is often not possible to fully
protect endpoints (see, e.g., [Kocher2019] [Lipp2018] [I- protect endpoints (see, e.g., [Kocher2019] [Lipp2018]
D.taddei-smart-cless-introduction] [I-D.mcfadden-smart-endpoint- [I-D.taddei-smart-cless-introduction]
taxonomy-for-cless]). And of course, a trusted computing may be [I-D.mcfadden-smart-endpoint-taxonomy-for-cless]). And of
set up and controlled by a party that itself is not trusted; a course, a trusted computing may be set up and controlled by a
client that contacts a server that the server's owner runs in a party that itself is not trusted; a client that contacts a
trusted computing setting does not change the fact that the server that the server's owner runs in a trusted computing
client and the server's owner may have different interests. As setting does not change the fact that the client and the
a result, there is a need to prepare for the possibility that server's owner may have different interests. As a result, there
another party in a communication is not entirely trusted. is a need to prepare for the possibility that another party in a
communication is not entirely trusted.
8. Trust Boundaries: Traditional forms of communication equipment 9. Trust Boundaries: Traditional forms of communication equipment
have morphed into today's virtualized environments, where new have morphed into today's virtualized environments, where new
trust boundaries exist, e.g., between different virtualisation trust boundaries exist, e.g., between different virtualisation
layers. And an application might consider itself trusted while layers. And an application might consider itself trusted while
not entirely trusting the underlying operating system. A not entirely trusting the underlying operating system. A
browser application wants to protect itself against Javascript browser application wants to protect itself against Javascript
loaded from a website, while the website considers itself and loaded from a website, while the website considers itself and
the Javascript an application that it wants to protect from the the Javascript an application that it wants to protect from the
browser. In general, there are multiple parties even in a browser. In general, there are multiple parties even in a
single device, with differing interests, including some that single device, with differing interests, including some that
have (or claim to) the interest of the human user in mind. have (or claim to) the interest of the human user in mind.
9. Develop a BCP for privacy considerations: It may be time for the 10. Develop a BCP for privacy considerations: It may be time for the
IETF to develop a BCP for privacy considerations, possibly IETF to develop a BCP for privacy considerations, possibly
starting from [RFC6973]. starting from [RFC6973].
10. Re-consider protocol design "lore": It could be that this 11. Re-consider protocol design "lore": It could be that this
discussion demonstrates that it is timely to reconsider some discussion demonstrates that it is timely to reconsider some
protocol design "lore" as for example is done in [I-D.iab- protocol design "lore" as for example is done in
protocol-maintenance]. More specifically, protocol [I-D.iab-protocol-maintenance]. More specifically, protocol
extensibility mechanisms may inadvertently create vectors for extensibility mechanisms may inadvertently create vectors for
abuse-cases, given that designers cannot fully analyse their abuse-cases, given that designers cannot fully analyse their
impact at the time a new protocol is defined or standardised. impact at the time a new protocol is defined or standardised.
One might conclude that a lack of extensibility could be a One might conclude that a lack of extensibility could be a
virtue for some new protocols, in contrast to earlier virtue for some new protocols, in contrast to earlier
assumptions. As pointed out by one commenter though, people can assumptions. As pointed out by one commenter though, people can
find ways to extend things regardless, if they feel the need. find ways to extend things regardless, if they feel the need.
11. Consider the user perspective: [I-D.nottingham-for-the-users] 12. Consider the user perspective: [I-D.nottingham-for-the-users]
argues that, in relevant cases where there are conflicting argues that, in relevant cases where there are conflicting
requirements, the "IETF considers end users as its highest requirements, the "IETF considers end users as its highest
priority concern." Doing so seems consistent with the expanded priority concern." Doing so seems consistent with the expanded
threat model being argued for here, so may indicate that a BCP threat model being argued for here, so may indicate that a BCP
in that space could also be useful. in that space could also be useful.
12. Have explicit agreements: When users and their devices provide 13. Have explicit agreements: When users and their devices provide
information to network entities, it would be beneficial to have information to network entities, it would be beneficial to have
an opportunity for the users to state their requirements an opportunity for the users to state their requirements
regarding the use of the information provided in this way. regarding the use of the information provided in this way.
While the actual use of such requirements and the willingness of While the actual use of such requirements and the willingness of
network entities to agree to them remains to be seen, at the network entities to agree to them remains to be seen, at the
moment even the technical means of doing this are limited. For moment even the technical means of doing this are limited. For
instance, it would be beneficial to be able to embed usage instance, it would be beneficial to be able to embed usage
requirements within popular data formats. requirements within popular data formats.
As appropriate, users should be made aware of the choices made As appropriate, users should be made aware of the choices made
in a particular design, and avoid designs or products that in a particular design, and avoid designs or products that
protect against some threats but are wide open to other serious protect against some threats but are wide open to other serious
issues. (SF doesn't know what that last bit means;-) issues. (SF doesn't know what that last bit means;-)
13. Perform end-to-end protection via other parties: Information 14. Perform end-to-end protection via other parties: Information
passed via another party who does not intrinsically need the passed via another party who does not intrinsically need the
information to perform its function should be protected end-to- information to perform its function should be protected end-to-
end to its intended recipient. This guideline is general, and end to its intended recipient. This guideline is general, and
holds equally for sending TCP/IP packets, TLS connections, or holds equally for sending TCP/IP packets, TLS connections, or
application-layer interactions. As [RFC8546] notes, it is a application-layer interactions. As [RFC8546] notes, it is a
useful design rule to avoid "accidental invariance" (the useful design rule to avoid "accidental invariance" (the
deployment of on-path devices that over-time start to make deployment of on-path devices that over-time start to make
assumptions about protocols). However, it is also a necessary assumptions about protocols). However, it is also a necessary
security design rule to avoid "accidental disclosure" where security design rule to avoid "accidental disclosure" where
information originally thought to be benign and untapped over- information originally thought to be benign and untapped over-
skipping to change at line 1121 skipping to change at page 26, line 41
leakage. Designers should balance the benefits of centralized leakage. Designers should balance the benefits of centralized
resources or control points against the threats arising. If it resources or control points against the threats arising. If it
is not possible to avoid, find a way to allow the centralized is not possible to avoid, find a way to allow the centralized
resources to be selectable, depending on context and user resources to be selectable, depending on context and user
settings. settings.
7. Treat parties with which your protocol endpoints interact with 7. Treat parties with which your protocol endpoints interact with
suspicion, even if the communications are encrypted. Other suspicion, even if the communications are encrypted. Other
endpoints may misuse any information or control opportunity in endpoints may misuse any information or control opportunity in
the communication. Similarly, even endpoints within your own the communication. Similarly, even endpoints within your own
system need to be treated with suspicision, as some may become system need to be treated with suspicion, as some may become
compromised. compromised.
8. Consider abuse-cases. Protocol developers are typically most 8. Consider abuse-cases. Protocol developers are typically most
interested in a few specific use-cases for which they need interested in a few specific use-cases for which they need
solutions. Expanding the threat model to consider adversarial solutions. Expanding the threat model to consider adversarial
behaviours [AbuseCases] calls for significant attention to be behaviours [AbuseCases] calls for significant attention to be
paid to potential abuses of whatever new or re-purposed paid to potential abuses of whatever new or re-purposed
technology is being considered. technology is being considered.
9. Consider recovery from compromse or attack during protocol 9. Consider recovery from compromse or attack during protocol
skipping to change at line 1147 skipping to change at page 27, line 21
compromise security" as an inherent part of the design of that compromise security" as an inherent part of the design of that
protocol. protocol.
10. Consider linkability. As discussed in [RFC6973] the ability to 10. Consider linkability. As discussed in [RFC6973] the ability to
link or correlate different protocol messages with one another, link or correlate different protocol messages with one another,
or with external sources of information (e.g. public or private or with external sources of information (e.g. public or private
databases) can create privacy or security issues. As an databases) can create privacy or security issues. As an
example, re-use of TLS session tickets can enable an observer to example, re-use of TLS session tickets can enable an observer to
associate multiple TLS sessions regardless of changes in source associate multiple TLS sessions regardless of changes in source
or destination addressing, which may reduce privacy or help a or destination addressing, which may reduce privacy or help a
bad actor in targetting an attack. The same effects may result bad actor in targeting an attack. The same effects may result
regardless of how protocol exchanges can be linked to one regardless of how protocol exchanges can be linked to one
another. Protocol designs that aim to prevent such linkage may another. Protocol designs that aim to prevent such linkage may
produce have fewer unexpected or unwanted side-effects when produce have fewer unexpected or unwanted side-effects when
deployed. deployed.
But when applying these guidelines, don't take this as blanket reason But when applying these guidelines, don't take this as blanket reason
to provide no information to anyone, or (impractically) insist on to provide no information to anyone, or (impractically) insist on
encrypting everything, or other extreme measures. Designers need to encrypting everything, or other extreme measures. Designers need to
be aware of the different threats facing their system, and deal with be aware of the different threats facing their system, and deal with
the most serious ones (of which there are typically many) within the most serious ones (of which there are typically many) within
their applicable resource constraints. their applicable resource constraints.
6. Potential changes in BCP 72/RFC 3552 6. Potential changes in BCP 72/RFC 3552
BCP 72/RFC 3553 [RFC3552] defines an "Internet Threat Model" and BCP 72/RFC 3553 [RFC3552] defines an "Internet Threat Model" and
provides guidance on writing Security Considerations sections in provides guidance on writing Security Considerations sections in
other RFCs. It is important to note that BCP 72 is (or should be:-) other RFCs.
used by all IETF participants when developing protocols. Potential
changes to RFC 3552 therefore need to be brief - IETF participants
cannot in general be expected to devote huge amounts of time to
developing their security considerations text. Potential changes
also need to be easily understood as IETF participants from all
backgrounds need to be able to use BCP 72. In this section we
provide a couple of initial suggested changes to BCP 72 that will
need to be further developed as part of this work. (For example, it
may be possible to include some of the guidelines from Section 5 as
those are further developed.)
As evidenced in the OAuth quote in Section 4 - it can be useful to [RFC3552] also provided a description of classic issues for the
conside the effect of compromised endpoints on those that are not development of communications security protocols. However, in the
compromised. It may therefore be interesting to consider the nearly 20 years since the publication of RFC 3552, the practice of
consequeneces that would follow from a change to [RFC3552] that protocol design has moved on to a fair extent.
recognises how the landscape has changed since 2003.
It is important to note that BCP 72 is (or should be:-) used by all
IETF participants when developing protocols. Potential changes to
RFC 3552 therefore need to be brief - IETF participants cannot in
general be expected to devote huge amounts of time to developing
their security considerations text. Potential changes also need to
be easily understood as IETF participants from all backgrounds need
to be able to use BCP 72.
In this section we provide a few initial suggested changes to BCP 72
that will need to be further developed as part of this work. (For
example, it may be possible to include some of the guidelines from
Section 5 as those are further developed.)
There are a range of possible updates. We could propose adding a
simple observation (Section 6.1), or additionally propose further
discussion about endpoint compromises and the need for system-level
security analysis (Section 6.2).
Another possibility would be to add more guidance covering areas of
concern, and recommendations of broadly-applicable techniques to use.
One suggestion (due to others) for such material is provided in
Section 6.3.
The authors of this memo believe that any updates to RFC 3552 should
be relatively high-level and short. Additional documents may be
needed to provide further detail.
6.1. Simple change
This is the simple addition we are suggesting. As evidenced in the
OAuth quote in Section 4 - it can be useful to consider the effect of
compromised endpoints on those that are not compromised. It may
therefore be interesting to consider the consequences that would
follow from a change to [RFC3552] that recognises how the landscape
has changed since 2003.
One initial, draft proposal for such a change could be: One initial, draft proposal for such a change could be:
OLD: OLD:
In general, we assume that the end-systems engaging in a protocol In general, we assume that the end-systems engaging in a protocol
exchange have not themselves been compromised. Protecting against exchange have not themselves been compromised. Protecting against
an attack when one of the end-systems has been compromised is an attack when one of the end-systems has been compromised is
extraordinarily difficult. It is, however, possible to design extraordinarily difficult. It is, however, possible to design
protocols which minimize the extent of the damage done under these protocols which minimize the extent of the damage done under these
skipping to change at line 1203 skipping to change at page 29, line 5
NEW: NEW:
In general, we assume that the end-system engaging in a protocol In general, we assume that the end-system engaging in a protocol
exchange has not itself been compromised. Protecting against an exchange has not itself been compromised. Protecting against an
attack of a protocol implementation itself is extraordinarily attack of a protocol implementation itself is extraordinarily
difficult. It is, however, possible to design protocols which difficult. It is, however, possible to design protocols which
minimize the extent of the damage done when the other parties in a minimize the extent of the damage done when the other parties in a
protocol become compromised or do not act in the best interests protocol become compromised or do not act in the best interests
the end-system implementing a protocol. the end-system implementing a protocol.
In addition, the following new section could be added to discuss the 6.2. Additional discussion of compromises
capabilities required to mount an attack:
The following new section could be added to discuss the capabilities
required to mount an attack:
NEW: NEW:
3.x. Other endpoint compromise 3.x. Other endpoint compromise
In this attack, the other endpoints in the protocol become In this attack, the other endpoints in the protocol become
compromised. As a result, they can, for instance, misuse any compromised. As a result, they can, for instance, misuse any
information that the end-system implementing a protocol has sent information that the end-system implementing a protocol has sent
to the compromised endpoint. to the compromised endpoint.
skipping to change at line 1226 skipping to change at page 29, line 30
from Internet technology developers and standards organizations. from Internet technology developers and standards organizations.
Here is one possible addition: Here is one possible addition:
NEW: NEW:
The design of any Internet technology should start from an The design of any Internet technology should start from an
understanding of the participants in a system, their roles, and understanding of the participants in a system, their roles, and
the extent to which they should have access to information and the extent to which they should have access to information and
ability to control other participants. ability to control other participants.
6.3. Guidance with regards to communications security
The following discusses some of the aspects that should be considered
when designing a communications security protocol that are not
covered in detail in RFC 3552.
6.3.1. Limiting time scope of compromise
[RFC3552] Section 3 says:
The Internet environment has a fairly well understood threat
model. In general, we assume that the end-systems engaging in a
protocol exchange have not themselves been compromised.
Protecting against an attack when one of the end-systems has been
compromised is extraordinarily difficult. It is, however,
possible to design protocols which minimize the extent of the
damage done under these circumstances.
Although this text is technically correct, modern protocol designs
such as TLS 1.3 and MLS often try to provide a fair amount of defense
against various kinds of temporary compromise. Specifically:
NEW:
Forward Security: Many protocols are designed so that compromise
of an endpoint at time T does not lead to compromise of data
transmitted prior to some time T' < T. For instance, if a
protocol is based on Diffie-Hellman key establishment, then
compromise of the long-term keys does not lead to compromise of
traffic sent prior to compromise if the DH ephemerals and traffic
keys have been deleted.
Post-Compromise Security: Conversely, if an endpoint is
compromised at time T, it is often desirable to have the protocol
"self-heal" so that a purely passive adversary cannot access
traffic after a certain time T' > T. MLS, for instance, is
designed with this property.
Containing Partial Authentication Key Compromise: If an endpoint
is stolen and its authentication secret is stolen, then an
attacker can impersonate that endpoint. However, there a number
of scenarios in which an attacker can obtain use of an
authentication key but not the secret itself (see, for instance
[Jager2015]). It is often desirable to limit the impact of such
compromises (for instance, by avoiding unlimited delegation from
such keys).
Short-lived keys: Typical TLS certificates last for months or
years. There is a trend towards shorter certificate lifetimes so
as to minimize risk of exposure in the event of key compromise.
Relatedly, delegated credentials are short-lived keys the
certificate's owner has delegated for use in TLS. These help
reduce private key lifetimes without compromising or sacrificing
reliability.
6.3.2. Forcing active attack
[RFC3552] Section 3.2 notes that it is important to consider passive
attacks. This is still valid, but needs further elaboration:
NEW:
In general, it is much harder to mount an active attack, both in
terms of the capabilities required and the chance of being
detected. A theme in recent IETF protocols design is to build
systems which might have limited defense against active attackers
but are strong against passive attackers, thus forcing the
attacker to go active.
Examples include DTLS-SRTP and the trend towards opportunistic
security. However, ideally protocols are built with strong defenses
against active attackers. One prominent example is QUIC, which takes
steps to ensure that off-path connection resets are intractable in
practice.
6.3.3. Traffic analysis
[RFC3552] Section 3.2.1 describes how the absence of TLS or other
transport-layer encryption may lead to obvious confidentiality
violations against passive attackers. This too is still valid, but
does not take into account additional aspects:
NEW:
However, recent trends in traffic analysis indicate encryption
alone may be insufficient protection for some types of application
data [I-D.wood-pearg-website-fingerprinting]. Encrypted traffic
metadata, especially message size, can leak information about the
underlying plaintext. DNS queries and responses are particularly
at risk given their size distributions. Recent protocols account
for this leakage by supporting padding.
Some examples of recent work in this area include support for padding
either generically in the transport protocol (QUIC
[I-D.ietf-quic-transport] and TLS [RFC8446]), or specifically in the
application protocol (EDNS(0) padding option for DNS messages
[RFC7830]).
6.3.4. Containing compromise of trust points
Many protocols are designed to depend on trusted third parties (the
WebPKI is perhaps the canonical example); if those trust points
misbehave, the security of the protocol can be completely
compromised.
Some additional guidance in RFC 3552 might be needed to remind
protocol readers of this.
NEW:
A number of recent protocols have attempted to reduce the power of
trust points that the protocol or application depends on. For
instance, Certificate Transparency attempts to ensure that a CA
cannot issue valid certificates without publishing them, allowing
third parties to detect certain classes of misbehavior by those
CA. Similarly, Key Transparency attempts to ensure that (public)
keys associated with a given entity are publicly visible and
auditable in tamper-proof logs. This allows users of these keys
to check them for correctness.
In the realm of software, Reproducible Builds and Binary Transparency
are intended to allow a user to determine that they have received a
valid copy of the binary that matches the auditable source code.
Blockchain protocols such as Bitcoin and Ethereum also employ this
principle of transparency and are intended to detect misbehavior by
members of the network.
7. Potential Changes in BCP 188/RFC 7258 7. Potential Changes in BCP 188/RFC 7258
Other additional guidelines may be necessary also in BCP 188/RFC Other additional guidelines may be necessary also in BCP 188/RFC
7258[RFC7258], which specifies how IETF work should take into account 7258[RFC7258], which specifies how IETF work should take into account
pervasive monitoring. pervasive monitoring.
An initial, draft suggestion for starting point of those changes An initial, draft suggestion for starting point of those changes
could be adding the following paragraph after the 2nd paragraph in could be adding the following paragraph after the 2nd paragraph in
Section 2: Section 2:
NEW: NEW:
PM attacks include those cases where information collected by a PM attacks include those cases where information collected by a
legitimate protocol participant is misused for PM purposes. The legitimate protocol participant is misused for PM purposes. The
attacks also include those cases where a protocol or network attacks also include those cases where a protocol or network
architecture results in centralized data storage or control architecture results in centralized data storage or control
functions relating to many users, raising the risk of said misuse. functions relating to many users, raising the risk of said misuse.
8. Conclusions 8. Conclusions
At this stage we don't think it approriate to claim that any strong At this stage we don't think it appropriate to claim that any strong
conclusion can be reached based on the above. We do however, claim conclusion can be reached based on the above. We do however, claim
that the is a topic that could be worth discussion and more work. that the is a topic that could be worth discussion and more work.
To start with, Internet technology developers need to be better aware To start with, Internet technology developers need to be better aware
of the issues beyond communications security, and consider them in of the issues beyond communications security, and consider them in
design. At the IETF it would be beneficial to include some of these design. At the IETF it would be beneficial to include some of these
considerations in the usual systematic security analysis of considerations in the usual systematic security analysis of
technologies under development. technologies under development.
In particular, when the IETF develops infrastructure technology for In particular, when the IETF develops infrastructure technology for
skipping to change at line 1298 skipping to change at page 33, line 35
9. Informative References 9. Informative References
[AbuseCases] [AbuseCases]
McDermott, J. and C. Fox, "Using abuse case models for McDermott, J. and C. Fox, "Using abuse case models for
security requirements analysis", IEEE Annual Computer security requirements analysis", IEEE Annual Computer
Security Applications Conference (ACSAC'99), Security Applications Conference (ACSAC'99),
https://www.acsac.org/1999/papers/wed-b-1030-john.pdf , https://www.acsac.org/1999/papers/wed-b-1030-john.pdf ,
1999. 1999.
[Attitude] "User Perceptions of Sharing, Advertising, and Tracking", [AmIUnique]
INRIA, ., "Am I Unique?", https://amiunique.org , 2020.
[Attitude]
"User Perceptions of Sharing, Advertising, and Tracking",
Symposium on Usable Privacy and Security (SOUPS), Symposium on Usable Privacy and Security (SOUPS),
https://www.usenix.org/conference/soups2015/proceedings/ https://www.usenix.org/conference/soups2015/proceedings/
presentation/chanchary , 2015. presentation/chanchary , 2015.
[avleak] Cox, J., "Leaked Documents Expose the Secretive Market for [avleak] Cox, J., "Leaked Documents Expose the Secretive Market for
Your Web Browsing Data", Your Web Browsing Data",
https://www.vice.com/en_us/article/qjdkq7/ https://www.vice.com/en_us/article/qjdkq7/
avast-antivirus-sells-user-browsing-data-investigation , avast-antivirus-sells-user-browsing-data-investigation ,
February 2020. 2020.
[BgpHijack]Sermpezis, P., Kotronis, V., Dainotti, A., and X. [BgpHijack]
Sermpezis, P., Kotronis, V., Dainotti, A., and X.
Dimitropoulos, "A survey among network operators on BGP Dimitropoulos, "A survey among network operators on BGP
prefix hijacking", ACM SIGCOMM Computer Communication prefix hijacking", ACM SIGCOMM Computer Communication
Review 48, no. 1 (2018): 64-69, Review 48, no. 1 (2018): 64-69,
https://arxiv.org/pdf/1801.02918.pdf , 2018. https://arxiv.org/pdf/1801.02918.pdf , 2018.
[Bloatware]Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and [Bloatware]
Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and
N. Vallina, "An Analysis of Pre-installed Android N. Vallina, "An Analysis of Pre-installed Android
Software", arXiv preprint arXiv:1905.02713 (2019) , 2019. Software", arXiv preprint arXiv:1905.02713 (2019) , 2019.
[Cambridge]Isaak, J. and M. Hanna, "User Data Privacy: Facebook, [Boix2018]
Gomez-Boix, A., Laperdrix, P., and B. Baudry, "Hiding in
the crowd: an analysis of the effectiveness of browser
fingerprinting at large scale", Proceedings of the 2018
world wide web conference , 2018.
[Cambridge]
Isaak, J. and M. Hanna, "User Data Privacy: Facebook,
Cambridge Analytica, and Privacy Protection", Computer Cambridge Analytica, and Privacy Protection", Computer
51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/ 51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/
stamp.jsp?arnumber=8436400 , 2018. stamp.jsp?arnumber=8436400 , 2018.
[CommandAndControl] [CommandAndControl]
Botnet, ., "Creating botnet C&C server. What architecture Botnet, ., "Creating botnet C&C server. What architecture
should I use? IRC? HTTP?", Stackexchange.com question, should I use? IRC? HTTP?", Stackexchange.com question,
https://security.stackexchange.com/questions/100577/ https://security.stackexchange.com/questions/100577/
creating-botnet-cc-server-what-architecture-should-i-use- creating-botnet-cc-server-what-architecture-should-i-use-
irc-http , 2014. irc-http , 2014.
[Curated] Hammad, M., Garcia, J., and S. MaleK, "A large-scale [Curated] Hammad, M., Garcia, J., and S. MaleK, "A large-scale
empirical study on the effects of code obfuscations on empirical study on the effects of code obfuscations on
Android apps and anti-malware products", ACM International Android apps and anti-malware products", ACM International
Conference on Software Engineering 2018, Conference on Software Engineering 2018,
https://www.ics.uci.edu/~seal/ https://www.ics.uci.edu/~seal/
publications/2018ICSE_Hammad.pdf , 2018. publications/2018ICSE_Hammad.pdf , 2018.
[DeepDive] Krebs on Security, ., "A Deep Dive on the Recent [DeepDive]
Krebs on Security, ., "A Deep Dive on the Recent
Widespread DNS Hijacking Attacks", krebsonsecurity.com Widespread DNS Hijacking Attacks", krebsonsecurity.com
blog, https://krebsonsecurity.com/2019/02/a-deep-dive-on- blog, https://krebsonsecurity.com/2019/02/a-deep-dive-on-
the-recent-widespread-dns-hijacking-attacks/ , 2019. the-recent-widespread-dns-hijacking-attacks/ , 2019.
[DoubleKey]
Witte, D., "Thirdparty",
https://wiki.mozilla.org/Thirdparty , June 2010.
[DynDDoS] York, K., "Dyn's Statement on the 10/21/2016 DNS DDoS [DynDDoS] York, K., "Dyn's Statement on the 10/21/2016 DNS DDoS
Attack", Company statement: https://dyn.com/blog/ Attack", Company statement: https://dyn.com/blog/
dyn-statement-on-10212016-ddos-attack/ , 2016. dyn-statement-on-10212016-ddos-attack/ , 2016.
[GDPRAccess] [GDPRAccess]
EU, ., "Right of access by the data subject", Article 15, EU, ., "Right of access by the data subject", Article 15,
GDPR, https://gdpr-info.eu/art-15-gdpr/ , February 2020. GDPR, https://gdpr-info.eu/art-15-gdpr/ , n.d..
[HijackDet]Schlamp, J., Holz, R., Gasser, O., Korste, A., Jacquemart, [HijackDet]
Schlamp, J., Holz, R., Gasser, O., Korste, A., Jacquemart,
Q., Carle, G., and E. Biersack, "Investigating the nature Q., Carle, G., and E. Biersack, "Investigating the nature
of routing anomalies: Closing in on subprefix hijacking of routing anomalies: Closing in on subprefix hijacking
attacks", International Workshop on Traffic Monitoring and attacks", International Workshop on Traffic Monitoring and
Analysis, pp. 173-187. Springer, Cham, Analysis, pp. 173-187. Springer, Cham,
https://www.net.in.tum.de/fileadmin/bibtex/publications/ https://www.net.in.tum.de/fileadmin/bibtex/publications/
papers/schlamp_TMA_1_2015.pdf , 2015. papers/schlamp_TMA_1_2015.pdf , 2015.
[Home] Nthala, N. and I. Flechais, "Rethinking home network [Home] Nthala, N. and I. Flechais, "Rethinking home network
security", European Workshop on Usable Security security", European Workshop on Usable Security
(EuroUSEC), https://ora.ox.ac.uk/objects/ (EuroUSEC), https://ora.ox.ac.uk/objects/
uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa
fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica
tion%2Fpdf&type_of_work=Conference+item , 2018. tion%2Fpdf&type_of_work=Conference+item , 2018.
[I-D.arkko-arch-dedr-report] [I-D.arkko-arch-dedr-report]
Arkko, J. and T. Hardie, "Report from the IAB workshop on Arkko, J. and T. Hardie, "Report from the IAB workshop on
Design Expectations vs. Deployment Reality in Protocol Design Expectations vs. Deployment Reality in Protocol
Development", draft-arkko-arch-dedr-report-00 (work in Development", draft-arkko-arch-dedr-report-00 (work in
progress), 4 November 2019, progress), November 2019.
<http://www.ietf.org/internet-drafts/draft-arkko-arch-
dedr-report-00.txt>.
[I-D.arkko-arch-infrastructure-centralisation] [I-D.arkko-arch-infrastructure-centralisation]
Arkko, J., "Centralised Architectures in Internet Arkko, J., "Centralised Architectures in Internet
Infrastructure", draft-arkko-arch-infrastructure- Infrastructure", draft-arkko-arch-infrastructure-
centralisation-00 (work in progress), 4 November 2019, centralisation-00 (work in progress), November 2019.
<http://www.ietf.org/internet-drafts/draft-arkko-arch-
infrastructure-centralisation-00.txt>.
[I-D.arkko-arch-internet-threat-model] [I-D.arkko-arch-internet-threat-model]
Arkko, J., "Changes in the Internet Threat Model", draft- Arkko, J., "Changes in the Internet Threat Model", draft-
arkko-arch-internet-threat-model-01 (work in progress), 8 arkko-arch-internet-threat-model-01 (work in progress),
July 2019, July 2019.
<http://www.ietf.org/internet-drafts/draft-arkko-arch-
internet-threat-model-01.txt>.
[I-D.farrell-etm] [I-D.farrell-etm]
Farrell, S., "We're gonna need a bigger threat model", Farrell, S., "We're gonna need a bigger threat model",
draft-farrell-etm-03 (work in progress), 6 July 2019, draft-farrell-etm-03 (work in progress), July 2019.
<http://www.ietf.org/internet-drafts/draft-farrell-etm-
03.txt>.
[I-D.iab-protocol-maintenance] [I-D.iab-protocol-maintenance]
Thomson, M., "The Harmful Consequences of the Robustness Thomson, M., "The Harmful Consequences of the Robustness
Principle", draft-iab-protocol-maintenance-04 (work in Principle", draft-iab-protocol-maintenance-04 (work in
progress), 3 November 2019, progress), November 2019.
<http://www.ietf.org/internet-drafts/draft-iab-protocol-
maintenance-04.txt>.
[I-D.ietf-httpbis-expect-ct] [I-D.ietf-httpbis-expect-ct]
estark@google.com, e., "Expect-CT Extension for HTTP", estark@google.com, e., "Expect-CT Extension for HTTP",
draft-ietf-httpbis-expect-ct-08 (work in progress), 9 draft-ietf-httpbis-expect-ct-08 (work in progress),
December 2018, December 2018.
<http://www.ietf.org/internet-drafts/draft-ietf-httpbis-
expect-ct-08.txt>.
[I-D.ietf-mls-architecture] [I-D.ietf-mls-architecture]
Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon, Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon,
A., and A. Duric, "The Messaging Layer Security (MLS) A., and A. Duric, "The Messaging Layer Security (MLS)
Architecture", draft-ietf-mls-architecture-04 (work in Architecture", draft-ietf-mls-architecture-04 (work in
progress), 26 January 2020, progress), January 2020.
<http://www.ietf.org/internet-drafts/draft-ietf-mls-
architecture-04.txt>.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-25 (work and Secure Transport", draft-ietf-quic-transport-27 (work
in progress), 21 January 2020, in progress), February 2020.
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-25.txt>.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J. Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft- O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-02 (work in progress), 9 January 2020, ietf-rats-eat-03 (work in progress), February 2020.
<http://www.ietf.org/internet-drafts/draft-ietf-rats-eat-
02.txt>.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-05 (work in Architecture", draft-ietf-teep-architecture-07 (work in
progress), 12 December 2019, progress), March 2020.
<http://www.ietf.org/internet-drafts/draft-ietf-teep-
architecture-05.txt>.
[I-D.ietf-teep-protocol] [I-D.ietf-teep-protocol]
Tschofenig, H., Pei, M., Wheeler, D., and D. Thaler, Tschofenig, H., Pei, M., Wheeler, D., and D. Thaler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Protocol", draft-ietf-teep-protocol-00 (work in progress), Protocol", draft-ietf-teep-protocol-00 (work in progress),
12 December 2019, December 2019.
<http://www.ietf.org/internet-drafts/draft-ietf-teep-
protocol-00.txt>.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft- "Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-05 (work in progress), 4 November 2019, ietf-tls-esni-05 (work in progress), November 2019.
<http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-
05.txt>.
[I-D.ietf-tls-grease] [I-D.ietf-tls-grease]
Benjamin, D., "Applying GREASE to TLS Extensibility", Benjamin, D., "Applying GREASE to TLS Extensibility",
draft-ietf-tls-grease-04 (work in progress), 22 August draft-ietf-tls-grease-04 (work in progress), August 2019.
2019, <http://www.ietf.org/internet-drafts/draft-ietf-tls-
grease-04.txt>.
[I-D.lazanski-smart-users-internet] [I-D.lazanski-smart-users-internet]
Lazanski, D., "An Internet for Users Again", draft- Lazanski, D., "An Internet for Users Again", draft-
lazanski-smart-users-internet-00 (work in progress), 8 lazanski-smart-users-internet-00 (work in progress), July
July 2019, 2019.
<http://www.ietf.org/internet-drafts/draft-lazanski-smart-
users-internet-00.txt>.
[I-D.mcfadden-smart-endpoint-taxonomy-for-cless] [I-D.mcfadden-smart-endpoint-taxonomy-for-cless]
McFadden, M., "Endpoint Taxonomy for CLESS", draft- McFadden, M., "Endpoint Taxonomy for CLESS", draft-
mcfadden-smart-endpoint-taxonomy-for-cless-01 (work in mcfadden-smart-endpoint-taxonomy-for-cless-01 (work in
progress), 5 February 2020, progress), February 2020.
<http://www.ietf.org/internet-drafts/draft-mcfadden-smart-
endpoint-taxonomy-for-cless-01.txt>.
[I-D.nottingham-for-the-users] [I-D.nottingham-for-the-users]
Nottingham, M., "The Internet is for End Users", draft- Nottingham, M., "The Internet is for End Users", draft-
nottingham-for-the-users-09 (work in progress), 22 July nottingham-for-the-users-09 (work in progress), July 2019.
2019,
<http://www.ietf.org/internet-drafts/draft-nottingham-for-
the-users-09.txt>.
[I-D.taddei-smart-cless-introduction] [I-D.taddei-smart-cless-introduction]
Taddei, A., Wueest, C., Roundy, K., and D. Lazanski, Taddei, A., Wueest, C., Roundy, K., and D. Lazanski,
"Capabilities and Limitations of an Endpoint-only Security "Capabilities and Limitations of an Endpoint-only Security
Solution", draft-taddei-smart-cless-introduction-02 (work Solution", draft-taddei-smart-cless-introduction-02 (work
in progress), 9 January 2020, in progress), January 2020.
<http://www.ietf.org/internet-drafts/draft-taddei-smart-
cless-introduction-02.txt>. [I-D.wood-pearg-website-fingerprinting]
Goldberg, I., Wang, T., and C. Wood, "Network-Based
Website Fingerprinting", draft-wood-pearg-website-
fingerprinting-00 (work in progress), November 2019.
[Jager2015]
Jager, T., Schwenk, J., and J. Somorovsky, "On the
Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1
v1.5 Encryption", Proceedings of ACM CCS 2015, DOI
10.1145/2810103.2813657, https://www.nds.rub.de/media/nds/
veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf ,
October 2015.
[Kocher2019] [Kocher2019]
Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D., Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D.,
Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher, Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher,
T., Schwarz, M., and Y. Yarom, "Spectre Attacks: T., Schwarz, M., and Y. Yarom, "Spectre Attacks:
Exploiting Speculative Execution", 40th IEEE Symposium on Exploiting Speculative Execution", 40th IEEE Symposium on
Security and Privacy (S&P'19) , 2019. Security and Privacy (S&P'19) , 2019.
[LeakyBuckets] [LeakyBuckets]
Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3 Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3
Breaches", Bitdefender blog, Breaches", Bitdefender blog,
https://businessinsights.bitdefender.com/ https://businessinsights.bitdefender.com/
worst-amazon-breaches , 2018. worst-amazon-breaches , 2018.
[Lipp2018] Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W., [Leith2020]
Leith, D., "Web Browser Privacy: What Do Browsers Say When
They Phone Home?", In submission,
https://www.scss.tcd.ie/Doug.Leith/pubs/
browser_privacy.pdf , March 2020.
[Lipp2018]
Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W.,
Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D., Fogh, A., Horn, J., Mangard, S., Kocher, P., Genkin, D.,
Yarom, Y., and M. Hamburg, "Meltdown: Reading Kernel Yarom, Y., and M. Hamburg, "Meltdown: Reading Kernel
Memory from User Space", 27th USENIX Security Symposium Memory from User Space", 27th USENIX Security Symposium
(USENIX Security 18) , 2018. (USENIX Security 18) , 2018.
[Mailbug] Englehardt, S., Han, J., and A. Narayanan, "I never signed [Mailbug] Englehardt, S., Han, J., and A. Narayanan, "I never signed
up for this! Privacy implications of email tracking", up for this! Privacy implications of email tracking",
Proceedings on Privacy Enhancing Technologies 2018.1 Proceedings on Privacy Enhancing Technologies 2018.1
(2018): 109-126, https://www.degruyter.com/downloadpdf/j/ (2018): 109-126, https://www.degruyter.com/downloadpdf/j/
popets.2018.2018.issue-1/popets-2018-0006/ popets.2018.2018.issue-1/popets-2018-0006/
popets-2018-0006.pdf , 2018. popets-2018-0006.pdf , 2018.
[MeltdownAndSpectre] [MeltdownAndSpectre]
CISA, ., "Meltdown and Spectre Side-Channel Vulnerability CISA, ., "Meltdown and Spectre Side-Channel Vulnerability
Guidance", Alert (TA18-004A), Guidance", Alert (TA18-004A),
https://www.us-cert.gov/ncas/alerts/TA18-004A , 2018. https://www.us-cert.gov/ncas/alerts/TA18-004A , 2018.
[Passwords]com, haveibeenpwned., "Pwned Passwords", Website [Mozilla2019]
Camp, D., "Firefox Now Available with Enhanced Tracking
Protection by Default Plus Updates to Facebook Container,
Firefox Monitor and Lockwise", The Mozilla Blog,
https://blog.mozilla.org/blog/2019/06/04/firefox-now-
available-with-enhanced-tracking-protection-by-default/ ,
June 2019.
[Passwords]
com, haveibeenpwned., "Pwned Passwords", Website
https://haveibeenpwned.com/Passwords , 2019. https://haveibeenpwned.com/Passwords , 2019.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
<https://www.rfc-editor.org/info/rfc1958>. <https://www.rfc-editor.org/info/rfc1958>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", [RFC3935] Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
<https://www.rfc-editor.org/info/rfc3935>. <https://www.rfc-editor.org/info/rfc3935>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Computation Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<https://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
skipping to change at line 1572 skipping to change at page 39, line 41
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/info/rfc6962>. <https://www.rfc-editor.org/info/rfc6962>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <https://www.rfc-editor.org/info/rfc7469>. 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
Server Identity Check Procedure for Email-Related Server Identity Check Procedure for Email-Related
Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
<https://www.rfc-editor.org/info/rfc7817>. <https://www.rfc-editor.org/info/rfc7817>.
[RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830,
DOI 10.17487/RFC7830, May 2016,
<https://www.rfc-editor.org/info/rfc7830>.
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
of Things Software Update (IoTSU) Workshop 2016", of Things Software Update (IoTSU) Workshop 2016",
RFC 8240, DOI 10.17487/RFC8240, September 2017, RFC 8240, DOI 10.17487/RFC8240, September 2017,
<https://www.rfc-editor.org/info/rfc8240>. <https://www.rfc-editor.org/info/rfc8240>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
skipping to change at line 1612 skipping to change at page 40, line 41
[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a [RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a
Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
2019, <https://www.rfc-editor.org/info/rfc8546>. 2019, <https://www.rfc-editor.org/info/rfc8546>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
[Saltzer] Saltzer, J.H., Reed, D.P., and D.D. Clark, "End-To-End [Saltzer] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments
Arguments in System Design", ACM TOCS, Vol 2, Number 4, pp in System Design", ACM TOCS, Vol 2, Number 4, pp 277-288 ,
277-288 , November 1984. November 1984.
[Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes, [Savage] Savage, S., "Modern Automotive Vulnerabilities: Causes,
Disclosures, and Outcomes", USENIX , 2016. Disclosures, and Outcomes", USENIX , 2016.
[SmartTV] Malkin, N., Bernd, J., Johnson, M., and S. Egelman, "What [SmartTV] Malkin, N., Bernd, J., Johnson, M., and S. Egelman, "What
Can't Data Be Used For? Privacy Expectations about Smart Can't Data Be Used For? Privacy Expectations about Smart
TVs in the U.S.", European Workshop on Usable Security TVs in the U.S.", European Workshop on Usable Security
(Euro USEC), https://www.ndss-symposium.org/wp- (Euro USEC), https://www.ndss-symposium.org/wp-
content/uploads/2018/06/ content/uploads/2018/06/
eurousec2018_16_Malkin_paper.pdf" , 2018. eurousec2018_16_Malkin_paper.pdf" , 2018.
[StackEvo] Trammell, B., Thomson, M., Howard, L., and T. Hardie, [StackEvo]
Trammell, B., Thomson, M., Howard, L., and T. Hardie,
"What Is an Endpoint?", Unpublished work, "What Is an Endpoint?", Unpublished work,
https://github.com/stackevo/endpoint-draft/blob/master/ https://github.com/stackevo/endpoint-draft/blob/master/
draft-trammell-whats-an-endpoint.md , 2017. draft-trammell-whats-an-endpoint.md , 2017.
[Sybil] Viswanath, B., Post, A., Gummadi, K., and A. Mislove, "An [Sybil] Viswanath, B., Post, A., Gummadi, K., and A. Mislove, "An
analysis of social network-based sybil defenses", ACM analysis of social network-based sybil defenses", ACM
SIGCOMM Computer Communication Review 41(4), 363-374, SIGCOMM Computer Communication Review 41(4), 363-374,
https://conferences.sigcomm.org/sigcomm/2010/papers/ https://conferences.sigcomm.org/sigcomm/2010/papers/
sigcomm/p363.pdf , 2011. sigcomm/p363.pdf , 2011.
skipping to change at line 1648 skipping to change at page 41, line 35
Osborne, C., "How hackers stole millions of credit card Osborne, C., "How hackers stole millions of credit card
records from Target", ZDNET, records from Target", ZDNET,
https://www.zdnet.com/article/how-hackers-stole-millions- https://www.zdnet.com/article/how-hackers-stole-millions-
of-credit-card-records-from-target/ , 2014. of-credit-card-records-from-target/ , 2014.
[Toys] Chu, G., Apthorpe, N., and N. Feamster, "Security and [Toys] Chu, G., Apthorpe, N., and N. Feamster, "Security and
Privacy Analyses of Internet of Things Childrens' Toys", Privacy Analyses of Internet of Things Childrens' Toys",
IEEE Internet of Things Journal 6.1 (2019): 978-985, IEEE Internet of Things Journal 6.1 (2019): 978-985,
https://arxiv.org/pdf/1805.02751.pdf , 2019. https://arxiv.org/pdf/1805.02751.pdf , 2019.
[Tracking] Ermakova, T., Fabian, B., Bender, B., and K. Klimek, "Web [Tracking]
Ermakova, T., Fabian, B., Bender, B., and K. Klimek, "Web
Tracking-A Literature Review on the State of Research", Tracking-A Literature Review on the State of Research",
Proceedings of the 51st Hawaii International Conference on Proceedings of the 51st Hawaii International Conference on
System Sciences, https://scholarspace.manoa.hawaii.edu/ System Sciences, https://scholarspace.manoa.hawaii.edu/
bitstream/10125/50485/paper0598.pdf , 2018. bitstream/10125/50485/paper0598.pdf , 2018.
[Troll] Stewart, L., Arif, A., and K. Starbird, "Examining trolls [Troll] Stewart, L., Arif, A., and K. Starbird, "Examining trolls
and polarization with a retweet network", ACM Workshop on and polarization with a retweet network", ACM Workshop on
Misinformation and Misbehavior Mining on the Web, Misinformation and Misbehavior Mining on the Web,
https://faculty.washington.edu/kstarbi/ https://faculty.washington.edu/kstarbi/
examining-trolls-polarization.pdf , 2018. examining-trolls-polarization.pdf , 2018.
skipping to change at line 1673 skipping to change at page 42, line 12
Information, Communication and Society (2018): 1-20 , Information, Communication and Society (2018): 1-20 ,
2018. 2018.
[Vpns] Khan, M., DeBlasio, J., Voelker, G., Snoeren, A., Kanich, [Vpns] Khan, M., DeBlasio, J., Voelker, G., Snoeren, A., Kanich,
C., and N. Vallina, "An empirical analysis of the C., and N. Vallina, "An empirical analysis of the
commercial VPN ecosystem", ACM Internet Measurement commercial VPN ecosystem", ACM Internet Measurement
Conference 2018 (pp. 443-456), Conference 2018 (pp. 443-456),
https://eprints.networks.imdea.org/1886/1/ https://eprints.networks.imdea.org/1886/1/
imc18-final198.pdf , 2018. imc18-final198.pdf , 2018.
Appendix A. Acknowledgements Appendix A. Contributors
Eric Rescorla and Chris Wood provided much of the text in
Section 2.3.1.4, item 2 of Section 4 and Section 6.3.
Appendix B. Acknowledgements
The authors would like to thank the IAB: The authors would like to thank the IAB:
Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin
Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura, Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura,
Martin Thomson, Brian Trammel, Mirja Kuhlewind, and Colin Perkins. Martin Thomson, Brian Trammel, Mirja Kuhlewind, and Colin Perkins.
The authors would also like to thank the participants of the IETF The authors would also like to thank the participants of the IETF
SAAG meeting where this topic was discussed: SAAG meeting where this topic was discussed:
skipping to change at line 1710 skipping to change at page 43, line 5
The authors would also like to thank the participants of the November The authors would also like to thank the participants of the November
2016 meeting at the IETF: 2016 meeting at the IETF:
Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie, Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie,
Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric
Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and
Robin Wilton ... (missing many people... did we have minutes other Robin Wilton ... (missing many people... did we have minutes other
than the list of actions?) ... than the list of actions?) ...
Thanks for specific comments on this text to: Ronald van der Pol.
Finally, the authors would like to thank numerous other people for Finally, the authors would like to thank numerous other people for
insightful comments and discussions in this space. insightful comments and discussions in this space.
Authors' Addresses Authors' Addresses
Ericsson
Jari Arkko Jari Arkko
FI- Ericsson
Valitie 1B
Kauniainen
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Stephen Farrell Stephen Farrell
Trinity College Dublin Trinity College Dublin
College Green
Dublin
Ireland Ireland
Email: stephen.farrell@cs.tcd.ie Email: stephen.farrell@cs.tcd.ie
 End of changes. 110 change blocks. 
213 lines changed or deleted 514 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/