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

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Jul 2019 08:16:32 -0700

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

---

From: <[email-masked]>
Date: Thu, 25 Jul 2019 22:59:43 +0000

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 <[email-masked]> On Behalf Of Wes Hardaker
Sent: 24 July 2019 11:17
To: [email-masked]
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:

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]

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
[email-masked]
https://www.ietf.org/mailman/listinfo/add

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 26 Jul 2019 07:52:06 +0200

On 24 Jul 2019, at 17:16, Wes Hardaker wrote:

> 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?

The base architecture as defined by the IETF include two main things for DNS from my point of view:

- The routing of the DNS query (i.e. configuration of what is the full service resolver) is set by what I call "the operating system". All applications use the same configuration.

- The default configuration is set by the access provider that the end user have some kind of agreement with. Irrespectively if the end user is buying Internet Access at home or is at an enterprise. The end user might do override of this by configuring a different end point (x.x.x.x - technologies) or by launching a VPN tunnel which I see as "layering access on top of access" which implies getting a new default configuration when the tunnel is up.

My view: Changing *any* of these two base assumptions is what I do not think IETF should do.

> 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)?

Yes.

> 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?

By not changing the two base assumptions above as I lay out as response to (1) we do not rock the boat regarding evolution of name resolution.

If the above (...DNSSEC validation is only performed at the resolver...) is a negative thing, which I can agree it is, then *that* should be fixed, not breaking the two base assumptions I lay out above under (1).

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

The issues are mainly two:

A. The ability to "understand what is going on" when "the access to internet is broken". Support cost is unknown. Changing responsibilities regarding DNS resolution will make it crystal clear end users can and will no longer get help with DNS resolution from their network provider regardless of whether it is the enterprise or local ISP. This implies they will no longer help with connection issues.

I.e. operational nightmare.

B. Legal responsibilities for DNS resolution is today tied to the responsibilities regarding routing and IP address allocation, i.e. with the access provider. If this is changed, the legal situation in the world will be unknown, and the ramifications of that might break the network we know of today in ways we can not even dream of.

Note: if the end user by making its own decision to override the DNS resolution path given by the access provider, she can do so by changing the default configuration to something else (X.X.X.X), use a VPN, or by being a customer of some managed device system/mechanism (like by the enterprise they work for).

> 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), D…

Two issues here as well:

A. Encrypting traffic is, which IETF have said already, a good thing. I agree with this. The downside will be that deep packet inspection will not give information about the DNS traffic that passes the point of inspection. I think that is a good thing, and exactly why we have encryption.

B. Given encryption will protect the traffic, whoever have interest in inspecting the traffic anyways will have to say "no" in some way to the ability to "hide". The only way to do so is to block specific traffic that is "no longer allowed", and when implementing such policy that should be as surgical as possible without secondary damages. To be able to minimize secondary damages, it is important to separate "the bad traffic" from other traffic. Conclusion: mixing encrypted DNS traffic with encrypted other traffic and not having the ability to separate the two is *not* a good thing.

Conclusion: This is where DoT and DoH and other technologies differ, and while I think it is a good thing that DNS traffic end up being encrypted, it must be possible to identify what is DNS-hidden-in-TLS traffic from other-things-hidden-in-TLS, for example by using different port numbers.

> 5. Do we and how do we inform users of this new architecture?

I do not know what "this new architecure" is as the above have many open ended questions.

> 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.

If there are changes in the form of:

A. The end point of DNS routing is changing from access provider setting to application setting

OR

B. There is no longer a default setting in the operating system for DNS routing but instead a per application setting

OR

C. DNS query resolution is impossible to separate from other protocols

...then IETF must inform not only end users, but also manufacturers and legislators and inform them how these mechanisms are to be implemented given the new architecture IETF has invented:

A. How to do customer support and who is responsible for the end user ability to use the Internet?

B. How a legislator is to implement (and not) blocking access to certain domain names?

C. How an enterprise is implementing policies today implemented by managed device technologies and mix of flow inspection, dynamic IP tables and DNS resolutions?

> 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 be…

IETF is in the danger of just looking at one piece of of the puzzle and forgetting the architecture it is responsible for.

The IETF is responsible for ensuring "Internet works", and this today implies ability for not only end users to do their thing, but also enterprises, access providers and what not.

Legislation in the world is in IETF only talked about in the form of "bad States that require blocking" but we also have States that have requirements on access providers that the Internet Access must work, with severe penalties if it does not. If IETF by just looking at some local protocol detail is changing this oversight ability from the State to ensure ISPs do the right thing (regarding Network Transparency, Open Internet Access and what not) then IETF has the responsibility to not only explain this to the legislators and States around the world and also if needed come up with other protocol changes needed in the whole architecture that ensure future functionality.

That States or Enterprises want to block access to certain domain names is something that will not go away just because some individuals and individual companies active in the IETF have some cool ideas on how to do DNS.

It is time for IETF to grow up and be a real standard organization really taking some real responsibilities. And for example for every proposed protocol change regarding DNS resolution answer the questions and more:

- Who is responsible for DNS resolution from the end users perspective?
- How can legislation ensure this responsibility stays there?
- How is an enterprise or network provider ensuring name resolution is according to its policies?
- How is the end user given the above making a conscious choice and opt-out of the mechanisms provided and run on her own?

The danger is when a corner of the IETF say that every user of the internet is now opting out without that being known to anyone operationally involved (including legally), and without IETF having tools in place to ensure responsibilities still exists and policies can be implemented.

> 7. Deployment optimization is always difficult, and with a distributed DNS resolution system/fragmentation, architecting effective resolution caching becomes even more challenging.  What ramificati…

Nothing prohibits the recursive resolver (which also might do validation) on the local ::1 host route the DNS queries to a box which in turn use a forwarder which might even be a X.X.X.X kind of service. I.e. caching has to do with the RD flag more than the DNS routing.

In high latency or low bandwidth environments, a local cache is good. In higher bandwidth low latency, large centralized cache is good.

I do not know how many locations in low latency scenarios I have helped by having them adding (as the network operator) a local full service resolver that accepts RD. Sure, slow before the cache is loaded, but earlier every query was slow.

It is further bad to see TTL go down on RRSets as that also makes caches in specifically difficult environments have issues if queries for the same RRSet is sent more rarely than the TTL. Then the cache is cold in every TTL cycle.

> 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 difficu…

An access provider can already today choose to for example give their customers X.X.X.X as the end point of the DNS query routing. They can choose to run the recursive resolver themselves. They can choose to do forwarding to X.X.X.X in their recursive resolver. And with "access provider" I include not only "the ISP a user have at home" or "mobile operator" but also enterprise or for that matter the end user that buys a CPE and connects it to the ISP they get service from.

Adding encryption to this is a piece of cake given a. we keep the DNS configuration architecture the same and b. we keep the protocol identifiable and separable from other protocols.

> [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…

Exactly.

The Internet Architecture is built upon the idea that default configuration of DNS, IP address allocation and routing is the responsibility of whoever provides Internet Access.

Do not change that.

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Thu, 25 Jul 2019 23:07:46 -0700

On Thu, Jul 25, 2019 at 10:52 PM Patrik Fältström <paf=
[email-masked]> wrote:

> 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]
>
> Exactly.
>

One problem with this assertion is that it's usually the airline's DNS that
fails first and frequently. Try it yourself: turn on a VPN or use DoH in
Firefox next time you're on a plane, and enjoy a much better experience.

I think they do a bunch of aggressive (and, let's note, ineffective) DNS
filtering so people don't watch YouTube, and those servers don't seem to be
very reliable. It would be better to just throttle each client's bandwidth.

>
> The Internet Architecture is built upon the idea that default
> configuration of DNS, IP address allocation and routing is the
> responsibility of whoever provides Internet Access.
>

I couldn't find a reference for this assertion. I looked at RFC 1958 <
https://www.ietf.org/rfc/rfc1958.txt>.

In fact, in section 6.2, it says:
"Confidentiality and authentication are the responsibility of end users and
must be implemented in the protocols used by the end users. Endpoints
should not depend on the confidentiality or integrity of the carriers."

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 26 Jul 2019 08:14:38 +0200

On 26 Jul 2019, at 8:07, Rob Sayre wrote:

> One problem with this assertion is that it's usually the airline's DNS that fails first and frequently. Try it yourself: turn on a VPN or use DoH in Firefox next time you're on a plane, and enjoy a much better experience.

YMMV!

The key here is what responsibility the airline as the network provider have for a well functioning internet access?

My point is that today the airline DO have that responsibility, while you as a customer CAN make a choice like the one you explain.

> I think they do a bunch of aggressive (and, let's note, ineffective) DNS filtering so people don't watch YouTube, and those servers don't seem to be very reliable. It would be better to just throttle each client's bandwidth.

No.

They want to block access to certain things. They have decided to do so by blocking access to certain domain names. This in turn they police by filtering DNS queries.

> "Confidentiality and authentication are the responsibility of end users and must be implemented in the protocols used by the end users. Endpoints should not depend on the confidentiality or integrity of the carriers."

Ehhh...what you say is that it is not the default situation on the Internet today that the access provider has this responsibility, and includes that as part of their service? Can you point me to one access provider which do not include DNS end point information as part of the zeroconf they use in their network?

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Thu, 25 Jul 2019 23:22:59 -0700

On Thu, Jul 25, 2019 at 11:14 PM Patrik Fältström <[email-masked]> wrote:

> They want to block access to certain things. They have decided to do so by
> blocking access to certain domain names. This in turn they police by
> filtering DNS queries.
>

They actually say what they want to do on the billing page: provide basic
internet access for email and whatnot, but not streaming media. They do
this, badly, by using DNS filtering to block YouTube and friends.

So, I guess I disagree with the assertion that they are blocking access to
certain domain names. They aren't blocked to anyone that can install a
free-trial VPN app on their mobile phone.

>
> >> The Internet Architecture is built upon the idea ...
>
> Ehhh...what you say is that it is not the default situation on the
> Internet today
>

Well, you wrote "The Internet Architecture" in all-caps. It seemed like
that might refer to a document or standard of some kind.

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 26 Jul 2019 08:30:38 +0200

On 26 Jul 2019, at 8:22, Rob Sayre wrote:

> They actually say what they want to do on the billing page: provide basic internet access for email and whatnot, but not streaming media. They do this, badly, by using DNS filtering to block YouTube and friends.

Exactly. They have some goal, and implement it by filtering certain domain names, and in turn they implement that by hacking the recursive resolver they provide.

> So, I guess I disagree with the assertion that they are blocking access to certain domain names. They aren't blocked to anyone that can install a free-trial VPN app on their mobile phone.

Exactly my point. They like enterprises like governments do look at how successful the blocking mechanisms they have deployed is. As long as it is successful enough, that is enough. When it is not successful enough anymore, they have to change method to reach the same goals.

And my point is that if IETF is changing the model so that the success rate changes in implementing such policies, then IETF have a responsibility to provide other tools that can be used by the same parties to implement the same policies.

And to answer THAT question, my view is that it would be silly for the IETF to change the overall model when just by changing the DNS protocol to be encrypted, but not how to do DNS endpoint detection (for example) is so much easier. That way we get privacy, still have the ability for the end user to override the default setting and IETF do not have to really answer questions by for example legislators, hardware- and software manufacturers etc.

> Well, you wrote "The Internet Architecture" in all-caps. It seemed like that might refer to a document or standard of some kind.

Ok, noted. My apologies. My intention with the caps was exactly the opposite, it was to talk about what is in reality deployed out there.

This while (as you point out) the end user have the ability to override that by reconfiguring the operating system or use a VPN (or sign up to some managed device service).

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Thu, 25 Jul 2019 23:44:41 -0700

On Thu, Jul 25, 2019 at 11:30 PM Patrik Fältström <[email-masked]> wrote:

>
> And my point is that if IETF is changing the model so that the success
> rate changes in implementing such policies, then IETF have a responsibility
> to provide other tools that can be used by the same parties to implement
> the same policies.
>

I don't agree with this part of your message, and I don't think you will
find any IETF guideline supporting it (RFC 1958 seems against it, in fact).
Someone at the ADD BoF mic mentioned that these arguments seem
eerily-similar to those around HTTP/2 encryption, and I agree.

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 26 Jul 2019 08:55:52 +0200

On 26 Jul 2019, at 8:44, Rob Sayre wrote:

> I don't agree with this part of your message, and I don't think you will find any IETF guideline supporting it (RFC 1958 seems against it, in fact).
> Someone at the ADD BoF mic mentioned that these arguments seem eerily-similar to those around HTTP/2 encryption, and I agree.

First, the days are different now than before. Secondly, I claim IETF *did* explain to everyone why security as defined by SSL and TLS mechanisms improved the user experience to the point that discussions between States (for example) whether encryption in that way should be disallowed or not. Those explanations and "enough friendly governments" makes it possible to kill all international initiatives regarding forbidding those kind of encryption of flows.

This is the result of the long term path that IETF have taken, very much together with other standards organisations like W3C and others. But for example, not so much with ENISA although the issues there regarding TLS1.3 seems to be under control thanks to hard work there.

This is *exactly* my point. That *if* IETF do changes to "how the internet works" then IETF must take the same responsibility this time, and have tools, ideas, arguments lined up regarding how the new architecture is too look like. And be prepared to get counter arguments from everyone that do think it is necessary to (for example) a. identify DNS protocol flows or b. block lookups of certain domain names.

Not just say "this is the new tool in the toolbox" with the addition "by using this new tool, no one today implementing their policy will be able to do so in the future".

The IETF have a responsibility here. Just like IETF had when HTTP with SSL was introduced.

Or maybe IETF do not view itself being the standards organisation that want to ensure Internet works for the general public?

By being responsible and taking that responsibility it is included to also address these hard problems and answering them, and not only ignoring them.

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jul 2019 07:10:06 -0400

Patrik, regardless of whether the IETF has consensus to rule as you propose we do, we aren’t wizards. We do not have the power to stop apps from using DoH without the operating system’s knowledge. 

If you think this is a solvable problem, then rather than lecturing us on how things should be if we were wizards, it might be better to explain how to actually enforce the policy you think we should require operating systems to enforce. 

Think it through. Do you really want to go there?

Sent from my iPhone

> On Jul 26, 2019, at 2:55 AM, Patrik Fältström <paf=[email-masked]> wrote:
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 26 Jul 2019 10:50:44 -0400

On Fri, Jul 26, 2019 at 7:10 AM Ted Lemon <[email-masked]> wrote:

> Patrik, regardless of whether the IETF has consensus to rule as you
> propose we do, we aren’t wizards. We do not have the power to stop apps
> from using DoH without the operating system’s knowledge.
>

In retrospect, perhaps this should have been considered before DoH was
published, particularly given the ways in which apps bypassing existing DNS
controls (both DNS content and DNS server selection) impact the existing
ecosystems and security for hosts and networks?

>
> If you think this is a solvable problem, then rather than lecturing us on
> how things should be if we were wizards, it might be better to explain how
> to actually enforce the policy you think we should require operating
> systems to enforce.
>

I'm not Patrick, but I do have some observations:

   - One risk of apps that do DoH is the ability of malware to hijack
   DoH-implementing apps. Doing so simplifies the coding needed by the malware
   itself. (This is bad)
   - With the exception of the "dissident" use case, all of the privacy
   features of DoH can be achieved using DoT
   - All of the public resolvers offering DoH also offer DoT.
   - I believe it is the case that DoT is implemented more broadly in DNS
   software than DoH.
   - One approach to enforcing the policy has a larger scope than the OS.
   It is to view DoH itself as the problem, and ask, how can we put the DoH
   genie (djinn) back in the bottle?

The alternative approach to OS enforcement of such a policy, is much more
problematic, with vastly more work required to implement: block
applications from doing TLS themselves, and implement all of the TLS
functionality at the OS level, with access to that via APIs and with
additional controls. This would require substantial rewrites of all
browsers, and would require standardization for the APIs themselves.

Note that the latter could be partially done by the OSes themselves (at
least the blocking part) without IETF participation. No matter what, the
second option is exceedingly ugly, IMHO. It might have been a better
original approach to TLS, but it isn't where we are today, and retrofitting
that level of change into existing platforms (apps and OS) would be a
daunting task.

>
> Think it through. Do you *really* want to go there?
>

I don't think "want" enters into it per se; it is a question of what is
required in order to maintain all the existing functionality for things
implemented in DNS today, and for preventing the problems created when
applications use DoH to bypass OS-selected resolvers. The value of
"required" may differ by environment, and that is a big part of the
problem. The environments where DoH doesn't create problems, is very much a
subset of environments into which DoH applications are already deployed
(even without having DoH enabled).

Brian

> First, the days are different now than before. Secondly, I claim IETF
> *did* explain to everyone why security as defined by SSL and TLS mechanisms
> improved the user experience to the point that discussions between States
> (for example) whether encryption in that way should be disallowed or not.
> Those explanations and "enough friendly governments" makes it possible to
> kill all international initiatives regarding forbidding those kind of
> encryption of flows.
>
> This is the result of the long term path that IETF have taken, very much
> together with other standards organisations like W3C and others. But for
> example, not so much with ENISA although the issues there regarding TLS1.3
> seems to be under control thanks to hard work there.
>
> This is *exactly* my point. That *if* IETF do changes to "how the internet
> works" then IETF must take the same responsibility this time, and have
> tools, ideas, arguments lined up regarding how the new architecture is too
> look like. And be prepared to get counter arguments from everyone that do
> think it is necessary to (for example) a. identify DNS protocol flows or b.
> block lookups of certain domain names.
>
> Not just say "this is the new tool in the toolbox" with the addition "by
> using this new tool, no one today implementing their policy will be able to
> do so in the future".
>
> Or maybe IETF do not view itself being the standards organisation that
> want to ensure Internet works for the general public?
>
> By being responsible and taking that responsibility it is included to also
> address these hard problems and answering them, and not only ignoring them.
>
>   Patrik
>
> --
> Add mailing list
> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jul 2019 11:06:18 -0400

On Jul 26, 2019, at 10:50 AM, Brian Dickson <[email-masked]> wrote:
> One approach to enforcing the policy has a larger scope than the OS. It is to view DoH itself as the problem, and ask, how can we put the DoH genie (djinn) back in the bottle?
The djinn was never in the bottle in the first place. If this discussion is going to continue to entertain the fantasy that malware isn’t already doing this, it’s not likely to be very useful.

I get that there is a wish that it could be possible to prevent tunneling bad things over TLS, but this is simply not an available option unless we outlaw TLS, and it would appear that there is no consensus in the IETF to do this.

That being the case, all outlawing DoH will do is prevent us benefiting from what is good about it. It will not prevent us suffering from what is bad about it.

Does this make sense to you, or do you think there’s actually some benefit to outlawing it?  Do you think you could get consensus on outlawing it?  If you succeeded, what problems would you have solved?

---

From: Brian Dickson <[email-masked]>
Date: Fri, 26 Jul 2019 11:33:48 -0400

On Fri, Jul 26, 2019 at 11:06 AM Ted Lemon <[email-masked]> wrote:

> The djinn was never in the bottle in the first place. If this discussion
> is going to continue to entertain the fantasy that malware isn’t already
> doing this, it’s not likely to be very useful.
>

Malware was already communicating over TLS, but was not doing its DNS over
new channels, until DoH was widely deployed. The community pushing DoH gave
that new set of tools to the malware community.

>
> I get that there is a wish that it could be possible to prevent tunneling
> bad things over TLS, but this is simply not an available option unless we
> outlaw TLS, and it would appear that there is no consensus in the IETF to
> do this.
>

This isn't about TLS itself, this is about port 443 (using TLS).

The new problem is hiding DNS communications in a general-purpose port. It
means that new DNS servers being used cannot be detected, and it means it
is not possible to create a network-level enforcement scheme for which DNS
resolvers can be used (by white-listing or black-listing specific IP
addresses for DNS ports).

DNS resolver choice enforcement is the current mechanism for several
elements of enterprise networks, including preventing information leakage,
preventing breakage of split DNS, and preventing exfiltration and payload
acquisition by bad actors (humans and malware).

DNS resolver detection is one of the most important mechanisms for malware
detection, in particular discovery of new malware packages and/or strains.

>
> That being the case, all outlawing DoH will do is prevent us benefiting
> from what is good about it. It will not prevent us suffering from what is
> bad about it.
>

I fear you are conflating "DoH" with "all DNS over TLS things".

The only thing that differentiates DoH from DoT is the port number, and
inclusion of HTTP headers.

And if you read my whole message, I definitely am not suggesting any change
to the availability and use of DoT.

It is precisely the port number used by DoH that is the problem. That's the
only problem. If DoH were to decide to use a different port number, I would
have zero objection to DoH, and I suspect everyone else raising objections
to DoH would feel the same way.
(There are other issues with applications doing DNS, in terms of exposing
resolver choice to users rather than administrators, plus per-app resolver
choice and non-shared DNS cache, but those are not as fundamental as the
DoH port number issue.)

>
> Does this make sense to you, or do you think there’s actually some benefit
> to outlawing it?  Do you think you could get consensus on outlawing it?  If
> you succeeded, what problems would you have solved?
>

Please, let us try to avoid using pronouns, as that inherently (and perhaps
deliberately) sows confusion or conflates issues.

"It" in your previous sentence could mean many things, everything from
"DoH" to "TLS". I would like to answer the question you are asking, would
you mind rephrasing your question without pronouns?
Also, "you" is ambiguous, do you mean me personally, or the larger "you" of
some particular community? If the latter, which community in particular, or
just generally any larger community?

Also, "outlawing" is definitely a loaded term, and not necessarily an
accurate way of describing the method(s) that might be required to achieve
the results.

A better description of one possible approach would be
deprecating/obsoleting/historicizing DoH-the-protocol, and encouraging
implementers to remove DoH code from their apps, and to shut down DoH on
public resolvers.

That is a hypothetical approach, and not the only approach possible. It is
an answer to your question of "how", not the questions on "whether", or
"consensus". Those are separate discussions, and it is probably premature
to start those conversations.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 26 Jul 2019 11:53:45 -0400

> doing this, it’s not likely to be very useful.

One important distinction about malware "doing this": prior to the scenario
where DoH (to an independently-operated resolver) was used, it was possible
to detect this malware activity by correlation between DNS queries and TLS
connections.

In order to establish a TLS connection, the client app needs to do a DNS
query to identify the IP address of the server to which it plans to connect.

A hypothetical anti-malware system with integration to the DNS query feed,
would be aware of specific clients requesting specific DNS records, and the
TTLs of the responses.

Connections not conforming to tuples of (current time, client IP, server
IP, TTL expiry time) would be detectable and alert-able. (Additional
information on connections' SNI and servers' names allows much greater
accuracy, but if/when ESNI happens, this signal goes away.)

In an environment where DNS resolver choice cannot be detected or enforced,
negates this model, particularly if all DNS query traffic becomes
unobservable to the hypothetical anti-malware system.

This is a change to the threat detection and blocking environment, and
exists only when encrypted DNS is commingled with HTTPS traffic.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jul 2019 12:26:50 -0400

What would be the good outcome that would result from the IETF deprecating DoH?    Who would follow our advice?  

Sent from my iPhone

> On Jul 26, 2019, at 11:53 AM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> One important distinction about malware "doing this": prior to the scenario where DoH (to an independently-operated resolver) was used, it was possible to detect this malware activity by correlation between DNS queries and TLS connections.
> 
> In order to establish a TLS connection, the client app needs to do a DNS query to identify the IP address of the server to which it plans to connect.
> 
> A hypothetical anti-malware system with integration to the DNS query feed, would be aware of specific clients requesting specific DNS records, and the TTLs of the responses.
> 
> Connections not conforming to tuples of (current time, client IP, server IP, TTL expiry time) would be detectable and alert-able. (Additional information on connections' SNI and servers' names allows much greater accuracy, but if/when ESNI happens, this signal goes away.)
> 
> In an environment where DNS resolver choice cannot be detected or enforced, negates this model, particularly if all DNS query traffic becomes unobservable to the hypothetical anti-malware system.
> 
> This is a change to the threat detection and blocking environment, and exists only when encrypted DNS is commingled with HTTPS traffic.
> 
> Brian
>

---

From: Alec Muffett <[email-masked]>
Date: Fri, 26 Jul 2019 17:59:04 +0100

On Fri, 26 Jul 2019, 16:54 Brian Dickson, <[email-masked]>
wrote:

> One important distinction about malware "doing this": prior to the
> scenario where DoH (to an independently-operated resolver) was used, it was
> possible to detect this malware activity by correlation between DNS queries
> and TLS connections.
>

Unless the malware was using (eg) Tor, like in this article from 5 years
ago (and the world hasn't ended yet)

https://blog.trendmicro.com/trendlabs-security-intelligence/defending-against-tor-using-malware-part-1/

At best you might have detected Tor, in such circumstances, rather than
malware; and Tor is literally designed to bypass such filters.

- alec

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 26 Jul 2019 19:26:57 +0200 (CEST)

Il 26 luglio 2019 13:10 Ted Lemon <[email-masked]> ha scritto:

This is true, but the IETF also does not have the power to stop apps from doing things differently from the standards it publishes, yet it still publishes standards. So I do not see what would be wrong if we could come to consensus (assuming that we ever could, something that I don't know) that certain ways of deploying DoH are "best practices" while others are not recommended unless for some specific use cases, or even not recommended at all, because they create worse problems than they solve. This would still not prevent any application from doing the non-recommended things, but at least it would make it clear that this is not how the community thinks that the technology should be used, and make the IETF look a little more friendly to the needs of other Internet stakeholders.

This could also be important since among the unhappy stakeholders there are governments, which could resort to invasive regulatory countermeasures that would have much broader impacts over the Internet's usability and global interoperability, unless the IETF can offer them a better way to exert their sovereignty over the Internet to a reasonable extent.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] | +39 348 7015022
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Brian Dickson <[email-masked]>
Date: Fri, 26 Jul 2019 13:31:11 -0400

Sent from my iPhone

> On Jul 26, 2019, at 12:26 PM, Ted Lemon <[email-masked]> wrote:
> 

I think for the answer to that question, it might be necessary to compare with such deprecation activity such as MD5, TLS versions below 1.3, and other similar situations.

The Internet is a big place with a lot of diverse parties with their own specific approaches to things like this, and it is difficult to predict how any of them would respond, let alone all of them.

A significant factor in any similar situation has been deployment prior to deprecation, and available deployment of successors or alternatives.

I humbly acknowledge that it could get messy, particularly depending on how various groups and entities respond.

The deployment impact is one reason I think this should be addressed widely and soon, so that either way, the impact can be minimized.

Examples of groups that may not all share the same view on the issues at hand, include browser vendors, security vendors, industry groups like CA/B, resolver operators, ISP trade associations, ISPs, national governments, consumer protection entities, enterprises, DNS software vendors, OS maintainers, hosting companies, DPI equipment vendors, IoT vendors, open source router firmware groups, to list just a few off the top of my head.

And the degree to which those same groups have similar or dissimilar views of DoT is a relevant question in the context of “alternatives or successors”.

Brian

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 26 Jul 2019 18:07:28 +0000

I think for the WG to entertain the idea of deprecating or otherwise stop recommending DoH is a bad idea. The comparison with MD5 and outdated TLS versions has a fundamental flaw: those algorithms have suffered from some kind of breakage or weakness against moden infra that made using them insecure. DoH doesn't share that weakness; its effectiveness is actually a root cause of all the WG's debate. I don't think we gain anything from discovering and sharing a useful tool then telling people not to use that tool. And even if we wanted to, they're going to anyway, cat's out of the bag.

> I don't think "want" enters into it per se; it is a question of what is required in order to maintain all the existing functionality for things implemented in DNS today, and for preventing the problems created when applications use DoH to bypass OS-selected resolvers. The value of "required" may differ by environment, and that is a big part of the problem.

I think this is a constructive approach. I don't think we maintain the functionality we have today in the 53U world by finding ways to let middle boxes get access (visibility in any format) to the traffic. A major reason for encrypting DNS or any other traffic is to prevent exactly that. I think we need to focus on making recommendations that will maximize the cases where encrypted DNS traffic is going to RRs the user trusts to do traffic manipulation (parental controls, internal resolution routing, malware blocking, or whatever else that manipulation may be).

The platform can be the source of signal well-behaved apps need to get that kind of insight. For example, without reference to specific APIs, any given platform should know whether its configured DNS servers came from DHCP (and possibly whether the network that recommended them is "user trusted" or not in the context of being a home or work or public network) or were manually set by the user. This information can be used to help sort available RRs by how much the user has expressed trust in them already. If DNS-capable apps (DoH or otherwise) wanted to play nicely in the ecosystem, they could ask the platform about the currently configured system DNS and weigh that against their configuration.

My proposal is this sorting would prefer user involvement over anything else, and admin involvement over non-admin involvement. Meaning, where Firefox is on a platform where an admin has configured the platform's DNS servers manually, it would defer to the system resolver until it can promote its own RR recommendation directly to an admin authority (or to a non-admin user if that's all the system is using). OTOH, if the platform indicates its current DNS servers all came from a less trusted network, the app could then feel justified in deferring to its own recommendation without violating user trust.

Thoughts?

Thanks,
Tommy

________________________________
From: Add <[email-masked]> on behalf of Brian Dickson <[email-masked]>
Sent: Friday, July 26, 2019 10:31 AM
To: Ted Lemon <[email-masked]>
Cc: Patrik Fältström <paf=[email-masked]>; ADD Mailing list <[email-masked]>; Rob Sayre <[email-masked]>; Wes Hardaker <[email-masked]>
Subject: Re: [Add] My longer list of questions [from partial distribution at the MIC]

Sent from my iPhone

On Jul 26, 2019, at 12:26 PM, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Sent from my iPhone

On Jul 26, 2019, at 11:53 AM, Brian Dickson <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jul 26, 2019 at 11:06 AM Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 26, 2019, at 10:50 AM, Brian Dickson <[email-masked]<mailto:[email-masked]>> wrote:

  *   One approach to enforcing the policy has a larger scope than the OS. It is to view DoH itself as the problem, and ask, how can we put the DoH genie (djinn) back in the bottle?

The djinn was never in the bottle in the first place.. If this discussion is going to continue to entertain the fantasy that malware isn’t already doing this, it’s not likely to be very useful.

Brian

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 26 Jul 2019 20:09:37 +0200

First: Ted, you are correct, there is no protocol police and definitely IETF is not the one. Thats not the point.

People do listen to IETF or anyone else that comes up with "good words". There is a competition between standards and material that can be referenced. If IETF is not saying good things, then some other standard organization will be referenced.

This is not about telling people what to NOT do. This is about telling people what they SHOULD do.

> Examples of groups that may not all share the same view on the issues at hand, include browser vendors, security vendors, industry groups like CA/B, resolver operators, ISP trade associations, ISPs…

Plus other Standard Organizations.

> And the degree to which those same groups have similar or dissimilar views of DoT is a relevant question in the context of “alternatives or successors”.

There are so many players that sets the policy for how IP packets can be sent and used today, and if nothing else legal tools used (including licensing, oversight over peering, traffic exchange etc), that unless IETF (with the help of ISOC and cooperation with other SDOs) do take all of these things into account and CONTINUE TO EXPLAIN how a good balance is between the various interests that exists, IETF can quite quickly be non-interesting and loose its voice.

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jul 2019 14:30:03 -0400

I don’t think it’s a bad idea to talk about how well behaved apps and stacks ought to behave. Indeed I think it’s important work. I just want to make sure that we are careful not to imagine that we have powers we don’t actually have as we think about what the right advice may be.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 26 Jul 2019 14:54:55 -0400

Sent from my iPhone

> On Jul 26, 2019, at 2:07 PM, Tommy Jensen <[email-masked]> wrote:
> 

So, this is where I am in favor of deployment and use of DoT, with only the RR having the necessary visibility and control to accomplish the desired results.

The reason for DoT rather than DoH, is to enable detection and/or blocking of DoT connections at the network layer.

The network layer is critical for the ability to enforce policies for all devices on a network, regardless of ownership or status. EG BYOD, environments without active device management, compromised devices, apps with defects, unapproved apps, etc.

DoT is effectively an upgrade, without significant changes to network control capabilities or any new requirements for host level controls.

> My proposal is this sorting would prefer user involvement over anything else, and admin involvement over non-admin involvement. Meaning, where Firefox is on a platform where an admin has configured…

It is an excellent set of ideas for cases where there is no requirement for network level enforcement, or where only untrusted or insecure networks are used. These are a potential part of a larger and improved network ecosystem. However, I believe the network level stuff will always be a necessary aspect for several use cases. It might be the case where some mutual trust and discovery of posture and capability, from a not-yet-selected WG with TBD semantics.

A lot boils down to the concept of “mutual”, or of network-centric controls.

One possibility needs to be that the client has enough information to decide whether to connect to a given network. Multi homes devices (eg smartphones) may have alternative networks they can use.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Fri, 26 Jul 2019 15:23:26 -0400 (EDT)

> And my point is that if IETF is changing the model so that the success rate changes in implementing such policies, then IETF have a responsibility to provide other tools that can be used by the sam…

How dare you make such a good bike lock!

I think RFC 7258 still stands.

> And to answer THAT question, my view is that it would be silly for the IETF to change the overall model when just by changing the DNS protocol to be encrypted, but not how to do DNS endpoint detect…

There is DoT, DoH and VPNs. The problem is not that the IETF is doing
nothing. It is that is doing little to help the enterprise people
mess with DNS "for the user". Mostly because the IETF cannot help with
distinguishing the good people from the bad people.

I think the general enduser philosophy is that they trust a few big
centralized companies more than most network operators of the many
unknown networks they join. The centralization makes me sad, but
the additional security makes me happy. The privacy impact greatly
concerns me.

Paul

---

From: Dominique Lazanski <[email-masked]>
Date: Fri, 26 Jul 2019 17:43:07 -0400

>> On 26 Jul 2019, at 15:23, Paul Wouters <[email-masked]> wrote:
>> 

That’s not the issue. 
> unknown networks they join.

Um no. Depends on the country, the regulatory environment and the users. I trust the operator I use more than one of those big companies. 

> The centralization makes me sad,

Me too. 

> but
> the additional security makes me happy.

You mean additional encryption. For some users, this is a downgrade in security. 

> The privacy impact greatly
> concerns me.

Me too. 

> Paul

Dominique

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 27 Jul 2019 00:13:48 +0200 (CEST)

> Il 26 luglio 2019 21:23 Paul Wouters <[email-masked]> ha scritto:
> 

This is what you think, but is this assumption supported by data? I've never seen any. Moreover, this seems to be highly variable depending on context (location, user type, use case, level of tech-savviness etc). Different people see different contexts and generalize their perception to the entire Intenet.

This is also why, in the end, users need to be allowed to make this choice for themselves, though "I delegate this choice to ..." is also an acceptable user choice.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jul 2019 18:57:31 -0400

On Jul 26, 2019, at 6:13 PM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> This is what you think, but is this assumption supported by data? I've never seen any. 

The main evidence for this is that the businesses that use the “we sell your eyeballs” business model have many orders of magnitude (at least four) more eyeballs total than the companies that don’t have customers.   E.g., facebook and google.  This may change over time, but that’s the status quo, and it does us no good to pretend otherwise.

Also, by the way, if you run Ubuntu linux, you are trusting Canonical just as much as you are trusting Mozilla or Google.  At least Canonical seems willing to let us pay, but it’s important to pay attention to all the orgs we are trusting, and not just the charismatic megafauna.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jul 2019 19:27:03 -0400

> My view: Changing *any* of these two base assumptions is what I do not

I like the way you stated this.

    >> 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?

    > By not changing the two base assumptions above as I lay out as response
    > to (1) we do not rock the boat regarding evolution of name resolution.

    > If the above (...DNSSEC validation is only performed at the
    > resolver...) is a negative thing, which I can agree it is, then *that*
    > should be fixed, not breaking the two base assumptions I lay out above
    > under (1).

I wonder if we should define a new return other than NXDOMAIN that a
resolver that is censoring by choice (spam, malware), such that an
Application Doing DNSSEC could recognize as being intentional?

The NSEC3 would otherwise prove that the QNAME ought to exist.

    > A. The ability to "understand what is going on" when "the access to
    > internet is broken". Support cost is unknown. Changing responsibilities
    > regarding DNS resolution will make it crystal clear end users can and
    > will no longer get help with DNS resolution from their network provider
    > regardless of whether it is the enterprise or local ISP. This implies
    > they will no longer help with connection issues.

This is certainly a valid concern.

Up to now, ad-hoc help (neighboring teenager, etc.) would typically
override DNS server to 8.8.8.8, etc. before calling the ISP.

    > The IETF is responsible for ensuring "Internet works", and this today
    > implies ability for not only end users to do their thing, but also
    > enterprises, access providers and what not.

I like to say the IETF is responsible for Internet and also internet.

I +1 the rest of your comments, thank you Patrik.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 26 Jul 2019 18:35:06 -0500

On 2019-07-26 18:27 -0500, Michael Richardson <[email-masked]> 
wrote:>      > If the above (...DNSSEC validation is only performed at the
> Application Doing DNSSEC could recognize as being intentional?

Not a new return code, but an extension will provide that:
Extended DNS Errors
draft-ietf-dnsop-extended-error-06

For example:
4.6.1.  NXDOMAIN Extended DNS Error Code 2 - Censored

    The resolver attempted to perfom a DNS query but the domain was
    blacklisted by a security policy imposed upon the server being talked
    to.  Note that how the imposed policy is applied is irrelevant (in-
    band DNS somehow, court order, etc).  The R flag should be set.

The main problem remaining probably on how to give that information back 
to the application requesting DNS resolution.
-- 
Patrick Mevzek

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Sat, 27 Jul 2019 00:37:15 +0000

> On Jul 26, 2019, at 2:23 PM, Paul Wouters <[email-masked]> wrote:
> 
> think the general enduser philosophy is that they trust a few big

I’m not sure that’s a supportable statement.  Anecdotally I see lots of people joining WiFi in hotels and coffee shops pretty freely and without concern. 

Certainly there is a class of user who does take extra steps to use things like VPNs, but they are the exception and not the rule.  The global reports on internet traffic from Sandvine and Cisco show that the general user is not taking such action as a vpn or using a DNS service from big centralized companies.   Yes some are, but the traffic volumes in multiple reports show that the general user is not. 

The general user is using their networks suggested choices for DNS and they seem quite ok with that. I say this because they can change it in most networks (Corp networks often being the exception) to one of the centralized services that have been available for some time. Yet they have not made that choice as shown by public global reports which show that dns traffic to those other services is working hard to break 10% of total dns traffic. 

So according to the available data,  it’s not true that general end user philosophy is to trust a few big companies more than most Network operators.

Glenn

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Jul 2019 16:30:24 +0100

On 27/07/2019 01:37, Deen, Glenn (NBCUniversal) wrote:
> So according to the available data,  it’s not true that general end
> user philosophy is to trust a few big companies more than most
> Network operators.
So I think you're both wrong in that you left out the "for what"
that really is necessary when discussing who trusts whom for what.

And since the "for what" in this case is "DNS recursive resolver
selection" and my bet is that few people know what that is, it is
moot to discuss whom a random person might trust more for that.

S.

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Sat, 27 Jul 2019 16:23:50 +0000

> moot to discuss whom a random person might trust more for that.

As you would say ... “fair enough”.   My key point was that there is not data support for the assertion that general users trust a few big companies more.

Glenn

---

From: Ted Lemon <[email-masked]>
Date: Sat, 27 Jul 2019 12:51:24 -0400

On Jul 27, 2019, at 12:23 PM, Deen, Glenn (NBCUniversal) <[email-masked]> wrote:
>  My key point was that there is not data support for the assertion that general users trust a few big companies more.

This is a really puzzling observation.  I guess it depends on what you mean by trust.   You could mean “put their trust in” (operational trust) or you could mean “feel that they are trustworthy” (emotional trust).  Or possibly some third thing I didn’t think of! :)

So if you mean “feel that they are trustworthy,” I think this is true—there’s plenty of evidence that people do not think that various large corporations are trustworthy in that sense.

However, what we mean by “trust” when we are talking about protocols is operational trust: that they actually make a choice to trust the corporation regardless of how they feel about the corporation’s trustworthiness.   We do this all the time, and I suspect everyone here is familiar with the feeling of reluctantly allowing a corporation to be “trusted” when we feel fairly certain they are not worthy of that trust, simply because we have no choice.

In that sense, there is a tremendous amount of data to support the conjecture that users trust a few big companies more.  It’s not because they trust them in the sense of considering them trustworthy, but because they have no choice but to trust them: the small company that might actually be more trustworthy (or might not) is not an option for them.   The service that the end-user wants is not available from that small company.

In this sense, then, we can see that in fact users do trust various large companies.   When they use the resolver offered by their ISP, they are trusting their ISP.   When they use the resolver in the coffee shop, they are trusting the coffee shop.   When they choose to use 8.8.8.8., they are trusting Google, and they are also trusting their ISP not to intercept their connection to Google, if they are using Do53.   If they use 1.1.1.1, the same is true.   If they use 8.8.8.8 with DoT, they are trusting Google, and if their ISP wants to intercept the connection, they will know that this is happening.   But it’s pretty easy for the ISP to do this.

If they want to use 8.8.8.8, and either they know their ISP is not trustworthy, or know that they will sometimes be using ISPs that aren’t trustworthy (the coffee shop use case), then they have no choice but to use DoH, because it’s not really something that a coffee shop would be able to intercept or block, even if they wanted to.

In most cases, I think it’s safe to say that the users just take the default behavior.   So if they have a smartphone, they just trust the vendor to act in their best interests (whether they actually believe the vendor will do this or not).   If they are running Firefox or Chrome, they will trust Mozilla or Google to act in their interest, which may mean using DoH, whether either of these orgs is actually acting in their interest or not.

And if they are using the operating system resolver, they may legitimately hope that what they are buying is an O.S. that doesn’t betray their trust by sending personally-identifying information down the DoH channel.   It might even be possible for a small company to make money offering this as a service, to those people who want it.

So I hope this clarifies the distinction between emotional trust, for which I believe there is plenty of data that actually supports your assertion, and operational trust, for which there is data that pretty definitively contradicts it.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 27 Jul 2019 11:19:06 -0700

> On Jul 27, 2019, at 9:23 AM, Deen, Glenn (NBCUniversal) <[email-masked]> wrote:
> 

The data that I have in mind is Gmail's market share. That seems like big enough fact. It is not unreasonable to believe that moving DNS to a web service would result in the same kind of evolution. Unless of course we do something, but then the question is what.

-- Christian Huitema

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 28 Jul 2019 11:56:56 +0200

> The data that I have in mind is Gmail's market share. That seems like big enough fact. It is not unreasonable to believe that moving DNS to a web service would result in the same kind of evolution.…

It is not IETF that have decided everyone should use a centralised mail service like Gmail. IETF still give the end user a choice on what to do.

I want IETF to have the same view on DNS.

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Sun, 28 Jul 2019 07:37:53 -0400

Sure, but isn’t the conclusion to draw from this that there is at present a natural tendency toward consolidation that exists because we haven’t offered a better alternative?  Isn’t the right answer then to figure out that alternative, rather than to complain about the choices people make in its absence?

Sent from my iPhone

> On Jul 28, 2019, at 5:56 AM, Patrik Fältström <paf=[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Jul 2019 05:55:21 -0700

On Sun, Jul 28, 2019 at 2:57 AM Patrik Fältström <paf=
[email-masked]> wrote:

> > The data that I have in mind is Gmail's market share. That seems like
> big enough fact. It is not unreasonable to believe that moving DNS to a web
> service would result in the same kind of evolution. Unless of course we do
> something, but then the question is what.
>
> It is not IETF that have decided everyone should use a centralised mail
> service like Gmail. IETF still give the end user a choice on what to do.
>

In what way is that not what is happening?

-Ekr

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 28 Jul 2019 15:09:27 +0200

> In what way is that not what is happening?

I hope there is where we will end up ultimately, but I see individual voices on this mailing list that from my perspective is asking for solutions where the ability to choose is removed.

   Patrik

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 28 Jul 2019 06:36:30 -0700

On Sun, Jul 28, 2019 at 6:09 AM Patrik Fältström <[email-masked]> wrote:

> I hope there is where we will end up ultimately, but I see individual
> voices on this mailing list that from my perspective is asking for
> solutions where the ability to choose is removed.
>

Which solutions are those?

-Ekr

---

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 29 Jul 2019 00:22:18 +0200

> Which solutions are those?

Once again, let me start by explicitly stating I do feel the discussion is going in the right direction. Partly thanks to you ekr.

Now, my statement comes from the few individuals on this list which say that IETF should promote DoH as envisioned as a protocol not separable from other protocols explicitly doing an end run around the local access provider default configuration.

My point is that IETF should take a broader view on what is happening at the moment, where for example there is a difference (as you pointed out a few posts ago) there is a big difference between what the base open architecture looks like, and what then can be done by users by for example launching VPN's, reconfiguring the default routing of DNS queries and applications using specific configurations.

To me the fact DNS resolution can be done already today in so many different ways is a strength, just like email can be set up and run in many different ways. Many people might today use Google (I do it myself for a few domains), but others might not for various reasons. Including their decisions on who they trust and why. And also including the ability access providers have to understand what is going on. Not specifically wiretap, but understand what protocols are in use.

I like that freedom we have, and the ability to innovate, and I want to keep it that way.

Basically, as I wrote in a different email: I do not understand why IETF should walk away from the base architecture we have today, that the access provider do give not only routing of IP packets but also DNS resolution to the client. But then at the same time we a. secure the communication to that end point (query minimization and TLS), while b. we allow people to override this by just adding another layer in the value chain.

   Patrik

---

From: Tony Finch <[email-masked]>
Date: Mon, 29 Jul 2019 11:59:16 +0100

Patrick Mevzek <[email-masked]> wrote:
> Michael Richardson <[email-masked]> wrote:>
> >
> Extended DNS Errors draft-ietf-dnsop-extended-error-06
>

In a lot of cases this will not be as useful as you might hope. It's
common for RPZ deployments to redirect malware domains to an informative
web server rather than return NXDOMAIN.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rattray Head to Berwick upon Tweed: East or northeast becoming variable, 3 or
less, increasing 4 at times. Slight, occasionally smooth in south. Showers,
fog patches. Moderate or good, occasionally very poor.

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 29 Jul 2019 13:04:59 +0200

> web server rather than return NXDOMAIN.

At this point we could extend the draft to also allow "Censored" in
positive NOERROR answers, but in that case the problem with getting the
information to applications might be even more difficult.  Still, I
can't immediately see any harm in allowing the combination in the standard.

--Vladimir

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2019 07:29:57 -0400

> On Jul 28, 2019, at 09:09, Patrik Fältström <[email-masked]> wrote:
> 

I think that is a misconception on your end. 

And since you don’t quote supporting text, let me make it clear that I am not advocating for that in the slightest. My point was that most users trust the quad servers more than a random coffee shop because they don’t even know the coffee shop operator whereas the quads have at least some reputation and therefor presumably are more  trustworthy than a completely unknown entity.

I’m not a fan of the centralization. I am a fan of removing blind trust on unknown parties. 

What we need is a decentralized quad X provider.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2019 07:35:57 -0400

> On Jul 29, 2019, at 06:59, Tony Finch <[email-masked]> wrote:
> 
>> 

I have already proposed a fix for rpz years ago that moves the censored answer to the additional section so that “dumb clients” are protected and “smart clients” can do the dnssec validation of the censorship (and possibly override).

I’ve completed a review of the current rpz for the ISE in the hopes that the current rpz document will be published as RFC, so we can start the bis document with this feature ASAP.

Paul

---

From: Jim Reid <[email-masked]>
Date: Mon, 29 Jul 2019 13:37:41 +0100

> On 29 Jul 2019, at 12:29, Paul Wouters <[email-masked]> wrote:
> 
> My point was that most users trust the quad servers more than a random coffee shop because they don’t even know the coffee shop operator whereas the quads have at least some reputation and therefor presumably are more  trustworthy than a completely unknown entity.

Paul, there’s a lot more to this notion of trust. It’s not as simple as you suggest. Suppose this hypothetical coffee shop is shoving all outbound HTTPS through some web proxy. Can the end user be sure their DoH queries go to their “trustworthy” DoH provider-du-jour?

However another aspect of trust comes from contractual relationships. The notion of least surprise also applies. I pay my ISP or coffee shop for Internet service and one of those services is DNS resolution. [OK, it’s buried deep in the T&C’s nobody reads.] I trust (handwave!) my provider to supply that service. That implicit trust relationship gets ripped up when some browser or web-based app uses its own DoH resolver. Which might or might not be the same as my provider's/coffee shop’s resolver or the one I hard-wired into my device.

Oh, and can you trust DoH providers to never, ever change their privacy policies or have data breaches?

And FWIW, the quad N services may well be great. They’re run by fine people who I like and respect. But unless I can audit/inspect their infrastructure, they’re just as much of an unknown entity as the local coffee shop.

> I’m not a fan of the centralization. I am a fan of removing blind trust on unknown parties.

How does that work for the 99.99% of the planet who can’t even spell DNS, far less understand what it does? The same goes for other blind trust elements that underpin pretty much everything on the Internet. I trust my ISP has given me a unique IP address. I trust they use a genuine ASN. I trust nobody else is making bogus BGP announcements for that address space or is spoofing my IP address. I trust CAs aren’t issuing bogus certs to people pretending to be me. I trust nobody fakes my email address. I trust nobody impersonates me on $social-media-platfrom. etc, etc.

> What we need is a decentralized quad X provider.

Only one?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2019 08:50:19 -0400

On Jul 29, 2019, at 8:37 AM, Jim Reid <[email-masked]> wrote:
> 
> Can the end user be sure their DoH queries go to their “trustworthy” DoH provider-du-jour?

If PKI is working, yes. If not, this is the least of your problems. Regarding me having a trust relationship with the coffee shop, there are two problems. 

First, the coffee shop case is explicitly where you are using a free service. If you have a trust relationship with them, they are an ISP, despite that they serve coffee. 

Secondly, the benefit of DoH is that you have just one trust relationship to reason about, rather than n. So even if your coffee shop is an ISP, you’re still better off with DoH, unless you can’t find a trustworthy DoH provider.

For the case where the user is choosing DoH, it’s hard to come up with a case where they’d be better off not choosing it, except for services where they will get a better CDN answer from the ISP resolver.

So if we are trying to solve a real problem here, that is the problem.

Do you disagree?

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Mon, 29 Jul 2019 05:52:17 -0700

I think Paul is talking about draft-vixie-dnsop-dns-rpz

My understanding of the status of this draft is that it is with the
authors pending updates from quite a few reviews.

Once adequately updated it will be ready for publication, but I can't give
you a time frame for that.

Thanks,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

Paul Wouters wrote:
>> common for RPZ deployments to redirect malware domains to an
>> informative web server rather than return NXDOMAIN.
>
> I have already proposed a fix for rpz years ago that moves the
> censored answer to the additional section so that "dumb clients" are
> protected and "smart clients" can do the dnssec validation of the
> censorship (and possibly override).
>
> I've completed a review of the current rpz for the ISE in the hopes
> that the current rpz document will be published as RFC, so we can
> start the bis document with this feature ASAP.
>
> Paul

---

From: Jim Reid <[email-masked]>
Date: Mon, 29 Jul 2019 14:08:15 +0100

> On 29 Jul 2019, at 13:50, Ted Lemon <[email-masked]> wrote:
> 

It’s one of the problems Ted, not *the* problem. There are others.

> Do you disagree?

Yes. You’ve outlined one problem. It’s not the only one. Do you agree?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2019 09:34:05 -0400

> Yes. You’ve outlined one problem. It’s not the only one. Do you agree?

Jim, you came up with a bunch of problems in the message I replied to, but as far as I could tell none of them were IETF problems.  The reason I’m probing you about this is actually to see if you can surface another problem and express it in a way that’s clear and not obviously something we can’t do anything about.

When I read your message and responded to it, it seemed to be talking about something that is a problem for the ISP, not the user, and that is a problem because it’s hard on the ISP’s business model, not because it’s hard on the ISP’s infrastructure.

It may be that there is some additional problem that is actually a problem for the ISP’s ops staff, but if there is, I do not know what the problem is.

E.g., you could say that there is a problem in that the ISP can’t prevent me from using a resolver that doesn’t protect me from malware.  If you think that is a problem, I guess I could agree with you in theory that it is a problem.   The sense in which this is a problem for the user is that the user isn’t protected against malware, but AFAIK all of the available options do provide protection against malware.   The solution to this problem is part of the trust choice the user is making.

It’s a problem for the ISP only if the user is a malefactor—e.g., a piece of malware, not a person.   But that’s not a problem we can solve, because the malware is going to do what it’s going to do, and not follow the IETF’s advice.   If the malware uses e.g. Cloudflare, this is actually a win for us, because now Cloudflare has intelligence about the malware it didn’t have before, and an opportunity to block the queries it sends to discover its controller.

We could also say that it’s a problem that the Cloudflare gets to have this information, and that reduces the ISP’s ability to collect the same information.   I’d agree with this, except that (a) again, we don’t have any control over the malware, and (b) it’s a business problem, not a technical problem.  The IETF shouldn’t be trying to help the ISP to prevent Cloudflare from getting this information.   So if this is a problem, I don’t see how it’s an IETF problem.

So this is what I mean when I say that the only problem I can see here for the IETF to solve is the CDN problem.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2019 09:48:09 -0400 (EDT)

> Paul, there’s a lot more to this notion of trust. It’s not as simple as you suggest. Suppose this hypothetical coffee shop is shoving all outbound HTTPS through some web proxy. Can the end user be…

The expectation is that after hotspot authentication, those networks
just route my (https) packets without MITM it based on content. Your
hypothethical proxy would need to pass gmail traffic without knowing
the contents too - why would DoH to google be different?

But your question is really moot - the coffeeshop network shouldnt
require any of my trust. not for https or anything else.

> However another aspect of trust comes from contractual relationships. The notion of least surprise also applies. I pay my ISP or coffee shop for Internet service and one of those services is DNS re…

Singling out DNS from other packets in this "(free) service" to which
I signed up for (un)willingly makes no sense. Sure, any of the 80+ ToS
conditions can be reasonable or unreasonable. You claiming I might bypass
some condition saying "We inspect/filter all DNS" is just proof putting
those conditions there are unreasonable and wouldn't hold muster in a
reasonable (EU) court. But regardless, contractual issues are not within
the expertise of the IETF. Whether or not some govermental or commercial
entity "bans" DoH is only relevant to those applications depending on
it and doing some reconfiguration with or without prompting the user
about the dangers.

> Oh, and can you trust DoH providers to never, ever change their privacy policies or have data breaches?

The IETF does not evaluate the security of peers on the internet.
However, personally, I would trust the quads' security and privacy
policies over any local unknown hotspot network I randmonly connect
to - indepedent on the quality of their flat whites.

> And FWIW, the quad N services may well be great. They’re run by fine people who I like and respect. But unless I can audit/inspect their infrastructure, they’re just as much of an unknown entity as…

Again, not in the realm of IETF decisions.  But you can make a few
assumptions. The quads run DNS as part of the core business. I would
not trust them for either good quality flat whites or ethnical or
organically farmed beans. Just as I don't expect the coffeeshop to
have a good security and privacy policy and ongoing maintance of their
wifi/router/DNS infrastructure.

> How does that work for the 99.99% of the planet who can’t even spell DNS

Perhaps this is an engineering question to be solved by good
implementations of IETF DNS protocols.

>> What we need is a decentralized quad X provider.

Maybe more than one would be good. A million+ of them, not so good :)

Paul

---

From: Jim Reid <[email-masked]>
Date: Mon, 29 Jul 2019 14:57:02 +0100

> On 29 Jul 2019, at 14:34, Ted Lemon <[email-masked]> wrote:
> 

Ted, we’re talking at cross-purposes and this confusion would best be resolved over beer.

My initial point was that the issues of trust are far more complex than Paul was suggesting. These are probably out of scope for the IETF. Though I think the operational implications of these trust considerations are or could be a matter for the IETF.

> When I read your message and responded to it, it seemed to be talking about something that is a problem for the ISP, not the user,

No. Those problems apply to both the end user and the provider. Consider what can happen when the end user chooses a DNS resolver (or has one forced on them) that isn’t the one on offer from their ISP or coffee shop. That third party won't be getting the support calls or complaints when the end user has a problem - the user's (contracted) provider will. That’s a problem for both the end user and their ISP.

FWIW I face these all the time because I have to switch off my laptop’s validating resolver to get past the captive portal at $coffeeshop or whatever. In a sense, I was/am violating their trust model and therefore have to pay the penalty.

> and that is a problem because it’s hard on the ISP’s business model, not because it’s hard on the ISP’s infrastructure.

I wasn’t considering ISP business models at all -- just the implied or explicit trust relationships.

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 29 Jul 2019 09:15:38 -0600

pwouters> What we need is a decentralized quad X provider.

Nice idea but highly unlikely we'll get better than quad9. (Note I'm not
saying they're perfect but they're as close as we'll see to not having
a hidden agenda).

The logistics, hassle, cost, etc. of getting enough anycast nodes
installed, the peering or transit agreements to get on the net and get
the anycast announcements propogated and the staff to keep such an
infrastructure running are all prohibitive for most of the world.

And then you have the problem of who could afford to do that at no
charge that we'd all "trust".

If you're not doing that, we're back to "run your own resolver".

---

From: Andrew Campling <[email-masked]>
Date: Mon, 29 Jul 2019 15:23:05 +0000

> On Jul 28, 2019, at 12:30, Paul Wouters <[email-masked]> wrote:

I think this assertion is questionable, not least of which because most users have not heard of DNS let alone DoH, and certainly don't understand either.  Given the various privacy issues that have unfortunately embroiled the tech sector of late, you might be surprised to find rather more trust in their favourite coffee shop than in a tech company that, in some cases, they've never heard of before.  

On a more general point, what is the balance of DNS traffic between ISPs and alternate resolvers?  Whilst I don't claim familiarity with the US market, I know that large ISPs in the UK typically resolve around 90% of traffic, underlining the fact that non-ISP DNS resolution is very much an edge case at present.  In other words, I urge people to remember that what you are doing will fundamentally change arrangements for the majority of real users, in ways that they don't understand and that may undermine those current arrangements regardless of their wishes.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2019 11:38:55 -0400 (EDT)

> If you're not doing that, we're back to "run your own resolver".

I was thinking more along the lines of the pool.ntp.org model.

You register your node, it gets checked for a while, then it is
added to the pool. It is still checked for proper funtioning and
if not, removed from the pool again.

Obviously, the privacy bits of that model is harder to enforce, but
if the pool is large enough, it might not matter as long as the
majority of nodes in the pool can be trusted.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2019 11:41:24 -0400

> I think this assertion is questionable, not least of which because most users have not heard of DNS let alone DoH, and certainly don't understand either.  Given the various privacy issues that have…

The way this stuff works out is that users hear about things on the news, and modify their behavior on that basis.   And they read sales pitches, and modify their behavior on that basis.   When a sales pitch shows up in the news as having been a lie, they again modify their behavior.

So if a DoH provider were to make a promise and then break it, a couple of things would result.   First, it would get out, and people would modify their behavior.  Second, they’d likely face some consequences for breaking their promise.   What about a provider who doesn’t make the promise in the first place?   They would be called out for it in the press, at least in theory.

We don’t really have a say in how this process unfolds.   What we have a say in is whether the underlying technology can support user choice in this way.   It really is user choice, even though the sense in which users are making informed decisions is different than the way we do it.

---

From: Andrew Campling <[email-masked]>
Date: Mon, 29 Jul 2019 15:42:46 +0000

> On Fri, Jul 26, 2019 at 15:51 Brian Dickson <[email-masked]> wrote:

>> On Fri, Jul 26, 2019 at 7:10 AM Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

> I don't think "want" enters into it per se; it is a question of what is required in order to maintain all the existing functionality for things implemented in DNS today, and for preventing the problems created when applications use DoH to bypass OS-selected resolvers. The value of "required" may differ by environment, and that is a big part of the problem. The environments where DoH doesn't create problems, is very much a subset of environments into which DoH applications are already deployed (even without having DoH enabled).

I think a key question to as is, if you don’t believe that the IETF has any responsibility to provide guidance regarding the use of protocols that it has introduced or changes that it has made, which body or bodies do you envisage taking up this task?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2019 11:48:09 -0400

> No. Those problems apply to both the end user and the provider. Consider what can happen when the end user chooses a DNS resolver (or has one forced on them) that isn’t the one on offer from their…

Is it?   It sounds like a quality of implementation issue: if I am using Firefox and it is doing DoH, does it have a choice of resolvers, or only one?   If only one, that’s a poor implementation, which will indeed fail.   Yes, they might call the ISP.   But how is that different than any of the other varied ways that internet services can fail that might trigger a call to the ISP?   I sometimes find that my home router fails—something goes wrong with DHCP, or DNS, and I’m offline until I turn it off and then on again.   I haven’t ever called the ISP as a result of this.   Is it normal for users to do so?   Don’t ISPs already have a process for dealing with this problem?   Suppose a bad browser DoH implementation fails in the way you describe.   How many calls does the ISP have to receive on it before it goes into the problem resolution tree and starts showing up in the ‘on hold’ information dump?

Does the IETF currently provide advice to ISPs on how to deal with outages of this sort?   Should we?   Do ISPs need us to?

> FWIW I face these all the time because I have to switch off my laptop’s validating resolver to get past the captive portal at $coffeeshop or whatever. In a sense, I was/am violating their trust mod…

This is a bug in the way your laptop interacts with captive portals.   The IETF has a working group that works on this topic.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2019 11:51:03 -0400

> I think a key question to as is, if you don’t believe that the IETF has any responsibility to provide guidance regarding the use of protocols that it has introduced or changes that it has made, whi…

I’m still stuck back on the question of what advice the IETF ought to provide.   If there’s advice that you think we are qualified to provide, what is it?   If we provided it, would it be followed?

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 29 Jul 2019 09:51:47 -0600

ebersman> If you're not doing that, we're back to "run your own
ebersman> resolver".

paul> I was thinking more along the lines of the pool.ntp.org model.

NTP isn't nearly as latency sensitive, since it's designed to deal with
this and it's not a human waiting for a page load. NTP also deals nicely
with having multiple sources, some of which aren't good/accurate and
still get to one answer.

It would also require changes to client/device OS stacks.

There is a reason that there are a very limited number of large open
recursive DNS services well anycasted, well distributed and well
run. It's not because being centralizes was the primary goal; it's
because it's expensive and difficult.

Much like email, you can run your own server. But getting trusted IP
space, doing SPF/DKIM/DMARC correctly, getting large email services to
accept your email, dealing with DDoS, etc are all hard and beyond most
users. Most users will take ease over privacy. And the step function to
go from easy to privacy is a fairly high technical bar for most users.

I think that we're going to keep with this for most of the world:

  - run your own resolver for a small group of techies
  - accept your ISP/company resolvers
  - use a centralized service like the quadX

There will probably be a small number will use a DoT/DoH service that
isn't run by one of the big RDNS servers.

Perhaps we should be talking to device OS vendors like Apple, Microsoft,
etc. to put a fully recursive validating resolver built into the OS...

---

From: Andrew Campling <[email-masked]>
Date: Mon, 29 Jul 2019 16:04:18 +0000

> On Sun, Jul 28, 2019 at 13:55 Eric Rescorla <[email-masked]> wrote:

>>  On Sun, Jul 28, 2019 at 2:57 AM Patrik Fältström <paf=[email-masked]<mailto:[email-masked]>> wrote:

> In what way is that not what is happening?

I think part of the problem here is that, by having DoH operate in the application layer, there is no real certainty that the user will be consulted regarding the use of a particular resolver, and that their wishes will be respected if they are.  Especially as their preferred resolver may not be signed up to a given vendor’s resolver programme, so may not even be readily available as an option for them to select in the first place.

The current proposals appear to pay little more than lip service to the needs and expectations of end users, with the claimed additional privacy seemingly being used to justify this.  (Even though the privacy on offer is a backward step from DoT).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2019 12:13:48 -0400

Vladimír Čunát <[email-masked]> wrote:
    >>> Not a new return code, but an extension will provide that: Extended
    >>> DNS Errors draft-ietf-dnsop-extended-error-06
    >>> 

    > can't immediately see any harm in allowing the combination in the

Not if it's the Application Doing the DNSSEC.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Andrew Campling <[email-masked]>
Date: Mon, 29 Jul 2019 16:14:33 +0000

From: Ted Lemon <[email-masked]>
Sent: 29 July 2019 16:51
To: Andrew Campling <[email-masked]>
Cc: Brian Dickson <[email-masked]>; Patrik Fältström <paf=[email-masked]>; Wes Hardaker <[email-masked]>; ADD Mailing list <[email-masked]>; Rob Sayre <[email-masked]>
Subject: Re: [Add] My longer list of questions [from partial distribution at the MIC]

On Jul 29, 2019, at 11:42 AM, Andrew Campling <[email-masked]<mailto:[email-masked]>> wrote:
I think a key question to as is, if you don’t believe that the IETF has any responsibility to provide guidance regarding the use of protocols that it has introduced or changes that it has made, which body or bodies do you envisage taking up this task?

I think Patrik Fältström made a good start on this in his response on Friday (06:52):

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jul 2019 09:21:56 -0700

On Mon, Jul 29, 2019 at 9:04 AM Andrew Campling
<[email-masked]> wrote:

> I think part of the problem here is that, by having DoH operate in the
> application layer, there is no real certainty that the user will be
> consulted regarding the use of a particular resolver, and that their wishes
> will be respected if they are.
>

As I said in Montreal, it's not like the user was consulted regarding the
use of the network provided resolver. As a general matter, users aren't
aware of DNS at all.

> Especially as their preferred resolver may not be signed up to a given
> vendor’s resolver programme, so may not even be readily available as an
> option for them to select in the first place.
>

Firefox, at least, allows the user to configure any DoH resolver of their
choice -- whether the resolver is part of our program or ont -- in a
fashion not much different from how they would configure the OS resolver
(i.e., there is a preference pane).

>
> The current proposals appear to pay little more than lip service to the
> needs and expectations of end users, with the claimed additional privacy
> seemingly being used to justify this.  (Even though the privacy on offer is
> a backward step from DoT).
>

It's hard to really respond to this statement because DoT is two different
things. I don't agree that DoH to a TRR is a step back from DoT to the
local ISP resolver for the reasons that have already been discussed at
length, namely the inadequacy of the local resolver's privacy guarantees.
When implemented correctly, DoT to a TRR and DoH to a TRR have relatively
similar privacy properties, as laid out in
https://tools.ietf.org/html/rfc8484#section-8

-Ekr

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 29 Jul 2019 18:27:14 +0200

> Not if it's the Application Doing the DNSSEC.

Well, that's a general problem of filtering/modifying DNS before the
last validation point, but extended errors actually allow the
application to know why the data is wrong and that it's pointless to retry.

Validation never prevented denying the answers (causing SERVFAILs), so
spoofing this filtering doesn't seem to bring new risks (at a quick
glance).  And if you add a secure transport to the filtering resolver
(DoT, DoH), you authenticate even that part.

--Vladimir

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Jul 2019 13:01:10 -0400

> I think Patrik Fältström made a good start on this in his response on Friday (06:52):

Do you see any action items in Patrik’s message?   Can you mention one specific action that you think we should take, based on what Patrik has said?

E.g., how would the IETF make tools that ensure responsibilities still exist and policies can be implemented?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2019 13:27:48 -0400 (EDT)

> with having multiple sources, some of which aren't good/accurate and

If you think DNS is latency sensitive, I can advise you to install an
ad-blocker instead.

Browers might think latency is the only useful metric for DNS, but it is
not. It's as meaningful as horse power is on modern cars.

> It would also require changes to client/device OS stacks.

I'm fine with needing configuration changes and using the local network
suggested resolver by default. I'll leave that discussion up to the
browser vendors.

> because it's expensive and difficult.

Mostly due to UDP reflection/amplification attacks, which are not
present if your open resolver runs with DNS COOKIES or TCP, which it
will when using DoT or DoH. (note I am running an open resolver for the
last 15 years. It does not see much downtime at all.

> Much like email, you can run your own server.

the problem of running your own resolver server that hardly anyone else
uses, is that is has bad privacy properties. Getting privacy means
mixing up a large number of people's queries. Hence the pool.ntp.org
model and not the "spin up your own el cheapo aws node".

> But getting trusted IP
> users.

None of this relates to the DNS discussion.

> Most users will take ease over privacy. And the step function to

Again, I will leave up the defaults discussion to the browsers and the
apps that feel they have something to offer to the user beyond the
DHCP provided untrusted DNS resolver.

> etc. to put a fully recursive validating resolver built into the OS...

While that's great, it is not very relevant to this discussion, as those
validating resolvers still either have to 1) forward queries to locally
recommended resolver or 2) forward to a known quad or 3) go without
forwarder. Where 1) is the status quo, and 3) is the worst privacy case
compared to the disinterested RDNS service.

Paul

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 29 Jul 2019 19:42:43 +0200 (CEST)

On Mon, 29 Jul 2019, Jim Reid wrote:

> How does that work for the 99.99% of the planet who can’t even spell 
> DNS, far less understand what it does? The same goes for other blind 
> trust elements that underpin pretty much everything on the Internet. I 
> trust my ISP has given me a unique IP address. I trust they use a 
> genuine ASN. I trust nobody else is making bogus BGP announcements for 
> that address space or is spoofing my IP address. I trust CAs aren’t 
> issuing bogus certs to people pretending to be me. I trust nobody fakes 
> my email address. I trust nobody impersonates me on 
> $social-media-platfrom. etc, etc.

I'm very concerned about this being chosen for the user and now all of a 
sudden different applications on their computer might use different 
resolvers without their knowledge. It makes for extremely confusing 
customer support calls.

I'd also like to +1 to what Lorenzo said in the ADD meeting. This isn't 
about DoT, DoH or what other transport people might come up with. This is 
about "what resolver am I using right now?" and if this is all of a sudden 
different across application, operating system, home or however someone 
might carve it. Historically, this has been the same across everything 
unless someone specifically brought up a VPN or did explicit 
configuration. Personally, I trust my ISP both with moving my packets and 
performing lookups. I don't want my queries to all of a sudden end up 
somewhere else without my knowledge, especially not some data-collecting 
cloud provider that happens to have some commercial deal with my browser 
vendor. The failure cases both when it comes to GDPR or similar, and 
purely technical problems (if the cloud provider resolver stops working 
and I get an error page, who do I call?).

But, looking at it from another perspective I also see the need in some 
places to try to make the traffic as much secret/verified as possible, for 
instance when there is pervasive monitoring or alteration of it. I don't 
see any other way to understand the users choice/preference unless we ask 
them. People install a TOR browser because they want to circumvent 
something. This is an active choice. If they install a VPN, then they make 
the choice to run both traffic (and potentially DNS queries) through this 
VPN. This is also a choice.

The same way the user today can make a choice when it comes to "I want to 
run my browser in incognito/private mode", we need to ask them the same 
thing about their DNS lookups if we want to stop using the operating 
system provided one.

I feel a lot of this discussion has touch points on the whole MIF / 
Provisioning Domains topic, and also with a touch of "captive portal" (in 
that specific information needs to be conveyed to applications and 
different information needs to be used depending on who the application 
intends to talk to). It's quite possible that I would like to use one DoH 
server for some domains, and use my system default one for others. This 
would probably help some of the VPN issues I have (where each tunnel just 
thinks they "own" the entire operating system including resolver setting). 
Preferrably I'd like the operating system and VPN application to just 
configure this for me so that split horizon works as expected (I get 
different results depending on if the VPN tunnel to the internal network 
is up or down).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Jul 2019 18:56:05 +0100

Hiya,

> I was thinking more along the lines of the pool.ntp.org model.

FWIW, I think it'd be great to see a more fleshed-out version
of this idea. Even if it doesn't fly, I think that might be a
useful way to elicit some more structured argument about this
problem-space. So, I'd encourage you (or someone) to try flesh
it out some.

Cheers,
S.

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 29 Jul 2019 16:08:50 -0600

ebersman> NTP isn't nearly as latency sensitive, since it's designed to
ebersman> deal with this and it's not a human waiting for a page
ebersman> load. NTP also deals nicely with having multiple sources, some
ebersman> of which aren't good/accurate and still get to one answer.

paul> If you think DNS is latency sensitive, I can advise you to install
paul> an ad-blocker instead.

paul> Browers might think latency is the only useful metric for DNS, but
paul> it is not. It's as meaningful as horse power is on modern cars.

It's not always just ads and much of what ADD is all about is browser
usage, so it is relevant to this comparison.

And regardless of if you care about latency as the most important
metric, we're still talking about an NTP design trying to be rammed onto
a DNS design.

You'd started by talking about a replacement for the quadX anycasted
RDNS services. I'm curious how you think that maps to pool.ntp.org.

If you are talking about widely distributed anycast, whose address space
and infrastructure are you planning on using and who will deal with all
the peering to get the anycast announced?

If you're not talking about using one single pair of anycast v4 and pair
of v6 but using whatever local unicast addrs are available, how are you
getting it to clients? That's why I mentioned client OS changes. Unless
you're planning to try to get this into CPE routers? If you think the
browser will be doing it, how will the browser get said addrs and how
will a user see this and get a choice?

ebersman> There is a reason that there are a very limited number of
ebersman> large open recursive DNS services well anycasted, well
ebersman> distributed and well run. It's not because being centralizes
ebersman> was the primary goal; it's because it's expensive and
ebersman> difficult.

paul> Mostly due to UDP reflection/amplification attacks, which are not
paul> present if your open resolver runs with DNS COOKIES or TCP, which
paul> it will when using DoT or DoH. (note I am running an open resolver
paul> for the last 15 years. It does not see much downtime at all.

No. Mostly due to the expense of being in dozens of data centers around
the world to be sufficiently distributed, the cost or connections to get
all the IXs or transit providers to accept your BGP announcements of
your anycast and the staff to watch that 7x24. If you're not doing that,
you're not a valid comparis to the quadX folks at all.

So, love to hear how a pool.ntp.org clone would actually work for DNS
and be better than running a local resolver.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 31 Jul 2019 12:12:00 +0000

>    I’m not a fan of the centralization. I am a fan of removing blind trust on unknown parties. 

The potential for an unknown party seems to arise when an app changes from the user's typical resolver to some unknown-to-the-user party, so I agree this is a risk. And I also feel it is high time we all, strongly, push back on the dramatic rise and potential future continuation towards consolidation/centralisation. This seems an unacceptable state for the Internet and for society, and we can't just shrug it off - we have a role to play here too IMO.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 31 Jul 2019 15:02:19 +0200 (CEST)

On Mon, 29 Jul 2019, Eric Rescorla wrote:

> As I said in Montreal, it's not like the user was consulted regarding 
> the use of the network provided resolver. As a general matter, users 
> aren't aware of DNS at all.

Indeed. This is how it's always been. They expect this to be part of their 
Internet access functionality. The ones who do not make explicit choices 
by configuring a VPN, enable incognito mode, run a TOR browser because 
they explicitly want to change how things work.

The proposal from several parties now seems to be to change this without 
asking the user. This is a big change. The user might not want to share 
their DNS lookups with whatever DoH resolver that the browser vendor has 
chosen. How do you know?

Putting me end-user hat on, I trust my ISP more than I trust any of the 
common quad-whatever DNS resolver operators out there. I do not want my 
DNS lookups to all of a sudden end up somewhere else without my explicit 
consent.

I expect unless I am asked and explicitly accept to not follow my DHCP 
configured resolver, for that DHCP configured resolver to be used. Not 
anything else.

I feel we're back in the bad old days where a browser would just change 
what default browser I want to use, just because I happened to install 
that browser. Those kinds of policy choices are for me explicitly to make, 
not for the browser vendor to do for me. I don't want the browser vendor 
to choose search engine for me and I don't want the browser vendor to 
choose DNS resolver for me, without asking.

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 31 Jul 2019 17:23:44 +0000

Exactly. The default browser setting is a great parallel to the DNS configuration. It makes perfect sense for browsers to make recommendations to users about what DNS to trust and why, but not to decide under the covers without the full knowledge the platform may have about network policies, other apps, and so on. I imagine a world where browsers refer users to "change their default DNS" or "change who you trust with your browsing" and configure DNS servers through the platform and thereby compete with DHCP.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Mikael Abrahamsson <[email-masked]>
Sent: Wednesday, July 31, 2019 6:02 AM
To: Eric Rescorla <[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] [EXTERNAL] Re: My longer list of questions [from partial distribution at the MIC]

--
Add mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&amp;data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cff4068a09e0a40adc00f08d715b75a4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637001749554921119&amp;sdata=TCuqvORtEX70sh7eVsLHSInlta8BG4ssjGNwd97dcp8%3D&amp;reserved=0

---

From: Alec Muffett <[email-masked]>
Date: Wed, 31 Jul 2019 18:29:15 +0100

Hi Mikael!

On Wed, 31 Jul 2019, 14:02 Mikael Abrahamsson, <[email-masked]> wrote:

> not for the browser vendor to do for me.
>

So, how do you feel about a coffee shop owner, ISP, or national government
doing the same thing to you?

-a

---

From: "Cook, Neil" <[email-masked]>
Date: Wed, 31 Jul 2019 19:16:54 +0100

Hmm coffee shops and ISPs provide a recursive DNS service so that you can access the internet. One that you’re not obliged to use. I think I’m ok with that.

Also let’s not conflate coffee shops and ISPs with oppressive governments.

Neil

Sent from my iPhone

> On 31 Jul 2019, at 18:29, Alec Muffett <[email-masked]> wrote:
> 
> Hi Mikael!
> 
> So, how do you feel about a coffee shop owner, ISP, or national government doing the same thing to you?
> 
> -a
> 
> -- 
> Add mailing list
> [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 31 Jul 2019 20:46:24 +0200

Moin!

> doing the same thing to you?
Simply better as:
- if the coffee shop owner does something I do not like I can not buy my 
coffee there, or if it is really worse I can sue them as long as they 
are in my jurisdiction.
- I have a contract with my ISP and ISPs where I live (Europe/Germany) 
are heavily regulated so there ability to do evil is very limited. If 
they do I can sue them, but that is hardly necessary as my ISP (Deutsche 
Telekom) actually sued the government in order to not retain my login 
data.
- My national government is something I can influence by voting or 
participating in the political process
None of this applies to most browser and DoH server vendors. Eg. Mozilla 
is an US non profit and Cloudflare is an US for profit, I simply have no 
way to hold them accountable.

That is one of the major drawbacks of the centralisation that will be 
caused by applications doing DNS (there are more ISPs then applications 
that will do that).

So long
-Ralf
——
Ralf Weber

---

From: Paul Wouters <[email-masked]>
Date: Wed, 31 Jul 2019 16:15:22 -0400 (EDT)

On Wed, 31 Jul 2019, Ralf Weber wrote:

> coffee there, or if it is really worse I can sue them as long as they are in 
> my jurisdiction.
> - I have a contract with my ISP and ISPs where I live (Europe/Germany) are 
> heavily regulated so there ability to do evil is very limited. If they do I 
> can sue them, but that is hardly necessary as my ISP (Deutsche Telekom) 
> actually sued the government in order to not retain my login data.

The difference between a hotel/coffeeshop wifi and an ISP is very
minimal in the EU. Legally, the hotel and coffeeshop are ISPs.

You are furthermore reasoning from the idea that you can find out about
the coffeeshop violation of your privacy, but real users cannot.

> participating in the political process

Have you seen the madness in the world these days?

> None of this applies to most browser and DoH server vendors. Eg. Mozilla is 
> an US non profit and Cloudflare is an US for profit, I simply have no way to 
> hold them accountable.

I believe the GDPR covers foreign entities servicing Europeans, so I think
these entities are also required to follow GDPR.

Paul

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 31 Jul 2019 23:29:33 +0200

Moin!

> minimal in the EU. Legally, the hotel and coffeeshop are ISPs.
So even less reasons to point your DNS to a huge US corporation.

> the coffeeshop violation of your privacy, but real users cannot.
That is what consumer advocacy groups and the press are for. Once smart 
people have figured out these violations they will get known.

> Have you seen the madness in the world these days?
Yes, but I am still with Churchill on this:

Many forms of Government have been tried, and will be tried in this 
world of sin and woe. No one pretends that democracy is perfect or 
all-wise. Indeed, it has been said that democracy is the worst form of 
Government except all those others that have been.

But we are getting off topic here.

>> None of this applies to most browser and DoH server vendors. Eg. 
>> Mozilla is an US non profit and Cloudflare is an US for profit, I 
>> simply have no way to hold them accountable.
>
That is true, but ISPs are bound to more then the GDPR, but enforcing 
anything if you don’t have a legal entity in the EU is difficult.

Long story short there is no reason for me or any other european to 
switch it’s DNS from its ISP to a US cloud provider.

So long
-Ralf
—--
Ralf Weber

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 31 Jul 2019 23:02:00 +0100

Hiya,

On 31/07/2019 22:29, Ralf Weber wrote:
> Long story short there is no reason for me 

It's fine that you conclude that.

> or any other european 

That is incorrect. I do use CF's DoT and other DoT
services and occasionally CF's DoH. Some of that is
just playing about/testing, but my home ISP did have
an incident last year where their DNS went awol for
a weekend (seemingly related to the root key roll;-)
so I set my home router to use CF's DoT. I've not
bothered to reset it since as my view of the choice
is between two for-profit foreign-owned companies
and in fact I know more about CF than the latest
in a long line of investors who happen to own the
ISP today. I make no claim that that is common but
it is an existence proof that your claim above is
false.

In much of the discussion on this list, I see what
I perceive as people (on all "sides") frequently
describing DNS setups in ways that seem tailored
to suit their argument and not reflect reality with
any fidelity. I don't find any conclusions based
on such arguments at all convincing TBH, no matter
how frequently those may be asserted.

And I have a hard time seeing any WG working on
this topic being able to make progress in the face
of such dodgy arguments.

Cheers,
S.

> to