draft-arkko-dns-confidential-01.txt   draft-arkko-dns-confidential.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft J. Novotny Internet-Draft J. Novotny
Intended status: Informational Ericsson Intended status: Informational Ericsson
Privacy Improvements for DNS Resolution with Confidential Computing Privacy Improvements for DNS Resolution with Confidential Computing
draft-arkko-dns-confidential-01 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 Confidential 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. The document looks at the context of DNS resolution services. The document looks at the
operational implications of running services in a way that even the operational implications of running services in a way that even the
owner of the service or compute platform cannot access user-specific owner of the service or compute platform cannot access user-specific
information produced by the resolution process. 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.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 11 September 2021. This Internet-Draft will expire on 3 January 2022.
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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
7.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Debugging . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Debugging . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Dependencies . . . . . . . . . . . . . . . . . . . . . . 11 7.3. Dependencies . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Additional services . . . . . . . . . . . . . . . . . . . 12 7.4. Additional services . . . . . . . . . . . . . . . . . . . 12
7.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 12 7.5. Performance . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Observations from outside the TEE . . . . . . . . . . . . 13 8.1. Observations from outside the TEE . . . . . . . . . . . . 13
8.2. Trust Relationships . . . . . . . . . . . . . . . . . . . 13 8.2. Trust Relationships . . . . . . . . . . . . . . . . . . . 13
8.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 14 8.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 14
8.4. Other vulnerabilities . . . . . . . . . . . . . . . . . . 15 8.4. Other vulnerabilities . . . . . . . . . . . . . . . . . . 15
9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
DNS privacy has been a popular topic in the last few years, and 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 continues to be. The issues with regards to privacy are first that
skipping to change at page 9, line 8 skipping to change at page 9, line 8
* Through off-line reliance on a particular service, i.e., a human * Through off-line reliance on a particular service, i.e., a human
decision to use a particular system. Once there is a decision to decision to use a particular system. Once there is a decision to
use a particular system, cryptographic means such as public keys use a particular system, cryptographic means such as public keys
may be used to ensure that the client is indeed connected to the may be used to ensure that the client is indeed connected to the
expected server. However, there is no guarantee that the human- expected server. However, there is no guarantee that the human-
space statements about the practices used in running the server space statements about the practices used in running the server
are valid. are valid.
* Cryptographic check that the service is actually running inside a * Cryptographic check that the service is actually running inside a
valid TEE and that it runs the expected software. Such a checks valid TEE and that it runs the expected software. Such checks
needs to rely on third parties. In this case the user's computer needs to rely on third parties. The attestation verification is
performs a remote attestation about the server. The user's performed by a verifier - that can be either user's computer or a
computer checks that (a) the cryptographic attestation refers to a designated verifier as discussed in [I-D.ietf-rats-architecture]
server machine that is acceptable to the user (e.g., manufactured and [I-D.voit-rats-attestation-results] The verifier checks that
by a manufacturer it trusts, CPU features considered secure are (a) the cryptographic attestation refers to a server machine that
used, features considered insecure are turned off, etc.) (b) that is acceptable to the user (e.g., manufactured by a manufacturer it
the software image designated as being run in the attestation is a trusts, CPU features considered secure are used, features
software image that the user's computer is willing to use (e.g., considered insecure are turned off, etc.) (b) that the software
image designated as being run in the attestation is a software
image that the relying party (end user) is willing to use (e.g.,
has a hash that matches a known software that does not log user has a hash that matches a known software that does not log user
actions, or is vouched as trustworthy by another party that the actions, or is vouched as trustworthy by another party that the
user's computer trusts). relying party trusts).
7. Operational Considerations 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 authors' experience with these arrangement for DNS, based on the authors' experience with these
systems. systems.
7.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
skipping to change at page 12, line 40 skipping to change at page 12, line 40
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.
7.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 DNS resolution within a TEE where their
DNS server to support Confidential Computing, and were able to solution could outperform the open source Unbound DNS server in
provide better performance than the original server, due to better certain scenarios, especially in situations where there are not a lot
use of threading. of DNS client connections. We concur their suggestion that at
current stage of Confidential Computing technology, possible
implementations may be more suited for local DNS resolution services
rather than global scale implementation, where the performance hit
would be much more significant. Nonetheless with Confidential
Computing technology ever evolving we believe the low performance
overhead solutions will be possible in foreseeable future.
However, other things being equal there's likely some performance Other things being equal there's likely some performance hit, as
hit, as current Confidential Computing technology typically involves 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.
In practice, all communications need to go through both, and the In practice, all communications need to go through both, and the
communication between the two parts consumes some cycles. There are communication between the two parts consumes some cycles. There are
also current limitations on amount of memory or threads supported by also current limitations on amount of memory or threads supported by
these technologies. However, newer virtualization-based confidential these technologies. However, newer virtualization-based confidential
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
skipping to change at page 15, line 44 skipping to change at page 15, line 46
factors beyond privacy, such as cost, ease of use, switching costs, factors beyond privacy, such as cost, ease of use, switching costs,
and so on. and so on.
There is also a danger of attacks or pressure from intelligence There is also a danger of attacks or pressure from intelligence
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 than 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.
9. 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 authors would like to draw attention to the problem of data The authors would like to draw attention to the problem of data
leaks, particularly for data in use, and RECOMMEND the application of leaks, particularly for data in use, and RECOMMEND the application of
skipping to change at page 17, line 16 skipping to change at page 17, line 20
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.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Matti Kauppi, Jimmy Kjaellman, and The authors would like to thank Juhani Kauppi, Jimmy Kjaellman, and
Tero Kauppinen for their work on systems supporting some of the ideas Tero Kauppinen for their work on systems supporting some of the ideas
discussed in this memo, and Dave Thaler, Daniel Migault, Karl discussed in this memo, and Dave Thaler, Daniel Migault, Karl
Norrman, and Christian Schaefer for significant feedback on early Norrman, and Christian Schaefer for significant feedback on early
version of this draft. The author would also like to thank Marcus version of this draft. The author would also like to thank Marcus
Ihlar, Maria Luisa Mas, Miguel Angel Munos De La Torre Alonso, Jukka Ihlar, Maria Luisa Mas, Miguel Angel Munos De La Torre Alonso, Jukka
Ylitalo, Bengt Sahlin, Tomas Mecklin, Ben Smeets and many others for Ylitalo, Bengt Sahlin, Tomas Mecklin, Ben Smeets and many others for
interesting discussions in this problem space. interesting discussions in this problem space.
11. References 11. References
skipping to change at page 18, line 10 skipping to change at page 18, line 16
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.
[CC] Rashid, F.Y., "What Is Confidential Computing?", IEEE [CC] Rashid, F.Y., "What Is Confidential Computing?", IEEE
Spectrum, https://spectrum.ieee.org/computing/hardware/ Spectrum, https://spectrum.ieee.org/computing/hardware/
what-is-confidential-computing , May 2020. what-is-confidential-computing , May 2020.
[CCC-Deepdive] [CCC-Deepdive]
Confidential Computing Consortium, ., "Confidential Confidential Computing Consortium, ., "A Technical
Computing Deep Dive v1.0", Analysis of Confidential Computing",
https://confidentialcomputing.io/whitepaper-02-latest , https://confidentialcomputing.io/whitepaper-02-latest ,
October 2020. January 2021.
[Chautauquan] [Chautauquan]
"The Chautauquan", Volume 3, Issue 9, p. 543 , June 1883. "The Chautauquan", Volume 3, Issue 9, p. 543 , June 1883.
[Comparison] [Comparison]
Mofrad, S., Zhang, F., Lu, S., and W. Shi, "A comparison Mofrad, S., Zhang, F., Lu, S., and W. Shi, "A comparison
study of intel SGX and AMD memory encryption technology", study of intel SGX and AMD memory encryption technology",
HASP '18, Proceedings of the 7th International Workshop on HASP '18, Proceedings of the 7th International Workshop on
Hardware and Architectural Support for Security and Hardware and Architectural Support for Security and
Privacy, Pages 1-8, Privacy, Pages 1-8,
skipping to change at page 19, line 26 skipping to change at page 19, line 33
Huitema, C., Mankin, A., and S. Dickinson, "Specification Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", Work in Progress, of DNS over Dedicated QUIC Connections", Work in Progress,
Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February
2021, <https://www.ietf.org/archive/id/draft-ietf-dprive- 2021, <https://www.ietf.org/archive/id/draft-ietf-dprive-
dnsoquic-02.txt>. 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-09, 7 March Progress, Internet-Draft, draft-ietf-rats-eat-10, 7 June
2021, <https://www.ietf.org/archive/id/draft-ietf-rats- 2021, <https://www.ietf.org/archive/id/draft-ietf-rats-
eat-09.txt>. eat-10.txt>.
[I-D.ietf-tls-esni] [I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS
Encrypted Client Hello", Work in Progress, Internet-Draft, Encrypted Client Hello", Work in Progress, Internet-Draft,
draft-ietf-tls-esni-10, 8 March 2021, draft-ietf-tls-esni-11, 14 June 2021,
<https://www.ietf.org/archive/id/draft-ietf-tls-esni- <https://www.ietf.org/archive/id/draft-ietf-tls-esni-
10.txt>. 11.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] [I-D.reddy-add-server-policy-selection]
Reddy, T., Wing, D., Richardson, M. C., and M. Boucadair, Reddy, T., Wing, D., Richardson, M. C., and M. Boucadair,
"DNS Server Selection: DNS Server Information with "DNS Server Selection: DNS Server Information with
Assertion Token", Work in Progress, Internet-Draft, draft- Assertion Token", Work in Progress, Internet-Draft, draft-
reddy-add-server-policy-selection-07, 9 March 2021, reddy-add-server-policy-selection-08, 29 March 2021,
<https://www.ietf.org/archive/id/draft-reddy-add-server- <https://www.ietf.org/archive/id/draft-reddy-add-server-
policy-selection-07.txt>. 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>.
[I-D.voit-rats-attestation-results]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-voit-rats-
attestation-results-01, 10 June 2021,
<https://www.ietf.org/archive/id/draft-voit-rats-
attestation-results-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", [MozTRR] Mozilla, ., "Security/DOH-resolver-policy",
 End of changes. 20 change blocks. 
33 lines changed or deleted 49 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/