< draft-farrell-etm-02.txt   draft-farrell-etm-03.txt >
Network Working Group S. Farrell Network Working Group S. Farrell
Internet-Draft Trinity College Dublin Internet-Draft Trinity College Dublin
Intended status: Informational May 1, 2019 Intended status: Informational July 6, 2019
Expires: November 2, 2019 Expires: January 7, 2020
We're gonna need a bigger threat model We're gonna need a bigger threat model
draft-farrell-etm-02 draft-farrell-etm-03
Abstract Abstract
We argue that an expanded threat model is needed for Internet We argue that an expanded threat model is needed for Internet
protocol development as protocol endpoints can no longer be protocol development as protocol endpoints can no longer be
considered to be generally trustworthy for any general definition of considered to be generally trustworthy for any general definition of
"trustworthy." "trustworthy."
This draft will be a submission to the DEDR IAB workshop.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 2, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Examples of deliberate adversarial behaviour in applications 4 2. Examples of deliberate adversarial behaviour in applications 4
2.1. Malware in curated application stores . . . . . . . . . . 4 2.1. Malware in curated application stores . . . . . . . . . . 4
2.2. Virtual private networks (VPNs) . . . . . . . . . . . . . 5 2.2. Virtual private networks (VPNs) . . . . . . . . . . . . . 5
2.3. Compromised (home) networks . . . . . . . . . . . . . . . 5 2.3. Compromised (home) networks . . . . . . . . . . . . . . . 5
2.4. Web browsers . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Web browsers . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Web site policy deception . . . . . . . . . . . . . . . . 5 2.5. Web site policy deception . . . . . . . . . . . . . . . . 5
2.6. Tracking bugs in mail . . . . . . . . . . . . . . . . . . 6 2.6. Tracking bugs in mail . . . . . . . . . . . . . . . . . . 6
2.7. Troll farms in online social networks . . . . . . . . . . 6 2.7. Troll farms in online social networks . . . . . . . . . . 6
2.8. Smart televisions . . . . . . . . . . . . . . . . . . . . 6 2.8. Smart televisions . . . . . . . . . . . . . . . . . . . . 6
2.9. So-called Internet of things . . . . . . . . . . . . . . 7 2.9. So-called Internet of things . . . . . . . . . . . . . . 7
3. Inadvertent adversarial behaviours . . . . . . . . . . . . . 7 2.10. Attacks leveraging compromised high-level DNS
4. Possible directions for an expanded threat model . . . . . . 8 infrastructure . . . . . . . . . . . . . . . . . . . . . 7
4.1. Develop a BCP for privacy considerations . . . . . . . . 8 2.11. BGP hijacking . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Consider the user perspective . . . . . . . . . . . . . . 8 3. Inadvertent adversarial behaviours . . . . . . . . . . . . . 8
4.3. Consider ABuse-cases as well as use-cases . . . . . . . . 8 4. Possible directions for an expanded threat model . . . . . . 9
4.4. Re-consider protocol design "lore" . . . . . . . . . . . 8 4.1. Develop a BCP for privacy considerations . . . . . . . . 10
4.5. Isolation . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Consider the user perspective . . . . . . . . . . . . . . 10
4.6. Transparency . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Consider ABuse-cases as well as use-cases . . . . . . . . 10
4.7. Minimise . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Re-consider protocol design "lore" . . . . . . . . . . . 10
4.8. Same-Origin Policy . . . . . . . . . . . . . . . . . . . 9 4.5. Isolation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.9. Greasing . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Transparency . . . . . . . . . . . . . . . . . . . . . . 11
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Minimise . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.8. Same-Origin Policy . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.9. Greasing . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 4.10. Generalise OAuth Threat Model . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.11. One (or more) endpoint may be compromised . . . . . . . . 12
9.1. Informative References . . . . . . . . . . . . . . . . . 10 4.12. Look again at how well we're securing infrastructure . . 12
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.13. Consider recovery from attack as part of protocol design 13
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 4.14. Don't think in terms of hosts . . . . . . . . . . . . . . 13
A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 15 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Informative References . . . . . . . . . . . . . . . . . 14
9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
A.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 19
A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 19
A.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
[[There's a github repo for this -- issues and PRs are welcome there. [[There's a github repo for this -- issues and PRs are welcome there.
<https://github.com/sftcd/etm> ]] <https://github.com/sftcd/etm> ]]
[RFC3552], Section 3 defines an "Internet Threat Model" which has [RFC3552], Section 3 defines an "Internet Threat Model" which has
been commonly used when developing Internet protocols. That assumes been commonly used when developing Internet protocols. That assumes
that "the end-systems engaging in a protocol exchange have not that "the end-systems engaging in a protocol exchange have not
themselves been compromised." RFC 3552 is a formal part of of the themselves been compromised." RFC 3552 is a formal part of of the
skipping to change at page 4, line 9 skipping to change at page 4, line 17
However, it is not clear if the IETF will reach rough consensus on a However, it is not clear if the IETF will reach rough consensus on a
description of such an expanded threat model. We argue that ignoring description of such an expanded threat model. We argue that ignoring
this aspect of deployed reality may not bode well for Internet this aspect of deployed reality may not bode well for Internet
protocol development. protocol development.
Absent such an expanded threat model, we expect to see more of a Absent such an expanded threat model, we expect to see more of a
mismatch between expectaions and the deployment reality for some mismatch between expectaions and the deployment reality for some
Internet protocols. Internet protocols.
This internet-draft is a submission to the IAB's DEDR workshop [3] Version -02 of this internet-draft was a submission to the IAB's DEDR
and is not intended to become an RFC. workshop [3]. We note that another author independently proposed
changes to the Internet threat model for related, but different,
We note that another author has independently proposed changes to the reasons, [I-D.arkko-arch-internet-threat-model] also as a submission
Internet threat model for related, but different, reasons, to the DEDR workshop.
[I-D.arkko-arch-internet-threat-model] also as a submission to the
DEDR workshop.
We are saddened by, and apologise for, the somewhat dystopian We are saddened by, and apologise for, the somewhat dystopian
impression that this document may impart - hopefully, there's a bit impression that this document may impart - hopefully, there's a bit
of hope at the end;-) of hope at the end;-)
2. Examples of deliberate adversarial behaviour in applications 2. Examples of deliberate adversarial behaviour in applications
In this section we describe a few documented examples of deliberate In this section we describe a few documented examples of deliberate
adversarial behaviour by applications that could affect Internet adversarial behaviour by applications that could affect Internet
protocol development. The adversarial behaviours described below protocol development. The adversarial behaviours described below
skipping to change at page 7, line 15 skipping to change at page 7, line 19
2.9. So-called Internet of things 2.9. So-called Internet of things
Many so-called Internet of Things (IoT) devices ("so-called" as all Many so-called Internet of Things (IoT) devices ("so-called" as all
devices were already things:-) have been found extremely deficient devices were already things:-) have been found extremely deficient
when their security and privacy aspects were analysed, for example when their security and privacy aspects were analysed, for example
children's toys. [toys] While in some cases this may be due to children's toys. [toys] While in some cases this may be due to
incompetence rather than being deliberately adversarial behaviour, incompetence rather than being deliberately adversarial behaviour,
the levels of incompetence frequently seen imply that it is valid to the levels of incompetence frequently seen imply that it is valid to
consider such cases as not being accidental. consider such cases as not being accidental.
2.10. Attacks leveraging compromised high-level DNS infrastructure
Recent attacks [6] against DNS infrastructure enable subsequent
targetted attacks on specific application layer sources or
destinations. The general method appears to be to attack DNS
infrastructure, in these cases infrastructure that is towards the top
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
TLS server certificates so as to subsequently attack TLS connections
from clients to services (with clients directed to an attacker-owned
server via additional fake DNS responses).
Attackers in these cases seem well resourced and patient - with
"practice" runs over months and with attack durations being
infrequent and short (e.g. 1 hour) before the attacker withdraws.
These are sophisticated multi-protocol attacks, where weaknesses
related to deployment of one protocol (DNS) bootstrap attacks on
another protocol (e.g. IMAP/TLS), via abuse of a 3rd protocol
(ACME), partly in order to capture user IMAP login credentials, so as
to be able to harvest message store content from a real message
store.
The fact that many mail clients regularly poll their message store
means that a 1-hour attack is quite likely to harvest many cleartext
passwords or crackable password hashes. The real IMAP server in such
a case just sees fewer connections during the "live" attack, and some
additional connections later. Even heavy email users in such cases
that might notice a slight gap in email arrivals, would likely
attribute that to some network or service outage.
In many of these cases the paucity of DNSSEC-signed zones (about 1%
of existing zones) and the fact that many resolvers do not enforce
DNSSEC validation (e.g., in some mobile operating systems) assisted
the attackers.
It is also notable that some of the personnel dealing with these
attacks against infrastructure entites are authors of RFCs and
Internet-drafts. That we haven't provided protocol tools that better
protect against these kinds of attack ought hit "close to home" for
the IETF.
In terms of the overall argument being made here, the PKI and DNS
interactions, and the last step in the "live" attack all involve
interaction with a deliberately adversarial application. Later, use
of acquired login credentials to harvest message store content
involves an adversarial client application. It all cases, a TLS
implementation's PKI and TLS protocol code will see the fake
endpoints as protocol-valid, even if, in the real world, they are
clearly fake. This appears to be a good argument that our current
threat model is lacking in some respect(s), even as applied to our
currently most important security protocol (TLS).
2.11. BGP hijacking
There is a clear history of BGP hijacking [bgphijack] being used to
ensure endpoints connect to adversarial applications. As in the
previous example, such hijacks can be used to trick a PKI into
issuing a certificate for a fake entity. Indeed one study
[hijackdet] used the emergence of new web server TLS key pairs during
the event, (detected via Internet-wide scans), as a distinguisher
between one form of deliberate BGP hijacking and indadvertent route
leaks.
3. Inadvertent adversarial behaviours 3. 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:
o 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 malware command and control [6] or apache logs for malware command and control [7]
o Carelessly leaky buckets [7], for example, lots of Amazon S3 leaks o Carelessly leaky buckets [8], for example, lots of Amazon S3 leaks
showing that careless admins can too easily cause application showing that careless admins can too easily cause application
server data to become available to adversaries server data to become available to adversaries
o Virtualisation exposing secrets, for example, Meltdown and Spectre o Virtualisation exposing secrets, for example, Meltdown and Spectre
[8] and similar side-channels [9] and similar side-channels
o Compromised badly-maintained web sites, that for example, have led o Compromised badly-maintained web sites, that for example, have led
to massive online databases of passwords [9] to massive online databases of passwords [10]
o Supply-chain attacks, for example, the Target attack [10] o Supply-chain attacks, for example, the Target attack [11] or
malware within pre-installed applications on Android phones.
[bloatware]
o 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: yahoo [11] * 3 billion accounts: yahoo [12]
* "up to 600M" account passwords stored in clear: facebook [12] * "up to 600M" account passwords stored in clear: facebook [13]
* many millions at risk: telcos selling location data [13] * many millions at risk: telcos selling location data [14]
* 50 million accounts: facebook [14] * 50 million accounts: facebook [15]
* 14 million accounts: verizon [15] * 14 million accounts: verizon [16]
* "hundreds of thousands" of accounts: google [16] * "hundreds of thousands" of accounts: google [17]
* unknown numbers, some email content exposed: microsoft [17]
* unknown numbers, some email content exposed: microsoft [18]
o Breaches of smaller service providers: Too many to enumerate, o Breaches of smaller service providers: Too many to enumerate,
sadly sadly
4. Possible directions for an expanded threat model 4. Possible directions for an expanded threat model
As we believe useful conclusions in this space require community As we believe useful conclusions in this space require community
consensus, we won't offer definitive descriptions of an expanded consensus, we won't offer definitive descriptions of an expanded
threat model but we will call out some potential directions that threat model but we will call out some potential directions that
could be explored at the DEDR workshop and thereafter, if there is could be explored as one follow-up to the DEDR workshop and
interest in this topic. thereafter, if there is interest in this topic.
Before doing so, it is worth calling out one of the justifications
for the RFC 3553 definition of the Internet threat model which is
that going beyond an assumption that protocol endpoints have not been
compromised rapidly introduces complexity into the analysis. We do
have plenty of experience that when security and privacy solutions
add too much complexity and/or are seen to add risks without
benefits, those tend not to be deployed. One of the risks in
expanding our threat model that we need to recognise is that the end
result could be too complex, might not be applied during protocol
design, or worse, could lead to flawed risk analyses. One of the
constraints on work on an expanded threat model is therefore that the
result has to remain usable by protocol designers who are not
security or privacy experts.
4.1. Develop a BCP for privacy considerations 4.1. Develop a BCP for privacy considerations
It may be time for the IETF to develop a BCP for privacy It may be time for the IETF to develop a BCP for privacy
considerations, possibly starting from [RFC6973]. considerations, possibly starting from [RFC6973].
4.2. Consider the user perspective 4.2. Consider the user perspective
[I-D.nottingham-for-the-users] argues that, in relevant cases where [I-D.nottingham-for-the-users] argues that, in relevant cases where
there are conflicting requirements, the "IETF considers end users as there are conflicting requirements, the "IETF considers end users as
skipping to change at page 9, line 23 skipping to change at page 11, line 12
isolation mechanisms might be worth considering. To an extent, the isolation mechanisms might be worth considering. To an extent, the
IETF has in practice already recognised some of these issues as being IETF has in practice already recognised some of these issues as being
in-scope, e.g. when considering the linkability issues with in-scope, e.g. when considering the linkability issues with
mechanisms such as TLS session tickets, or QUIC connection mechanisms such as TLS session tickets, or QUIC connection
identifiers. identifiers.
4.6. Transparency 4.6. Transparency
Certificate transparency (CT) [RFC6962] has been an effective Certificate transparency (CT) [RFC6962] has been an effective
countermeasure for X.509 certificate mis-issuance, which used be a countermeasure for X.509 certificate mis-issuance, which used be a
known application layer misbehaviour in the public web PKI. While known application layer misbehaviour in the public web PKI. CT can
the context in which CT operates is very constrained (essentially to also help with post-facto detection of some infrastructure attacks
the public CAs trusted by web browsers), similar approaches could be where BGP or DNS weakenesses have been leveraged so that some
useful for other protocols or technologies. certification authority is tricked into issuing a certificate for the
wrong entity.
While the context in which CT operates is very constrained
(essentially to the public CAs trusted by web browsers), similar
approaches could perhaps be useful for other protocols or
technologies.
In addition, legislative requirements such as those imposed by the In addition, legislative requirements such as those imposed by the
GDPR for subject access to data [18] could lead to a desire to handle GDPR for subject access to data [19] could lead to a desire to handle
internal data structures and databases in ways that are reminiscent internal data structures and databases in ways that are reminiscent
of CT, though clearly with significant authorisation being required of CT, though clearly with significant authorisation being required
and without the append-only nature of a CT log. and without the append-only nature of a CT log.
4.7. Minimise 4.7. Minimise
As recommended in [RFC6973] data minimisation and additional As recommended in [RFC6973] data minimisation and additional
encryption are likely to be helpful - if applications don't ever see encryption are likely to be helpful - if applications don't ever see
data, or a cleartext form of data, then they should have a harder data, or a cleartext form of data, then they should have a harder
time misbehaving. Similarly, not adding new long-term identifiers, time misbehaving. Similarly, not adding new long-term identifiers,
skipping to change at page 10, line 14 skipping to change at page 12, line 8
4.9. Greasing 4.9. Greasing
The TLS protocol [RFC8446] now supports the use of GREASE The TLS protocol [RFC8446] now supports the use of GREASE
[I-D.ietf-tls-grease] as a way to mitigate on-path ossification. [I-D.ietf-tls-grease] as a way to mitigate on-path ossification.
While this technique is not likely to prevent any deliberate While this technique is not likely to prevent any deliberate
misbehaviours, it may provide a proof-of-concept that network misbehaviours, it may provide a proof-of-concept that network
protocol mechanisms can have impact in this space, if we spend the protocol mechanisms can have impact in this space, if we spend the
time to try analyse the incentives of the various parties. time to try analyse the incentives of the various parties.
4.10. Generalise OAuth Threat Model
The OAuth threat model [RFC6819] provides an extensive list of
threats and security considerations for those implementing and
deploying OAuth version 2.0 [RFC6749]. That document is perhaps too
detailed to serve as useful generic guidance but does go beyond the
Internet threat model from RFC3552, for example it says:
two of the three parties involved in the OAuth protocol may
collude to mount an attack against the 3rd party. For example,
the client and authorization server may be under control of an
attacker and collude to trick a user to gain access to resources.
It could be useful to attempt to derive a more abstract threat model
from that RFC that considers threats in more generic multi-party
contexts.
4.11. One (or more) endpoint may be compromised
The quote from OAuth above also has another aspect - it considers the
effect of compromised endpoints on those that are not compromised.
It may therefore be interesting to consider the consequeneces that
would follow from this OLD/NEW change to RFC3552
OLD: In general, we assume that the end-systems engaging in a
protocol exchange have not themselves been compromised.
NEW:
In general, we assume that one of the protocol engines engaging in a
protocol exchange has not been compromised at the run-time of the
exchange.
4.12. Look again at how well we're securing infrastructure
Some attacks (e.g. against DNS or routing infrastructure) appear to
benefit from current infrastructure mechanisms not being deployed,
e.g. DNSSEC, RPKI. In the case of DNSSEC, deployment is still
minimal despite much time having elapsed. This suggests a number of
different possible avenues for investigation:
o For any protocol dependent on infrastructure like DNS or BGP, we
ought analysse potential outcomes in the event the relevant
infrastructure has been compromised
o Protocol designers perhaps ought consider post-facto detection
compromise mechanisms in the event that it is infeasible to
mitigate attacks on infrastructure that is not under local control
o Despite the sunk costs, it may be worth re-considering
infrastructure security mechanisms that have not been deployed,
and hence are ineffective.
4.13. Consider recovery from attack as part of protocol design
Recent work on multiparty messaging security primitives
[I-D.ietf-mls-architecture] considers "post-compromise security" as
an inherent part of the design of that protocol. Perhaps protocol
designers ought generally consider recovery from attack during
protocol design - we do know that all widely used protocols will at
sometime be subject to successful attack, whether that is due to
deployment or implementation error, or, as is less common, due to
protocol design flaws.
4.14. Don't think in terms of hosts
More and more, protocol endpoints are not being executed on what used
be understood as a host system. The web and Javascript model clearly
differs from traditional host models, but so do most server-side
deployments these days, thanks to virtualisation.
As yes unpublished work on this topic within the IAB stackevo [20]
programme, appears to posit the same kind of thesis. In the stackevo
case, that work would presumably lead to some new definition of
protocol endpoint, but (consensus on) such a definition may not be
needed for an expanded threat model. For this work, it may be
sufficient to note that protocol endpoints can no longer be
considered to be executing on a traditional host, to assume (at
protocol design time) that all endpoints will be run in a virtualised
environment where co-tenants and (sometimes) hypervisors are
adversaries, and to then call for analysis of such scenarios.
5. Conclusions 5. Conclusions
At this stage we don't think it approriate to claim that any strong At this stage we don't think it approriate 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 at the DEDR that the is a topic that could be worth discussion as part of the
workshop and elsewhere. follow-up to at the DEDR workshop and more generally within the IETF.
6. Security Considerations 6. Security Considerations
This draft is all about security, and privacy. This draft is all about security, and privacy.
Encryption is one of the most effective tools in countering network Encryption is one of the most effective tools in countering network
based attackers and will also have a role in protecting against based attackers and will also have a role in protecting against
adversarial applications. However, today many existing tools for adversarial applications. However, today many existing tools for
countering adversarial applications assume they can inspect network countering adversarial applications assume they can inspect network
traffic to or from potentially adversarial applications. These facts traffic to or from potentially adversarial applications. These facts
skipping to change at page 10, line 41 skipping to change at page 14, line 25
model could possibly help reduce some of those tensions, if it leads model could possibly help reduce some of those tensions, if it leads
to the development of protocols that make exploitation harder or more to the development of protocols that make exploitation harder or more
transparent for adversarial applications. transparent for adversarial applications.
7. IANA Considerations 7. IANA Considerations
There are no IANA considerations. There are no IANA considerations.
8. Acknowledgements 8. Acknowledgements
We'll happily ack anyone who's interested enough to read and comment With no implication that they agree with some or all of the above,
on this. With no implication that they agree with some or all of the thanks to Jari Arkko, Carsten Bormann, Christian Huitema and Daniel
above, thanks to Jari Arkko, Carsten Bormann, Christian Huitema and Kahn Gillmor for comments on an earlier version of the text.
Daniel Kahn Gillmor for comments on an earlier version of the text.
Thanks to Jari Arkko, Ted Hardie and Brian Trammell for discussions
on this topic after they (but not the author) had attended the DEDR
workshop.
9. References 9. References
9.1. Informative References 9.1. 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) 1999, 1999, Security Applications Conference (ACSAC'99) 1999, 1999,
<https://www.acsac.org/1999/papers/wed-b-1030-john.pdf>. <https://www.acsac.org/1999/papers/wed-b-1030-john.pdf>.
[attitude] [attitude]
Chanchary, F. and S. Chiasson, "User Perceptions of Chanchary, F. and S. Chiasson, "User Perceptions of
Sharing, Advertising, and Tracking", Symposium on Usable Sharing, Advertising, and Tracking", Symposium on Usable
Privacy and Security (SOUPS) 2015, 2015, Privacy and Security (SOUPS) 2015, 2015,
<https://www.usenix.org/conference/soups2015/proceedings/ <https://www.usenix.org/conference/soups2015/proceedings/
presentation/chanchary>. presentation/chanchary>.
[bgphijack]
Sermpezis, P., Kotronis, V., Dainotti, A., and X.
Dimitropoulos, "A survey among network operators on BGP
prefix hijacking", ACM SIGCOMM Computer Communication
Review 48, no. 1 (2018): 64-69., 2018,
<https://arxiv.org/pdf/1801.02918.pdf>.
[bloatware]
Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and
N. Vallina-Rodriguez, "An Analysis of Pre-installed
Android Software", arXiv preprint arXiv:1905.02713
(2019)., 2019, <https://arxiv.org/pdf/1905.02713.pdf>.
[cambridge] [cambridge]
Isaak, J. and M. Hanna, "User Data Privacy: Facebook, Isaak, J. and M. Hanna, "User Data Privacy: Facebook,
Cambridge Analytica, and Privacy Protection", Cambridge Analytica, and Privacy Protection",
Computer 51.8 (2018): 56-59, 2018, Computer 51.8 (2018): 56-59, 2018,
<https://ieeexplore.ieee.org/stamp/ <https://ieeexplore.ieee.org/stamp/
stamp.jsp?arnumber=8436400>. stamp.jsp?arnumber=8436400>.
[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, 2018, Conference on Software Engineering 2018, 2018,
<https://www.ics.uci.edu/~seal/ <https://www.ics.uci.edu/~seal/
publications/2018ICSE_Hammad.pdf>. publications/2018ICSE_Hammad.pdf>.
[hijackdet]
Schlamp, J., Holz, R., Gasser, O., Korste, A., Jacquemart,
Q., Carle, G., and E. Biersack, "Investigating the nature
of routing anomalies: Closing in on subprefix hijacking
attacks", International Workshop on Traffic Monitoring
and Analysis, pp. 173-187. Springer, Cham, 2015., 2015,
<https://www.net.in.tum.de/fileadmin/bibtex/publications/
papers/schlamp_TMA_1_2015.pdf>.
[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-00 (work in progress), arkko-arch-internet-threat-model-00 (work in progress),
April 2019. April 2019.
[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-02 (work in Principle", draft-iab-protocol-maintenance-03 (work in
progress), May 2019.
[I-D.ietf-mls-architecture]
Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon,
A., and A. Duric, "The Messaging Layer Security (MLS)
Architecture", draft-ietf-mls-architecture-02 (work in
progress), March 2019. progress), March 2019.
[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-02 (work in progress), January 2019. draft-ietf-tls-grease-02 (work in progress), January 2019.
[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-07 (work in progress), March nottingham-for-the-users-08 (work in progress), June 2019.
2019.
[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., 2018, (2018): 109-126., 2018,
<https://www.degruyter.com/downloadpdf/j/ <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>. popets-2018-0006.pdf>.
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic
skipping to change at page 12, line 31 skipping to change at page 16, line 45
[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>.
[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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013,
<https://www.rfc-editor.org/info/rfc6819>.
[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>.
skipping to change at page 14, line 27 skipping to change at page 18, line 47
[3] https://www.iab.org/activities/workshops/dedr-workshop/ [3] https://www.iab.org/activities/workshops/dedr-workshop/
[4] https://www.nytimes.com/2018/10/20/us/politics/saudi-image- [4] https://www.nytimes.com/2018/10/20/us/politics/saudi-image-
campaign-twitter.html campaign-twitter.html
[5] https://www.welivesecurity.com/2013/11/22/lg-admits-that-its- [5] https://www.welivesecurity.com/2013/11/22/lg-admits-that-its-
smart-tvs-have-been-watching-users-and-transmitting-data-without- smart-tvs-have-been-watching-users-and-transmitting-data-without-
consent/ consent/
[6] https://security.stackexchange.com/questions/100577/creating- [6] https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-
widespread-dns-hijacking-attacks/
[7] https://security.stackexchange.com/questions/100577/creating-
botnet-cc-server-what-architecture-should-i-use-irc-http botnet-cc-server-what-architecture-should-i-use-irc-http
[7] https://businessinsights.bitdefender.com/worst-amazon-breaches [8] https://businessinsights.bitdefender.com/worst-amazon-breaches
[8] https://www.us-cert.gov/ncas/alerts/TA18-004A [9] https://www.us-cert.gov/ncas/alerts/TA18-004A
[9] https://haveibeenpwned.com/Passwords [10] https://haveibeenpwned.com/Passwords
[10] https://www.zdnet.com/article/how-hackers-stole-millions-of- [11] https://www.zdnet.com/article/how-hackers-stole-millions-of-
credit-card-records-from-target/ credit-card-records-from-target/
[11] https://www.wired.com/story/yahoo-breach-three-billion-accounts/ [12] https://www.wired.com/story/yahoo-breach-three-billion-accounts/
[12] https://www.pcmag.com/news/367319/facebook-stored-up-to-600m- [13] https://www.pcmag.com/news/367319/facebook-stored-up-to-600m-
user-passwords-in-plain-text user-passwords-in-plain-text
[13] https://www.zdnet.com/article/us-telcos-caught-selling-your- [14] https://www.zdnet.com/article/us-telcos-caught-selling-your-
location-data-again-senator-demands-new-laws/ location-data-again-senator-demands-new-laws/
[14] https://www.cnet.com/news/facebook-breach-affected-50-million- [15] https://www.cnet.com/news/facebook-breach-affected-50-million-
people/ people/
[15] https://www.zdnet.com/article/millions-verizon-customer-records- [16] https://www.zdnet.com/article/millions-verizon-customer-records-
israeli-data/ israeli-data/
[16] https://www.wsj.com/articles/google-exposed-user-data-feared- [17] https://www.wsj.com/articles/google-exposed-user-data-feared-
repercussions-of-disclosing-to-public-1539017194 repercussions-of-disclosing-to-public-1539017194
[17] https://motherboard.vice.com/en_us/article/ywyz3x/hackers-could- [18] https://motherboard.vice.com/en_us/article/ywyz3x/hackers-could-
read-your-hotmail-msn-outlook-microsoft-customer-support read-your-hotmail-msn-outlook-microsoft-customer-support
[18] https://gdpr-info.eu/art-15-gdpr/ [19] https://gdpr-info.eu/art-15-gdpr/
[20] https://github.com/stackevo/endpoint-draft/blob/master/draft-
trammell-whats-an-endpoint.md
Appendix A. Change Log Appendix A. Change Log
This isn't gonna end up as an RFC, but may as well be tidy... This isn't gonna end up as an RFC, but may as well be tidy...
A.1. Changes from -01 to -02 A.1. Changes from -02 to -03
o Integrated some changes based on discussion with Ted, Jari and
Brian.
A.2. Changes from -01 to -02
o Oops - got an RFC number wrong in reference o Oops - got an RFC number wrong in reference
A.2. Changes from -00 to -01 A.3. Changes from -00 to -01
o Made a bunch more edits and added more references o Made a bunch more edits and added more references
o I had lots of typos (as always:-) o I had lots of typos (as always:-)
o cabo: PR#1 fixed more typos and noted extensbility danger o cabo: PR#1 fixed more typos and noted extensbility danger
Author's Address Author's Address
Stephen Farrell Stephen Farrell
 End of changes. 45 change blocks. 
79 lines changed or deleted 303 lines changed or added

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