Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                                S. Farrell
Expires: January 15, 2021                         Trinity College Dublin
                                                           July 14, 2020


          Challenges and Changes in the Internet Threat Model
                  draft-arkko-farrell-arch-model-t-04

Abstract

   Communications security has been at the center of many security
   improvements in the Internet.  The goal has been to ensure that
   communications are protected against outside observers and attackers.

   This memo suggests that the existing RFC 3552 threat model, while
   important and still valid, is no longer alone sufficient to cater for
   the pressing security and privacy issues seen on the Internet today.
   For instance, it is often also necessary to protect against endpoints
   that are compromised, malicious, or whose interests simply do not
   align with the interests of users.  While such protection is
   difficult, there are some measures that can be taken and we argue
   that investigation of these issues is warranted.

   It is particularly important to ensure that as we continue to develop
   Internet technology, non-communications security related threats, and
   privacy issues, are properly understood.

Status of This Memo

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

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

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

   This Internet-Draft will expire on January 15, 2021.






Arkko & Farrell         Expires January 15, 2021                [Page 1]


Internet-Draft       Internet Threat Model Evolution           July 2020


Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Observations  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Communications Security Improvements  . . . . . . . . . .   5
     2.2.  Beyond Communications Security  . . . . . . . . . . . . .   6
     2.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   9
       2.3.1.  Deliberate adversarial behaviour in applications  . .   9
       2.3.2.  Inadvertent adversarial behaviours  . . . . . . . . .  15
   3.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     3.1.  The Role of End-to-end  . . . . . . . . . . . . . . . . .  16
     3.2.  Trusted networks  . . . . . . . . . . . . . . . . . . . .  18
       3.2.1.  Even closed networks can have compromised nodes . . .  19
     3.3.  Balancing Threats . . . . . . . . . . . . . . . . . . . .  20
     3.4.  Checklist for Protocol Designers  . . . . . . . . . . . .  21
   4.  Areas requiring more study  . . . . . . . . . . . . . . . . .  23
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  27
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  28
   Appendix A.  Changes from previous version  . . . . . . . . . . .  36
   Appendix B.  Contributors . . . . . . . . . . . . . . . . . . . .  37
   Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction

   Communications security has been at the center of many security
   improvements in the Internet.  The goal has been to ensure that
   communications are protected against outside observers and attackers.
   At the IETF, this approach has been formalized in BCP 72 [RFC3552],
   which defined the Internet threat model in 2003.




Arkko & Farrell         Expires January 15, 2021                [Page 2]


Internet-Draft       Internet Threat Model Evolution           July 2020


   The purpose of a threat model is to outline what threats exist in
   order to assist the protocol designer.  But RFC 3552 also ruled some
   threats to be in scope and of primary interest, and some threats out
   of scope [RFC3552]:

      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.

      By contrast, we assume that the attacker has nearly complete
      control of the communications channel over which the end-systems
      communicate.  This means that the attacker can read any PDU
      (Protocol Data Unit) on the network and undetectably remove,
      change, or inject forged packets onto the wire.

   However, the communications-security -only threat model is becoming
   outdated.  Some of the causes for this are:

   o  Success!  Advances in protecting most of our communications with
      strong cryptographic means.  This has resulted in much improved
      communications security, but also highlights the need for
      addressing other, remaining issues.  This is not to say that
      communications security is not important, it still is:
      improvements are still needed.  Not all communications have been
      protected, and even out of the already protected communications,
      not all of their aspects have been fully protected.  Fortunately,
      there are ongoing projects working on improvements.

   o  Adversaries have increased their pressure against other avenues of
      attack, from supply-channel attacks, to compromising devices to
      legal coercion of centralized endpoints in conversations.

   o  New adversaries and risks have arisen, e.g., due to creation of
      large centralized information sources.

   o  While communications-security does seem to be required to protect
      privacy, more is needed, especially if endpoints choose to act
      against the interests of their peers or users.

   In short, attacks are migrating towards the currently easier targets,
   which no longer necessarily include direct attacks on traffic flows.
   In addition, trading information about users and ability to influence
   them has become a common practice for many Internet services, often
   without users understanding those practices.



Arkko & Farrell         Expires January 15, 2021                [Page 3]


Internet-Draft       Internet Threat Model Evolution           July 2020


   This memo suggests that the existing threat model, while important
   and still valid, is no longer alone sufficient to cater for the
   pressing security and privacy issues on the Internet.  For instance,
   while it continues to be very important to protect Internet
   communications against outsiders, it is also necessary to protect
   systems against endpoints that are compromised, malicious, or whose
   interests simply do not align with the interests of the users.

   Of course, there are many trade-offs in the Internet on who one
   chooses to interact with and why or how.  It is not the role of this
   memo to dictate those choices.  But it is important that we
   understand the implications of different practices.  It is also
   important that when it comes to basic Internet infrastructure, our
   chosen technologies lead to minimal exposure with respect to the non-
   communications threats.

   It is particularly important to ensure that non-communications
   security related threats are properly understood for any new Internet
   technology.  While the consideration of these issues is relatively
   new in the IETF, this memo provides some initial ideas about
   potential broader threat models to consider when designing protocols
   for the Internet or when trying to defend against pervasive
   monitoring.  Further down the road, updated threat models could
   result in changes in BCP 72 [RFC3552] (guidelines for writing
   security considerations) and BCP 188 [RFC7258] (pervasive
   monitoring), to include proper consideration of non-communications
   security threats.

   It may also be necessary to have dedicated guidance on how systems
   design and architecture affect security.  The sole consideration of
   communications security aspects in designing Internet protocols may
   lead to accidental or increased impact of security issues elsewhere.
   For instance, allowing a participant to unnecessarily collect or
   receive information may lead to a similar effect as described in
   [RFC8546] for protocols: over time, unnecessary information will get
   used with all the associated downsides, regardless of what deployment
   expectations there were during protocol design.

   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-internet-threat-model].  There are also other
   documents discussing this overall space, e.g.
   [I-D.lazanski-smart-users-internet] [I-D.arkko-arch-dedr-report].

   The authors of this memo envisage independent development of each of
   those (and other work) with an eventual goal to extract an updated
   (but usefully brief!) description of an extended threat model from
   the collection of works.  We consider it an open question whether



Arkko & Farrell         Expires January 15, 2021                [Page 4]


Internet-Draft       Internet Threat Model Evolution           July 2020


   this memo, or any of the others, would be usefully published as an
   RFC.

   The rest of this memo is organized as follows.  Section 2 makes some
   observations about the situation, with respect to communications
   security and beyond.  The section also provides a number of real-
   world examples.

   Section 3 discusses some high-level implications that can be drawn,
   such as the need to consider what the "ends" really are in an "end-
   to-end" communication.  A checklist for issues that protocol
   designers need to consider is also included.

   Section 4 lists some areas where additional work is required.

   Possible changes to [RFC3552] are covered in a separate document, see
   I-D.arkko-farrell-arch-model-t-3552-additions.  Similarly, possible
   changes to [RFC7258] are covered in I-D.arkko-farrell-arch-model-
   t-7258-additions.

   Comments are solicited on these and other aspects of this document.
   The best place for discussion is on the model-t list.
   (https://www.ietf.org/mailman/listinfo/model-t)

   Finally, Section 5 draws some conclusions for next steps.

2.  Observations

2.1.  Communications Security Improvements

   Being able to ask about threat model improvements is due to progress
   already made: The fraction of Internet traffic that is
   cryptographically protected has grown tremendously in the last few
   years.  Several factors have contributed to this change, from Snowden
   revelations to business reasons and to better available technology
   such as HTTP/2 [RFC7540], TLS 1.3 [RFC8446], QUIC
   [I-D.ietf-quic-transport].

   In many networks, the majority of traffic has flipped from being
   cleartext to being encrypted.  Reaching the level of (almost) all
   traffic being encrypted is no longer something unthinkable but rather
   a likely outcome in a few years.

   At the same time, technology developments and policy choices have
   driven the scope of cryptographic protection from protecting only the
   pure payload to protecting much of the rest as well, including far
   more header and meta-data information than was protected before.  For
   instance, efforts are ongoing in the IETF to assist encrypting



Arkko & Farrell         Expires January 15, 2021                [Page 5]


Internet-Draft       Internet Threat Model Evolution           July 2020


   transport headers [I-D.ietf-quic-transport], server domain name
   information in TLS [I-D.ietf-tls-esni], and domain name queries
   [RFC8484].

   There have also been improvements to ensure that the security
   protocols that are in use actually have suitable credentials and that
   those credentials have not been compromised, see, for instance, Let's
   Encrypt [RFC8555], HSTS [RFC6797], HPKP [RFC7469], and Expect-CT
   [I-D.ietf-httpbis-expect-ct].

   This is not to say that all problems in communications security have
   been resolved - far from it.  But the situation is definitely
   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
   continue.  Communications security will stay at the top of the agenda
   in any Internet technology development.

2.2.  Beyond Communications Security

   There are, however, significant issues beyond communications security
   in the Internet.  To begin with, it is not necessarily clear that one
   can trust all the endpoints in any protocol interaction.

   Of course, client endpoint implementations were never fully trusted,
   but the environments in which those endpoints exist are changing.
   For instance, users may not have as much control over their own
   devices as they used to, due to manufacturer-controlled operating
   system installations and locked device ecosystems.  And within those
   ecosystems, even the applications that are available tend to have
   privileges that users by themselves might not desire those
   applications be granted, such as excessive rights to media, location,
   and peripherals.  There are also designated efforts by various
   authorities to hack end-user devices as a means of intercepting data
   about the user.

   The situation is different, but not necessarily better on the side of
   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
   other parties have.  For instance, these third parties are typically
   endpoints for any transport layer security connections, and able to
   see much communications or other messaging in cleartext.  There are
   some exceptions, of course, e.g., messaging applications with end-to-
   end confidentiality protection.

   With the growth of trading users' information by many of these third
   parties, it becomes necessary to take precautions against endpoints
   that are compromised, malicious, or whose interests simply do not
   align with the interests of the users.



Arkko & Farrell         Expires January 15, 2021                [Page 6]


Internet-Draft       Internet Threat Model Evolution           July 2020


   Specifically, the following issues need attention:

   o  Security of users' devices and the ability of the user to control
      their own equipment.

   o  Leaks and attacks related to data at rest.

   o  Coercion of some endpoints to reveal information to authorities or
      surveillance organizations, sometimes even in an extra-territorial
      fashion.

   o  Application design patterns that result in cleartext information
      passing through a third party or the application owner.

   o  Involvement of entities that have no direct need for involvement
      for the sake of providing the service that the user is after.

   o  Network and application architectures that result in a lot of
      information collected in a (logically) central location.

   o  Leverage and control points outside the hands of the users or end-
      user device owners.

   For instance, while e-mail transport security [RFC7817] has become
   much more widely deployed in recent years, progress in securing
   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
   some mail service providers who use the content for machine learning,
   advertisement targeting, and other purposes unrelated to message
   delivery.  Equally however, it is unclear how some useful anti-spam
   techniques could be deployed in an end-to-end encrypted mail universe
   (with today's end-to-end mail security protocols) and there are many
   significant challenges should one desire to deploy end-to-end email
   security at scale.

   The Domain Name System (DNS) shows signs of ageing but due to the
   legacy of deployed systems has changed very slowly.  Newer technology
   [RFC8484] developed at the IETF enables DNS queries to be performed
   with confidentiality and authentication (of a recursive resolver),
   but its initial deployment is happening mostly in browsers that use
   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
   security for end users.

   However, if one steps back and considers the potential security and
   privacy effects of these developments, the outcome could appear
   different.  While the security and confidentiality of the protocol
   exchanges improves with the introduction of this new technology, at



Arkko & Farrell         Expires January 15, 2021                [Page 7]


Internet-Draft       Internet Threat Model Evolution           July 2020


   the same time this could lead to a move from using (what appears to
   be) a large worldwide distributed set of DNS resolvers into a far
   smaller set of centralised global resolvers.  While these resolvers
   are very well maintained (and a great service), they are potential
   high-value targets for pervasive monitoring and Denial-of-Service
   (DoS) attacks.  In 2016, for example, DoS attacks were launched
   against Dyn, [DynDDoS] then one of the largest DNS providers, leading
   to some outages.  It is difficult to imagine that DNS resolvers
   wouldn't be a target in many future attacks or pervasive monitoring
   projects.

   Unfortunately, there is little that even large service providers can
   do to not be a DDoS target, (though anycast and other DDoS
   mitigations can certainly help when one is targeted), nor to refuse
   authority-sanctioned pervasive monitoring.  As a result it seems that
   a reasonable defense strategy may be to aim for outcomes where such
   highly centralised control points are unnecessary or don't handle
   sensitive data.  (Recalling that with the DNS, meta-data about the
   requestor and the act of requesting an answer are what is potentially
   sensitive, rather than the content of the answer.)

   There are other examples of the perils of centralised solutions in
   Internet infrastructure.  The DNS example involves an interesting
   combination of information flows (who is asking for what domain
   names) as well as a potential ability to exert control (what domains
   will actually resolve to an address).  Routing systems are primarily
   about control.  While there are intra-domain centralized routing
   solutions (such as PCE [RFC4655]), a control within a single
   administrative domain is usually not the kind of centralization that
   we would be worried about.  Global centralization would be much more
   concerning.  Fortunately, global Internet routing is performed among
   peers.  However, controls could be introduced even in this global,
   distributed system.  To secure some of the control exchanges, the
   Resource Public Key Infrastructure (RPKI) system ([RFC6480]) allows
   selected Certification Authorities (CAs) to help drive decisions
   about which participants in the routing infrastructure can make what
   claims.  If this system were globally centralized, it would be a
   concern, but again, fortunately, current designs involve at least
   regional distribution.

   In general, many recent attacks relate more to information than
   communications.  For instance, personal information leaks typically
   happen via information stored on a compromised server rather than
   capturing communications.  There is little hope that such attacks can
   be prevented entirely.  Again, the best course of action seems to be
   avoid the disclosure of information in the first place, or at least
   to not perform that in a manner that makes it possible that others
   can readily use the information.



Arkko & Farrell         Expires January 15, 2021                [Page 8]


Internet-Draft       Internet Threat Model Evolution           July 2020


2.3.  Examples

2.3.1.  Deliberate adversarial behaviour in applications

   In this section we describe some documented examples of deliberate
   adversarial behaviour by applications that could affect Internet
   protocol development.  The adversarial behaviours described below
   involve various kinds of attack, varying from simple fraud, to
   credential theft, surveillance and contributing to DDoS attacks.
   This is not intended to be a comprehensive nor complete survey, but
   to motivate us to consider deliberate adversarial behaviour by
   applications.

   While we have these examples of deliberate adversarial behaviour,
   there are also many examples of application developers doing their
   best to protect the security and privacy of their users or customers.
   That's just the same as the case today where we need to consider in-
   network actors as potential adversaries despite the many examples of
   network operators who do act primarily in the best interests of their
   users.

2.3.1.1.  Malware in curated application stores

   Despite the best efforts of curators, so-called App-Stores frequently
   distribute malware of many kinds and one recent study [Curated]
   claims that simple obfuscation enables malware to avoid detection by
   even sophisticated operators.  Given the scale of these deployments,
   distribution of even a small percentage of malware-infected
   applications can affect a huge number of people.

2.3.1.2.  Virtual private networks (VPNs)

   Virtual private networks (VPNs) are supposed to hide user traffic to
   various degrees depending on the particular technology chosen by the
   VPN provider.  However, not all VPNs do what they say, some for
   example misrepresenting the countries in which they provide vantage
   points [Vpns].

2.3.1.3.  Compromised (home) networks

   What we normally might consider network devices such as home routers
   do also run applications that can end up being adversarial, for
   example running DNS and DHCP attacks from home routers targeting
   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
   software update [RFC8240] has been a major cause of these issues and
   rises to the level that considering this as intentional behaviour by
   device vendors who have chosen this path is warranted.



Arkko & Farrell         Expires January 15, 2021                [Page 9]


Internet-Draft       Internet Threat Model Evolution           July 2020


2.3.1.4.  Web tracking

   One of the biggest threats to user privacy on the Web is ubiquitous
   tracking.  This is often done to support advertising based business
   models.

   While some people may be sanguine about this kind of tracking, others
   consider this behaviour unwelcome, when or if they are informed that
   it happens, [Attitude] though the evidence here seems somewhat harder
   to interpret and many studies (that we have found to date) involve
   small numbers of users.  Historically, browsers have not made this
   kind of tracking visible and have enabled it by default, though some
   recent browser versions are starting to enable visibility and
   blocking of some kinds of tracking.  Browsers are also increasingly
   imposing more stringent requirements on plug-ins for varied security
   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.




Arkko & Farrell         Expires January 15, 2021               [Page 10]


Internet-Draft       Internet Threat Model Evolution           July 2020


   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



Arkko & Farrell         Expires January 15, 2021               [Page 11]


Internet-Draft       Internet Threat Model Evolution           July 2020


   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

   Many web sites today provide some form of privacy policy and terms of
   service, that are known to be mostly unread [Unread].  This implies
   that, legal fiction aside, users of those sites have not in reality
   agreed to the specific terms published and so users are therefore
   highly exposed to being exploited by web sites, for example
   [Cambridge] is a recent well-publicised case where a service provider
   abused the data of 87 million users via a partnership.  While many
   web site operators claim that they care deeply about privacy, it
   seems prudent to assume that some (or most?) do not in fact care
   about user privacy, or at least not in ways with which many of their
   users would agree.  And of course, today's web sites are actually
   mostly fairly complex web applications and are no longer static sets
   of HTML files, so calling these "web sites" is perhaps a misnomer,
   but considered as web applications, that may for example link in
   advertising networks, it seems clear that many exist that are
   adversarial.

2.3.1.6.  Tracking bugs in mail

   Some mail user agents (MUAs) render HTML content by default (with a
   subset not allowing that to be turned off, perhaps particularly on
   mobile devices) and thus enable the same kind of adversarial tracking
   seen on the web.  Attempts at such intentional tracking are also seen
   many times per day by email users - in one study [Mailbug] the
   authors estimated that 62% of leakage to third parties was
   intentional, for example if leaked data included a hash of the
   recipient email address.

2.3.1.7.  Troll farms in online social networks

   Online social network applications/platforms are well-known to be
   vulnerable to troll farms, sometimes with tragic consequences where
   organised/paid sets of users deliberately abuse the application
   platform for reasons invisible to a normal user.  For-profit
   companies building online social networks are well aware that subsets
   of their "normal" users are anything but.  In one US study, [Troll]
   sets of troll accounts were roughly equally distributed on both sides
   of a controversial discussion.  While Internet protocol designers do
   sometimes consider sybil attacks [Sybil], arguably we have not



Arkko & Farrell         Expires January 15, 2021               [Page 12]


Internet-Draft       Internet Threat Model Evolution           July 2020


   provided mechanisms to handle such attacks sufficiently well,
   especially when they occur within walled-gardens.  Equally, one can
   make the case that some online social networks, at some points in
   their evolution, appear to have prioritised counts of active users so
   highly that they have failed to invest sufficient effort for
   detection of such troll farms.

2.3.1.8.  Smart televisions

   There have been examples of so-called "smart" televisions spying on
   their owners and one survey of user attitudes [SmartTV] found "broad
   agreement was that it is unacceptable for the data to be repurposed
   or shared" although the level of user understanding may be
   questionable.  What is clear though is that such devices generally
   have not provided controls for their owners that would allow them to
   meaningfully make a decision as to whether or not they want to share
   such data.

2.3.1.9.  Internet of things

   Internet of Things (IoT) devices (which might be "so-called Internet
   of Things" as all devices were already things:-) have been found
   deficient when their security and privacy aspects were analysed, for
   example children's toys [Toys].  While in some cases this may be due
   to incompetence rather than being deliberately adversarial behaviour,
   the levels of incompetence frequently seen imply these aspects have
   simply not been considered a priority.

2.3.1.10.  Attacks leveraging compromised high-level DNS infrastructure

   Recent attacks [DeepDive] against DNS infrastructure enable
   subsequent targeted 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



Arkko & Farrell         Expires January 15, 2021               [Page 13]


Internet-Draft       Internet Threat Model Evolution           July 2020


   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.3.1.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 inadvertent route
   leaks.








Arkko & Farrell         Expires January 15, 2021               [Page 14]


Internet-Draft       Internet Threat Model Evolution           July 2020


2.3.1.12.  Anti-virus vendor selling user clickstream data

   An anti-virus product vendor was feeding user clickstream data to a
   subsidiary that then sold on supposedly "anonymised" but highly
   detailed data to unrelated parties.  [avleak] After browser makers
   had removed that vendor's browser extension from their online stores,
   the anti-virus product itself apparently took over data collection
   initially only offering users an opt-out, with the result that
   apparently few users were even aware of the data collection, never
   mind the subsequent clickstream sales.  Very shortly after
   publication of [avleak], the anti-virus vendor announced they were
   closing down the subsidiary.

2.3.2.  Inadvertent adversarial behaviours

   Not all adversarial behaviour by applications is deliberate, some is
   likely due to various levels of carelessness (some quite
   understandable, others not) and/or due to erroneous assumptions about
   the environments in which those applications (now) run.

   We very briefly list some such cases:

   o  Application abuse for command and control, for example, use of IRC
      or apache logs for [CommandAndControl]

   o  Carelessly leaky data stores [LeakyBuckets], for example, lots of
      Amazon S3 leaks showing that careless admins can too easily cause
      application server data to become available to adversaries

   o  Virtualisation exposing secrets, for example, Meltdown and Spectre
      [MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar
      side-channel attacks.

   o  Compromised badly-maintained web sites, that for example, have led
      to massive online [Passwords].

   o  Supply-chain attacks, for example, the [TargetAttack] or malware
      within pre-installed applications on Android phones [Bloatware].

   o  Breaches of major service providers, that many of us might have
      assumed would be sufficiently capable to be the best large-scale
      "Identity providers", for example:

      *  3 billion accounts: https://www.wired.com/story/yahoo-breach-
         three-billion-accounts/






Arkko & Farrell         Expires January 15, 2021               [Page 15]


Internet-Draft       Internet Threat Model Evolution           July 2020


      *  "up to 600M" account passwords stored in clear:
         https://www.pcmag.com/news/367319/facebook-stored-up-to-600m-
         user-passwords-in-plain-text

      *  many millions at risk: https://www.zdnet.com/article/us-telcos-
         caught-selling-your-location-data-again-senator-demands-new-
         laws/

      *  50 million accounts: https://www.cnet.com/news/facebook-breach-
         affected-50-million-people/

      *  14 million accounts: https://www.zdnet.com/article/millions-
         verizon-customer-records-israeli-data/

      *  "hundreds of thousands" of accounts:
         https://www.wsj.com/articles/google-exposed-user-data-feared-
         repercussions-of-disclosing-to-public-1539017194

      *  unknown numbers, some email content exposed:
         https://motherboard.vice.com/en_us/article/ywyz3x/hackers-
         could-read-your-hotmail-msn-outlook-microsoft-customer-support

   o  Breaches of smaller service providers: Too many to enumerate,
      sadly

3.  Analysis

3.1.  The Role of End-to-end

   [RFC1958] notes that "end-to-end functions can best be realised by
   end-to-end protocols":

      The basic argument is that, as a first principle, certain required
      end-to-end functions can only be performed correctly by the end-
      systems themselves.  A specific case is that any network, however
      carefully designed, will be subject to failures of transmission at
      some statistically determined rate.  The best way to cope with
      this is to accept it, and give responsibility for the integrity of
      communication to the end systems.  Another specific case is end-
      to-end security.

   The "end-to-end argument" was originally described by Saltzer et al
   [Saltzer].  They said:

      The function in question can completely and correctly be
      implemented only with the knowledge and help of the application
      standing at the endpoints of the communication system.  Therefore,




Arkko & Farrell         Expires January 15, 2021               [Page 16]


Internet-Draft       Internet Threat Model Evolution           July 2020


      providing that questioned function as a feature of the
      communication system itself is not possible.

   These functional arguments align with other, practical arguments
   about the evolution of the Internet under the end-to-end model.  The
   endpoints evolve quickly, often with simply having one party change
   the necessary software on both ends.  Whereas waiting for network
   upgrades would involve potentially a large number of parties from
   application owners to multiple network operators.

   The end-to-end model supports permissionless innovation where new
   innovation can flourish in the Internet without excessive wait for
   other parties to act.

   But the details matter.  What is considered an endpoint?  What
   characteristics of Internet are we trying to optimize?  This memo
   makes the argument that, for security purposes, there is a
   significant distinction between actual endpoints from a user's
   interaction perspective (e.g., another user) and from a system
   perspective (e.g., a third party relaying a message).

   This memo proposes to focus on the distinction between "real ends"
   and other endpoints to guide the development of protocols.  A
   conversation between one "real end" to another "real end" has
   necessarily different security needs than a conversation between,
   say, one of the "real ends" and a component in a larger system.  The
   end-to-end argument is used primarily for the design of one protocol.
   The security of the system, however, depends on the entire system and
   potentially multiple storage, compute, and communication protocol
   aspects.  All have to work properly together to obtain security.

   For instance, a transport connection between two components of a
   system is not an end-to-end connection even if it encompasses all the
   protocol layers up to the application layer.  It is not end-to-end,
   if the information or control function it carries actually extends
   beyond those components.  For instance, just because an e-mail server
   can read the contents of an e-mail message does not make it a
   legitimate recipient of the e-mail.

   This memo also proposes to focus on the "need to know" aspect in
   systems.  Information should not be disclosed, stored, or routed in
   cleartext through parties that do not absolutely need to have that
   information.

   The proposed argument about real ends is as follows:

      Application functions are best realised by the entities directly
      serving the users, and when more than one entity is involved, by



Arkko & Farrell         Expires January 15, 2021               [Page 17]


Internet-Draft       Internet Threat Model Evolution           July 2020


      end-to-end protocols.  The role and authority of any additional
      entities necessary to carry out a function should match their part
      of the function.  No information or control roles should be
      provided to these additional entities unless it is required by the
      function they provide.

   For instance, a particular piece of information may be necessary for
   the other real endpoint, such as message contents for another user.
   The same piece of information may not be necessary for any additional
   parties, unless the information had to do with, say, routing
   information for the message to reach the other user.  When
   information is only needed by the actual other endpoint, it should be
   protected and be only relayed to the actual other endpoint.  Protocol
   design should ensure that the additional parties do not have access
   to the information.

   Note that it may well be that the easiest design approach is to send
   all information to a third party and have majority of actual
   functionality reside in that third party.  But this is a case of a
   clear tradeoff between ease of change by evolving that third party
   vs. providing reasonable security against misuse of information.

   Note that the above "real ends" argument is not limited to
   communication systems.  Even an application that does not communicate
   with anyone else than its user may be implemented on top of a
   distributed system where some information about the user is exposed
   to untrusted parties.

   The implications of the system security also extend beyond
   information and control aspects.  For instance, poorly design
   component protocols can become DoS vectors which are then used to
   attack other parts of the system.  Availability is an important
   aspect to consider in the analysis along other aspects.

3.2.  Trusted networks

   Some systems are thought of as being deployed only in a closed
   setting, where all the relevant nodes are under direct control of the
   network administrators.  Technologies developed for such networks
   tend to be optimized, at least initially, for these environments, and
   may lack security features necessary for different types of
   deployments.

   It is well known that many such systems evolve over time, grow, and
   get used and connected in new ways.  For instance, the collaboration
   and mergers between organizations, and new services for customers may
   change the system or its environment.  A system that used to be truly
   within an administrative domain may suddenly need to cross network



Arkko & Farrell         Expires January 15, 2021               [Page 18]


Internet-Draft       Internet Threat Model Evolution           July 2020


   boundaries or even run over the Internet.  As a result, it is also
   well known that it is good to ensure that underlying technologies
   used in such systems can cope with that evolution, for instance, by
   having the necessary security capabilities to operate in different
   environments.

   In general, the outside vs. inside security model is outdated for
   most situations, due to the complex and evolving networks and the
   need to support mixture of devices from different sources (e.g., BYOD
   networks).  Network virtualization also implies that previously clear
   notions of local area networks and physical proximity may create an
   entirely different reality from what appears from a simple notion of
   a local network.

   Similarly, even trusted, well-managed parties can be problematic,
   even when operating openly in the Internet.  Systems that collect
   data from a large number of Internet users, or that are used by a
   large number of devices have some inherent issues: large data stores
   attract attempts to use that data in a manner that is not consistent
   with the users' interests.  They can also become single points of
   failure through network management, software, or business failures.
   See also [I-D.arkko-arch-infrastructure-centralisation].

3.2.1.  Even closed networks can have compromised nodes

   This memo argues that the situation is even more dire than what was
   explained above.  It is impossible to ensure that all components in a
   network are actually trusted.  Even in a closed network with
   carefully managed components there may be compromised components, and
   this should be factored into the design of the system and protocols
   used in the system.

   For instance, during the Snowden revelations it was reported that
   internal communication flows of large content providers were
   compromised in an effort to acquire information from large numbers of
   end users.  This shows the need to protect not just communications
   targeted to go over the Internet, but in many cases also internal and
   control communications.

   Furthermore, there is a danger of compromised nodes, so
   communications security alone will be insufficient to protect against
   this.  The defences against this include limiting information within
   networks to the parties that have a need to know, as well as limiting
   control capabilities.  This is necessary even when all the nodes are
   under the control of the same network manager; the network manager
   needs to assume that some nodes and communications will be
   compromised, and build a system to mitigate or minimise attacks even
   under that assumption.



Arkko & Farrell         Expires January 15, 2021               [Page 19]


Internet-Draft       Internet Threat Model Evolution           July 2020


   Even airgapped networks can have these issues, as evidenced, for
   instance, by the Stuxnet worm.  The Internet is not the only form of
   connectivity, as most systems include, for instance, USB ports that
   proved to be the achilles heel of the targets in the Stuxnet case.
   More commonly, every system runs large amount of software, and it is
   often not practical or even possible to prevent compromised code even
   in a high-security setting, let alone in commercial or private
   networks.  Installation media, physical ports, both open source and
   proprietary programs, firmware, or even innocent-looking components
   on a circuit board can be suspect.  In addition, complex underlying
   computing platforms, such as modern CPUs with underlying security and
   management tools are prone to problems.

   In general, this means that one cannot entirely trust even a closed
   system where you picked all the components yourself.  Analysis for
   the security of many interesting real-world systems now commonly
   needs to include cross-component attacks, e.g., the use of car radios
   and other externally communicating devices as part of attacks
   launched against the control components such as brakes in a car
   [Savage].

3.3.  Balancing Threats

   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 are understood and protected against.  Nothing is this
   document should be taken as a blanket reason to provide no
   information to anyone, or (impractically) insist on encrypting
   everything, or other extreme measures.  But designers should be
   informed about the trade-offs they make.

   Sometimes there are higher-level mechanisms that provide safeguards
   for failures.  For instance, it is very difficult in general to
   protect against denial-of-service against compromised nodes on a
   communications path.  However, it may be possible to detect that a
   service has failed.

   Another example is from packet-carrying networks.  Payload traffic
   that has been properly protected with encryption does not provide
   much value to an attacker.  For instance, it does not always make
   sense to encrypt every packet transmission in a packet-carrying
   system where the traffic is already encrypted at other layers.  But
   it almost always makes sense to protect control communications and to
   understand the impacts of compromised nodes, particularly control
   nodes.






Arkko & Farrell         Expires January 15, 2021               [Page 20]


Internet-Draft       Internet Threat Model Evolution           July 2020


3.4.  Checklist for Protocol Designers

   The following topics are thought to be generally important for
   protocol designers to take into account:

   1.  Consider first principles in protecting information and systems,
       rather than following a specific pattern such as protecting
       information in a particular way or only at a particular protocol
       layer.  It is necessary to understand what assets there are, what
       components can be compromised, where interests may or may not be
       aligned, and what parties have a legitimate role in being a party
       to a specific information or a control task.

   2.  Once you have an asset, do not pass it onto others without
       serious consideration.  In other words, minimize information
       passed to others to guard against the potential compromise of
       that party.  As recommended in [RFC6973] data minimisation and
       additional encryption can be helpful - if applications don't ever
       see data, or a cleartext form of data, then they should have a
       harder time misbehaving.  Similarly, not defining new long-term
       identifiers, and not exposing existing ones, help in minimising
       risk.

   3.  Consider avoiding centralized resources.  While centralized
       components, resources, and functions are often simplest
       deployment models, there can be issues associated with them, for
       example meta-data leakage.  Consider also how you depend on
       infrastructure, such as DNS or BGP, and analyse potential
       outcomes in the event that the relevant infrastructure has been
       compromised (see, e.g., [DeepDive]).  Similarly, minimize passing
       of control functions to others.  Designers should balance the
       benefits of centralized resources or control points against the
       threats arising.  If it is not possible to avoid, find a way to
       allow the centralized resources to be selectable, depending on
       context and user settings.  As [RFC3935] says: " We embrace
       technical concepts such as decentralized control, edge-user
       empowerment and sharing of resources, because those concepts
       resonate with the core values of the IETF community."

   4.  Consider treating parties with which your protocol endpoints
       interact with suspicion, even if the communications are
       encrypted.  Other endpoints may misuse any information or control
       opportunity in the communication.  Similarly, even endpoints
       within your own system need to be treated with suspicion, as some
       may become compromised.  For instance, consider performing end-
       to-end protection via other parties: Information passed via
       another party who does not intrinsically need the information to
       perform its function should be protected end-to-end to its



Arkko & Farrell         Expires January 15, 2021               [Page 21]


Internet-Draft       Internet Threat Model Evolution           July 2020


       intended recipient.  This holds equally for sending TCP/IP
       packets, TLS connections, or application-layer interactions.  As
       [RFC8546] notes, it is a useful design rule to avoid "accidental
       invariance" (the deployment of on-path devices that over-time
       start to make assumptions about protocols).  However, it is also
       a necessary security design rule to avoid "accidental disclosure"
       where information originally thought to be benign and untapped
       over-time becomes a significant information leak.  This guideline
       can also be applied for different aspects of security, e.g.,
       confidentiality and integrity protection, depending on what the
       specific need for information is in the other parties.  Of
       course, depending on the situation end-to-end protection may have
       key management implications; this may not be possible in all
       situations.

   5.  Consider abuse-cases.  Protocol developers are typically most
       interested in a few specific use-cases for which they need
       solutions.  Expanding the threat model to consider adversarial
       behaviours [AbuseCases] calls for significant attention to be
       paid to potential abuses of whatever new or re-purposed
       technology is being considered.

   6.  Consider recovery from compromise or attack during protocol
       design - all widely used protocols will at some time be subject
       to successful attack, whether that is due to deployment or
       implementation error, or, less commonly, due to protocol design
       flaws.  For example, 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.

   7.  Consider linkability.  As discussed in [RFC6973] the ability to
       link or correlate different protocol messages with one another,
       or with external sources of information (e.g. public or private
       databases) can create privacy or security issues.  As an example,
       re-use of TLS session tickets can enable an observer to associate
       multiple TLS sessions regardless of changes in source or
       destination addressing, which may reduce privacy or help a bad
       actor in targeting an attack.  The same effects may result
       regardless of how protocol exchanges can be linked to one
       another.  Protocol designs that aim to prevent such linkage may
       produce have fewer unexpected or unwanted side-effects when
       deployed.

   8.  Consider the nature of modern protocol implementations.  Protocol
       endpoints are commonly no longer executed on what used be
       understood as a host system.  [StackEvo] The web and Javascript
       model clearly differs from traditional host models, but so do
       many server-side deployments, thanks to virtualisation.  At



Arkko & Farrell         Expires January 15, 2021               [Page 22]


Internet-Draft       Internet Threat Model Evolution           July 2020


       protocol design time assume that all endpoints will be run in
       virtualised environments where co-tenants and (sometimes)
       hypervisors are adversaries, and then analyse such scenarios.

4.  Areas requiring more study

   There may be value in further study on the topics below, with the
   goal of producing new tools to counter attacks and provide additional
   guidance for protocol designers.

   1.   Update the BCP for threat models and security considerations It
        may be time for the IETF to extend [RFC3552] to cover additional
        issues.  See also I-D.arkko-farrell-arch-model-t-3552-additions.

   2.   Update the BCP about pervasive monitoring It may be time for the
        IETF to extend [RFC7258] to cover additional issues.  See also
        I-D.arkko-farrell-arch-model-t-7258-additions.

   3.   Develop a BCP for privacy considerations: It may be time for the
        IETF to develop a BCP for privacy considerations, possibly
        starting from [RFC6973].

   4.   Isolation: Sophisticated users can sometimes deal with
        adversarial behaviours in applications by using different
        instances of those applications, for example, differently
        configured web browsers for use in different contexts.
        Applications (including web browsers) and operating systems are
        also building in isolation via use of different processes or
        sandboxing.  Protocol artefacts that relate to uses of such
        isolation mechanisms might be worth considering.  To an extent,
        the IETF has in practice already recognised some of these issues
        as being in-scope, e.g.  when considering the linkability issues
        with mechanisms such as TLS session tickets, or QUIC connection
        identifiers.

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



Arkko & Farrell         Expires January 15, 2021               [Page 23]


Internet-Draft       Internet Threat Model Evolution           July 2020


        to ensure that browsers themselves do not themselves enable new
        data collection points, e.g., via search, DNS, or other
        functions.

   6.   Transparency: Certificate transparency (CT) [RFC6962] has been
        an effective countermeasure for X.509 certificate mis-issuance,
        which used be a known application layer misbehaviour in the
        public web PKI.  CT can also help with post-facto detection of
        some infrastructure attacks where BGP or DNS weaknesses have
        been leveraged so that some 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
        GDPR [GDPRAccess] could lead to a desire to handle internal data
        structures and databases in ways that are reminiscent of CT,
        though clearly with significant authorisation being required and
        without the append-only nature of a CT log.

   7.   Same-Origin Policy: The Same-Origin Policy (SOP) [RFC6454]
        perhaps already provides an example of how going beyond the RFC
        3552 threat model can be useful.  Arguably, the existence of the
        SOP demonstrates that at least web browsers already consider the
        3552 model as being too limited.  (Clearly, differentiating
        between same and not-same origins implicitly assumes that some
        origins are not as trustworthy as others.)

   8.   Greasing: The TLS protocol [RFC8446] now supports the use of
        GREASE [I-D.ietf-tls-grease] as a way to mitigate on-path
        ossification.  While this technique is not likely to prevent any
        deliberate misbehaviours, it may provide a proof-of-concept that
        network protocol mechanisms can have impact in this space, if we
        spend the time to try analyse the incentives of the various
        parties.

   9.   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].  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.  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



Arkko & Farrell         Expires January 15, 2021               [Page 24]


Internet-Draft       Internet Threat Model Evolution           July 2020


           example, the client and authorization server may be under
           control of an attacker and collude to trick a user to gain
           access to resources.

   10.  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:

        *  For any protocol dependent on infrastructure like DNS or BGP,
           we ought analyse potential outcomes in the event the relevant
           infrastructure has been compromised

        *  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

        *  Despite the sunk costs, it may be worth re-considering
           infrastructure security mechanisms that have not been
           deployed, and hence are ineffective.

   11.  Trusted Computing: Various trusted computing mechanisms allow
        placing some additional trust on a particular endpoint.  This
        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
           devices have not been compromised.

        *  An outside party may be assured that someone who runs a
           device employs a particular software installation in that
           device, and that the software runs in a protected
           environment.

        IETF work such as TEEP [I-D.ietf-teep-architecture]
        [I-D.ietf-teep-protocol] and RATS [I-D.ietf-rats-eat] may be
        helpful in providing attestations to other nodes about a
        particular endpoint, or lifecycle management of such endpoints.

        One should note, however, that it is often not possible to fully
        protect endpoints (see, e.g., [Kocher2019] [Lipp2018]
        [I-D.taddei-smart-cless-introduction]
        [I-D.mcfadden-smart-endpoint-taxonomy-for-cless]).  And of
        course, a trusted computing may be set up and controlled by a
        party that itself is not trusted; a client that contacts a



Arkko & Farrell         Expires January 15, 2021               [Page 25]


Internet-Draft       Internet Threat Model Evolution           July 2020


        server that the server's owner runs in a trusted computing
        setting does not change the fact that the client and the
        server's owner may have different interests.  As a result, there
        is a need to prepare for the possibility that another party in a
        communication is not entirely trusted.

   12.  Trust Boundaries: Traditional forms of communication equipment
        have morphed into today's virtualized environments, where new
        trust boundaries exist, e.g., between different virtualisation
        layers.  And an application might consider itself trusted while
        not entirely trusting the underlying operating system.  A
        browser application wants to protect itself against Javascript
        loaded from a website, while the website considers itself and
        the Javascript an application that it wants to protect from the
        browser.  In general, there are multiple parties even in a
        single device, with differing interests, including some that
        have (or claim to) the interest of the human user in mind.

   13.  Re-consider protocol design "lore": It could be that this
        discussion demonstrates that it is timely to reconsider some
        protocol design "lore" as for example is done in
        [I-D.iab-protocol-maintenance].  More specifically, protocol
        extensibility mechanisms may inadvertently create vectors for
        abuse-cases, given that designers cannot fully analyse their
        impact at the time a new protocol is defined or standardised.
        One might conclude that a lack of extensibility could be a
        virtue for some new protocols, in contrast to earlier
        assumptions.  As pointed out by one commenter though, people can
        find ways to extend things regardless, if they feel the need.

   14.  Consider the potentially different defences against commercial
        data collection and surveillance.  There are similarities in
        these activities.  Tracking for commercial information
        collection may also have an indirect impact on making accidental
        data leaks or surveillance more feasible, given the data that
        exists about users.  However, the defences are likely still
        different, given that the defending and attacking parties are
        different.

   15.  Consider the user perspective: [I-D.nottingham-for-the-users]
        argues that, in relevant cases where there are conflicting
        requirements, the "IETF considers end users as its highest
        priority concern."  Doing so seems consistent with the expanded
        threat model being argued for here, so may indicate that a BCP
        in that space could also be useful.

   16.  Explicit agreements: When users and their devices provide
        information to network entities, it would perhaps be beneficial



Arkko & Farrell         Expires January 15, 2021               [Page 26]


Internet-Draft       Internet Threat Model Evolution           July 2020


        to have an opportunity for the users to state their requirements
        regarding the use of the information provided in this way.
        While the actual use of such requirements and the willingness of
        network entities to agree to them remains to be seen, at the
        moment even the technical means of doing this are limited.  For
        instance, it would be beneficial to be able to embed usage
        requirements within popular data formats.

        As appropriate, users could be made aware of the choices and
        policies offered.

5.  Conclusions

   There are few hard rules in dealing with the evolving threats
   discussed in this document.  However, we believe that Internet
   technology developers need to be aware of the issues beyond
   communications security, and consider them in design.  At the IETF it
   would be beneficial to include some of these considerations in the
   usual systematic security analysis of technologies under development.

   In particular, when the IETF develops infrastructure technology for
   the Internet (such as routing or naming systems), considering the
   impacts of data generated by those technologies is important.
   Minimising data collection from users, minimising the parties who get
   exposed to user data, and protecting data that is relayed or stored
   in systems should be a priority.

   A key focus area at the IETF has been the security of transport
   protocols, and how transport layer security can be best used to
   provide the right security for various applications.  However, more
   work is needed in equivalently broadly deployed tools for minimising
   or obfuscating information provided by users to other entities, and
   the use of end-to-end security through entities that are involved in
   the protocol exchange but who do not need to know everything that is
   being passed through them.

6.  Security Considerations

   The entire memo covers the security considerations.

7.  IANA Considerations

   There are no IANA considerations in this work.








Arkko & Farrell         Expires January 15, 2021               [Page 27]


Internet-Draft       Internet Threat Model Evolution           July 2020


8.  Informative References

   [AbuseCases]
              McDermott, J. and C. Fox, "Using abuse case models for
              security requirements analysis", IEEE Annual Computer
              Security Applications Conference (ACSAC'99),
              https://www.acsac.org/1999/papers/wed-b-1030-john.pdf ,
              1999.

   [AmIUnique]
              INRIA, ., "Am I Unique?", https://amiunique.org , 2020.

   [Attitude]
              "User Perceptions of Sharing, Advertising, and Tracking",
              Symposium on Usable Privacy and Security (SOUPS),
              https://www.usenix.org/conference/soups2015/proceedings/
              presentation/chanchary , 2015.

   [avleak]   Cox, J., "Leaked Documents Expose the Secretive Market for
              Your Web Browsing Data",
              https://www.vice.com/en_us/article/qjdkq7/
              avast-antivirus-sells-user-browsing-data-investigation ,
              2020.

   [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,
              https://arxiv.org/pdf/1801.02918.pdf , 2018.

   [Bloatware]
              Gamba, G., Rashed, M., Razaghpanah, A., Tapiado, J., and
              N. Vallina, "An Analysis of Pre-installed Android
              Software", arXiv preprint arXiv:1905.02713 (2019) , 2019.

   [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
              51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/
              stamp.jsp?arnumber=8436400 , 2018.




Arkko & Farrell         Expires January 15, 2021               [Page 28]


Internet-Draft       Internet Threat Model Evolution           July 2020


   [CommandAndControl]
              Botnet, ., "Creating botnet C&C server. What architecture
              should I use? IRC? HTTP?", Stackexchange.com question,
              https://security.stackexchange.com/questions/100577/
              creating-botnet-cc-server-what-architecture-should-i-use-
              irc-http , 2014.

   [Curated]  Hammad, M., Garcia, J., and S. MaleK, "A large-scale
              empirical study on the effects of code obfuscations on
              Android apps and anti-malware products", ACM International
              Conference on Software Engineering 2018,
              https://www.ics.uci.edu/~seal/
              publications/2018ICSE_Hammad.pdf , 2018.

   [DeepDive]
              Krebs on Security, ., "A Deep Dive on the Recent
              Widespread DNS Hijacking Attacks", krebsonsecurity.com
              blog, https://krebsonsecurity.com/2019/02/a-deep-dive-on-
              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
              Attack", Company statement: https://dyn.com/blog/
              dyn-statement-on-10212016-ddos-attack/ , 2016.

   [GDPRAccess]
              EU, ., "Right of access by the data subject", Article 15,
              GDPR, https://gdpr-info.eu/art-15-gdpr/ , n.d..

   [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,
              https://www.net.in.tum.de/fileadmin/bibtex/publications/
              papers/schlamp_TMA_1_2015.pdf , 2015.

   [Home]     Nthala, N. and I. Flechais, "Rethinking home network
              security", European Workshop on Usable Security
              (EuroUSEC), https://ora.ox.ac.uk/objects/
              uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa
              fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica
              tion%2Fpdf&type_of_work=Conference+item , 2018.




Arkko & Farrell         Expires January 15, 2021               [Page 29]


Internet-Draft       Internet Threat Model Evolution           July 2020


   [I-D.arkko-arch-dedr-report]
              Arkko, J. and T. Hardie, "Report from the IAB workshop on
              Design Expectations vs. Deployment Reality in Protocol
              Development", draft-arkko-arch-dedr-report-00 (work in
              progress), November 2019.

   [I-D.arkko-arch-infrastructure-centralisation]
              Arkko, J., "Centralised Architectures in Internet
              Infrastructure", draft-arkko-arch-infrastructure-
              centralisation-00 (work in progress), November 2019.

   [I-D.arkko-arch-internet-threat-model]
              Arkko, J., "Changes in the Internet Threat Model", draft-
              arkko-arch-internet-threat-model-01 (work in progress),
              July 2019.

   [I-D.farrell-etm]
              Farrell, S., "We're gonna need a bigger threat model",
              draft-farrell-etm-03 (work in progress), July 2019.

   [I-D.iab-protocol-maintenance]
              Thomson, M., "The Harmful Consequences of the Robustness
              Principle", draft-iab-protocol-maintenance-04 (work in
              progress), November 2019.

   [I-D.ietf-httpbis-expect-ct]
              estark@google.com, e., "Expect-CT Extension for HTTP",
              draft-ietf-httpbis-expect-ct-08 (work in progress),
              December 2018.

   [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-04 (work in
              progress), January 2020.

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-29 (work
              in progress), June 2020.

   [I-D.ietf-rats-eat]
              Mandyam, G., Lundblade, L., Ballesteros, M., and J.
              O'Donoghue, "The Entity Attestation Token (EAT)", draft-
              ietf-rats-eat-03 (work in progress), February 2020.






Arkko & Farrell         Expires January 15, 2021               [Page 30]


Internet-Draft       Internet Threat Model Evolution           July 2020


   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
              "Trusted Execution Environment Provisioning (TEEP)
              Architecture", draft-ietf-teep-architecture-11 (work in
              progress), July 2020.

   [I-D.ietf-teep-protocol]
              Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.
              Tsukamoto, "Trusted Execution Environment Provisioning
              (TEEP) Protocol", draft-ietf-teep-protocol-02 (work in
              progress), April 2020.

   [I-D.ietf-tls-esni]
              Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
              Encrypted Client Hello", draft-ietf-tls-esni-07 (work in
              progress), June 2020.

   [I-D.ietf-tls-grease]
              Benjamin, D., "Applying GREASE to TLS Extensibility",
              draft-ietf-tls-grease-04 (work in progress), August 2019.

   [I-D.lazanski-smart-users-internet]
              Lazanski, D., "An Internet for Users Again", draft-
              lazanski-smart-users-internet-00 (work in progress), July
              2019.

   [I-D.mcfadden-smart-endpoint-taxonomy-for-cless]
              McFadden, M., "Endpoint Taxonomy for CLESS", draft-
              mcfadden-smart-endpoint-taxonomy-for-cless-02 (work in
              progress), July 2020.

   [I-D.nottingham-for-the-users]
              Nottingham, M., "The Internet is for End Users", draft-
              nottingham-for-the-users-09 (work in progress), July 2019.

   [I-D.taddei-smart-cless-introduction]
              Taddei, A., Wueest, C., Roundy, K., and D. Lazanski,
              "Capabilities and Limitations of an Endpoint-only Security
              Solution", draft-taddei-smart-cless-introduction-02 (work
              in progress), January 2020.

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






Arkko & Farrell         Expires January 15, 2021               [Page 31]


Internet-Draft       Internet Threat Model Evolution           July 2020


   [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]
              Kocher, P., Horn, J., Fogh, A., Genkin, D., Gruss, D.,
              Haas, W., Hamburg, M., Lipp, M., Mangard, S., Prescher,
              T., Schwarz, M., and Y. Yarom, "Spectre Attacks:
              Exploiting Speculative Execution", 40th IEEE Symposium on
              Security and Privacy (S&P'19) , 2019.

   [LeakyBuckets]
              Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3
              Breaches", Bitdefender blog,
              https://businessinsights.bitdefender.com/
              worst-amazon-breaches , 2018.

   [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.,
              Yarom, Y., and M. Hamburg, "Meltdown: Reading Kernel
              Memory from User Space", 27th USENIX Security Symposium
              (USENIX Security 18) , 2018.

   [Mailbug]  Englehardt, S., Han, J., and A. Narayanan, "I never signed
              up for this! Privacy implications of email tracking",
              Proceedings on Privacy Enhancing Technologies 2018.1
              (2018): 109-126, https://www.degruyter.com/downloadpdf/j/
              popets.2018.2018.issue-1/popets-2018-0006/
              popets-2018-0006.pdf , 2018.

   [MeltdownAndSpectre]
              CISA, ., "Meltdown and Spectre Side-Channel Vulnerability
              Guidance", Alert (TA18-004A),
              https://www.us-cert.gov/ncas/alerts/TA18-004A , 2018.






Arkko & Farrell         Expires January 15, 2021               [Page 32]


Internet-Draft       Internet Threat Model Evolution           July 2020


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

   [RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
              Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
              <https://www.rfc-editor.org/info/rfc1958>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

   [RFC3935]  Alvestrand, H., "A Mission Statement for the IETF",
              BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
              <https://www.rfc-editor.org/info/rfc3935>.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <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,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/info/rfc6454>.

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <https://www.rfc-editor.org/info/rfc6480>.

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






Arkko & Farrell         Expires January 15, 2021               [Page 33]


Internet-Draft       Internet Threat Model Evolution           July 2020


   [RFC6797]  Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
              Transport Security (HSTS)", RFC 6797,
              DOI 10.17487/RFC6797, November 2012,
              <https://www.rfc-editor.org/info/rfc6797>.

   [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
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <https://www.rfc-editor.org/info/rfc6962>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <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
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/info/rfc7258>.

   [RFC7469]  Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
              Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
              2015, <https://www.rfc-editor.org/info/rfc7469>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC7817]  Melnikov, A., "Updated Transport Layer Security (TLS)
              Server Identity Check Procedure for Email-Related
              Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
              <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>.





Arkko & Farrell         Expires January 15, 2021               [Page 34]


Internet-Draft       Internet Threat Model Evolution           July 2020


   [RFC8240]  Tschofenig, H. and S. Farrell, "Report from the Internet
              of Things Software Update (IoTSU) Workshop 2016",
              RFC 8240, DOI 10.17487/RFC8240, September 2017,
              <https://www.rfc-editor.org/info/rfc8240>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

   [RFC8546]  Trammell, B. and M. Kuehlewind, "The Wire Image of a
              Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
              2019, <https://www.rfc-editor.org/info/rfc8546>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

   [Saltzer]  Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments
              in System Design", ACM TOCS, Vol 2, Number 4, pp 277-288 ,
              November 1984.

   [Savage]   Savage, S., "Modern Automotive Vulnerabilities: Causes,
              Disclosures, and Outcomes", USENIX , 2016.

   [SmartTV]  Malkin, N., Bernd, J., Johnson, M., and S. Egelman, "What
              Can't Data Be Used For? Privacy Expectations about Smart
              TVs in the U.S.", European Workshop on Usable Security
              (Euro USEC), https://www.ndss-symposium.org/wp-
              content/uploads/2018/06/
              eurousec2018_16_Malkin_paper.pdf" , 2018.

   [StackEvo]
              Trammell, B., Thomson, M., Howard, L., and T. Hardie,
              "What Is an Endpoint?", Unpublished work,
              https://github.com/stackevo/endpoint-draft/blob/master/
              draft-trammell-whats-an-endpoint.md , 2017.

   [Sybil]    Viswanath, B., Post, A., Gummadi, K., and A. Mislove, "An
              analysis of social network-based sybil defenses", ACM
              SIGCOMM Computer Communication Review 41(4), 363-374,
              https://conferences.sigcomm.org/sigcomm/2010/papers/
              sigcomm/p363.pdf , 2011.




Arkko & Farrell         Expires January 15, 2021               [Page 35]


Internet-Draft       Internet Threat Model Evolution           July 2020


   [TargetAttack]
              Osborne, C., "How hackers stole millions of credit card
              records from Target", ZDNET,
              https://www.zdnet.com/article/how-hackers-stole-millions-
              of-credit-card-records-from-target/ , 2014.

   [Toys]     Chu, G., Apthorpe, N., and N. Feamster, "Security and
              Privacy Analyses of Internet of Things Childrens' Toys",
              IEEE Internet of Things Journal 6.1 (2019): 978-985,
              https://arxiv.org/pdf/1805.02751.pdf , 2019.

   [Tracking]
              Ermakova, T., Fabian, B., Bender, B., and K. Klimek, "Web
              Tracking-A Literature Review on the State of Research",
              Proceedings of the 51st Hawaii International Conference on
              System Sciences, https://scholarspace.manoa.hawaii.edu/
              bitstream/10125/50485/paper0598.pdf , 2018.

   [Troll]    Stewart, L., Arif, A., and K. Starbird, "Examining trolls
              and polarization with a retweet network", ACM Workshop on
              Misinformation and Misbehavior Mining on the Web,
              https://faculty.washington.edu/kstarbi/
              examining-trolls-polarization.pdf , 2018.

   [Unread]   Obar, J. and A. Oeldorf, "The biggest lie on the
              internet{:} Ignoring the privacy policies and terms of
              service policies of social networking services",
              Information, Communication and Society (2018): 1-20 ,
              2018.

   [Vpns]     Khan, M., DeBlasio, J., Voelker, G., Snoeren, A., Kanich,
              C., and N. Vallina, "An empirical analysis of the
              commercial VPN ecosystem", ACM Internet Measurement
              Conference 2018 (pp. 443-456),
              https://eprints.networks.imdea.org/1886/1/
              imc18-final198.pdf , 2018.

Appendix A.  Changes from previous version

   The -04 version of the draft made the following changes:

   o  Split the RFC 3552 and RFC 7258 changes to separate documents.

   o  Added a discussion of assets.

   o  Shortened the guidelines and converted it to a "designer's
      checklist" list.




Arkko & Farrell         Expires January 15, 2021               [Page 36]


Internet-Draft       Internet Threat Model Evolution           July 2020


   o  Moved the end-to-end security via third parties study item to the
      checklist, and added a discussion about key management to it.

   o  Added a discussion of differences between commercial data
      collection and surveillance.

   o  Shortened the conclusions, while avoiding making overly strong
      claims.

Appendix B.  Contributors

   Eric Rescorla and Chris Wood provided much of the text in
   Section 2.3.1.4 and item 2 of Section 4.

Appendix C.  Acknowledgements

   The authors would like to thank the IAB:

   Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin
   Li, Erik Nordmark, Mark Nottingham, Melinda Shore, Jeff Tantsura,
   Martin Thomson, Brian Trammel, Mirja Kuhlewind, and Colin Perkins.

   The authors would also like to thank the participants of the IETF
   SAAG meeting where this topic was discussed:

   Harald Alvestrand, Roman Danyliw, Daniel Kahn Gilmore, Wes Hardaker,
   Bret Jordan, Ben Kaduk, Dominique Lazanski, Eliot Lear, Lawrence
   Lundblade, Kathleen Moriarty, Kirsty Paine, Eric Rescorla, Ali
   Rezaki, Mohit Sethi, Ben Schwartz, Dave Thaler, Paul Turner, David
   Waltemire, and Jeffrey Yaskin.

   The authors would also like to thank the participants of the IAB 2019
   DEDR workshop:

   Tuomas Aura, Vittorio Bertola, Carsten Bormann, Stephane Bortzmeyer,
   Alissa Cooper, Hannu Flinck, Carl Gahnberg, Phillip Hallam-Baker, Ted
   Hardie, Paul Hoffman, Christian Huitema, Geoff Huston, Konstantinos
   Komaitis, Mirja Kuhlewind, Dirk Kutscher, Zhenbin Li, Julien
   Maisonneuve, John Mattson, Moritz Muller, Joerg Ott, Lucas Pardue,
   Jim Reid, Jan-Frederik Rieckers, Mohit Sethi, Melinda Shore, Jonne
   Soininen, Andrew Sullivan, and Brian Trammell.

   The authors would also like to thank the participants of the November
   2016 meeting at the IETF:

   Carsten Bormann, Randy Bush, Tommy C, Roman Danyliw, Ted Hardie,
   Christian Huitema, Ben Kaduk, Dirk Kutscher, Dominique Lazanski, Eric
   Rescorla, Ali Rezaki, Mohit Sethi, Melinda Shore, Martin Thomson, and



Arkko & Farrell         Expires January 15, 2021               [Page 37]


Internet-Draft       Internet Threat Model Evolution           July 2020


   Robin Wilton ... (missing many people... did we have minutes other
   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
   insightful comments and discussions in this space.

Authors' Addresses

   Jari Arkko
   Ericsson
   Valitie 1B
   Kauniainen
   Finland

   Email: jari.arkko@piuha.net


   Stephen Farrell
   Trinity College Dublin
   College Green
   Dublin
   Ireland

   Email: stephen.farrell@cs.tcd.ie

























Arkko & Farrell         Expires January 15, 2021               [Page 38]