draft-arkko-dns-confidential-00.txt   draft-arkko-dns-confidential.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft J. Novotny
Intended status: Informational February 2021 Intended status: Informational Ericsson
Expires: 26 August 2021
Privacy Improvements for DNS Resolution with Confidential Computing Privacy Improvements for DNS Resolution with Confidential Computing
draft-arkko-dns-confidential-00 draft-arkko-dns-confidential-latest
Abstract Abstract
Data leaks are a serious privacy problem for Internet users. Data in Data leaks are a serious privacy problem for Internet users. Data in
flight and at rest can be protected with traditional communications flight and at rest can be protected with traditional communications
security and data encryption. Protecting data in use is more security and data encryption. Protecting data in use is more
difficult. In addition, failure to protect data in use can lead to difficult. In addition, failure to protect data in use can lead to
disclosing session or encryption keys needed for protecting data in disclosing session or encryption keys needed for protecting data in
flight or at rest. flight or at rest.
This document discusses the use of onfidential Computing, to reduce This document discusses the use of onfidential Computing, to reduce
the risk of leaks from data in use. Our example use case is in the the risk of leaks from data in use. Our example use case is in the
context of DNS resolution services. context of DNS resolution services. The document looks at the
operational implications of running services in a way that even the
owner of the service or compute platform cannot access user-specific
information produced by the resolution process.
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 5 August 2021. This Internet-Draft will expire on 19 November 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Prerequisities . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Confidential Computing . . . . . . . . . . . . . . . . . . . 4 4. Prerequisities . . . . . . . . . . . . . . . . . . . . . . . 5
5. Using Confidential Computing for DNS Resolution . . . . . . . 6 5. Confidential Computing . . . . . . . . . . . . . . . . . . . 6
6. Operational Considerations . . . . . . . . . . . . . . . . . 7 6. Using Confidential Computing for DNS Resolution . . . . . . . 7
6.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 7 7. Operational Considerations . . . . . . . . . . . . . . . . . 9
6.2. Debugging . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Dependencies . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Debugging . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Additional services . . . . . . . . . . . . . . . . . . . 9 7.3. Dependencies . . . . . . . . . . . . . . . . . . . . . . 11
6.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 10 7.4. Additional services . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Observations from outside the TEE . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.2. Trust Relationships . . . . . . . . . . . . . . . . . . . 11 8.1. Observations from outside the TEE . . . . . . . . . . . . 13
7.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 11 8.2. Trust Relationships . . . . . . . . . . . . . . . . . . . 13
7.4. Other vulnerabilities . . . . . . . . . . . . . . . . . . 12 8.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 14
8. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. Other vulnerabilities . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
DNS privacy has been a popular topic in the last few years, and
continues to be. The issues with regards to privacy are first that
domain name meta-data is visible on the wire, even when the actual
communications are encryped. This is being addressed with better
technology.
But even if the meta-data is hidden inside communications, any DNS
resolvers still have the potential too see users' entire browsing
history. This is particularly problematic, given that commonly used
large public or operator resolver services are an obviously
attractive target, for both attacks and for commercial or other use
of information visible to them.
A lot of work is ongoing in the industry and the IETF to address some
of these issues:
* Work on encrypted DNS query protocols to hide the meta-data
related to domain names.
* Discovery mechanisms. These may enable a bigger fraction of DNS
query traffic to move to encrypted protocols, and may also help
distributed queries to different parties to avoid concentrating
all information in one place.
* Practices, expectations, contracts (e.g., [RFC8932], Mozilla's
trusted recursive resolver requirements [MozTRR])
* Improvements outside DNS (e.g., encrypted Server Name Indication
(eSNI) [I-D.ietf-tls-esni]).
* General technology developments (e.g., confidential computing,
attestations, remote attestation work at the IETF RATS WG, and so
on)
The goal of this document is to build on all that work - and assume
all communications are or become encrypted, including the DNS
traffic. Our question is what problems remain? Is there a next
step?
Our worry is that resolvers can be a major remaining source of leaks,
e.g., through accidents, attacks, commercial use, or requests from
the authorities. We need to protect user's data in flight, at rest,
or in use - we wanted to experiment with technology that could reduce
leaks on the last two cases. Confidential Computing is one such
potential technology, but it is important to talk about it and get
broader feedback. The use of this technology does have some
operational impacts.
Our primary conclusions are that data held by servers should receive
at least as much security attention as communications do. The
authors feel that this isparticularly crucial for DNS, due to the
potential to leak of users' browsing histories, but principles apply
also to other services.
As a result, all applicable tools should be considered, including
confidential computing that is discussed in this document. However,
the operational and business implications of such tools should be
considered. Feedback to us is very welcome. Are these approaches
feasible or infeasible? What aspects need to be taken into account
to successfully apply them?
2. Background
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
[RFC3552] [RFC7258]. Communications security is, however, not [RFC3552] [RFC7258]. Communications security is, however, not
sufficient by itself, and continuing success in better protection of sufficient by itself, and continuing success in better protection of
communications is highlighting the need to address other issues. communications is highlighting the need to address other issues.
In particular, more attention needs to be paid to protecting data not In particular, more attention needs to be paid to protecting data not
just in flight but also at rest or in use. User data leaks that can just in flight but also at rest or in use. User data leaks that can
occur from servers and other systems, through accidents, attacks, occur from servers and other systems, through accidents, attacks,
skipping to change at page 3, line 30 skipping to change at page 4, line 49
[I-D.arkko-arch-infrastructure-centralisation]. [I-D.arkko-arch-infrastructure-centralisation].
Data leaks can occur in user-visible services that user has chosen to Data leaks can occur in user-visible services that user has chosen to
use and agreed to provide information to (at least in theory use and agreed to provide information to (at least in theory
[Unread]). But leaks can also occur in other types of services, that [Unread]). But leaks can also occur in other types of services, that
are part of the infrastructure, such as DNS resolution services or are part of the infrastructure, such as DNS resolution services or
parts of the communication infrastructure. parts of the communication infrastructure.
This document looks at the possibility of using a specific technical This document looks at the possibility of using a specific technical
solution, Confidential Computing [CCC-Deepdive], to reduce the risk solution, Confidential Computing [CCC-Deepdive], to reduce the risk
of leaks from data in use. of leaks from data in use. We consider the operational implications
of running services in a way that even the owner of the service or
compute platform cannot access user-specific information that is
produced as a side-effect of the service.
We explore the use of Confidential Computing in the context of DNS We explore the use of Confidential Computing in the context of DNS
resolution services [RFC1035]. This is a nice and relatively simple resolution services [RFC1035]. This is a nice and relatively simple
example, but there are of course potential other applications as example, but there are of course potential other applications as
well. well.
DNS resolution services are of course also an important case where DNS resolution services are of course also an important case where
privacy matters a lot for the users. Threats against the resolution privacy matters a lot for the users. Threats against the resolution
process could prevent the user from accessing services. Data leaks process could prevent the user from accessing services. Data leaks
from the process have the potential to expose the user's entire from the process have the potential to expose the user's entire
browsing history. browsing history.
2. Terminology The use of Confidential Computing in the DNS context has been also
discussed in other documents, e.g., [PDoT] and
[I-D.reddy-add-server-policy-selection].
The DNS privacy issues have been also discussed in multiple
documents, such as [RFC7626] [RFC8324] and so on.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Prerequisities 4. Prerequisities
The primary sources of leaks are as follows: The primary sources of leaks are as follows:
* Communications interception. This threat can be addressed by * Communications interception. This threat can be addressed by
encrypted communications, such as the use of DoT [RFC7858] or DoH encrypted communications, such as the use of DNS-over-TLS (DoT)
[RFC8484] instead of traditional DNS protocols. [RFC7858], DNS-over-HTTPS (DoH) [RFC8484], or DNS-over-QUIC (DoQ)
[I-D.ietf-dprive-dnsoquic] instead of traditional DNS protocols.
* Data leakage from the server or service, either from data at rest * Data leakage from the server or service, either from data at rest
or in use. This can be addressed by encrypting the data while at or in use. This can be addressed by encrypting the data while at
rest and employing the techniques discussed in this document for rest and employing the techniques discussed in this document for
data in use. data in use.
The specific information that is privacy sensitive depends on the The specific information that is privacy sensitive depends on the
application. In DNS resolution application it is clear that the application. In DNS resolution application it is clear that the
users' browsing histories, i.e., which users asked for what names is users' browsing histories, i.e., which users asked for what names is
privacy sensitive, and protecting that information is the primary privacy sensitive, and protecting that information is the primary
focus in this document. In contrast, the domains themselves or the focus in this document. In contrast, the domains themselves or the
associated address information is in the general case public and not associated address information is in the general case public and not
privacy sensitive. However, in some cases even this information may privacy sensitive. However, in some cases even this information may
be sensitive, such as in the case of internal domains of a corporate be sensitive, such as in the case of internal domains of a corporate
network. Information not related to individuals may also be network. Information not related to individuals may also be
sensitive in some cases, e.g., the collective browsing destinations sensitive in some cases, e.g., the collective browsing destinations
of an entire organization. of an entire organization.
It should be noted that technology can help only insofar as there is The above was also observed in [RFC7626] which stated the following:
commercial willingness to provide the best possible service and to
protect the users' information. "DNS data and the results of a DNS query are public [...], and may
not have any confidentiality requirements. However, the same is
not true of a single transaction or a sequence of transactions;
that transaction is not / should not be public."
Nevertheless, it should be noted that technology can help only
insofar as there is commercial willingness to provide the best
possible service and to protect the users' information.
Similarly, the techniques discussed in this document are not the Similarly, the techniques discussed in this document are not the
sole, or full answer to all problems. There are a lot of technical, sole, or full answer to all problems. There are a lot of technical,
operational, and governance issues that also matter and practices operational, and governance issues that also matter and practices
that help. A good compilation of some best practices can be found in that help. A good compilation of some best practices can be found in
[RFC8932], and particularly Section 5.2 that discusses data at rest. [RFC8932], and particularly Section 5.2 that discusses data at rest.
4. Confidential Computing 5. Confidential Computing
Confidential Computing is about protecting data in use by performing Confidential Computing is about protecting data in use by performing
computation in a hardware enforced Trusted Execution Environment computation in a hardware enforced Trusted Execution Environment
(TEE) [CCC-Deepdive]. It addresses the need to protect data in use, (TEE) [CCC-Deepdive]. It addresses the need to protect data in use,
which traditionally has been hard to achieve. It may also help which traditionally has been hard to achieve. It may also help
improve the encryption of data in flight and at rest, by helping improve the encryption of data in flight and at rest, by helping
protect session keys and other security information used in that protect session keys and other security information used in that
process. process.
For our purposes, we focus on Trusted Execution Environments that use For our purposes, we focus on Trusted Execution Environments that use
skipping to change at page 6, line 5 skipping to change at page 7, line 43
Note that availability might be another desirable characteristic for Note that availability might be another desirable characteristic for
Confidential Computing systems, but it is one that is not in any Confidential Computing systems, but it is one that is not in any
special way supported by current technology. Ultimately, the owner special way supported by current technology. Ultimately, the owner
of the computer still has the ability to choose when to switch the of the computer still has the ability to choose when to switch the
computer off, for instance. There is also no particular hardware computer off, for instance. There is also no particular hardware
technology at this time to deal with Denial-of-Service attacks. Some technology at this time to deal with Denial-of-Service attacks. Some
of the software techniques related to dealing with Denial-of-Service of the software techniques related to dealing with Denial-of-Service
attacks are discussed in the Security Considerations section. attacks are discussed in the Security Considerations section.
5. Using Confidential Computing for DNS Resolution 6. Using Confidential Computing for DNS Resolution
Confidential Computing can be used to provide a privacy-friendly Confidential Computing can be used to provide a privacy-friendly
resolution service in a server. resolution service in a server.
The arrangement is threefold: The basic arrangement is two-fold:
* User's computer and the DNS resolution server communicate using an * User's computer and the DNS resolution server communicate using an
encrypted and integrity protected transport protocol, such as DoT encrypted and integrity protected transport protocol, such as DoT
or DoH [RFC7858] [RFC8484]. or DoH [RFC7858] [RFC8484].
* The secure connection terminates inside a TEE running in the the * The secure connection terminates inside a TEE running in the the
DNS resolution server. This TEE performs all the necessary DNS resolution server. This TEE performs all the necessary
processing to respond to the user's query. It may need to contact processing to respond to the user's query. The TEE will not
other local servers or in the Internet to resolve a query that has provide any user-specific information outside of the TEE, such as
no recently cached answer. We weill discuss later how this can be logs of what names specific clients queried for.
done securely.
* The user's computer receives the query answer and a remote The TEE may need to contact other local servers or in the Internet
attestation about the server. The user's computer checks that (a) to resolve a query that has no recently cached answer. We will
the cryptographic attestation refers to a server machine that is discuss later how this can be done securely: it is necessary to
acceptable to the user (e.g., manufactured by a manufacturer it prevent the linking any external actions such as receiving a
trusts, CPU features considered secure are used, features client request and observing a query going out to other DNS
considered insecure are turned off, etc.) (b) that the software servers in the Internet.
image designated as being run in the attestation is a software
image that the user's computer is willing to use (e.g., has a hash
that matches a known software that does not log user actions, or
is vouched as trustworthy by another party that the user's
computer trusts).
The arrangement is shown in Figure 1. The arrangement is shown in Figure 1.
+------------------+ +----------------+ +------------------+ +----------------+
| User's | | Server | | User's | | Server |
| Computer | | Computer | | Computer | | Computer |
| | | | | | | |
| | | +----------+ | | | | +----------+ |
| | | | A TEE, | | | | | | A TEE, | |
| +------------+ | | | running | | other DNS | +------------+ | | | running | | other DNS
| | DNS Client |-|-------------|--| a DNS |--|------ servers | | DNS Client |-|-------------|--| a DNS |--|------ servers
| +------------+ | | | resolver | | (if needed) | +------------+ | | | resolver | | (if needed)
| | | +----------+ | | | | +----------+ |
| | | | | | | |
+------------------+ +----------------+ +------------------+ +----------------+
Figure 1: Confidential Computing for DNS Resoluton Figure 1: Confidential Computing for DNS Resoluton
Note that in this application, we strive to have no data at rest at
all, at least nothing that relates directly to users. This leaves
only data in flight and data in use to be protected. It will also be
necessary to prevent the linking any external actions such as
receiving a client request and observing a query going out to other
DNS servers in the Internet.
6. Operational Considerations In this application, we strive to have no data at rest at all, at
least nothing that relates directly to users. Data in flight and
data in use are both protected by encryption. As a result of running
the resolution service in this manner, any user-specific information
should remain within the TEE, and not exposed to outsiders or even
the owner of the service or the compute platform where the service is
running in.
The authors believe that this is a desirable property. However, it
remains to assure users and clients that the service is actually run
in this manner. This can be done in two ways:
* Through off-line reliance on a particular service, i.e., a human
decision to use a particular system. Once there is a decision to
use a particular system, cryptographic means such as public keys
may be used to ensure that the client is indeed connected to the
expected server. However, there is no guarantee that the human-
space statements about the practices used in running the server
are valid.
* Cryptographic check that the service is actually running inside a
valid TEE and that it runs the expected software. Such a checks
needs to rely on third parties. In this case the user's computer
performs a remote attestation about the server. The user's
computer checks that (a) the cryptographic attestation refers to a
server machine that is acceptable to the user (e.g., manufactured
by a manufacturer it trusts, CPU features considered secure are
used, features considered insecure are turned off, etc.) (b) that
the software image designated as being run in the attestation is a
software image that the user's computer is willing to use (e.g.,
has a hash that matches a known software that does not log user
actions, or is vouched as trustworthy by another party that the
user's computer trusts).
7. Operational Considerations
This section discusses some aspects of the Confidential Computing This section discusses some aspects of the Confidential Computing
arrangement for DNS, based on the author's experience with these arrangement for DNS, based on the authors' experience with these
systems. systems.
6.1. Operations 7.1. Operations
Given that the service executes confidentially, and is not observable Given that the service executes confidentially, and is not observable
even by the owner of the hardware, the operations model becomes even by the owner of the hardware, the operations model becomes
different. Some different models may be applied: different. Some different models may be applied:
* The service executes on a hardware platform (such as a commercial * The service executes on a hardware platform (such as a commercial
cloud service) that has no access to information, but there is cloud service) that has no access to information, but there is
some other management entity that does have access. The control some other management entity that does have access. The control
functions of this entity can communicate with the service functions of this entity can communicate with the service
instances running in TEEs, and have access to the internal state instances running in TEEs, and have access to the internal state
skipping to change at page 8, line 5 skipping to change at page 10, line 14
user-related information, and our document argues that we should do user-related information, and our document argues that we should do
so. so.
Of course, the owners of a service do need some information to run Of course, the owners of a service do need some information to run
the service, from an efficiency, scaling, problem tracking, and the service, from an efficiency, scaling, problem tracking, and
security monitoring point of view. The service operator may even security monitoring point of view. The service operator may even
benefit from seeing some overall trend information about various benefit from seeing some overall trend information about various
queries and traffic. This does not have to mean exposing individual queries and traffic. This does not have to mean exposing individual
user behaviours, however. user behaviours, however.
The author has worked with aggregate statistics to be able to provide The authors have worked with aggregate statistics to be able to
load, performance, memory usage, cache statistics, error, and other provide load, performance, memory usage, cache statistics, error, and
information out of the confidential processes. This helps the other information out of the confidential processes. This helps the
operator understand the health and status of various service operator understand the health and status of various service
instances. Even with aggregate statistics, there are some danger of instances. Even with aggregate statistics, there are some danger of
revealing private information. For instance, even a sum of counters revealing private information. For instance, even a sum of counters
across all clients can reveal counters associated with an individual across all clients can reveal counters associated with an individual
user, if the aggregate counters can be sampled at any time with user, if the aggregate counters can be sampled at any time with
arbitrary precision. For instance, the actions of a single client arbitrary precision. For instance, the actions of a single client
can be determined by sampling the statistics before and after that can be determined by sampling the statistics before and after that
client sent a message. client sent a message.
A simplistic approach to producing safer statistics in such cases is A simplistic approach to producing safer statistics in such cases is
skipping to change at page 8, line 38 skipping to change at page 11, line 5
received. received.
Another complementary technique to monitor the health of confidential Another complementary technique to monitor the health of confidential
services is the use of probes to ensure that the services function services is the use of probes to ensure that the services function
correctly. Probes can also measure the performance of the services. correctly. Probes can also measure the performance of the services.
The case of excessive service conditions due to Denial-of-Service The case of excessive service conditions due to Denial-of-Service
attacks is discussed further under the Security Considerations attacks is discussed further under the Security Considerations
section. section.
6.2. Debugging 7.2. Debugging
Various error conditions and software issues may occur, as is usual Various error conditions and software issues may occur, as is usual
with any service. There is a need to monitor problems that occur with any service. There is a need to monitor problems that occur
inside the service or at the client. This can be done, for instance, inside the service or at the client. This can be done, for instance,
with the help of various statistics discussed earlier. with the help of various statistics discussed earlier.
Some of the monitored conditions should include: Some of the monitored conditions should include:
* All major (or preferably even minor) error conditions should have * All major (or preferably even minor) error conditions should have
an associated counter. This is necessary as no traditional an associated counter. This is necessary as no traditional
skipping to change at page 9, line 19 skipping to change at page 11, line 35
Of course, for dedicated software testing purposes (such as debugging Of course, for dedicated software testing purposes (such as debugging
interoperability problems), even confidential services need to be run interoperability problems), even confidential services need to be run
in a mode that exposes everything. Actual clients and users MUST be in a mode that exposes everything. Actual clients and users MUST be
able to ensure that they are connected to a production service able to ensure that they are connected to a production service
instance. This can be be done by providing debugging status as part instance. This can be be done by providing debugging status as part
of the remote attestation, so that clients can verify it is off. of the remote attestation, so that clients can verify it is off.
Alternatively, testing versions of the service are simply not listed Alternatively, testing versions of the service are simply not listed
as trusted software versions. as trusted software versions.
6.3. Dependencies 7.3. Dependencies
The use of Confidential Computing introduces three additional The use of Confidential Computing introduces three additional
dependencies to the system: dependencies to the system:
There is a need to be able to verify that the CPU executing the There is a need to be able to verify that the CPU executing the
service is a legitimate CPU with the right hardware, and that the service is a legitimate CPU with the right hardware, and that the
software being run for the service is acceptable. While this can be software being run for the service is acceptable. While this can be
hard coded information in the service clients, in practice there is hard coded information in the service clients, in practice there is
often a need to rely on other parties for scalability. As a result, often a need to rely on other parties for scalability. As a result,
there are two dependencies for legitimate CPU verification and for there are two dependencies for legitimate CPU verification and for
skipping to change at page 9, line 43 skipping to change at page 12, line 10
verification. verification.
The third dependency is on the client. Depending on specific The third dependency is on the client. Depending on specific
protocol arrangements, Confidential Computing services often can protocol arrangements, Confidential Computing services often can
serve unmodified clients, but for the full benefits and for serve unmodified clients, but for the full benefits and for
validating attestations or software images, client changes are validating attestations or software images, client changes are
necessary. The necessary communications may happen as part of TLS necessary. The necessary communications may happen as part of TLS
negotiations or other general purpose protocols negotiations or other general purpose protocols
[I-D.mandyam-tokbind-attest], [I-D.ietf-rats-eat]. [I-D.mandyam-tokbind-attest], [I-D.ietf-rats-eat].
6.4. Additional services 7.4. Additional services
Many services employ information that can be used to perform Many services employ information that can be used to perform
additional services beyond the basic task. For instance, knowledge additional services beyond the basic task. For instance, knowledge
about what the users requests or who the user is can be used for about what the users requests or who the user is can be used for
various optimizations or additional information that can be delivered various optimizations or additional information that can be delivered
to the user. Or the user can provide some additional information to the user. Or the user can provide some additional information
that is taken into account by the service. that is taken into account by the service.
One concern with these types of additional services is that the One concern with these types of additional services is that the
information used by them can be privacy sensitive. But Confidential information used by them can be privacy sensitive. But Confidential
skipping to change at page 10, line 23 skipping to change at page 12, line 37
relay some information outside the TEE. Some specific situations relay some information outside the TEE. Some specific situations
where this is needed with DNS are discussed in Section 7.1. where this is needed with DNS are discussed in Section 7.1.
One example of additional services is that aggregate, privacy- One example of additional services is that aggregate, privacy-
sensitive data may be produced about trends in a confidentially run sensitive data may be produced about trends in a confidentially run
service, if it will not be possible to separate individual users from service, if it will not be possible to separate individual users from
that data. For instance, it would be difficult sell information that data. For instance, it would be difficult sell information
about individual users to help with targeted advertising, but the about individual users to help with targeted advertising, but the
overall popularity of some websites could be measured. overall popularity of some websites could be measured.
6.5. Performance 7.5. Performance
Confidential Computing technology may impact performance. Nakatsuka Confidential Computing technology may impact performance. Nakatsuka
et al. [PDoT] report on an open source modification of the Unbound et al. [PDoT] report on an open source modification of the Unbound
DNS server to support Confidential Computing, and were able to DNS server to support Confidential Computing, and were able to
provide better performance than the original server, due to better provide better performance than the original server, due to better
use of threading. use of threading.
However, other things being equal there's likely some performance However, other things being equal there's likely some performance
hit, as current Confidential Computing technology typically involves hit, as current Confidential Computing technology typically involves
separating a server into two parts, the trusted and untrusted parts. separating a server into two parts, the trusted and untrusted parts.
skipping to change at page 10, line 48 skipping to change at page 13, line 15
computing TEE approaches are likely going to improve these aspects. computing TEE approaches are likely going to improve these aspects.
Another performance hit comes from the overhead related to running Another performance hit comes from the overhead related to running
the attestation process, and passing the necessary extra information the attestation process, and passing the necessary extra information
in the communications protocols with the clients. In general, this in the communications protocols with the clients. In general, this
works best when the cost of the setup is amortized over a long-lived works best when the cost of the setup is amortized over a long-lived
session. Such sessions may exist between DoT/DoH-enabled clients and session. Such sessions may exist between DoT/DoH-enabled clients and
resolvers. Also, there are many possible arrangements and possible resolvers. Also, there are many possible arrangements and possible
parties involved in attestation, see [I-D.ietf-rats-architecture]. parties involved in attestation, see [I-D.ietf-rats-architecture].
7. Security Considerations 8. Security Considerations
Security issues in this arrangement are discussed below. Security issues in this arrangement are discussed below.
7.1. Observations from outside the TEE 8.1. Observations from outside the TEE
While a TEE is considered to be secure and not observable, there may While a TEE is considered to be secure and not observable, there may
be signs outside the TEE that can reveal information. be signs outside the TEE that can reveal information.
For instance, a server may receive a request from a client and For instance, a server may receive a request from a client and
immediately send out a question to a server in the Internet about a immediately send out a question to a server in the Internet about a
particular domain name. Observers - such as the owner of the server particular domain name. Observers - such as the owner of the server
computer or the cloud farm - may be able to link incoming user computer or the cloud farm - may be able to link incoming user
queries to outgoing questions queries to outgoing questions
Caching, randomly made other traffic, and timing obfuscation can Caching, randomly made other traffic, and timing obfuscation can
deter such attacks, at least to an extent. deter such attacks, at least to an extent.
7.2. Trust Relationships 8.2. Trust Relationships
For scaling reasons, the arrangement typically depends on the ability For scaling reasons, the arrangement typically depends on the ability
to have trusted parties (a) for attesting the validity of a to have trusted parties (a) for attesting the validity of a
particular CPU being manufactured by a CPU manufacturer, and (b) for particular CPU being manufactured by a CPU manufacturer, and (b) for
determining whether a particular software image hash is acceptable determining whether a particular software image hash is acceptable
for the task it is advertising to do. for the task it is advertising to do.
Such trusted parties need to be configured, which presents an Such trusted parties need to be configured, which presents an
additional operational burden. The information can of course be additional operational burden. The information can of course be
provided as part of a device manufacturer's or application's initial provided as part of a device manufacturer's or application's initial
skipping to change at page 11, line 45 skipping to change at page 14, line 11
establishing a secure, encrypted channel is of no use if it is not establishing a secure, encrypted channel is of no use if it is not
with the intended party due to a certificate authority that proved to with the intended party due to a certificate authority that proved to
be untrustworthy. With confidential computing, the same applies: one be untrustworthy. With confidential computing, the same applies: one
has to have someone who can assert that a CPU is capable of has to have someone who can assert that a CPU is capable of
performing the confidential computing task and that the indicated performing the confidential computing task and that the indicated
software is good for performing the task that the user expects it to software is good for performing the task that the user expects it to
perform. That being said, when such trusted parties can be found, perform. That being said, when such trusted parties can be found,
the service performed by the server can become much more privacy the service performed by the server can become much more privacy
friendly. friendly.
7.3. Denial-of-Service Attacks 8.3. Denial-of-Service Attacks
To paraphrase an old philosophical question, "If an evil packet is To paraphrase an old philosophical question, "If an evil packet is
sent behind the veil of encryption and no one is around to lift it, sent behind the veil of encryption and no one is around to lift it,
did an attack happen?" [Chautauquan] did an attack happen?" [Chautauquan]
Denial-of-Service attacks are a more serious form of the problems Denial-of-Service attacks are a more serious form of the problems
with operating services that the operator (intentionally) does not with operating services that the operator (intentionally) does not
fully see. There needs to be means to deal with these attacks. fully see. There needs to be means to deal with these attacks.
Attacks that can be identified by particularly high traffic flows Attacks that can be identified by particularly high traffic flows
skipping to change at page 12, line 36 skipping to change at page 15, line 5
attacks as well. One technique is to be able to provide instruction attacks as well. One technique is to be able to provide instruction
to the confidential part of the service to refuse service for to the confidential part of the service to refuse service for
specific requests (e.g., specific domain names) or for specific specific requests (e.g., specific domain names) or for specific
clients (e.g., coming from specific addresses). Alternatively, the clients (e.g., coming from specific addresses). Alternatively, the
service can also dynamically react to issues, e.g., by starting to service can also dynamically react to issues, e.g., by starting to
reduce the amount of resources dedicated to some classes of requests reduce the amount of resources dedicated to some classes of requests
that for some reason are starting to require exceptionally high that for some reason are starting to require exceptionally high
amount of resources. These techniques do not endanger user privacy, amount of resources. These techniques do not endanger user privacy,
but may of course impact provided service. but may of course impact provided service.
7.4. Other vulnerabilities 8.4. Other vulnerabilities
Like all security mechanisms, this solution is not a panacea. It Like all security mechanisms, this solution is not a panacea. It
relies on the correct operation of a number of technologies and relies on the correct operation of a number of technologies and
entities. For instance, CPU bugs or side channel vulnerabilities can entities. For instance, CPU bugs or side channel vulnerabilities can
cause information leaks to become possible. While confidential cause information leaks to become possible. While confidential
computing offers a layer of protection against attacks even from the computing offers a layer of protection against attacks even from the
owner of the computer hardware or the operating system, it is owner of the computer hardware or the operating system, it is
believed that this protection does not extend to sophisticated believed that this protection does not extend to sophisticated
physical attacks, such being able to study chips with an electron physical attacks, such being able to study chips with an electron
microscope. microscope.
skipping to change at page 13, line 32 skipping to change at page 15, line 48
agencies that could result in, e.g., the use of unpublicized agencies that could result in, e.g., the use of unpublicized
vulnerabilities in an attempt to dwarf the protections in vulnerabilities in an attempt to dwarf the protections in
Confidential Computing. This could be used to perform pervasive Confidential Computing. This could be used to perform pervasive
monitoring, for instance [RFC7258]. Even so, it is always beneficial monitoring, for instance [RFC7258]. Even so, it is always beneficial
to push the costs and difficulty for attackers. Requiring parties to push the costs and difficulty for attackers. Requiring parties
who perform pervasive monitoring to employ complex technical attacks who perform pervasive monitoring to employ complex technical attacks
rather being able to request logs from a service provider rather being able to request logs from a service provider
significantly increases the difficulty and risk associated with such significantly increases the difficulty and risk associated with such
monitoring. monitoring.
8. Recommendations 9. Recommendations
Data held by servers SHOULD receive at least as much security Data held by servers SHOULD receive at least as much security
attention as communications do. attention as communications do.
The author would like to draw attention to the problem of data leaks, The authors would like to draw attention to the problem of data
particularly for data in use, and RECOMMEND the application of all leaks, particularly for data in use, and RECOMMEND the application of
available tools to prevent inappropriate access to users' all available tools to prevent inappropriate access to users'
information. information.
This is particularly crucial for DNS resolution services that have This is particularly crucial for DNS resolution services that have
the potential to learn user's browsing histories. But the principles the potential to learn user's browsing histories. But the principles
apply also to other services. apply also to other services.
While using Confidential Computing without other modifications to the While using Confidential Computing without other modifications to the
service in question is possible, real benefits can only be realized service in question is possible, real benefits can only be realized
when the actual service is built for the purpose of avoiding data when the actual service is built for the purpose of avoiding data
leaks or user data capture. Systems may need to be tuned or leaks or user data capture. Systems may need to be tuned or
skipping to change at page 14, line 45 skipping to change at page 17, line 14
way, by, e.g., forcing cache overflow, overloading it with traffic it way, by, e.g., forcing cache overflow, overloading it with traffic it
knows about, etc. knows about, etc.
The situation is slightly different when the interaction is with The situation is slightly different when the interaction is with
other systems that form a part of the same administrative domain. In other systems that form a part of the same administrative domain. In
particular, if those other systems employ similar confidential particular, if those other systems employ similar confidential
computing setup, and an encrypted channel is used, then some computing setup, and an encrypted channel is used, then some
additional security can be provided compared to communicating with additional security can be provided compared to communicating with
other entities in the Internet. other entities in the Internet.
9. Acknowledgments 10. Acknowledgments
The author would like to thank Jiri Novotny, Matti Kauppi, Jimmy The authors would like to thank Matti Kauppi, Jimmy Kjaellman, and
Kjaellman, and Tero Kauppinen for their work on systems supporting Tero Kauppinen for their work on systems supporting some of the ideas
some of the ideas discussed in this memo, and Dave Thaler, Daniel discussed in this memo, and Dave Thaler, Daniel Migault, Karl
Migault, Karl Norrman, Christian Schaefer, and Jiri Novotny for Norrman, and Christian Schaefer for significant feedback on early
significant feedback on early version of this draft. The author version of this draft. The author would also like to thank Marcus
would also like to thank Marcus Ihlar, Maria Luisa Mas, Miguel Angel Ihlar, Maria Luisa Mas, Miguel Angel Munos De La Torre Alonso, Jukka
Munos De La Torre Alonso, Jukka Ylitalo, Bengt Sahlin, Tomas Mecklin, Ylitalo, Bengt Sahlin, Tomas Mecklin, Ben Smeets and many others for
Ben Smeets and many others for interesting discussions in this interesting discussions in this problem space.
problem space.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P.V., "Domain names - implementation and [RFC1035] Mockapetris, P.V., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 11.2. Informative References
[AMD] Kaplan, D., Powell, J., and T. Woller, "AMD Memory [AMD] Kaplan, D., Powell, J., and T. Woller, "AMD Memory
Encryption", AMD White Paper , April 2016. Encryption", AMD White Paper , April 2016.
[Cambridge] [Cambridge]
Isaak, J. and M. Hanna, "User Data Privacy: Facebook, Isaak, J. and M. Hanna, "User Data Privacy: Facebook,
Cambridge Analytica, and Privacy Protection", Computer Cambridge Analytica, and Privacy Protection", Computer
51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/ 51.8 (2018): 56-59, https://ieeexplore.ieee.org/stamp/
stamp.jsp?arnumber=8436400 , 2018. stamp.jsp?arnumber=8436400 , 2018.
skipping to change at page 16, line 36 skipping to change at page 18, line 52
[I-D.arkko-arch-infrastructure-centralisation] [I-D.arkko-arch-infrastructure-centralisation]
Arkko, J., "Centralised Architectures in Internet Arkko, J., "Centralised Architectures in Internet
Infrastructure", Work in Progress, Internet-Draft, draft- Infrastructure", Work in Progress, Internet-Draft, draft-
arkko-arch-infrastructure-centralisation-00, 4 November arkko-arch-infrastructure-centralisation-00, 4 November
2019, <https://www.ietf.org/archive/id/draft-arkko-arch- 2019, <https://www.ietf.org/archive/id/draft-arkko-arch-
infrastructure-centralisation-00.txt>. infrastructure-centralisation-00.txt>.
[I-D.arkko-farrell-arch-model-t-redux] [I-D.arkko-farrell-arch-model-t-redux]
Arkko, J. and S. Farrell, "Internet Threat Model Arkko, J. and S. Farrell, "Internet Threat Model
Evolution: Background and Principles", Work in Progress, Evolution: Background and Principles", Work in Progress,
Internet-Draft, draft-arkko-farrell-arch-model-t-redux-00, Internet-Draft, draft-arkko-farrell-arch-model-t-redux-01,
2 November 2020, <https://www.ietf.org/archive/id/draft- 22 February 2021, <https://www.ietf.org/archive/id/draft-
arkko-farrell-arch-model-t-redux-00.txt>. arkko-farrell-arch-model-t-redux-01.txt>.
[I-D.iab-dedr-report] [I-D.iab-dedr-report]
Arkko, J. and T. Hardie, "Report from the IAB Workshop on Arkko, J. and T. Hardie, "Report from the IAB Workshop on
Design Expectations vs. Deployment Reality in Protocol Design Expectations vs. Deployment Reality in Protocol
Development", Work in Progress, Internet-Draft, draft-iab- Development", Work in Progress, Internet-Draft, draft-iab-
dedr-report-01, 2 November 2020, dedr-report-01, 2 November 2020,
<https://www.ietf.org/archive/id/draft-iab-dedr-report- <https://www.ietf.org/archive/id/draft-iab-dedr-report-
01.txt>. 01.txt>.
[I-D.ietf-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", Work in Progress,
Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February
2021, <https://www.ietf.org/archive/id/draft-ietf-dprive-
dnsoquic-02.txt>.
[I-D.ietf-rats-architecture] [I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture- in Progress, Internet-Draft, draft-ietf-rats-architecture-
10, 9 February 2021, <https://www.ietf.org/archive/id/ 12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
draft-ietf-rats-architecture-10.txt>. ietf-rats-architecture-12.txt>.
[I-D.ietf-rats-eat] [I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J. Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", Work in O'Donoghue, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-08, 4 Progress, Internet-Draft, draft-ietf-rats-eat-09, 7 March
February 2021, <https://www.ietf.org/archive/id/draft- 2021, <https://www.ietf.org/archive/id/draft-ietf-rats-
ietf-rats-eat-08.txt>. eat-09.txt>.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-10, 8 March 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-esni-
10.txt>.
[I-D.lazanski-smart-users-internet] [I-D.lazanski-smart-users-internet]
Lazanski, D., "An Internet for Users Again", Work in Lazanski, D., "An Internet for Users Again", Work in
Progress, Internet-Draft, draft-lazanski-smart-users- Progress, Internet-Draft, draft-lazanski-smart-users-
internet-00, 8 July 2019, internet-00, 8 July 2019,
<https://www.ietf.org/archive/id/draft-lazanski-smart- <https://www.ietf.org/archive/id/draft-lazanski-smart-
users-internet-00.txt>. users-internet-00.txt>.
[I-D.mandyam-tokbind-attest] [I-D.mandyam-tokbind-attest]
Mandyam, G., Lundblade, L., and J. Azen, "Attested TLS Mandyam, G., Lundblade, L., and J. Azen, "Attested TLS
Token Binding", Work in Progress, Internet-Draft, draft- Token Binding", Work in Progress, Internet-Draft, draft-
mandyam-tokbind-attest-07, 24 January 2019, mandyam-tokbind-attest-07, 24 January 2019,
<https://www.ietf.org/archive/id/draft-mandyam-tokbind- <https://www.ietf.org/archive/id/draft-mandyam-tokbind-
attest-07.txt>. attest-07.txt>.
[I-D.reddy-add-server-policy-selection]
Reddy, T., Wing, D., Richardson, M. C., and M. Boucadair,
"DNS Server Selection: DNS Server Information with
Assertion Token", Work in Progress, Internet-Draft, draft-
reddy-add-server-policy-selection-08, 29 March 2021,
<https://www.ietf.org/archive/id/draft-reddy-add-server-
policy-selection-08.txt>.
[I-D.thomson-tmi] [I-D.thomson-tmi]
Thomson, M., "Principles for the Involvement of Thomson, M., "Principles for the Involvement of
Intermediaries in Internet Protocols", Work in Progress, Intermediaries in Internet Protocols", Work in Progress,
Internet-Draft, draft-thomson-tmi-01, 3 January 2021, Internet-Draft, draft-thomson-tmi-01, 3 January 2021,
<https://www.ietf.org/archive/id/draft-thomson-tmi- <https://www.ietf.org/archive/id/draft-thomson-tmi-
01.txt>. 01.txt>.
[Innovative] [Innovative]
Ittai, A., Gueron, S., Johnson, S., and V. Scarlata, Ittai, A., Gueron, S., Johnson, S., and V. Scarlata,
"Innovative Technology for CPU Based Attestation and "Innovative Technology for CPU Based Attestation and
Sealing", HASP'2013 , 2013. Sealing", HASP'2013 , 2013.
[Mem] Henson, M. and S. Taylor, "Memory encryption: a survey of [Mem] Henson, M. and S. Taylor, "Memory encryption: a survey of
existing techniques", ACM Computing Surveys volume 46 existing techniques", ACM Computing Surveys volume 46
issue 4 , 2014. issue 4 , 2014.
[MozTRR] Mozilla, ., "Security/DOH-resolver-policy",
https://wiki.mozilla.org/Security/DOH-resolver-policy ,
2019.
[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private [PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
DNS-over-TLS with TEE Support", Digit. Threat.: Res. DNS-over-TLS with TEE Support", Digit. Threat.: Res.
Pract., Vol. 2, No. 1, Article 3, Pract., Vol. 2, No. 1, Article 3,
https://dl.acm.org/doi/fullHtml/10.1145/3431171 , February https://dl.acm.org/doi/fullHtml/10.1145/3431171 , February
2021. 2021.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[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>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<https://www.rfc-editor.org/info/rfc7626>.
[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>.
[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses,
Encoding, Characters, Matching, and Root Structure: Time
for Another Look?", RFC 8324, DOI 10.17487/RFC8324,
February 2018, <https://www.rfc-editor.org/info/rfc8324>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
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>.
[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and [RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
A. Mankin, "Recommendations for DNS Privacy Service A. Mankin, "Recommendations for DNS Privacy Service
skipping to change at page 19, line 14 skipping to change at page 22, line 17
service policies of social networking services", service policies of social networking services",
Information, Communication and Society (2018): 1-20 , Information, Communication and Society (2018): 1-20 ,
2018. 2018.
[Vastaamo] Redcross Finland, ., "Read this if your personal data was [Vastaamo] Redcross Finland, ., "Read this if your personal data was
leaked in the Vastaamo data system break-in", leaked in the Vastaamo data system break-in",
https://www.redcross.fi/news/20201029/read-if-your- https://www.redcross.fi/news/20201029/read-if-your-
personal-data-was-leaked-vastaamo-data-system-break , personal-data-was-leaked-vastaamo-data-system-break ,
October 2020. October 2020.
Author's Address Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Email: jari.arkko@ericsson.com Email: jari.arkko@ericsson.com
Jiri Novotny
Ericsson
Email: jiri.novotny@ericsson.com
 End of changes. 47 change blocks. 
101 lines changed or deleted 240 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/