draft-arkko-farrell-arch-model-t-00.txt   draft-arkko-farrell-arch-model-t.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational S. Farrell Intended status: Informational S. Farrell
Expires: May 7, 2020 Trinity College Dublin Expires: June 17, 2020 Trinity College Dublin
November 04, 2019 December 15, 2019
Challenges and Changes in the Internet Threat Model Challenges and Changes in the Internet Threat Model
draft-arkko-farrell-arch-model-t-00 draft-arkko-farrell-arch-model-t-01
Abstract Abstract
Communications security has been at the center of many security Communications security has been at the center of many security
improvements in the Internet. The goal has been to ensure that improvements in the Internet. The goal has been to ensure that
communications are protected against outside observers and attackers. communications are protected against outside observers and attackers.
This memo suggests that the existing threat model, while important This memo suggests that the existing threat model, while important
and still valid, is no longer alone sufficient to cater for the and still valid, is no longer alone sufficient to cater for the
pressing security issues in the Internet. For instance, it is also pressing security issues in the Internet. For instance, it is also
necessary to protect systems against endpoints that are compromised, necessary to protect systems against endpoints that are compromised,
malicious, or whose interests simply do not align with the interests malicious, or whose interests simply do not align with the interests
of the users. While such protection is difficult, there are some of the users. While such protection is difficult, there are some
measures that can be taken. measures that can be taken.
It is particularly important to ensure that as we continue to develop It is particularly important to ensure that as we continue to develop
Internet technology, non-communications security related threats are Internet technology, non-communications security related threats, and
properly understood. privacy issues, are properly understood.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020. This Internet-Draft will expire on June 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Observations . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Communications Security Improvements . . . . . . . . . . 5 2.1. Communications Security Improvements . . . . . . . . . . 6
2.2. Beyond Communications Security . . . . . . . . . . . . . 6 2.2. Beyond Communications Security . . . . . . . . . . . . . 6
2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Deliberate adversarial behaviour in applications . . 8 2.3.1. Deliberate adversarial behaviour in applications . . 9
2.3.2. Inadvertent adversarial behaviours . . . . . . . . . 13 2.3.2. Inadvertent adversarial behaviours . . . . . . . . . 13
3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. The Role of End-to-end . . . . . . . . . . . . . . . . . 14 3.1. The Role of End-to-end . . . . . . . . . . . . . . . . . 14
3.2. Trusted networks . . . . . . . . . . . . . . . . . . . . 16 3.2. Trusted networks . . . . . . . . . . . . . . . . . . . . 16
3.2.1. Even closed networks can have compromised nodes . . . 17 3.2.1. Even closed networks can have compromised nodes . . . 17
3.3. Balancing Threats . . . . . . . . . . . . . . . . . . . . 18 3.3. Balancing Threats . . . . . . . . . . . . . . . . . . . . 18
4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Basic Guidelines . . . . . . . . . . . . . . . . . . . . 18 4.1. Basic Guidelines . . . . . . . . . . . . . . . . . . . . 19
4.2. Potential Further Guidelines . . . . . . . . . . . . . . 20 4.2. Potential Further Guidelines . . . . . . . . . . . . . . 21
4.2.1. Consider ABuse-cases as well as use-cases . . . . . . 20 4.2.1. Consider ABuse-cases as well as use-cases . . . . . . 21
4.2.2. Isolation . . . . . . . . . . . . . . . . . . . . . . 20 4.2.2. Isolation . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3. Transparency . . . . . . . . . . . . . . . . . . . . 20 4.2.3. Transparency . . . . . . . . . . . . . . . . . . . . 21
4.2.4. Minimise . . . . . . . . . . . . . . . . . . . . . . 21 4.2.4. Minimise . . . . . . . . . . . . . . . . . . . . . . 22
4.2.5. Same-Origin Policy . . . . . . . . . . . . . . . . . 21 4.2.5. Same-Origin Policy . . . . . . . . . . . . . . . . . 22
4.2.6. Greasing . . . . . . . . . . . . . . . . . . . . . . 21 4.2.6. Greasing . . . . . . . . . . . . . . . . . . . . . . 22
4.2.7. Generalise OAuth Threat Model . . . . . . . . . . . . 21 4.2.7. Generalise OAuth Threat Model . . . . . . . . . . . . 22
4.2.8. Look again at how well we're securing infrastructure 22 4.2.8. Look again at how well we're securing infrastructure 23
4.2.9. Consider recovery from attack as part of protocol 4.2.9. Consider recovery from attack as part of protocol
design . . . . . . . . . . . . . . . . . . . . . . . 22 design . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.10. Don't think in terms of hosts . . . . . . . . . . . . 22 4.2.10. Don't think in terms of hosts . . . . . . . . . . . . 23
4.3. Does IETF Analysis of Protocols Need to Change? . . . . . 23 4.2.11. Trusted Computing . . . . . . . . . . . . . . . . . . 24
4.3.1. Develop a BCP for privacy considerations . . . . . . 23 4.2.12. Trust Boundaries . . . . . . . . . . . . . . . . . . 24
4.3.2. Re-consider protocol design "lore" . . . . . . . . . 23 4.3. Does IETF Analysis of Protocols Need to Change? . . . . . 25
4.3.3. Consider the user perspective . . . . . . . . . . . . 23 4.3.1. Develop a BCP for privacy considerations . . . . . . 25
4.3.4. Potential changes in RFC 3552 . . . . . . . . . . . . 24 4.3.2. Re-consider protocol design "lore" . . . . . . . . . 25
4.3.5. Potential Changes in RFC 7258 . . . . . . . . . . . . 25 4.3.3. Consider the user perspective . . . . . . . . . . . . 25
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.4. Potential changes in RFC 3552 . . . . . . . . . . . . 25
6. Informative References . . . . . . . . . . . . . . . . . . . 26 4.3.5. Potential Changes in RFC 7258 . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 6. Informative References . . . . . . . . . . . . . . . . . . . 28
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
Communications security has been at the center of many security Communications security has been at the center of many security
improvements in the Internet. The goal has been to ensure that improvements in the Internet. The goal has been to ensure that
communications are protected against outside observers and attackers. communications are protected against outside observers and attackers.
At the IETF, this approach has been formalized in BCP 72 [RFC3552], At the IETF, this approach has been formalized in BCP 72 [RFC3552],
which defined the Internet threat model in 2003. which defined the Internet threat model in 2003.
The purpose of a threat model is to outline what threats exist in The purpose of a threat model is to outline what threats exist in
skipping to change at page 4, line 12 skipping to change at page 4, line 12
not all of their aspects have been fully protected. Fortunately, not all of their aspects have been fully protected. Fortunately,
there are ongoing projects working on improvements. there are ongoing projects working on improvements.
o Adversaries have increased their pressure against other avenues of o Adversaries have increased their pressure against other avenues of
attack, from compromising devices to legal coercion of centralized attack, from compromising devices to legal coercion of centralized
endpoints in conversations. endpoints in conversations.
o New adversaries and risks have arisen, e.g., due to creation of o New adversaries and risks have arisen, e.g., due to creation of
large centralized information sources. large centralized information sources.
o While communications-security does seem to be required to protect
privacy, more is needed.
In short, attacks are migrating towards the currently easier targets, In short, attacks are migrating towards the currently easier targets,
which no longer necessarily include direct attacks on traffic flows. which no longer necessarily include direct attacks on traffic flows.
In addition, trading information about users and ability to influence In addition, trading information about users and ability to influence
them has become a common practice for many Internet services, often them has become a common practice for many Internet services, often
without consent of the users. without users understanding those practices.
This memo suggests that the existing threat model, while important This memo suggests that the existing threat model, while important
and still valid, is no longer alone sufficient to cater for the and still valid, is no longer alone sufficient to cater for the
pressing security issues in the Internet. For instance, while it pressing security issues in the Internet. For instance, while it
continues to be very important to protect Internet communications continues to be very important to protect Internet communications
against outsiders, it is also necessary to protect systems against against outsiders, it is also necessary to protect systems against
endpoints that are compromised, malicious, or whose interests simply endpoints that are compromised, malicious, or whose interests simply
do not align with the interests of the users. do not align with the interests of the users.
Of course, there are many trade-offs in the Internet on who one Of course, there are many trade-offs in the Internet on who one
skipping to change at page 4, line 50 skipping to change at page 5, line 4
monitoring. Further down the road, updated threat models could monitoring. Further down the road, updated threat models could
result in changes in BCP 72 [RFC3552] (guidelines for writing result in changes in BCP 72 [RFC3552] (guidelines for writing
security considerations) and BCP 188 [RFC7258] (pervasive security considerations) and BCP 188 [RFC7258] (pervasive
monitoring), to include proper consideration of non-communications monitoring), to include proper consideration of non-communications
security threats. security threats.
It may also be necessary to have dedicated guidance on how systems It may also be necessary to have dedicated guidance on how systems
design and architecture affect security. The sole consideration of design and architecture affect security. The sole consideration of
communications security aspects in designing Internet protocols may communications security aspects in designing Internet protocols may
lead to accidental or increased impact of security issues elsewhere. lead to accidental or increased impact of security issues elsewhere.
For instance, allowing a participant to unnecessarily collect or For instance, allowing a participant to unnecessarily collect or
receive information may lead to a similar effect as described in receive information may lead to a similar effect as described in
[RFC8546] for protocols: over time, unnecessary information will get [RFC8546] for protocols: over time, unnecessary information will get
used with all the associated downsides, regardless of what deployment used with all the associated downsides, regardless of what deployment
expectations there were during protocol design. expectations there were during protocol design.
This memo does not stand alone. To begin with, it is a merge of
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
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 The rest of this memo is organized as follows. Section 2 makes some
observations about the situation, with respect to communications observations about the situation, with respect to communications
security and beyond. The section also provides a number of real- security and beyond. The section also provides a number of real-
world examples. world examples.
Section 3 discusses some high-level implications that can be drawn, 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- such as the need to consider what the "ends" really are in an "end-
to-end" communication. to-end" communication.
Section 4 discusses the potential remedies, both from the point of Section 4 discusses some potential remedies, both from the point of
view of a system design, as well as from the point of IETF procedures view of a system design, as well as from the point of IETF procedures
and recommended analysis procedures when designing new protocols. and recommended analysis procedures when designing new protocols.
For instance, Section 4.1 will also discuss high-level guidance to For instance, Section 4.1 will also discuss high-level guidance to
addressing these threats, and Section 4.3.4 suggests some potential addressing these threats, and Section 4.3.4 suggests some potential
changes to the definition of the IETF's "Internet Threat Model". It changes to the definition of the IETF's "Internet Threat Model". It
is also apparent that the dangers posed by pervasive monitoring need is also apparent that the dangers posed by pervasive monitoring need
to be taken in a broader light, given the evolution of the threats to be taken in a broader light, given the evolution of the threats
beyond communications security. beyond communications security.
Comments are solicited on these and other aspects of this document. Comments are solicited on these and other aspects of this document.
The best place for discussion is on the arch-discuss list The best place for discussion is on the arch-discuss list
(https://www.ietf.org/mailman/listinfo/Architecture-discuss). (https://www.ietf.org/mailman/listinfo/Architecture-discuss).
Finally, Section 5 draws some conclusions for next steps. Finally, Section 5 draws some conclusions for next steps.
2. Observations 2. Observations
2.1. Communications Security Improvements 2.1. Communications Security Improvements
The fraction of Internet traffic that is cryptographically protected Being able to ask about threat model improvements is due to progress
has grown tremendously in the last few years. Several factors have already made: The fraction of Internet traffic that is
contributed to this change, from Snowden revelations to business cryptographically protected has grown tremendously in the last few
reasons and to better available technology such as HTTP/2 [RFC7540], years. Several factors have contributed to this change, from Snowden
TLS 1.3 [RFC8446], QUIC [I-D.ietf-quic-transport]. 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 In many networks, the majority of traffic has flipped from being
cleartext to being encrypted. Reaching the level of (almost) all cleartext to being encrypted. Reaching the level of (almost) all
traffic being encrypted is no longer something unthinkable but rather traffic being encrypted is no longer something unthinkable but rather
a likely outcome in a few years. a likely outcome in a few years.
At the same time, technology developments and policy choices have At the same time, technology developments and policy choices have
driven the scope of cryptographic protection from protecting only the driven the scope of cryptographic protection from protecting only the
pure payload to protecting much of the rest as well, including far pure payload to protecting much of the rest as well, including far
more header and meta-data information than was protected before. For more header and meta-data information than was protected before. For
skipping to change at page 6, line 25 skipping to change at page 6, line 48
been resolved - far from it. But the situation is definitely been resolved - far from it. But the situation is definitely
different from what it was a few years ago. Remaining issues will be different from what it was a few years ago. Remaining issues will be
and are worked on; the fight between defense and attack will also and are worked on; the fight between defense and attack will also
continue. Communications security will stay at the top of the agenda continue. Communications security will stay at the top of the agenda
in any Internet technology development. in any Internet technology development.
2.2. Beyond Communications Security 2.2. Beyond Communications Security
There are, however, significant issues beyond communications security There are, however, significant issues beyond communications security
in the Internet. To begin with, it is not necessarily clear that one in the Internet. To begin with, it is not necessarily clear that one
can trust all the endpoints. can trust all the endpoints in any protocol interaction.
Of course, the endpoints were never trusted, but the pressures Of course, the endpoints were never trusted, but the pressures
against endpoints issues seem to be mounting. For instance, the against endpoints issues seem to be mounting. For instance, the
users may not be in as much control over their own devices as they users may not be in as much control over their own devices as they
used to be due to manufacturer-controlled operating system used to be due to manufacturer-controlled operating system
installations and locked device ecosystems. And within those installations and locked device ecosystems. And within those
ecosystems, even the applications that are available tend to have ecosystems, even the applications that are available tend to have
features that users by themselves would most likely not desire to privileges that users by themselves would most likely not desire
have, such as excessive rights to media, location, and peripherals. those applications have, such as excessive rights to media, location,
There are also designated efforts by various authorities to hack end- and peripherals. There are also designated efforts by various
user devices as a means of intercepting data about the user. 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 The situation is different, but not necessarily better on the side of
servers. The pattern of communications in today's Internet is almost servers. The pattern of communications in today's Internet is almost
always via a third party that has at least as much information than always via a third party that has at least as much information as the
the other parties have. For instance, these third parties are other parties have. For instance, these third parties are typically
typically endpoints for any transport layer security connections, and endpoints for any transport layer security connections, and able to
able to see any communications or other messaging in cleartextx. see any communications or other messaging in cleartext. There are
There are some exceptions, of course, e.g., messaging applications some exceptions, of course, e.g., messaging applications with end-to-
with end-to-end protection. end protection.
With the growth of trading users' information by many of these third With the growth of trading users' information by many of these third
parties, it becomes necessary to take precautions against endpoints parties, it becomes necessary to take precautions against endpoints
that are compromised, malicious, or whose interests simply do not that are compromised, malicious, or whose interests simply do not
align with the interests of the users. align with the interests of the users.
Specifically, the following issues need attention: Specifically, the following issues need attention:
o Security of users' devices and the ability of the user to control o Security of users' devices and the ability of the user to control
their own equipment. their own equipment.
skipping to change at page 7, line 32 skipping to change at page 8, line 6
o Network and application architectures that result in a lot of o Network and application architectures that result in a lot of
information collected in a (logically) central location. information collected in a (logically) central location.
o Leverage and control points outside the hands of the users or end- o Leverage and control points outside the hands of the users or end-
user device owners. user device owners.
For instance, while e-mail transport security [RFC7817] has become For instance, while e-mail transport security [RFC7817] has become
much more widely distributed in recent years, progress in securing much more widely distributed in recent years, progress in securing
e-mail messages between users has been much slower. This has lead to e-mail messages between users has been much slower. This has lead to
a situation where e-mail content is considered a critical resource by a situation where e-mail content is considered a critical resource by
mail providers who use it for machine learning, advertisement some mail service providers who use the content for machine learning,
targeting, and other purposes. 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 sercurity protocols).
The Domain Name System (DNS) shows signs of ageing but due to the The Domain Name System (DNS) shows signs of ageing but due to the
legacy of deployed systems has changed very slowly. Newer technology legacy of deployed systems has changed very slowly. Newer technology
[RFC8484] developed at the IETF enables DNS queries to be performed [RFC8484] developed at the IETF enables DNS queries to be performed
confidentially, but its deployment is happening mostly in browsers confidentially, but its initial deployment is happening mostly in
that use global DNS resolver services, such as Cloudflare's 1.1.1.1 browsers that use global DNS resolver services, such as Cloudflare's
or Google's 8.8.8.8. This results in faster evolution and better 1.1.1.1 or Google's 8.8.8.8. This results in faster evolution and
security for end users. better security for end users.
However, if one steps back and considers the overall security effects However, if one steps back and considers the potential security and
of these developments, the resulting effects can be different. While privacy effects of these developments, the outcome could appear
the security of the actual protocol exchanges improves with the different. While the security and confidentiality of the protocol
introduction of this new technology, at the same time this implies a exchanges improves with the introduction of this new technology, at
move from using a worldwide distributed set of DNS resolvers into the same time this could lead to a move from using a worldwide
more centralised global resolvers. While these resolvers are very distributed set of DNS resolvers into a far smaller set of
well maintained (and a great service), they are potential high-value 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. targets for pervasive monitoring and Denial-of-Service (DoS) attacks.
In 2016, for example, DoS attacks were launched against Dyn, one of In 2016, for example, DoS attacks were launched against Dyn, one of
the largest DNS providers, leading to some outages. It is difficult the largest DNS providers, leading to some outages. It is difficult
to imagine that DNS resolvers wouldn't be a target in many future to imagine that DNS resolvers wouldn't be a target in many future
attacks or pervasive monitoring projects. attacks or pervasive monitoring projects.
Unfortunately, there is little that even large service providers can Unfortunately, there is little that even large service providers can
do to refuse authority-sanctioned pervasive monitoring. As a result do to not be a DDoS target, not to refuse authority-sanctioned
it seems that the only reasonable course of defense is to ensure that pervasive monitoring. As a result it seems that a reasonable defense
no such information or control point exists. strategy may be to aim for outcomes where such highly centralised
control points are unecessary or don't handle sensitive data.
(Recalling that with the DNS, information 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 about the perils of centralised solutions in There are other examples of the perils of centralised solutions in
Internet infrastructure. The DNS example involved an interesting Internet infrastructure. The DNS example involves an interesting
combination of information flows (who is asking for what domain combination of information flows (who is asking for what domain
names) as well as a potential ability to exert control (what domains names) as well as a potential ability to exert control (what domains
will actually resolve to an address). Routing systems are primarily will actually resolve to an address). Routing systems are primarily
about control. While there are intra-domain centralized routing about control. While there are intra-domain centralized routing
solutions (such as PCE [RFC4655]), a control within a single solutions (such as PCE [RFC4655]), a control within a single
administrative domain is usually not the kind of centralization that administrative domain is usually not the kind of centralization that
we would be worried about. Global centralization would be much more we would be worried about. Global centralization would be much more
concerning. Fortunately, global Internet routing is performed a concerning. Fortunately, global Internet routing is performed a
among peers. However, controls could be introduced even in this among peers. However, controls could be introduced even in this
global, distributed system. To secure some of the control exchanges, global, distributed system. To secure some of the control exchanges,
skipping to change at page 9, line 19 skipping to change at page 9, line 50
network actors as potential adversaries despite the many examples of network actors as potential adversaries despite the many examples of
network operators who do act primarily in the best interests of their network operators who do act primarily in the best interests of their
users. users.
2.3.1.1. Malware in curated application stores 2.3.1.1. Malware in curated application stores
Despite the best efforts of curators, so-called App-Stores frequently Despite the best efforts of curators, so-called App-Stores frequently
distribute malware of many kinds and one recent study [Curated] distribute malware of many kinds and one recent study [Curated]
claims that simple obfuscation enables malware to avoid detection by claims that simple obfuscation enables malware to avoid detection by
even sophisticated operators. Given the scale of these deployments, even sophisticated operators. Given the scale of these deployments,
ditribution of even a small percentage of malware-infected distribution of even a small percentage of malware-infected
applictions can affect a huge number of people. applictions can affect a huge number of people.
2.3.1.2. Virtual private networks (VPNs) 2.3.1.2. Virtual private networks (VPNs)
Virtual private networks (VPNs) are supposed to hide user traffic to Virtual private networks (VPNs) are supposed to hide user traffic to
various degrees depending on the particular technology chosen by the various degrees depending on the particular technology chosen by the
VPN provider. However, not all VPNs do what they say, some for VPN provider. However, not all VPNs do what they say, some for
example misrepresenting the countries in which they provide vantage example misrepresenting the countries in which they provide vantage
points [Vpns]. points [Vpns].
skipping to change at page 13, line 17 skipping to change at page 13, line 42
Not all adversarial behaviour by applications is deliberate, some is Not all adversarial behaviour by applications is deliberate, some is
likely due to various levels of carelessness (some quite likely due to various levels of carelessness (some quite
understandable, others not) and/or due to erroneous assumptions about understandable, others not) and/or due to erroneous assumptions about
the environments in which those applications (now) run. the environments in which those applications (now) run.
We very briefly list some such cases: We very briefly list some such cases:
o Application abuse for command and control, for example, use of IRC o Application abuse for command and control, for example, use of IRC
or apache logs for [CommandAndControl] or apache logs for [CommandAndControl]
o Carelessly [LeakyBuckets], for example, lots of Amazon S3 leaks o Carelessly leaky data stores [LeakyBuckets], for example, lots of
showing that careless admins can too easily cause application Amazon S3 leaks showing that careless admins can too easily cause
server data to become available to adversaries application server data to become available to adversaries
o Virtualisation exposing secrets, for example, [MeltdownAndSpectre] o Virtualisation exposing secrets, for example, Meltdown and Spectre
and similar side-channels [MeltdownAndSpectre] [Kocher2019] [Lipp2018] and other similar
side-channel attacks.
o Compromised badly-maintained web sites, that for example, have led o Compromised badly-maintained web sites, that for example, have led
to massive online [Passwords]. to massive online [Passwords].
o Supply-chain attacks, for example, the [TargetAttack] or malware o Supply-chain attacks, for example, the [TargetAttack] or malware
within pre-installed applications on Android phones [Bloatware]. within pre-installed applications on Android phones [Bloatware].
o Breaches of major service providers, that many of us might have o Breaches of major service providers, that many of us might have
assumed would be sufficiently capable to be the best large-scale assumed would be sufficiently capable to be the best large-scale
"Identity providers", for example: "Identity providers", for example:
skipping to change at page 17, line 5 skipping to change at page 17, line 27
environments. environments.
In general, the outside vs. inside security model is outdated for In general, the outside vs. inside security model is outdated for
most situations, due to the complex and evolving networks and the most situations, due to the complex and evolving networks and the
need to support mixture of devices from different sources (e.g., BYOD need to support mixture of devices from different sources (e.g., BYOD
networks). Network virtualization also implies that previously clear networks). Network virtualization also implies that previously clear
notions of local area networks and physical proximity may create an notions of local area networks and physical proximity may create an
entirely different reality from what appears from a simple notion of entirely different reality from what appears from a simple notion of
a local network. 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 3.2.1. Even closed networks can have compromised nodes
This memo argues that the situation is even more dire than what was 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 explained above. It is impossible to ensure that all components in a
network are actually trusted. Even in a closed network with network are actually trusted. Even in a closed network with
carefully managed components there may be compromised components, and carefully managed components there may be compromised components, and
this should be factored into the design of the system and protocols this should be factored into the design of the system and protocols
used in the system. used in the system.
For instance, during the Snowden revelations it was reported that For instance, during the Snowden revelations it was reported that
internal communication flows of large content providers were internal communication flows of large content providers were
compromised in an effort to acquire information from large number of compromised in an effort to acquire information from large numbers of
end users. This shows the need to protect not just communications end users. This shows the need to protect not just communications
targeted to go over the Internet, but in many cases also internal and targeted to go over the Internet, but in many cases also internal and
control communications. control communications.
Furthermore, there is a danger of compromised nodes, so Furthermore, there is a danger of compromised nodes, so
communications security alone will be insufficient to protect against communications security alone will be insufficient to protect against
this. The defences against this include limiting information within this. The defences against this include limiting information within
networks to the parties that have a need to know, as well as limiting 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 control capabilities. This is necessary even when all the nodes are
under the control of the same network manager; the network manager under the control of the same network manager; the network manager
needs to assume that some nodes and communications will be needs to assume that some nodes and communications will be
compromised, and build a system to mitigate or minimise attacks even compromised, and build a system to mitigate or minimise attacks even
under that assumption. under that assumption.
Even airgapped networks can have these issues, as evidenced, for Even airgapped networks can have these issues, as evidenced, for
instance, by the Stuxnet worm. The Internet is not the only form of instance, by the Stuxnet worm. The Internet is not the only form of
connectivity, as most systems include, for instance, USB ports that connectivity, as most systems include, for instance, USB ports that
proved to be the achilles heel of the targets in the Stuxnet case. 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 More commonly, every system runs large amount of software, and it is
often not practical or even possible to black the software to prevent often not practical or even possible to prevent compromised code even
compromised code even in a high-security setting, let alone in in a high-security setting, let alone in commercial or private
commercial or private networks. Installation media, physical ports, networks. Installation media, physical ports, both open source and
both open source and proprietary programs, firmware, or even proprietary programs, firmware, or even innocent-looking components
innocent-looking components on a circuit board can be suspect. In on a circuit board can be suspect. In addition, complex underlying
addition, complex underlying computing platforms, such as modern CPUs computing platforms, such as modern CPUs with underlying security and
with underlying security and management tools are prone for problems. management tools are prone to problems.
In general, this means that one cannot entirely trust even a closed In general, this means that one cannot entirely trust even a closed
system where you picked all the components yourself. Analysis for system where you picked all the components yourself. Analysis for
the security of many interesting real-world systems now commonly the security of many interesting real-world systems now commonly
needs to include cross-component attacks, e.g., the use of car radios needs to include cross-component attacks, e.g., the use of car radios
and other externally communicating devices as part of attacks and other externally communicating devices as part of attacks
launched against the control components such as breaks in a car launched against the control components such as breaks in a car
[Savage]. [Savage].
3.3. Balancing Threats 3.3. Balancing Threats
skipping to change at page 18, line 50 skipping to change at page 19, line 32
protocol designers: protocol designers:
1. Consider first principles in protecting information and systems, 1. Consider first principles in protecting information and systems,
rather than following a specific pattern such as protecting rather than following a specific pattern such as protecting
information in a particular way or at a particular protocol information in a particular way or at a particular protocol
layer. It is necessary to understand what components can be layer. It is necessary to understand what components can be
compromised, where interests may or may not be aligned, and what compromised, where interests may or may not be aligned, and what
parties have a legitimate role in being a party to a specific parties have a legitimate role in being a party to a specific
information or a control task. information or a control task.
2. Minimize information passed to others: Information passed to 2. Once you have something, do not pass it onto others without
another party in a protocol exchange should be minimized to guard serious consideration: In other words, minimize information
against the potential compromise of that party. passed to others. Information passed to another party in a
protocol exchange should be minimized to guard against the
potential compromise of that party.
3. Perform end-to-end protection via other parties: Information 3. Perform end-to-end protection via other parties: Information
passed via another party who does not intrinsically need the passed via another party who does not intrinsically need the
information to perform its function should be protected end-to- information to perform its function should be protected end-to-
end to its intended recipient. This guideline is general, and end to its intended recipient. This guideline is general, and
holds equally for sending TCP/IP packets, TLS connections, or holds equally for sending TCP/IP packets, TLS connections, or
application-layer interactions. As [RFC8546] notes, it is a application-layer interactions. As [RFC8546] notes, it is a
useful design rule to avoid "accidental invariance" (the useful design rule to avoid "accidental invariance" (the
deployment of on-path devices that over-time start to make deployment of on-path devices that over-time start to make
assumptions about protocols). However, it is also a necessary assumptions about protocols). However, it is also a necessary
skipping to change at page 23, line 16 skipping to change at page 24, line 5
programme, appears to posit the same kind of thesis. In the stackevo programme, appears to posit the same kind of thesis. In the stackevo
case, that work would presumably lead to some new definition of case, that work would presumably lead to some new definition of
protocol endpoint, but (consensus on) such a definition may not be protocol endpoint, but (consensus on) such a definition may not be
needed for an expanded threat model. For this work, it may be needed for an expanded threat model. For this work, it may be
sufficient to note that protocol endpoints can no longer be sufficient to note that protocol endpoints can no longer be
considered to be executing on a traditional host, to assume (at considered to be executing on a traditional host, to assume (at
protocol design time) that all endpoints will be run in a virtualised protocol design time) that all endpoints will be run in a virtualised
environment where co-tenants and (sometimes) hypervisors are environment where co-tenants and (sometimes) hypervisors are
adversaries, and to then call for analysis of such scenarios. adversaries, and to then call for analysis of such scenarios.
4.2.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:
o A network manager of a set of devices may be assured that the
devices have not been compromised.
o 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 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.
4.2.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.
4.3. Does IETF Analysis of Protocols Need to Change? 4.3. Does IETF Analysis of Protocols Need to Change?
It may also be necessary to make procedural changes in how new It may also be necessary to make procedural changes in how new
protocols are defined at the IETF. For instance, our existing protocols are defined at the IETF. For instance, our existing
documentation of threat models and requirements for security documentation of threat models and requirements for security
considerations sections may not be adequate in today's world. considerations sections may not be adequate in today's world.
These suggested changes are entirely tentative. These suggested changes are entirely tentative.
4.3.1. Develop a BCP for privacy considerations 4.3.1. Develop a BCP for privacy considerations
skipping to change at page 26, line 9 skipping to change at page 27, line 46
A key focus area at the IETF has been the security of transport A key focus area at the IETF has been the security of transport
protocols, and how transport layer security can be best used to protocols, and how transport layer security can be best used to
provide the right security for various applications. However, more provide the right security for various applications. However, more
work is needed in equivalently broadly deployed tools for minimising work is needed in equivalently broadly deployed tools for minimising
or obfuscating information provided by users to other entities, and or obfuscating information provided by users to other entities, and
the use of end-to-end security through entities that are involved in 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 the protocol exchange but who do not need to know everything that is
being passed through them. being passed through them.
Comments on the issues discussed in this memo are gladly taken either Comments on the issues discussed in this memo are gladly taken either
privately or on the architecture-discuss mailing list. privately or on the model-t mailing list
(https://www.ietf.org/mailman/listinfo/Model-t).
Some further work includes items listed in Section 4.1 and
Section 4.3, as well as compiling categories of vulnerabilities that
need to be addressed, examples of specific attacks, and continuing
the analysis of the situation and possible new remedies.
It is also necessary find suitable use cases that the IETF can
address by further work in this space. A completely adversial
situation is not really workable, but there are situations where some
parties are trustworthy, and wish to co-operate to show to each other
that this is really the case. In these situations data minimisation
can be beneficial to both, attestation can provide additional trust,
detection of incidents can alert the parties to action, and so on.
6. Informative References 6. Informative References
[AbuseCases] [AbuseCases]
McDermott, J. and C. Fox, "Using abuse case models for McDermott, J. and C. Fox, "Using abuse case models for
security requirements analysis", IEEE Annual Computer security requirements analysis", IEEE Annual Computer
Security Applications Conference (ACSAC'99), Security Applications Conference (ACSAC'99),
https://www.acsac.org/1999/papers/wed-b-1030-john.pdf , https://www.acsac.org/1999/papers/wed-b-1030-john.pdf ,
1999. 1999.
skipping to change at page 27, line 38 skipping to change at page 29, line 38
https://www.net.in.tum.de/fileadmin/bibtex/publications/ https://www.net.in.tum.de/fileadmin/bibtex/publications/
papers/schlamp_TMA_1_2015.pdf , 2015. papers/schlamp_TMA_1_2015.pdf , 2015.
[Home] Nthala, N. and I. Flechais, "Rethinking home network [Home] Nthala, N. and I. Flechais, "Rethinking home network
security", European Workshop on Usable Security security", European Workshop on Usable Security
(EuroUSEC), https://ora.ox.ac.uk/objects/ (EuroUSEC), https://ora.ox.ac.uk/objects/
uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa uuid:e2460f50-579b-451b-b14e-b7be2decc3e1/download_file?sa
fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica fe_filename=bare_conf_EuroUSEC2018.pdf&file_format=applica
tion%2Fpdf&type_of_work=Conference+item , 2018. tion%2Fpdf&type_of_work=Conference+item , 2018.
[I-D.arkko-arch-dedr-report]
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] [I-D.farrell-etm]
Farrell, S., "We're gonna need a bigger threat model", Farrell, S., "We're gonna need a bigger threat model",
draft-farrell-etm-03 (work in progress), July 2019. draft-farrell-etm-03 (work in progress), July 2019.
[I-D.iab-protocol-maintenance] [I-D.iab-protocol-maintenance]
Thomson, M., "The Harmful Consequences of the Robustness Thomson, M., "The Harmful Consequences of the Robustness
Principle", draft-iab-protocol-maintenance-03 (work in Principle", draft-iab-protocol-maintenance-04 (work in
progress), May 2019. progress), November 2019.
[I-D.ietf-httpbis-expect-ct] [I-D.ietf-httpbis-expect-ct]
estark@google.com, e., "Expect-CT Extension for HTTP", estark@google.com, e., "Expect-CT Extension for HTTP",
draft-ietf-httpbis-expect-ct-08 (work in progress), draft-ietf-httpbis-expect-ct-08 (work in progress),
December 2018. December 2018.
[I-D.ietf-mls-architecture] [I-D.ietf-mls-architecture]
Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon, Omara, E., Beurdouche, B., Rescorla, E., Inguva, S., Kwon,
A., and A. Duric, "The Messaging Layer Security (MLS) A., and A. Duric, "The Messaging Layer Security (MLS)
Architecture", draft-ietf-mls-architecture-03 (work in Architecture", draft-ietf-mls-architecture-03 (work in
progress), September 2019. progress), September 2019.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-23 (work and Secure Transport", draft-ietf-quic-transport-24 (work
in progress), September 2019. in progress), November 2019.
[I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-01 (work in progress), July 2019.
[I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-05 (work in
progress), December 2019.
[I-D.ietf-teep-protocol]
Tschofenig, H., Pei, M., Wheeler, D., and D. Thaler,
"Trusted Execution Environment Provisioning (TEEP)
Protocol", draft-ietf-teep-protocol-00 (work in progress),
December 2019.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood, Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft- "Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-04 (work in progress), July 2019. ietf-tls-esni-05 (work in progress), November 2019.
[I-D.ietf-tls-grease] [I-D.ietf-tls-grease]
Benjamin, D., "Applying GREASE to TLS Extensibility", Benjamin, D., "Applying GREASE to TLS Extensibility",
draft-ietf-tls-grease-04 (work in progress), August 2019. 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-00 (work in
progress), July 2019.
[I-D.nottingham-for-the-users] [I-D.nottingham-for-the-users]
Nottingham, M., "The Internet is for End Users", draft- Nottingham, M., "The Internet is for End Users", draft-
nottingham-for-the-users-09 (work in progress), July 2019. 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-01 (work
in progress), July 2019.
[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] [LeakyBuckets]
Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3 Chickowski, E., "Leaky Buckets: 10 Worst Amazon S3
Breaches", Bitdefender blog, Breaches", Bitdefender blog,
https://businessinsights.bitdefender.com/ https://businessinsights.bitdefender.com/
worst-amazon-breaches , 2018. worst-amazon-breaches , 2018.
[Lipp2018]
Lipp, M., Schwarz, M., Gruss, D., Prescher, T., Haas, W.,
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 [Mailbug] Englehardt, S., Han, J., and A. Narayanan, "I never signed
up for this! Privacy implications of email tracking", up for this! Privacy implications of email tracking",
Proceedings on Privacy Enhancing Technologies 2018.1 Proceedings on Privacy Enhancing Technologies 2018.1
(2018): 109-126, https://www.degruyter.com/downloadpdf/j/ (2018): 109-126, https://www.degruyter.com/downloadpdf/j/
popets.2018.2018.issue-1/popets-2018-0006/ popets.2018.2018.issue-1/popets-2018-0006/
popets-2018-0006.pdf , 2018. popets-2018-0006.pdf , 2018.
[MeltdownAndSpectre] [MeltdownAndSpectre]
CISA, ., "Meltdown and Spectre Side-Channel Vulnerability CISA, ., "Meltdown and Spectre Side-Channel Vulnerability
Guidance", Alert (TA18-004A), Guidance", Alert (TA18-004A),
skipping to change at page 32, line 26 skipping to change at page 35, line 38
[Vpns] Khan, M., DeBlasio, J., Voelker, G., Snoeren, A., Kanich, [Vpns] Khan, M., DeBlasio, J., Voelker, G., Snoeren, A., Kanich,
C., and N. Vallina, "An empirical analysis of the C., and N. Vallina, "An empirical analysis of the
commercial VPN ecosystem", ACM Internet Measurement commercial VPN ecosystem", ACM Internet Measurement
Conference 2018 (pp. 443-456), Conference 2018 (pp. 443-456),
https://eprints.networks.imdea.org/1886/1/ https://eprints.networks.imdea.org/1886/1/
imc18-final198.pdf , 2018. imc18-final198.pdf , 2018.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank the members of the IAB, participants The authors would like to thank the IAB:
of the IETF SAAG meeting, participants of the IAB 2019 DEDR workshop,
and numerous other people for insightful comments and discussions in Alissa Cooper, Wes Hardaker, Ted Hardie, Christian Huitema, Zhenbin
this space. 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, Stephen Farrell, 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, Tommy C, Roman Danyliw, Christian Huitema, Ben
Kaduk, Dirk Kutscher, Dominique Lazanski, Eric Rescorla, Ali Rezaki,
Melinda Shore, Martin Thomson, and Robin Wilton ... (missing many
people... did we have minutes other than the list of actions?) ...
Finally, the authors would like to thank numerous other people for
insightful comments and discussions in this space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Stephen Farrell Stephen Farrell
Trinity College Dublin Trinity College Dublin
 End of changes. 39 change blocks. 
96 lines changed or deleted 291 lines changed or added

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