draft-arkko-iab-data-minimization-principle-00.txt   draft-arkko-iab-data-minimization-principle.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational October 2021 Intended status: Informational March 8, 2022
Expires: 28 April 2022 Expires: September 9, 2022
Data minimization Data minimization
draft-arkko-iab-data-minimization-principle-00 draft-arkko-iab-data-minimization-principle
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 this is no longer alone sufficient to cater This document recommends that this is no longer alone sufficient to
for the security and privacy issues seen on the Internet today. For cater for the security and privacy issues seen on the Internet today.
instance, it is often also necessary to protect against endpoints For instance, it is often also necessary to protect 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 users. While such protection is align with the interests of users. While such protection is
difficult, there are some measures that can be taken. It is difficult, there are some measures that can be taken. It is
particularly important that new technology and new deployments important to consider the role of data passed to various parties -
consider the role of data passed to various parties -- including the including the primary protocol participants - and balance the
primary protocol participants -- and balance the information given to information given to them considering their roles and possible
them considering their roles and possible compromise of the compromise of the information.
information.
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 http://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 4 April 2022. This Internet-Draft will expire on September 9, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related work . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Principles . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Dealing with compromise . . . . . . . . . . . . . . . . . 4
4.1. Scope of protocol exchanges . . . . . . . . . . . . . . . 4 3.2. Related work . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Principle: Transmission is publication . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Principle: Build for eventual compromise . . . . . . . . 5 5. Informative References . . . . . . . . . . . . . . . . . . . 6
4.4. Principle: Data and recipient minimization . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.1. Protocol design implications . . . . . . . . . . . . 6
4.4.2. Fingerprinting avoidance . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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 on the Internet. The goal has been to ensure that improvements on 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 has been exemplified in many aspects of IETF efforts, in the This has been exemplified in many aspects of IETF efforts, in the
threat models [RFC3552], concerns about surveillance [RFC7258], and threat models [RFC3552], concerns about surveillance [RFC7258], IAB
the introduction of encryption in many protocols [RFC9000], statements [Confidentiality], and the introduction of encryption in
[RFC7858], [RFC8484]. many protocols [RFC9000], [RFC7858], [RFC8484]. This has been very
successful. Advances in protecting most of our communications with
strong cryptographic has resulted in much improved security. Work on
these advances continues to be a key part of IETF's security effort.
This memo suggests that current security and privacy issues on the This document recommends that further action is needed, however. For
Internet require even further action. For instance, it is often also instance, the possibility that endpoints are compromised, malicious,
necessary to protect against endpoints that are compromised, or have interests that do not align with the interests of users.
malicious, or whose interests simply do not align with the interests Given the advances in communication seceurity, adversaries have had
of users. to increase their pressure against new avenues of attack. New
adversaries and risks have also arisen, e.g., due to increasing
amount of information stored in various Internet services.
While such protection is difficult, there are some measures that can While such protection is difficult, there are some measures that can
be taken. It is particularly important that new technology and new be taken. This document focuses on the specific question of data
deployments consider the role of data passed to various parties -- passed to various parties - including the primary protocol
including the primary protocol participants -- and balance the participants. What information given to any other party needs to
information given to them considering their roles and possible depend on the role of that party, with the possibility of a
compromise of the information. compromised access to the information kept in mind. This
consideration is important particularly when designing new technology
2. Background or planning new deployments.
The primary reason for having to go beyond communications security is
success. Advances in protecting most of our communications with
strong cryptographic has resulted in much improved security, but also
highlight the need for addressing other, remaining issues.
Particularly when adversaries have increased their pressure against
other avenues of attack. New adversaries and risks have arisen,
e.g., due to increasing amount of information stored in various
Internet services, or with the services whose interests are not
aligned with their users.
In short, attacks are migrating towards the currently easier targets,
which no longer necessarily include direct attacks on traffic flows.
These have been discussed at length in, for instance, [RFC8980],
[I-D.farrell-etm] [I-D.arkko-arch-internet-threat-model-guidance],
[I-D.lazanski-smart-users-internet], and others.
It is important that when it comes to basic Internet infrastructure,
our technology addresses non-communications threats to the extent
possible. It is particularly important to ensure that non-
communications security related threats are properly understood for
any new Internet technology.
The sole consideration of communications security aspects in Careful control of information is also necessary from the perspective
designing Internet protocols may lead to accidental or increased of technology evolution. For instance, allowing a participant to
impact of security issues elsewhere. For instance, allowing a unnecessarily collect or receive information may lead to a similar
participant to unnecessarily collect or receive information may lead effect as described in [RFC8546] for protocols: over time,
to a similar effect as described in [RFC8546] for protocols: over unnecessary information will get used with all the associated
time, unnecessary information will get used with all the associated
downsides, regardless of what deployment expectations there were downsides, regardless of what deployment expectations there were
during protocol design. during protocol design. This may also lead to ossification, as
systems start to expect they have access to the information.
3. Related work
Hardie [RFC8558] discusses path signals, i.e., messages to or from 2. Recommendations
on-path elements to endpoints. In the past, path signals were often
implicit, e.g., network nodes interpreting in a particular way
transport protocol headers originally intended for end-to-end
consumption. The document recommends a principle that implicit
signals should be avoided and that explicit signals be used instead,
and only when the signal's originator intends that it be used by the
network elements on the path.
Arkko, Kuhlewind, Pauly, and Hardie The Principle of Least Privilege [PoLP] is applicable:
[I-D.arkko-iab-path-signals-collaboration] discuss the same topic,
and extend the RFC 8558 principles with recommendations to ensure
minimum set of parties, minimum information, and consent.
Thomson [I-D.thomson-tmi] discusses the role intermediaries in the "Every program and every user of the system should operate
Internet architecture, at different layers of the stack. For using the least set of privileges necessary to complete the
instance, a router is an intermediary, some parts of DNS job."
infrastructure can be intermediaries, messaging gateways are
intermediaries. Thomson discusses when intermediaries are or are not
an appropriate tool, and presents a number of principles relating to
the use of intermediaries, e.g., deliberate selection of protocol
participants or limiting the capabilities or information exposure
related to the intermediaries.
Trammel and Kuehlewind [RFC8546] discuss the concept of a "wire In this context, it is recommended that the protocol participants
image" of a protocol. This is an abstraction of the information minimize the information they share. I.e., they should provide only
available to an on-path non-participant in a networking protocol. It the information to each other that is necessary for the function that
relates to the topic of non-participants interpreting information is expected to be performed by the other party.
that is available to them in the "wire image" (or associated timing
and other indirect information). The issues are largely the same
even for participants. Even proper protocol participants may start
to use information available to them, regardless of whether it was
intended to that participant or simply relayed through them.
4. Principles This recommendation is of course very similar to the current approach
to communications security. As with communication security, we try
to avoid providing too much information as it may be misused or leak
through attacks. The same principle applies not just to routers and
potential attackers on path, but also many other services in the
Internet, including servers that provide some function.
This memo approaches the topic from the point of disclosing Of course, participants may provide more information to each after
information to another participant in a protocol exchange. careful consideration, e.g., information provided in exchange of some
benefit, or to parties that are trusted by the participant.
4.1. Scope of protocol exchanges 3. Discussion
This memo does not limit what types of protocol exchanges can lead to Information disclosure may relate to different types of protocol
information disclosure. The protocol exchanges may relate to: exchanges:
* The interaction of an endpoint with the network, e.g., information o The interaction of an endpoint with the network, e.g., information
they provide in any network attachment process or the wire images they provide in any network attachment process or the wire images
of the packets sent via the network. of the packets sent via the network.
* The interaction of an endpoint with intermediaries, in the meaning o The interaction of an endpoint with intermediaries, in the meaning
discussed by Thomson. discussed by Thomson [I-D.thomson-tmi].
* The interaction of an endpoint with a service, such as a website o The interaction of an endpoint with a service, such as a website
or social networking function. or social networking function.
* End-to-end interactions between users, represented by applications o End-to-end interactions between users, represented by applications
running on their computers. running on their computers.
It is also important to observe that information disclosure can It is also important to observe that information disclosure can
appear in several ways: appear in several ways. It can be explicitly carried information,
e.g., a data item in a message sent to a protocol participant. But
* Explicitly carried information, e.g., a data item in a message it can also be indirectly inferred information, such as message
sent to a protocol participant. Note that the carried information arrival times or patterns in the traffic flow. Information may also
may appear at multiple layers in the protocol stack. For be obtained from fingerprinting the protocol participants, in an
instance, both protocol participants and non-participants may effort to identify unique endpoints or users. Finally, information
observe lower layer information, such as topological network gathered from a collaboration among several parties, e.g., websites
addresses. Such information can be collected, used, and perhaps and social media systems collaborating to identify visiting users
misused or leaked. [WP2021].
* Indirectly inferred information, such as message arrival times or
patterns in the traffic flow. Information may also be obtained
from fingerprinting the protocol participants, in an effort to
identify unique endpoints or users.
* Information gathered from a collaboration among several parties,
e.g., websites and social media systems collaborating to identify
visiting users [WP2021].
4.2. Principle: Transmission is publication
PRINCIPLE: Consider information passed to another party as a
publication. Avoid passing information that should not be published.
This principle applies even if the communications that carry that
information are encrypted, as the party that received the
communications and can decrypt them may use the information, e.g.,
because it has become or will later become compromised.
4.3. Principle: Build for eventual compromise
PRINCIPLE: Build defenses to protect information, even when some 3.1. Dealing with compromise
component in a system is or becomes compromised.
For instance, at the service side encryption of data at rest may Even with careful exposure of information, compromises may occur. It
assist in protecting information if an attacker gains access to the is important to build defenses to protect information, even when some
servers. Similarly, protecting data in use can prevent leakage in component in a system is or becomes compromised. This may involve
some cases, and regular purging of old information can limit the designs where no single party has all information such as with
amount of leaked information. Oblivious DNS, cryptographic designs where a service such as with the
recent IETF PPM effort, service side encryption of data at rest,
confidential computing, and other mechanisms.
Protocols can ensure that perfect forward secrecy is provided, so Protocols can ensure that forward secrecy is provided, so that the
that the damage resulting from a compromise of keying material has damage resulting from a compromise of keying material has limited
limited impact. impact.
On the client side, the client may trust that another party handles On the client side, the client may trust that another party handles
information appropriately, but take steps to ensure or verify that information appropriately, but take steps to ensure or verify that
this is the case. For instance, as discussed above, the client can this is the case. For instance, as discussed above, the client can
encrypt a message only to the actual final recipient, even if the encrypt a message only to the actual final recipient, even if the
server holds our message before it is delivered. In some case the server holds our message before it is delivered.
client may also verify correct behavior, e.g., through confidential
computing attestations.
4.4. Principle: Data and recipient minimization
PRINCIPLE: Information should not be disclosed, stored, or routed in
cleartext through services that do not absolutely need to have that
information for the function they perform.
This the "need to know" principle. Note that this principle applies
at multiple layers in the stack. It is not just about intermediaries
in the network and transport layers, but also intermediaries and
services on the application layer.
Information should only be passed between the "real ends" of a A corollary of the recommendation is that information should not be
conversation, unless the information is necessary for a useful disclosed, stored, or routed in cleartext through services that do
function in a service. not need to have that information for the function they perform.
For instance, a transport connection between two components of a For instance, a transport connection between two components of a
system is not an end-to-end connection even if it encompasses all the 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, protocol layers up to the application layer. It is not end-to-end,
if the information or control function it carries extends beyond if the information or control function it carries extends beyond
those components. For instance, just because an e-mail server can those components. For instance, just because an e-mail server can
read the contents of an e-mail message do not make it a legitimate read the contents of an e-mail message do not make it a legitimate
recipient of the e-mail. recipient of the e-mail.
Typically, information can be classified in different categories, The general topic of ensuring that protocol mechanisms stays
such as information needed for the function provided by a service evolvable and workable is covered in [I-D.iab-use-it-or-lose-it].
(e.g., addressing information such as e-mail headers needed to find But the associated methods for reducing fingerprinting possibilities
targeted destination) and information that should only be revealed to probably deserve further study.
the targeted destination (such as e-mail message contents). [I-D.wood-pearg-website-fingerprinting] discusses one aspect of this.
4.4.1. Protocol design implications
An obvious implication of the above is that it is necessary to have
mechanisms that allow secure communication and data object
protection, that is not tied to a particular IP packet source and
destination or a transport layer connection.
These mechanisms also require associated key distribution and 3.2. Related work
agreement facilities.
4.4.2. Fingerprinting avoidance Trends in attacks have been discussed at length in, for instance, in
[RFC8980], [I-D.farrell-etm]
[I-D.arkko-arch-internet-threat-model-guidance],
[I-D.lazanski-smart-users-internet], and others.
Fingerprinting warrants a separate discussion. Internet technology Hardie [RFC8558] discusses path signals, i.e., messages to or from
has tended to move towards richer and more power mechanisms over on-path elements to endpoints. In the past, path signals were often
time. For instance, full-functionality web and transport layer implicit, e.g., network nodes interpreting in a particular way
security stacks are now used for almost all purposes across the transport protocol headers originally intended for end-to-end
network. consumption. The document recommends a principle that implicit
signals should be avoided and that explicit signals be used instead,
and only when the signal's originator intends that it be used by the
network elements on the path.
This is of course good, and the performance, expressive power, and Arkko, Kuhlewind, Pauly, and Hardie
security improvements that came through these are much needed. [I-D.iab-path-signals-collaboration] discuss the same topic, and
extend the RFC 8558 principles with recommendations to ensure minimum
set of parties, minimum information, and consent.
Nevertheless, all protocol mechanisms come with some fingerprinting Thomson [I-D.thomson-tmi] discusses the role intermediaries in the
opportunities, and this tends to be easier the higher in the stack we Internet architecture, at different layers of the stack. For
are, given the wealth of options and algorithms in use. instance, a router is an intermediary, some parts of DNS
[Fingerprinting] and [AmIUnique] provide a good starting point for infrastructure can be intermediaries, messaging gateways are
some of the issues, along with measurements about the accuracy of intermediaries. Thomson discusses when intermediaries are or are not
fingerprinting mechanisms and defenses against them. an appropriate tool, and presents a number of principles relating to
the use of intermediaries, e.g., deliberate selection of protocol
participants or limiting the capabilities or information exposure
related to the intermediaries.
The general topic of ensuring that protocol mechanisms stays Trammel and Kuehlewind [RFC8546] discuss the concept of a "wire
evolvable and workable is covered in [I-D.iab-use-it-or-lose-it]. image" of a protocol. This is an abstraction of the information
But the associated methods for reducing fingerprinting possibilities available to an on-path non-participant in a networking protocol. It
probably deserve further study. relates to the topic of non-participants interpreting information
[I-D.wood-pearg-website-fingerprinting] discusses one aspect of this. that is available to them in the "wire image" (or associated timing
and other indirect information). The issues are largely the same
even for participants. Even proper protocol participants may start
to use information available to them, regardless of whether it was
intended to that participant or simply relayed through them.
5. Acknowledgements 4. Acknowledgements
The author would like to thank the members of the IAB, and the The author would like to thank the members of the IAB, and the
participants of IETF SAAG WG, Model-T IAB program, and the 2019 IAB participants of IETF SAAG WG, Model-T IAB program, and the 2019 IAB
DEDR workshop that all discussed some aspects of these issues. The DEDR workshop that all discussed some aspects of these issues. The
author would like to acknowledge the significant contributions of author would like to acknowledge the significant contributions of
Stephen Farrell, Martin Thomson, Mark McFadden, Chris Wood, Dominique Martin Thomson, Stephen Farrell, Mark McFadden, John Mattsson, Chris
Lazanski, Eric Rescorla, Russ Housley, Robin Wilton, Mirja Wood, Dominique Lazanski, Eric Rescorla, Russ Housley, Robin Wilton,
Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema in Mirja Kuehlewind, Tommy Pauly, Jaime Jimenez and Christian Huitema in
discussions around this general problem area. discussions around this general problem area.
6. Informative References 5. Informative References
[AmIUnique] [AmIUnique]
INRIA, ., "Am I Unique?", https://amiunique.org , 2020. INRIA, ., "Am I Unique?", https://amiunique.org , 2020.
[Confidentiality]
The Internet Architecture Board, ., "IAB Statement on
Internet Confidentiality", https://www.iab.org/2014/11/14/
iab-statement-on-internet-confidentiality/ , November
2014.
[Fingerprinting] [Fingerprinting]
Laperdrix, P., Bielova, N., Baudry, B., and G. Avoine, Laperdrix, P., Bielova, N., Baudry, B., and G. Avoine,
"Browser Fingerprinting: A survey", arXiv:1905.01051v2 "Browser Fingerprinting: A survey", arXiv:1905.01051v2
[cs.CR] 4 Nov 2019 , n.d.. [cs.CR] 4 Nov 2019 , November 2019.
[I-D.arkko-arch-internet-threat-model-guidance] [I-D.arkko-arch-internet-threat-model-guidance]
Arkko, J. and S. Farrell, "Internet Threat Model Ericsson and Trinity College Dublin, "Internet Threat
Guidance", Work in Progress, Internet-Draft, draft-arkko- Model Guidance", draft-arkko-arch-internet-threat-model-
arch-internet-threat-model-guidance-00, 12 July 2021, guidance-00 (work in progress), July 2021.
<https://www.ietf.org/archive/id/draft-arkko-arch-
internet-threat-model-guidance-00.txt>.
[I-D.arkko-iab-path-signals-collaboration]
Arkko, J., Hardie, T., and T. Pauly, "Considerations on
Application - Network Collaboration Using Path Signals",
Work in Progress, Internet-Draft, draft-arkko-iab-path-
signals-collaboration-01, 25 October 2021,
<https://www.ietf.org/archive/id/draft-arkko-iab-path-
signals-collaboration-01.txt>.
[I-D.farrell-etm] [I-D.farrell-etm]
Farrell, S., "We're gonna need a bigger threat model", Trinity College Dublin, "We're gonna need a bigger threat
Work in Progress, Internet-Draft, draft-farrell-etm-03, 6 model", draft-farrell-etm-03 (work in progress), July
July 2019, <https://www.ietf.org/archive/id/draft-farrell- 2019.
etm-03.txt>.
[I-D.iab-path-signals-collaboration]
Ericsson, Cisco, Apple, and Ericsson, "Considerations on
Application - Network Collaboration Using Path Signals",
draft-iab-path-signals-collaboration-00 (work in
progress), March 2022.
[I-D.iab-use-it-or-lose-it] [I-D.iab-use-it-or-lose-it]
Thomson, M. and T. Pauly, "Long-term Viability of Protocol Mozilla and Apple, "Long-Term Viability of Protocol
Extension Mechanisms", Work in Progress, Internet-Draft, Extension Mechanisms", draft-iab-use-it-or-lose-it-04
draft-iab-use-it-or-lose-it-04, 12 October 2021, (work in progress), October 2021.
<https://www.ietf.org/archive/id/draft-iab-use-it-or-lose-
it-04.txt>.
[I-D.lazanski-smart-users-internet] [I-D.lazanski-smart-users-internet]
Lazanski, D., "An Internet for Users Again", Work in Last Press Label, "An Internet for Users Again", draft-
Progress, Internet-Draft, draft-lazanski-smart-users- lazanski-smart-users-internet-00 (work in progress), July
internet-00, 8 July 2019, 2019.
<https://www.ietf.org/archive/id/draft-lazanski-smart-
users-internet-00.txt>.
[I-D.thomson-tmi] [I-D.thomson-tmi]
Thomson, M., "Principles for the Involvement of Mozilla, "Principles for the Involvement of Intermediaries
Intermediaries in Internet Protocols", Work in Progress, in Internet Protocols", draft-thomson-tmi-02 (work in
Internet-Draft, draft-thomson-tmi-02, 6 July 2021, progress), July 2021.
<https://www.ietf.org/archive/id/draft-thomson-tmi-
02.txt>.
[I-D.wood-pearg-website-fingerprinting] [I-D.wood-pearg-website-fingerprinting]
Goldberg, I., Wang, T., and C. A. Wood, "Network-Based University of Waterloo, HK University of Science and
Website Fingerprinting", Work in Progress, Internet-Draft, Technology, and Apple, Inc., "Network-Based Website
draft-wood-pearg-website-fingerprinting-00, 4 November Fingerprinting", draft-wood-pearg-website-
2019, <https://www.ietf.org/archive/id/draft-wood-pearg- fingerprinting-00 (work in progress), November 2019.
website-fingerprinting-00.txt>.
[PoLP] Saltzer, J. and M. Schroader, "The Protection of
Information in Computer Systems", Fourth ACM Symposium on
Operating System Principles , October 1975.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc3552>. editor.org/info/rfc3552>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
skipping to change at page 9, line 29 skipping to change at page 8, line 12
RFC 8558, DOI 10.17487/RFC8558, April 2019, RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>. <https://www.rfc-editor.org/info/rfc8558>.
[RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on [RFC8980] Arkko, J. and T. Hardie, "Report from the IAB Workshop on
Design Expectations vs. Deployment Reality in Protocol Design Expectations vs. Deployment Reality in Protocol
Development", RFC 8980, DOI 10.17487/RFC8980, February Development", RFC 8980, DOI 10.17487/RFC8980, February
2021, <https://www.rfc-editor.org/info/rfc8980>. 2021, <https://www.rfc-editor.org/info/rfc8980>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc9000>. editor.org/info/rfc9000>.
[WP2021] Fowler, Geoffrey A., "There's no escape from Facebook, [WP2021] Fowler, Geoffrey., "There's no escape from Facebook, even
even if you don't use it", Washington Post , August 2021. if you don't use it", Washington Post , August 2021.
Author's Address Author's Address
Jari Arkko Jari Arkko
Ericsson Ericsson
Valitie 1B Valitie 1B
FI- Kauniainen Kauniainen
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
 End of changes. 54 change blocks. 
260 lines changed or deleted 193 lines changed or added

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