draft-arkko-dinrg-centralization-dns-00.txt   draft-arkko-dinrg-centralization-dns.txt 
Network Working Group J. Arkko
Internet-Draft Ericsson
Expires: 19 November 2021
Mitigation Options against Centralization in DNS Resolvers
draft-arkko-dinrg-centralization-dns-00
Abstract
Centralization and consolidation of various Internet services are
major trends. While these trends have some benefits - for instance
in deployment of new technology - they also have serious drawbacks in
terms of resilience, privacy, and other aspects.
This extended abstract is a submission to the Decentralized Internet
Infrastructure Research Group (DINRG) workshop on Centralization in
the Internet.
The extended abstract focuses on the question of centralization
related to DNS resolver services.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 November 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Informative References . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Abstract
Centralization and consolidation of various Internet services are
major trends. While these trends have some benefits - for instance
in deployment of new technology - they also have serious drawbacks in
terms of resilience, privacy, and other aspects. This extended
abstract focuses on the question of centralization related to DNS
[RFC1035] resolver services.
DNS resolver services are also a good example of centralization and
approaches to dealing with it. The approaches may be applicable in
other contexts as well.
DNS resolver services have evolved in recent years largely due to two
trends:
* Availability of new technology protect the communications relating
to queries with TLS [RFC7858] [RFC8484]
[I-D.ietf-dprive-dnsoquic].
* Introduction of general-purpose resolver services in the Internet,
such as Google's 8.8.8.8 and Cloudflare's 1.1.1.1 service.
It is interesting that privacy of DNS queries has only surfaced as an
issue in recent years [RFC7626] [RFC8324]. The original DNS
protocols had no support whatsover for security, and later designs
such as DNSSEC addressed another problem, reliability of the
information, but not privacy. Yet, DNS queries reveal potentially
the users' entire browsing histories.
However, even when DNS queries are hidden inside communications, any
DNS resolvers still have the potential too see the users' actions.
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 of the users. The use of information
garnered from centralized services is particularly concerning in
light of possible pervasive surveillance [RFC7258].
While these services are run by highly competent organizations and
for the benefit of users, in general, it is undesirable to create
Internet architectures or infrastructure that collects massive amount
of information about users in few locations. Over longer time
scales, the danger is that it will not be possible to withstand legal
or commercial pressures to employ such information base in a way that
is actually not in line with the interests of the users.
The full paper for the workshop will discuss the reasons for
centralization in the DNS case, the problems it causes, and outlines
a number of directions for solutions.
Solutions address the privacy problems either by reducing the
centralization, reducing the information given to the centralized
solutions, or make it hard to use the information collected in the
centralized solutions. The solution directions include:
* Avoidance of centralized resolvers, and the introduction of
sufficiently large number of resolvers (e.g., in ISP networks).
* Improved practices, expectations, and contracts (e.g., [RFC8932],
Mozilla's trusted recursive resolver requirements [MozTRR])
* 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. The IETF working group ADD is
addressing these mechanisms.
* Service distribution through making users employ several services
such that only part of information is available in each service
(e.g,, [I-D.arkko-abcd-distributed-resolver-selection]).
* Splitting information generated by queries into parts that are
handled by different parties in a way that either part is useless
for data collection (unless the parties co-operate). Oblivious
DNS ([Oblivious]) is an example of this.
* Confidential computing mechanisms that set up technical boundaries
for even service or server hardware owners to peek into the DNS
resolver process (e.g., [PDoT] [I-D.arkko-dns-confidential]). For
the base confidential computing technology, see, e.g., [CC]
[CCC-Deepdive] [SGX] [Efficient] [Innovative] [Mem]
[I-D.ietf-rats-architecture] [I-D.ietf-rats-eat].
Addressing the resiliency problems associated with centralization is
harder. This further discussed in
[I-D.arkko-arch-infrastructure-centralisation].
2. Informative References
[CC] Rashid, F.Y., "What Is Confidential Computing?", IEEE
Spectrum, https://spectrum.ieee.org/computing/hardware/
what-is-confidential-computing , May 2020.
[CCC-Deepdive]
Confidential Computing Consortium, ., "Confidential
Computing Deep Dive v1.0",
https://confidentialcomputing.io/whitepaper-02-latest ,
October 2020.
[Chautauquan]
"The Chautauquan", Volume 3, Issue 9, p. 543 , June 1883.
[Efficient]
Suh, G.E., Clarke, D., Gasend, B., van Dijk, M., and S.
Devadas, "Efficient memory integrity verification and
encryption for secure processors", Proceedings. 36th
Annual IEEE/ACM International Symposium on
Microarchitecture, MICRO-36, San Diego, CA, USA, pp.
339-350, doi: 10.1109/MICRO.2003.1253207 , 2003.
[I-D.arkko-abcd-distributed-resolver-selection]
Arkko, J., Thomson, M., and T. Hardie, "Selecting
Resolvers from a Set of Distributed DNS Resolvers", Work
in Progress, Internet-Draft, draft-arkko-abcd-distributed-
resolver-selection-01, 9 March 2020,
<https://www.ietf.org/archive/id/draft-arkko-abcd-
distributed-resolver-selection-01.txt>.
[I-D.arkko-arch-infrastructure-centralisation]
Arkko, J., "Centralised Architectures in Internet
Infrastructure", Work in Progress, Internet-Draft, draft-
arkko-arch-infrastructure-centralisation-00, 4 November
2019, <https://www.ietf.org/archive/id/draft-arkko-arch-
infrastructure-centralisation-00.txt>.
[I-D.arkko-dns-confidential]
Arkko, J. and J. Novotny, "Privacy Improvements for DNS
Resolution with Confidential Computing", Work in Progress,
Internet-Draft, draft-arkko-dns-confidential-01, 10 March
2021, <https://www.ietf.org/archive/id/draft-arkko-dns-
confidential-01.txt>.
[I-D.arkko-farrell-arch-model-t-redux]
Arkko, J. and S. Farrell, "Internet Threat Model
Evolution: Background and Principles", Work in Progress,
Internet-Draft, draft-arkko-farrell-arch-model-t-redux-01,
22 February 2021, <https://www.ietf.org/archive/id/draft-
arkko-farrell-arch-model-t-redux-01.txt>.
[I-D.iab-dedr-report]
Arkko, J. and T. Hardie, "Report from the IAB Workshop on
Design Expectations vs. Deployment Reality in Protocol
Development", Work in Progress, Internet-Draft, draft-iab-
dedr-report-01, 2 November 2020,
<https://www.ietf.org/archive/id/draft-iab-dedr-report-
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]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture", Work
in Progress, Internet-Draft, draft-ietf-rats-architecture-
12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
ietf-rats-architecture-12.txt>.
[I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-09, 7 March
2021, <https://www.ietf.org/archive/id/draft-ietf-rats-
eat-09.txt>.
[Innovative]
Ittai, A., Gueron, S., Johnson, S., and V. Scarlata,
"Innovative Technology for CPU Based Attestation and
Sealing", HASP'2013 , 2013.
[Mem] Henson, M. and S. Taylor, "Memory encryption: a survey of
existing techniques", ACM Computing Surveys volume 46
issue 4 , 2014.
[MozTRR] Mozilla, ., "Security/DOH-resolver-policy",
https://wiki.mozilla.org/Security/DOH-resolver-policy ,
2019.
[Oblivious]
Schmitt, P., "Oblivious DNS: Practical privacy for DNS
queries", Proceedings on Privacy Enhancing Technologies
2019.2: 228-244 , 2019.
[PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private
DNS-over-TLS with TEE Support", Digit. Threat.: Res.
Pract., Vol. 2, No. 1, Article 3,
https://dl.acm.org/doi/fullHtml/10.1145/3431171 , February
2021.
[RFC1035] Mockapetris, P.V., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[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.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
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
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and
A. Mankin, "Recommendations for DNS Privacy Service
Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932,
October 2020, <https://www.rfc-editor.org/info/rfc8932>.
[SGX] Hoekstra, M.E., "Intel(R) SGX for Dummies (Intel(R) SGX
Design Objectives)", Intel,
https://software.intel.com/content/www/us/en/develop/
blogs/protecting-application-secrets-with-intel-sgx.html ,
September 2013.
Author's Address
Jari Arkko
Ericsson
Email: jari.arkko@ericsson.com
 End of changes. 1 change blocks. 
lines changed or deleted 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/