Subject: [Add] Use Cases - the coffee shop

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 14:25:34 +0000

On Thu, 15 Aug 2019, Daniel Stenberg <[email-masked]> wrote:

> I disagree. It would make DoH a whole lot less useful in my view as then coffere shop 
> operators can easily take away my ability to chose to use DoH, for example.

Since the coffee shop / hotel network use case arises so frequently, I think it's worth exploring this a little further.  

The coffee shop / hotel is providing the (presumably free) network in order to attract your custom, you are freely choosing to use it rather than an alternate such as a mobile network.  As the service provider, the coffee shop has the right to determine how its network is used, preferably clearly stating any such conditions at the outset.  If it decides not to allow you to access an alternate DNS for whatever reason, I'm not convinced that the most appropriate next step is to change the way the whole internet ecosystem works in order for you to circumvent its rules, with all the accompanying unintended consequences to the wider ecosystem.  The more usual approach in such circumstances, if such a prohibition matters to you, is to (i) raise your concerns and objections with the coffee shop owner and/or (ii) take your business elsewhere.  

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 10:29:32 -0400

What if the coffee shop is just using a crappy dns proxy that mangles dnssec messages?

Sent from my iPhone

> On Aug 15, 2019, at 10:25, Andrew Campling <[email-masked]> wrote:
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 14:38:08 +0000

> On Aug 15, 2019, at 15:30, Ted Lemon <[email-masked]> wrote:
> 

I believe the point still stands.  You have the option of taking your business elsewhere or, if the coffee really is that good, accepting the network compromises in order to consume it.  Changing the way the whole internet ecosystem works in order for you to circumvent the network rules of our hypothetical coffee shop so that it works to your liking feels like a wholly disproportionate response with likely unintended and unknown consequences.  

There may be compelling use cases, in my view this is not one of them.

Andrew

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Aug 2019 14:42:13 +0000

> What if the coffee shop is just using a crappy dns proxy that mangles dnssec

I'm pretty sure people in coffee shops have the ability to not use the coffee shop network if it doesn't meet their needs. Using private coffee shop networks is not a basic human right, IMO. Coffee shops don't have an obligation to provide free Internet access (or free Internet access that actually works).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 10:48:44 -0400

I go to the coffee shop for coffee. If they have crappy IT, complaining to the barista isn’t going to help, and it’s almost certainly not intentional. I’m not going to go to a less  good coffee shop to satisfy some weird moral code of yours. 

In any case, this is a straw man. I’ve never seen a ToS that forbade me to use DoH, or to do my own thing generally as long as it isn’t criminal or abusing of the network. I have seen lots of broken DNS proxies. So that is the use case that I take seriously, not your hypothetical coffee shop panopticon. 

Sent from my iPhone

> On Aug 15, 2019, at 10:38, Andrew Campling <[email-masked]> wrote:
> 
> 
>>

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 15 Aug 2019 16:53:28 +0200 (CEST)

On Thu, 15 Aug 2019, STARK, BARBARA H wrote:

> I'm pretty sure people in coffee shops have the ability to not use the 
> coffee shop network if it doesn't meet their needs. Using private coffee 
> shop networks is not a basic human right, IMO. Coffee shops don't have an 
> obligation to provide free Internet access (or free Internet access that 
> actually works).

I hate that I seem to have to explain this.

"Coffee shop" is a handy shortcut to refer to a network where you might think 
twice before you send traffic in the clear, where you perhaps don't trust 
unauthorized clear text protocols or that just offer a crappy DNS. There are 
many such networks where the coffee shop is just one example.

-- 

  / daniel.haxx.se

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 17:02:02 +0200 (CEST)

On Thu, 15 Aug 2019, Daniel Stenberg wrote:

> "Coffee shop" is a handy shortcut to refer to a network where you might 
> think twice before you send traffic in the clear, where you perhaps 
> don't trust unauthorized clear text protocols or that just offer a 
> crappy DNS. There are many such networks where the coffee shop is just 
> one example.

Yes, that's fine.

So how are you going to detect that the network is one of these and run 
DoH as main resolver path, but not change the default of all other 
networks I attach to where I actually trust the resolver an desire to use 
it?

1. I am at home. I trust my home ISP more than I trust CF/GOOG, so I want 
to use my ISP resolver.

2. I go to a coffee shop and I trust CF/GOOG more than I trust the Coffee 
shop, so I want to use them there.

How are you going to solve this? Until I see a concrete proposal, my 
statement is that there is absolutely no technical way to do this without 
asking me, and changing the default to GOOG/CF for * to fix 2 is ... just 
horrible.

Most ISPs I've seen hover around 5% of the customers that make an active 
choice not to use their ISP provided resolver. So the proposal to change 
the defaults for everything means 95% will have their default changed. 
Some users on this list seems to think this is acceptable fallout to fix 
2.

I do not agree.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 15:04:16 +0000

On Thu, 15 Aug 2019, Daniel Stenberg <[email-masked]> wrote:

> "Coffee shop" is a handy shortcut to refer to a network where you might think twice before 
> you send traffic in the clear, where you perhaps don't trust unauthorized clear text protocols 
> or that just offer a crappy DNS. There are many such networks where the coffee shop is just 
> one example.

I think it was understood that "coffee shop" was a metaphor, indeed was "coffee" in my original email on this subject.  If you, for example, replace coffee shop with ISP, I think that the point still stands - in most (every?) case, you have the ability to take your business elsewhere either until the "coffee shop" adapts its offering to your liking or you decide that its overall offering is such that you can live with the trade-offs.  

As per my earlier comments, I'm not clear why changing the way the internet ecosystem works with likely unintended and unknown consequences is the most appropriate and proportionate response.  

Andrew

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Aug 2019 11:05:26 -0400 (EDT)

> I believe the point still stands.  You have the option of taking your business elsewhere or, if the coffee really is that good, accepting the network compromises in order to consume it.  Changing t…

I strongly disgree with the "agreement" between user and coffeeshop.

There is an expectation by the user that once authenticated to the
hotspot, that the user can then more or less send/receive whatever
they want. Sure there are some limitations based on sharing the
bandwidth, and prevention of certain websites (eg porn) that would
negatively affect other customers. But the user may totally corrupt
their own device by downloading malicious content.

And there is still an expectation of privacy (eg when reading email,
when browsing sites) that a coffeeshop owner cannot just claim that they
do not apply because you are a guest and you can choose not to connect.

Furthermore, the main "issue" with DoH is that it bypasses protection
offered by the network to the enduser. Well, in this case, the user
clearly opts out of that "protection", and since coffeeshop users these
days are always containerized, so their traffic cannot reach any other
users of the coffeeshop/hotel, there is zero risk to the other users. So
there are zero resaons not to give the coffeeshop / hotel enduser that
freedom (or rather, give the user an "uncensored internet")

If you say the coffeeshop / hotel as an ISP has the right to filter any
of your traffic, I don't see why that would not apply to DSL or LTE
based ISPs. That would be the end of net neutrality and the start of
commercial (not government) censorship. I have already experienced that a
large hotel chain would prevent access to booking.com or kayak.com and
those practicises should be illegal and it is fine to work around that
with DoH.

Paul

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 15 Aug 2019 17:08:09 +0200 (CEST)

On Thu, 15 Aug 2019, Mikael Abrahamsson wrote:

>> think twice before you send traffic in the clear, where you perhaps don't 
>> trust unauthorized clear text protocols or that just offer a crappy DNS. 
>> There are many such networks where the coffee shop is just one example.

> So how are you going to detect that the network is one of these and run DoH 
> as main resolver path, but not change the default of all other networks I 
> attach to where I actually trust the resolver an desire to use it?

I have never claimed to be able to detect this situation and I won't do it now 
either - I'm just stressing that I think there are good uses for DoH already 
as it works today. I haven't seen anyone at all present ideas on how to detect 
the different situations, and even "the situations" themselves are hard to 
define and agree upon.

-- 

  / daniel.haxx.se

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Aug 2019 11:12:48 -0400 (EDT)

On Thu, 15 Aug 2019, Mikael Abrahamsson wrote:

> 1. I am at home. I trust my home ISP more than I trust CF/GOOG, so I want to 
> use my ISP resolver.
>

Browsers could become aware of which wifi network they are on and
configure DNS appropriately. Of course, this would have to be strictly
controlled so that webpages do not gain access to any of this
information. It is the same idea as Microsoft's "home", "office" and
"public" network association when connecting to a new network.

> choice not to use their ISP provided resolver. So the proposal to change the 
> defaults for everything means 95% will have their default changed. Some users 
> on this list seems to think this is acceptable fallout to fix 2.

How many million routers need to be hacked and have their DHCP DNS
configuration modified before you deem it "acceptable" ?

https://www.google.com/search?q=modem+router+dns+modified+attack

Paul

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 17:28:57 +0200 (CEST)

> "public" network association when connecting to a new network.

Indeed, and I have made this argument 3-4 times already in the past 1-2 
weeks on this list. ASK THE USER! However, the people advocating to change 
the default seem to not agree.

> configuration modified before you deem it "acceptable" ?

A lot more than has happened to date. Since the malicious ones are barely 
a blip on the radar (the number for "other" I have seen in peoples 
presentations are barely noticable). Most of the ones not using their ISP 
resolvers are instead using Google, Cloudflare, opendns or something that 
is not changed to this for malicious reasons.

---

From: Neil Cook <[email-masked]>
Date: Thu, 15 Aug 2019 16:29:21 +0100

> On 15 Aug 2019, at 16:05, Paul Wouters <[email-masked]> wrote:

> negatively affect other customers.

> . So

I think you just gave a reason yourself in the above paragraph why the coffee shop would not want to give the user an uncensored internet.

Neil Cook
[email-masked]

-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Director: Frank Hoberg

US Office: 
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 
-------------------------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 08:32:59 -0700

On Aug 15, 2019, at 8:28 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Indeed, and I have made this argument 3-4 times already in the past 1-2 weeks on this list. ASK THE USER! However, the people advocating to change the default seem to not agree.

Any security UI that the user sees more than once at setup time is going to turn into a “what do I have to click to get work done” decision.   The reason we say “don’t ask the user” is not because we don’t think what the user wants matters.   It’s because asking the user what they want when they are trying to get work done will not result in us getting an answer that actually represents what the user wants.

Look at the failure of Windows Vista.   I thought that the notification system for security issues was fantastic, because I understand the problem and its solutions.  And even I got tired of the security alert popups after a while.   Most users hated this UI with a passion and stuck to Windows XP.   It was a disaster for user security, despite being a better UI in the sense that you are imagining.   It was a better UI in theory, but not in practice.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 17:39:34 +0200 (CEST)

On Thu, 15 Aug 2019, Ted Lemon wrote:

> Any security UI that the user sees more than once at setup time is going 
> to turn into a “what do I have to click to get work done” decision. 
> The reason we say “don’t ask the user” is not because we don’t think 
> what the user wants matters.  It’s because asking the user what they 
> want when they are trying to get work done will not result in us getting 
> an answer that actually represents what the user wants.

Does this mean you think what MS is doing in Windows at network connect 
(first time, regarding the public/private wifi) is the wrong thing to do?

Because that's exactly what I am talking about. Sensible defaults 
depending on that kind of question. Ask once per SSID.

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 15 Aug 2019 17:46:11 +0200

Moin!

On 15 Aug 2019, at 17:05, Paul Wouters wrote:
> they want.
Is there really? In all parts of the world?

> Sure there are some limitations based on sharing the
So given that you are ok with the provision of not accessing certain
sites would you be ok with them to enforce this?

> But the user may totally corrupt
TBH I’d rather connect to a network that protects me from malware/
trojans then one that protects me from porn (Though there is some
relationship there ;-)

> do not apply because you are a guest and you can choose not to connect.
I agree here, but isn’t that what TLS is for. Sure it would be good
if the DNS connection also would be encrypted, but if the coffee shop
owner offered it he would still be able to see the traffic. On most
coffee shops/hotels I would have less problem with that then if
Cloudflare or Google get all my browsing traffic.

Anyway I think the fundamental problem is that there are a lot of
different use cases and environments out there and there will not
be a one size fits all solution.

Even the coffee shop could be in a jurisdiction where the user
expects the network to protect them or where networks are required
to do that (and get fined/license revoked when they don’t).

So long
-Ralf
—--
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 08:46:35 -0700

On Aug 15, 2019, at 8:39 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Does this mean you think what MS is doing in Windows at network connect (first time, regarding the public/private wifi) is the wrong thing to do?

That was bad too, yes.   How does the user know?   What will happen if they say “public”?   What will happen if they say “private?”   What will happen in practice is that the user will notice when clicking “public” causes problems, and when clicking “private” causes problems, and over time will be conditioned to, without thinking, click the one that causes the least problems.

But I was actually referring to the notification that an app has done a privilege escalation, which happened all the time.  I found it helpful because when an app unexpectedly escalated privileges, I could kill it and stop using it.  Others found it annoying because it happened a lot.

> Because that's exactly what I am talking about. Sensible defaults depending on that kind of question. Ask once per SSID.

Absent authentication and unambiguous identification, neither of which are present in SSIDs, there is no way to make this work.   Every SSID, even if it’s got the same name and the same BSSID, has to be treated as a new SSID, because there is no way to prove that it is not without 802.1x.   So you could use 802.1x authentication to trigger different behavior, but that’s the only case where this would make sense.   Even there, you have to make sure that two SSIDs marked DeutscheTelekom with different certs are treated as different SSIDs, and that there’s a way for the user to understand what is going on.   This is a really hard problem, because there’s no definitive registry for SSIDs.   I honestly can’t think of a secure way to do this that doesn’t involve the IT department installing certs on the host, at which point there’s no need for a UI.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 08:51:19 -0700

> trojans then one that protects me from porn (Though there is some

If you want that, and you want DNS filtering of malware, then the best way to get that is to know what resolver you are talking to.   IOW, that’s a really clear use case for DoH.

If you trust a resolver offered to you over DHCP or RA, you do not get any assurance that your resolver has this property.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 17:55:50 +0200 (CEST)

On Thu, 15 Aug 2019, Ted Lemon wrote:

> problem, because there’s no definitive registry for SSIDs.  I honestly 
> can’t think of a secure way to do this that doesn’t involve the IT 
> department installing certs on the host, at which point there’s no need 
> for a UI.

So just because it can't be made 100% sure and fool-proof, let's just 
change the default in browsers to use CF/GOOG for all browser users?

This is the tradeoff I am opposed to. This is the crux of the problem. 
There is no way to technically decide if the network can be trusted or not 
(we agree on that), now what? We can also agree that asking the user is a 
bad thing. But is the solution really to change the default resolver path?

Is this the least harmful way?

That is the important question to ask ourselves. This is where we have 
disagreement.

What is the sensible default? Follow the operating system (as has been the 
case for 20+ years), or change it.

Changing it has consequences, keeping it the way it has always been has 
consequences. Which one is the least bad? How do we come up with a 
compromise that everybody can live with?

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 12:02:20 -0400

Top-reply addressing some of Paul W’s arguments:
- My recent experience with public Wi-Fi has been mixed. Many offer “open” SSIDs (no lock symbol, no password required) with captive portals of some flavor. I would not agree with the expectation of privacy for those. Nor would I expect any containerization.
- Given the previous bullet point, I believe it is reasonable for operators of those networks to limit their liability on customer vs customer traffic (eg malware) by use of DNS-based filters or other filter mechanisms. The same applies to community standards on content (porn etc). IMHO, liability trumps user choice, which is why there are Ts and Ca, whether or not the users pay attention to them.

The definition I’d use for “coffee shop” is “not the user’s primary ISP”. Where there may be some kind of purchased service for access (eg GoGo or similar), I would expect some explicit TOS covering relevant expectations.

Network neutrality is, unfortunately, a localized (possibly geo-political in nature or subject to corruption) thing.

Violating TOS and or jurisdiction-specific laws should not be done on a user’s behalf, IMHO. Paul may choose to do so, but if he does, any risk associated with that is his responsibility, as it should be.

The sentiment that something “should be illegal”, does not change the legality of that thing. Whether “it is fine” to work around that is both questionable logic and very likely something that differs significantly by jurisdiction.

My point is basically, unless the network is owned by you or is a permanent provider to you (with well defined contract etc), the network owner is entirely justified in operating the network however they wish, and using a network, whether “offered to the public” or to a more restricted set of users (eg hotel guests), is basically a proposition of accept the terms as-is, or don’t use it. That can range from allowing anything at all, to requiring use of their broken DNS proxy, to blocking all HTTPS and doing horrible things to the remaining traffic. Unfettered Internet access is not yet a universal right.

It doesn’t mean I like some of these things, or agree with these practices in general. I’m pointing out that legal stuff at a per-jurisdiction level, may not be compatible with DoH, regardless of who controls the enabling or disabling, which makes compliance and informed user consent a huge issue. IMHO that should be a barrier to deployment of DoH in browsers, but that is likely a choice that browser vendors and customers both need to consider.

Brian

Sent from my iPhone

> On Aug 15, 2019, at 11:05 AM, Paul Wouters <[email-masked]> wrote:
>

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 15 Aug 2019 18:03:17 +0200

Moin!

On 15 Aug 2019, at 17:51, Ted Lemon wrote:

> If you want that, and you want DNS filtering of malware, then the best 
> way to get that is to know what resolver you are talking to.   IOW, 
> that’s a really clear use case for DoH.
I was making the point on what people are ok with when it comes to DNS 
servers, but I can agree that we should work on making DNS server setup 
more secure and capabilities more known. I believe there is work in 
dnsop on that at the moment (draft-sah-resolver-information).

> If you trust a resolver offered to you over DHCP or RA, you do not get 
> any assurance that your resolver has this property.
There are ways to protect against rouge RA/DHCP on network devices, but 
I agree it is an attack vector.

So long
-Ralf
—--
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 09:09:05 -0700

On Aug 15, 2019, at 9:03 AM, Ralf Weber <[email-masked]> wrote:
> There are ways to protect against rouge RA/DHCP on network devices, but I agree it is an attack vector.

The point is, whatever network you are on, unless you know who operates it and have some reasonable basis for trusting their puissance at defending you, you must assume that the resolver will attack you, and the DHCP server will attack you, and the RAs will attack you, because none of them are authenticated.   If your strategy for configuring your box places trust in any of these services, you are at risk.   As the end user, or as the browser vendor, I have no knowledge of who is running the network to which I am connected at this moment, so I can’t make assumptions about how trustworthy it is.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 09:11:13 -0700

On Aug 15, 2019, at 9:02 AM, Brian Dickson <[email-masked]> wrote:
> - Given the previous bullet point, I believe it is reasonable for operators of those networks to limit their liability on customer vs customer traffic (eg malware) by use of DNS-based filters or other filter mechanisms.

This isn’t a valid assumption.  Depending on jurisdiction, this action may protect you from liability, but it may also expose you to liability.

Similarly, depending on the jurisdiction, the user may be more accountable, or less accountable, if they are using software that has default behavior that happens to be in violation of the ToS.

We really aren’t in a position to give advice about this.

---

From: Joe Abley <[email-masked]>
Date: Thu, 15 Aug 2019 12:19:01 -0400

> On 15 Aug 2019, at 11:46, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 15, 2019, at 8:39 AM, Mikael Abrahamsson <[email-masked] <mailto:[email-masked]>> wrote:
> That was bad too, yes.   How does the user know?   What will happen if they say “public”?   What will happen if they say “private?”

For what it's worth (not very much!) the small number of times I have seen this kind of question it has just made me mildly uncomfortable and I have not known how to answer.

I think the only reasonable security posture in general is to assume that all networks are hostile. I don't know how "public" and "private" maps to that, and I can't look up what implications the decision has without making a guess to get connected to search.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 15 Aug 2019 18:25:54 +0200 (CEST)

On Thu, 15 Aug 2019, Joe Abley wrote:

> For what it's worth (not very much!) the small number of times I have 
> seen this kind of question it has just made me mildly uncomfortable and 
> I have not known how to answer.

https://www.howtogeek.com/245982/whats-the-difference-between-private-and-public-networks-in-windows/

To me it seems MS has done a good job in trying to explain this to the 
user. I'd imagine they didn't do this lightly and had considerable 
research to base their user prompt on and what it contained.

---

From: Joe Abley <[email-masked]>
Date: Thu, 15 Aug 2019 12:33:17 -0400

> On 15 Aug 2019, at 12:25, Mikael Abrahamsson <[email-masked]> wrote:
> 
> To me it seems MS has done a good job in trying to explain this to the user.

I don't use windows very often (I haven't used it regularly since 1995). I don't remember the dialogue box on whatever I was using more recently looking like that, but I have to say that I am just differently confused by the pop-up shown at that link than I was for the one I saw.

If I don't want my PC to be discoverable by other devices on the network, isn't that the same as not connecting to the network? What is the point of a network if I can't exchange information with other devices?

I appreciate that this dialogue box is not intended for me (I interpret it at first glance as a weird request relating to ARP and ND filtering, and I'm pretty sure that's not what is intended) but I'll take the opportunity to express doubt that in general it's possible to achieve clarity for all audiences.

Really if your discovery protocol (whatever that is) is not secure, I recommend not implementing it. All networks are hostile. If your printer isn't fit to be connected to the Internet, don't connect it to any network more complicated than a crossover cable.

Joe

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 17:39:14 +0000

> If you want that, and you want DNS filtering of malware, then the best way to get that is
> to know what resolver you are talking to.   IOW, that’s a really clear use case for DoH.

Without authentication, a key missing feature of DoH alongside discovery, I don’t believe that this statement is correct.

---

From: Joe Abley <[email-masked]>
Date: Thu, 15 Aug 2019 13:50:23 -0400

Hi Andrew,

> Without authentication, a key missing feature of DoH alongside discovery, I don’t believe that this statement is correct.    

In your view, what is missing in HTTPS authentication that is needed for DoH?

I agree that there is a lack of automatic mechanisms to configure DoH.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Aug 2019 13:55:39 -0400

> Without authentication, a key missing feature of DoH alongside discovery, I don’t believe that this statement is correct.    

Fortunately DoH provides authentication.

---

From: Andrew Campling <[email-masked]>
Date: Thu, 15 Aug 2019 17:58:23 +0000

On Thu, 15 Aug 2019, Paul Wouters <[email-masked]> wrote:

> If you say the coffeeshop / hotel as an ISP has the right to filter any of your traffic, I don't see why that would not apply to DSL or LTE based ISPs. That would be the end of net neutrality and the start of commercial (not government) censorship. 

It's important to remember that definitions of net neutrality vary around the world, may not be viewed to be important or even relevant in some jurisdictions.  For example, some of the content available on 8chan in the US is unlikely to be legally acceptable in at least some European markets despite provisions for net neutrality applying in both geographies, albeit with differing views on meaning / application.  

Andrew

---

From: Paul Wouters <[email-masked]>
Date: Thu, 15 Aug 2019 14:11:12 -0400 (EDT)

> - Given the previous bullet point, I believe it is reasonable for operators of those networks to limit their liability on customer vs customer traffic (eg malware) by use of DNS-based filters or ot…

The only thing you need to do is block wifi-client --- AP ---wifi client
traffic. Why on earth would you try to block client to client traffic
using DNS? Especially because when clients can see each other's traffic,
they can also start spoofing DNS answers that will be quicker than the
real further away DNS server?

> The same applies to community standards on content (porn etc). IMHO, liability trumps user choice, which is why there are Ts and Ca, whether or not the users pay attention to them.

customers at any establishment can misbehave. You already should have
a system in place for removing such customers, whether it is "bad"
internet use, or spouting racists rants. Besides, you will never be
able to block all porn using a DNS filter anyway. Any user can bring
up a VPN and play all the porn they want.

So since it is fairly trivial to circument, and not using DoH actually
harms legitimate users that are being censored (new recent examples:
Kashmir, possibly soon Hong Kong), I am in favour of DoH being possible,
and maybe even should be the default. Although if it is the default, I
do believe the browsers should be helt to _very_ high privacy standards
for their DNS data.

> Network neutrality is, unfortunately, a localized (possibly geo-political in nature or subject to corruption) thing.

Still, the IETF designs for this principle.

> Violating TOS and or jurisdiction-specific laws should not be done on a user’s behalf

Neither should overreaching censorship be done on a user's behalf. But
these arguments are rather open doors into the legal system, and not so
much IETF themed discussions.

> My point is basically, unless the network is owned by you or is a permanent provider to you (with well defined contract etc), the network owner is entirely justified in operating the network however they wish

Sure, and the user is welcome to try and encrypt and route packets of
their own choosing and assume that if the packets routes and get answers,
that it falls within the network's valid use case. So DoH to my own
private server will be fine on those networks. Your argument also throws
dissidents and journalists under the bus. For the "safety" of trusting
random unknown local ISPs over established (sadly mostly US based) DoH
providers.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Thu, 15 Aug 2019 14:29:55 -0400

Sent from my iPhone

>> On Aug 15, 2019, at 2:11 PM, Paul Wouters <[email-masked]> wrote:
>> 
> dissidents and journalists under the bus.

You appear to have inadvertently excluded the one piece of my message that changes the intent of my message, with respect to this “under the bus” issue.

I said “Paul may choose to do so, but if he does, any risk associated with that is his responsibility, as it should be.”

That would (and should) apply to dissidents and journalists. I.e. parties who understand those risks and without a doubt are in a position to enable DoH with unambiguous informed consent.

My argument precisely does not throw those folks under the bus.

This is also the context within which to point out that since DoH hides all its DNS traffic in the volume of general HTTPS traffic, the percentage of users using DoH in theory should not matter, ie pushing all users onto DoH isn’t strictly necessary to protect the dissidents and journalists IMHO.

Brian

> For the "safety" of trusting

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Aug 2019 20:10:34 +0100

Users' wanting DoH in this kind of n/w scenario seems
to me a no-brainer.

I think points not already mentioned include:

- People who use such networks in one place likely use
  many such networks over time so the probability of
  being attacked by one such n/w accumulates.
- Consistent use of DoH with an authenticated recursive
  reduces those users' attack surface usefully as well
  as being more privacy friendly.
- I would not be surprised if consistent use of DoH
  also made the user experience more consistent and
  maybe better overall.
- I would be surprised if use of DoT was feasible,
  but it'd be nice if it were. (I have seen problems
  using stubby in some such networks that require
  a bit of "pretend" DNS resolution in the captive
  portal signon bit, and while I can see how stubby
  could do a bit better there I suspect that leaving
  the system resolver on Do53 and having applications
  do DoH may be a sweetspot setup for getting connection
  and DNS privacy for DoH-enabled applications in
  such networks.)

On the n/w admin side, ISTM most such networks have
two different kinds of "operator" - the first being
the coffee-shop or hotel business and the 2nd being
whomever the coffee-shop or hotel have contracted
with to provide hotspots. IIUC, that's the common
kind of setup these days but I don't claim that much
familiarity with who does exactly what.

I frankly don't believe that the hotel or similar
really care about choices of DNS recursive.

I've not heard anything convincing as to why the
hotspot-provider company would really either, though
the caport problem space has it's own complexities
I guess. (I did hear the points about T&C's, legalities
and whatnot, but those mostly seems like normally
necessary business-oriented arse-covering to me.)

I wonder if many of the DNS queries in such cases
don't already end up with a quadN resolver - does
anyone know?

Anyway, bottom line for me is absent something
convincing, these scenarios strongly argue in favour
of wanting to see as much use of DoH as is practical.
(At the same time we do have the problem that e.g.
a browser can't really know when we're in that kind
of n/w scenario so this is not the same as saying
that browsers ought make DoH their default, just so
as to cover these scenarios well.)

Cheers,
S.

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 16 Aug 2019 08:04:17 +0200

> really care about choices of DNS recursive.

They do when the legislation require certain actions by whoever provides the service to the end user within the jurisdiction where the access is provided. If they do not fulfil the requirements, legal actions are awaiting the provider of the access service.

   Patrik

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 07:10:59 +0100

On Fri, 16 Aug 2019, 07:04 Patrik Fältström, <paf=
[email-masked]> wrote:

> They do when the legislation require certain actions by whoever provides
> the service to the end user within the jurisdiction where the access is
> provided. If they do not fulfil the requirements, legal actions are
> awaiting the provider of the access service.

If this were truly the case then why are hotels and cafes (etc) not
routinely being prosecuted for failing to block Tor and VPN usage?

-a

---

From: Rob Sayre <[email-masked]>
Date: Thu, 15 Aug 2019 23:21:22 -0700

> routinely being prosecuted for failing to block Tor and VPN usage?

Ah, yes. I looked into this issue a bit more. My Android phone
automatically switches on a VPN if the WiFi access point is in their
database and is open (no password, no portal). It turns out it is the
default setting on the handset, because it's a Google Fi device. <
https://mailarchive.ietf.org/arch/msg/add/exnClgsQMNmVU00v3fEUWBHR9WE>

It doesn't seem like these "legal requirements" arguments are very
up-to-date.

thanks,
Rob

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 16 Aug 2019 08:42:50 +0200

On 16 Aug 2019, at 8:10, Alec Muffett wrote:

> If this were truly the case then why are hotels and cafes (etc) not routinely being prosecuted for failing to block Tor and VPN usage?

As have been said so many times on this list before, but it must be repeated obviously:

Because the legislator believe the blocking access via manipulation of the recursive resolver is good enough.

If it is not good enough anymore, then there must be a different way for the access provider to block the access to the same domain names.

Today we have the good situation that:

- Legislation requires blocking to certain domain names
- It is blocked by manipulation of recursive resolvers by the access provider
- Legislation believe this blocking is good enough
- People can themselves set resolver to quadN or use VPN
- Legislation ignores the easy way of circumvent the blocking

If the legislator believe the action used is not good enough anymore, then we rise the bar regarding technical solutions for blocking and because of that most certainly decrease the ability for the customer to override the technical solution chosen by the access provider.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 16 Aug 2019 08:46:36 +0200

On 16 Aug 2019, at 8:21, Rob Sayre wrote:

> It doesn't seem like these "legal requirements" arguments are very up-to-date.

Do you see this as something positive or negative?

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Thu, 15 Aug 2019 23:48:58 -0700

On Thu, Aug 15, 2019 at 11:43 PM Patrik Fältström <paf=
[email-masked]> wrote:

> If the legislator believe the action used is not good enough anymore, then
> we rise the bar regarding technical solutions for blocking and because of
> that most certainly decrease the ability for the customer to override the
> technical solution chosen by the access provider.
>

This doesn't seem like a very good argument for leaving DNS unencrypted.
It's true that government could impose restrictions beyond what we see
today in DNS polices, but they already seem to do that in many places.

It seems like a net win if the regulators ratchet up enforcement to get the
same result they have now, but various common criminals are thwarted (see <
https://mailarchive.ietf.org/arch/msg/add/NIk8gIPZu52GXDsT8zy4S1I4QsM>).

thanks,
Rob

---

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

On 16 Aug 2019, at 8:48, Rob Sayre wrote:

> It's true that government could impose restrictions beyond what we see today in DNS polices, but they already seem to do that in many places.
>
> It seems like a net win if the regulators ratchet up enforcement to get the same result they have now, but various common criminals are thwarted (see <

I am not arguing in favor of leaving DNS unencrypted. Definitely not. I am strongly in favor of encryption of the DNS queries, like DoT. On top of local validation of DNSSEC signed responses in the client so that the client do know whether modification of the responses have happened.

What I am talking about is the full service resolver. Who runs it, who set the default full service resolver, whether this is part of "the access product or not", and who requires the modification of the responses at the end point of the encrypted tunnel used for the DNS queries.

   Patrik

---

From: Rob Sayre <[email-masked]>
Date: Fri, 16 Aug 2019 00:00:29 -0700

On Thu, Aug 15, 2019 at 11:52 PM Patrik Fältström <[email-masked]> wrote:

> > It seems like a net win if the regulators ratchet up enforcement to get
> the same result they have now, but various common criminals are thwarted
> (see <
> I am not arguing in favor of leaving DNS unencrypted. Definitely not.
>

I see. I apologize for misrepresenting your opinion.

>
> What I am talking about is the full service resolver. Who runs it, who set
> the default full service resolver, whether this is part of "the access
> product or not", and who requires the modification of the responses at the
> end point of the encrypted tunnel used for the DNS queries.
>

I think these are all valid questions, but they veer into OS APIs, business
deals (pre-install deals are big business), etc. They seem to be valid
concerns, but not something for a protocol SDO to get involved in.

thanks,
Rob

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 08:01:08 +0100

> recursive resolver is good enough.

But it's *not* good enough, is it? Anyone can access Tor, and VPNs are
extremely popular.

On that basis, why are you not lobbying your legislators to crack down on
this existing and popular hazard?

Evidence:

https://www.facebook.com/notes/facebook-over-tor/1-million-people-use-facebook-over-tor/865624066877648/
(disclosure: I had the honour of authoring this)

https://thewirecutter.com/reviews/best-vpn-service/

If "DNS lookup filtration" serves as some kind of checkbox censorship in
order to satisfy the censorious, then it will continue to do that.

Otherwise, if you are willing to accept that VPNs already exist, and that
technology will always advance in order to give people more privacy, what
_is_ the problem here?

-a

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 16 Aug 2019 09:09:47 +0200

On 16 Aug 2019, at 9:01, Alec Muffett wrote:

> On Fri, 16 Aug 2019, 07:42 Patrik Fältström, <[[email-masked]](<mailto:[email-masked]>)> wrote:
>
> But it's *not* good enough, is it? Anyone can access Tor, and VPNs are extremely popular.

No, it *is* good enough.

> On that basis, why are you not lobbying your legislators to crack down on this existing and popular hazard?

The legislator do not care. They require the access provider to ensure they have blocking which is "good enough". If the legislator one day believe the use of Tor and other mechanisms is too high (so that the mechanisms the access provider have implemented is not good enough) they just tell the access provider to "do better, or else you get a fine".

The legislator just do not care. Its the access provider that is nervous over some DoH arguments.

   Patrik

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 16 Aug 2019 09:18:56 +0200 (CEST)

> The legislator just do not care. Its the access provider that is nervous 

User-controlled resolver configuration you mean? Since I'm pretty sure most 
coffee shops don't intercept or meddle with plain Do53 DNS traffic to the quad 
servers either...

-- 

  / daniel.haxx.se

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 08:25:56 +0100

> The legislator just do not care. Its the access provider that is nervous

On those I believe that we agree; where we differ is whether everyone
else's privacy should continue to suffer, and whether pursuit of
technologically easier, better privacy and integrity ever should be chilled
or diverted in order to consider this "nervousness".

>From repeated experience in my career (including Crack, work assisting Tor
Onions, and E2E for FB Messenger) my perspective is that security and
privacy advancement is always the better option.

But then I build platforms for a living.

-a

---

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

> or diverted in order to consider this "nervousness".

I do not see what end users privacy have to do with this.

The end users privacy:

1. Can be protected via encrypted transport

2. Can always be violated at the end point of the encrypted transport

You seems to have a claim that having the end point in a different jurisdiction than the end user and at an entity that the end user do not have explicit contractual agreements with, is better privacy?

Can you expand on these two things explicitly please.

> privacy advancement is always the better option.

I agree, and this is why I was supporting and helping the Swedish Government when it supported financially further development of Tor. And why I am personally supporting privacy initiatives like Tor. And why I am arguing in favour of DNSSEC validation in the client so that "people messing around with DNS can be detected".

> But then I build platforms for a living.

So do I.

What I am nervous about is to shake the box so much that it will be harder to use things like Tor and VPNs.

I want the end user having the ability to override the default solution the access provider provides. I want the internet access the access provider provides be so open that I still can choose my full service resolver.

I do NOT want the legislator say the access providers are not doing a good enough job (today) when they "just" are patching the full service resolver they provide for their users.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 16 Aug 2019 09:40:33 +0200

On 16 Aug 2019, at 9:18, Daniel Stenberg wrote:

> User-controlled resolver configuration you mean? Since I'm pretty sure most coffee shops don't intercept or meddle with plain Do53 DNS traffic to the quad servers either...

We already have user controlled resolver configuration.

What am talking about is:

- Not having the access provider configuration as default

So that the access provider have to implement blocking in a different way.

- Not having resolver configuration per computer

So that the number of calls to customer care increases.

   Patrik

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 08:50:59 +0100

On Fri, 16 Aug 2019, 08:37 Patrik Fältström, <[email-masked]> wrote:

>
> I do NOT want the legislator say the access providers are not doing a good
> enough job (today) when they "just" are patching the full service resolver
> they provide for their users.

Then let us "lift all boats" so that any future hypothetical legislator is
not in a position to say "the internet has developed far enough and should
stop developing now".

They tried that with PGP. They tried that with HTTPS. They are yet again
attempting it with end-to-end encrypted messaging.

I propose that they not be accommodated, for fear of what their next "ask"
would be; aside from anything else if we begin to architect *ourselves* in
order to accommodate them, they will not appreciate the effort and will
simply demand more.

Essay: "Lift all boats" https://link.medium.com/xSzR7BE6bZ

-a

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 16 Aug 2019 10:27:29 +0200

> Essay: "Lift all boats" https://link.medium.com/xSzR7BE6bZ

My last message on this is, once again, the legislator do not care.

They have already told, and will continue to tell, the access provider to block access to certain domain names. The rest is up to the access provider.

   Patrik

---

From: Neil Cook <[email-masked]>
Date: Fri, 16 Aug 2019 09:33:16 +0100

> On 15 Aug 2019, at 20:10, Stephen Farrell <[email-masked]> wrote:
> 

Some hotspot providers are telcos, who also provide parental control/malware filtering to their users, which extends not only to their broadband connection, but also their mobile network and their Wifi hotspot network. So when you sign in to their hotspots you get the same filtering as you do at home. JFYI.

Neil Cook

European Office: 

US Office:

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 09:37:08 +0000

On Fri, Aug 16, 2019 at 07:21 Rob Sayre <[email-masked]> wrote:
> Ah, yes. I looked into this issue a bit more. My Android phone automatically switches on
> a VPN if the WiFi access point is in their database and is open (no password, no portal). It
> turns out it is the default setting on the handset, because it's a Google Fi device.
> <https://mailarchive.ietf.org/arch/msg/add/exnClgsQMNmVU00v3fEUWBHR9WE>
>

Which market(s) did these investigations cover, bearing in mind that legal requirements on both access providers and others vary considerably around the world?

Andrew

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 09:55:19 +0000

> (disclosure: I had the honour of authoring this)

This represents less than one percent of active Facebook users, doesn’t by itself challenge the “good enough” point being made and certainly isn’t a “popular hazard” relative to the total universe of internet users.

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 11:09:29 +0100

On Fri, 16 Aug 2019, 10:55 Andrew Campling, <[email-masked]>
wrote:

> This represents less than one percent of active Facebook users,
>
Or: Three times the population of Iceland.

That's the thing about perspective, at some point you have to talk about
absolute numbers.

One million people is a lot of people, and it's grown since that time,
because the technology has improved to enable it to get larger and better.
:-)

-a

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 10:15:48 +0000

On Fri, 16 Aug 2019, 11:09 Alec Muffett <[email-masked]> wrote:
> That's the thing about perspective, at some point you have to talk about absolute numbers.
> 
> One million people is a lot of people, and it's grown since that time, because the technology 
> has improved to enable it to get larger and better. :-)

I agree with you up to a point - clearly the regulator in Iceland would be concerned if these users were concentrated there.  However, for example, the UK regulator would have less of an issue as, even if all 1 million were located in the UK (unlikely!) they would still represent less than 10% of the internet user population in that country.  In reality, spread as they are around the world, absolute numbers only usually matter to regulators when they are considering those within their jurisdiction.

---

From: Alec Muffett <[email-masked]>
Date: Fri, 16 Aug 2019 11:20:04 +0100

On Fri, 16 Aug 2019, 11:15 Andrew Campling, <[email-masked]>
wrote:

> In reality, spread as they are around the world, absolute numbers only
> usually matter to regulators when they are considering those within their
> jurisdiction.
>

so you're saying the important thing is to not give too many people too
much security, for fear of annoying regulators?

-a

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 12:24:35 +0200

On Fri, Aug 16, 2019 at 9:38 AM Patrik Fältström <paf=
[email-masked]> wrote:

> You seems to have a claim that having the end point in a different
> jurisdiction than the end user and at an entity that the end user do not
> have explicit contractual agreements with, is better privacy?
>

I don't know what Alec's claim is, but my claim is that when the user gets
their resolver from the network, they have no real way of understanding
what the privacy behavior of that resolver is: in many cases (public WiFi,
etc.) they have no relationship at all with the provider, and even when
it's an ISP, the privacy policies are opaque and there is a fairly long
history of bad behavior. The intent of TRR is that the application provider
is able to negotiate for and assure an acceptable privacy policy on the
user's behalf.

-Ekr

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 10:27:03 +0000

On Fri, 16 Aug 2019, 11:20 Alec Muffett <[email-masked]> wrote:
> so you're saying the important thing is to not give too many people too much security, for fear of annoying regulators?

That's one interpretation of what Patrik stated earlier, my point was simply that your evidence did not undermine his comment.  (I might agree with a contention that some regulators, in some circumstances and in some markets, might be prepared to accept "good enough" because "perfect" is too expensive to delivery versus the additional benefit of doing so - obviously there will be exceptions to this).    

Separately, whether DoH by itself delivers on either "security" or "privacy" is at least a matter of debate, as evidenced by the exchanges here.

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 09:56:15 -0600

So you are asking users to just trust you and your application?  Because you know what is best for them in all situations and conditions? 

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Aug 16, 2019, at 4:24 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Aug 16, 2019 at 9:38 AM Patrik Fältström <paf=[email-masked] <mailto:[email-masked]>> wrote:
> > On Fri, 16 Aug 2019, 08:09 Patrik Fältström, <[email-masked] <mailto:[email-masked]>> wrote:
> >
> I don't know what Alec's claim is, but my claim is that when the user gets their resolver from the network, they have no real way of understanding what the privacy behavior of that resolver is: in many cases (public WiFi, etc.) they have no relationship at all with the provider, and even when it's an ISP, the privacy policies are opaque and there is a fairly long history of bad behavior. The intent of TRR is that the application provider is able to negotiate for and assure an acceptable privacy policy on the user's behalf.
> 
> -Ekr
> 
> -- 
> Add mailing list
> [email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Fri, 16 Aug 2019 16:35:53 +0000

On Fri, Aug 16, 2019 at 11:25 AM Eric Rescorla <[email-masked]> wrote:

> and even when it's an ISP, the privacy policies are opaque and there is a fairly long history of bad behaviour. The intent of TRR is that the application provider is able to negotiate for and assure an acceptable privacy policy on the user's behalf.

I think we should be careful to generalise given the significant differences between geographies.  We should also acknowledge that, unfortunately, many applications providers have long and opaque privacy policies* coupled with a long history of bad behaviour, especially regarding privacy violations, that continues (noting ongoing investigations in the EU, US and elsewhere).  The assumption that users might be expected to trust a given application provider more than a given ISP does not appear to reflect current the litigation, regulatory enforcement or legislative actions underway in a number of major markets.  

* A number of these privacy policies have previously featured in art installations to underline their length and complexity

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 16 Aug 2019 19:33:29 +0200

On Fri, Aug 16, 2019 at 6:35 PM Andrew Campling
<[email-masked]> wrote:

> > and even when it's an ISP, the privacy policies are opaque and there is
> a fairly long history of bad behaviour. The intent of TRR is that the
> application provider is able to negotiate for and assure an acceptable
> privacy policy on the user's behalf.
>
> I think we should be careful to generalise given the significant
> differences between geographies. We should also acknowledge that,
> unfortunately, many applications providers have long and opaque privacy
> policies* coupled with a long history of bad behaviour, especially
> regarding privacy violations, that continues (noting ongoing investigations
> in the EU, US and elsewhere).
>

Fortunately, no speculation is needed because the privacy requirements for
the Mozilla TRR program are short and readily available.
https://wiki.mozilla.org/Security/DOH-resolver-policy

-Ekr

---

From: Bret Jordan <[email-masked]>
Date: Fri, 16 Aug 2019 11:57:07 -0600

How are these audited and verified?  Who does this auditing and verification?  How frequently is it done?  Are the auditors beholden to any disclosure restrictions?

My concerns I raised before are still valid.  I also hold that this is one of the biggest concerns I have:

1) The potential for involuntary mass centralization of DNS data and the consistent erosion of privacy that comes from it 

Thanks,
Bret

> On Aug 16, 2019, at 11:33 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Aug 16, 2019 at 6:35 PM Andrew Campling <[email-masked]> wrote:
> On Fri, Aug 16, 2019 at 11:25 AM Eric Rescorla <ekr@rtfm..com <mailto:[email-masked]>> wrote:
> 
> I think we should be careful to generalise given the significant differences between geographies. We should also acknowledge that, unfortunately, many applications providers have long and opaque privacy policies* coupled with a long history of bad behaviour, especially regarding privacy violations, that continues (noting ongoing investigations in the EU, US and elsewhere). 
> 
> Fortunately, no speculation is needed because the privacy requirements for the Mozilla TRR program are short and readily available. https://wiki.mozilla.org/Security/DOH-resolver-policy <https://wiki.mozilla.org/Security/DOH-resolver-policy>
> 
> -Ekr
> 
> -- 
> Add mailing list
> [email-masked]