[Add] My longer list of questions [from partial distribution at the MIC]

[<[e-mail]>]

Wes posted a set of 8 thought-provoking questions to the list yesterday. Below is my attempt at a response to each one. Also I fully agree that protocols are not evil, and have never suggested that one is. It is the use of them that we are considering.

Anyway, to the questions.

1. My goals are to add privacy and security to DNS while not breaking things, still keeping a lid on malware, not astonishing end users, obtaining their informed consent for any necessary data processing, and for the provider of the access network (such as an ISP) to be able to offer support to users who are experiencing problems. The architecture described by Brian Dickson in https://mailarchive.ietf.org/arch/msg/add/HlKG81q7N-3WdAzIhsM0j-IEjuI makes some first steps on this journey, by arranging for all compliant applications to use the same route out of the users' device.

2. If browsers honor the DoH-Preference header described in draft-schinazi-httpbis-doh-preference-hints, yes, this can split the global name space. If google.com tells me to use chrisboxatbt.dns.google.com for all google.com resolutions, then Google is at liberty to respond to my queries there in an entirely different way than they would for their public authoritative zones. It also makes it trivially easy to identify me.

3. One ramification of the above is that it would not be possible for an enterprise firewall to dynamically permit outbound access to an IP address because it had seen the related DNS answer that provided the IP, and it's satisfied that the domain being connected to is ok. There will be many others.

4. Descriptions of many operational impacts of both encryption and centralization can be found in draft-reid-doh-operator and draft-livingood-doh-implementation-risks-issues.

5. I think we have an obligation to inform users which companies will be recording where they go on the internet. It can be argued that if users choose to purchase access from provider X, then they have consented to X handling this in some way. Similar when users choose to go to website Y, they have consented that Y will know about this. Beyond that, users will be surprised, and customer support will be at best difficult, at worst impossible.

6. If we were starting from scratch, obviously we would begin with the requirements, but these are still up for debate because we are talking about privacy and it's not yet clear who has the right to know about, and influence, network access. I think we need rough consensus on the requirements before design could begin.

7. It's clear to me that a ramification of fragmented DNS is a lower rate of caching, and higher latency. In an environment such as Uganda it can be highly impacting: https://mailarchive.ietf.org/arch/msg/add/qkbGVukRPkh1wuiGCHmPPn6TwOw

8. You ask for "localized, encrypted resolution that preserves user DNS resolution privacy". In part this depends on the extent to which the user is happy with sharing data with the local network provider. If they trust BT as an ISP, and are at home, using the BT network, then the answer is simple - they could use BT's local DoH server for everything. In less straightforward cases, perhaps there needs to be access to both a local resolver and a more central resolver that this user has chosen to trust. We could extend this with the resolvers owned by websites they are accessing, but this leads to the tracking and split namespace issues described above.

I do not know the optimal solution here; all I know is there are a set of problems waiting to be solved.

Chris

-----Original Message-----
From: Add <[e-mail]> On Behalf Of Wes Hardaker
Sent: 24 July 2019 11:17
To: [e-mail]
Subject: [Add] My longer list of questions [from partial distribution at the MIC]


Below is the longer list of thoughts at questions about ADD that I started at the microphone.  Thank you especially to those that encouraged me to write these up.

# Thoughts:

## Protocols themselves are not evil

They're just bits on a wire.  It's only misuse of the bits that is a problem.  DNS is not a problem.  DoH is not a problem.  It's ONE solution to an underlying problem: solving a privacy problem by encrypting DNS requests and responses help to ensure user privacy, and DoH is one mechanism to attempt to solve aspects of that problem.  It does so by shifting who can see the traffic, which is all encryption can ever easily do.  We have multiple choices in front of us, and I don't find any of them ideal with "no cons".

## Routing DNS requests

Today, devices are already routing DNS requests to places different than the access point initially offered them.  They do this sometimes by routing everything through a different network, such as when a VPN is in use.  Split-tunnel VPNs are a bit more tricky, as typically all DNS requests are routed to the VPN's DNS server (for split-DNS "benefits") even though traffic sent to resolved addresses may not be.  In both of these cases, users are typically aware that they're operating in a special environment.  The average user does not, however, use a VPN.

ADD technologies, which include DoH, DoT, global resolvers (e.g. google, cloudflare, quad9, opendns), and in-application full resolution required for in-app DNSSEC validation, all have the potential to change where resolution occurs at a much more granular level.  DNS requests may be handled by completely different services based on the application type (e.g. web browser vs an email application displaying html) or even implementation (e.g. Firefox vs Opera).  It is highly unlikely that the average user will be aware of this DNS request distribution architecture, however. Users will have trouble selecting where to send trouble ticket requests when "some aspect" of the Internet isn't working for them when "it's always the DNS".  For example, a newly emerging issue may be a website that may suddenly not work under Chrome when it does under Safari, with the underlying reason being solely where DNS resolution happens.

[Note: I'm not labeling this change as good or bad, just calling it out as something worth consideration]

## User understanding becomes tricky

# Questions outstanding in my mind:

The above has led me to a series of questions, that I would love community input and thought about.

1. Our primary goal in the IETF is standardization when interoperability over individually different implementation is beneficial.  As multiple application stacks are trending toward their own initial implementations of DNS resolution, what are the goals of promoting interoperability and
(hopefully) interchangeability?  What features and benefits are we architecting for?  What can we make simpler?  What is the right/best architecture for the problem?

2. Does splitting the DNS resolution paths into small pieces (possibly with a potential side-effect of centralization if only a few resolution services are offered), have the potential to split the global name space (further)?  If DNSSEC validation is only performed at the resolver, and never in the application, then resolvers have the freedom to answer for names that may not exist, or not answer for names that they are censoring by choice (spam, malware protection) or by force (government mandate through jurisdictional control).  What concerns should we be focusing on in this area to ensure the continuation of a consistent global name space under the dual threat/benefit of possible centralization?

3. What other ramifications exist by promoting a per-protocol or per-application or per-vendor DNS resolution solution?

4. What operational impacts will there be from encrypting all DNS traffic, both good and bad?  Just like TLS in the data-center issues have made debugging user problems difficult (and expensive), DoH and similar technologies may render ISP/access-point help desk's functionally unhelpful.

5. Do we and how do we inform users of this new architecture? Do users need to know what the resolution default path's are for of each OS, service and application?  What are the ramifications of adding another service that makes it harder for them to provide support desks with the necessary details of issues they're observing.

6. If we were architecting this from scratch, what protocol would be select today?  Would it be DoH?  Would it be DoT?  Would it be DNSCurve?
If we didn't have the deployment impediments that are getting in the way today (e.g. forced filtering), what would we select?  Are we architecting solutions for impediments over good engineering because we must?  Is there a better middle ground?

7. Deployment optimization is always difficult, and with a distributed DNS resolution system/fragmentation, architecting effective resolution caching becomes even more challenging.  What ramifications are likely to appear as a result of having multiple caches with different contents on end-user devices?  What are the ramifications of such a system in a low-bandwidth, or high-loss environment?

8. How does application-centric resolution affect and get affected by localization efforts and constant mobility?  Is centralization likely because a global-scale, low-latency resolution is difficult for small-scale deployments?  Can we achieve localized, encrypted resolution that preserves user DNS resolution privacy without requiring centralization?



[side thought this morning: I was imagining an airline attendant resetting the entire plane's network because of multiple complaints by passengers having network trouble, when the reality was they were all using a web browser pointing to a single (default?) DoH vendor and it had nothing to do with the local access point, but all passengers had to suffer the reset]

--
Wes Hardaker
USC/ISI

--
Add mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/add