Subject: Re: [Add] [EXT] Re: meeting hum: should the IETF take up this work?

From: Jacques Latour <[email-masked]>
Date: Thu, 1 Aug 2019 17:59:12 +0000

From the department of this-could-be-a-bad-idea and the department of omg-this-goes-against-everything-we’re-trying-do, but here it goes: a DoH operator should have a policy to blacklist IP address as requested by the network operator, since we can’t effectively block DoH at the edge of the enterprise network, an enterprise network should have the ability to request the well behaved DoH recursive operators to block requests coming from their network IP address.  Perhaps have some sort of trusted clearing house of IP addresses that the well behaved DoH recursive operators should blacklist from. Enterprises can block non well behaving DoH recursive operators.

Since the major problems of DoH is for all to understand the multidimensional matrix of deployment models vs. value proposition vs. user (vantage) point of view, it’s almost impossible to assess the value proposition of the above example against all the currently possible/available scenarios. But we know that DoH has a negative value proposition for Enterprises.

How do we turn DoH to have a positive value proposition for Enterprise?

Can DoH have positive value proposition for all scenarios?

What are the gaps and how do we address them methodically?

Jack

From: Add <[email-masked]> On Behalf Of Ólafur Guðmundsson
Sent: July 31, 2019 4:07 PM
To: Livingood, Jason <[email-masked]>
Cc: [email-masked]; Adam Roach <[email-masked]>
Subject: [EXT] Re: [Add] meeting hum: should the IETF take up this work?

Jason,

On Tue, Jul 30, 2019 at 5:49 PM Livingood, Jason <[email-masked]<mailto:[email-masked]>> wrote:
On 7/25/19, 10:12 AM, "Add on behalf of Adam Roach" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
> You can see, for example, Cloudflare's associated privacy
    policy at https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-policy/firefox/

[JL] This speaks to the DNS query/response. But with DoH, this is contained inside of an HTTP envelope, so to speak, which has much more rich tracking - noted at https://www.cloudflare.com/privacypolicy/ under website visitors (which I presume applies to all HTTP transactions). So the confluence of DNS and HTTP here seems interesting to better understand and document as TRR-style policies evolve. Since there is an HTTP server involved in DoH, presumably all the normal HTTP log items are seen & processed and can be logged, like user agent, cookies, and so on.

Cloudflare modified the HTTPS processing for DoH requests, we did this for privacy, efficiency and speed reasons.
The overwriting goal was to be compliant with the our public policies and commitments.
Anything that matches https://tools.ietf.org/html/rfc8484#section-4.1<https://tools.ietf..org/html/rfc8484#section-4.1> definition of DoH request is NOT logged by the HTTPS service, we will only respond to DoH requests on a defined list of DoH service names/addresses.

Our DoH module only counts connections, no logging of content ( mainly to verify we do not drop anything internally)
The DNS  resolver system is the only one that writes to the resolver logs, it is unaware of any user agent and other HTTP things,

There is no setting or reading of cookies from our servers (you can confirm this by doing a request on you own), like

curl --verbose -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=comcast.com&type=AAAA'

[JL] In addition, I suspect a concern (for the very high scale centralised DoH platforms) is not just the per-user privacy policy but also what aggregated business intelligence a global scale platform would be able to develop (e.g. of a population of 500M users, how many have queried for *.netflix.com<http://netflix.com> in the past N hours, by country, ASN, user agent, etc.), relative to competitors or potential competitors. So I suspect these concerns may arise, at least for platforms of very high scale / penetration.

This is not unique to DoH in any way or shape!
This is common to all DNS queries and having access to query streams, so every DNS provider should answer if they share any DNS query data and with whom and for what purpose.
Anyone that has access to query stream from one of the top ISP's in a few countries might have better view than large Public DNS Resolver.

Restating Cloudflare 1.1.1.1 data policy: Cloudflare will not share any query data with anyone!! Per our agreement with Apnic; they have access to subset Resolver of logs for the last 24 hours only data that arrived on the 1.x.x.1 addresses, they do not a have access to data sent by Firefox users unless the user modified the URL to "https://1.1.1.1/dns-query".
Cloudflare will not use the query data for anything other than to improve the service. Cloudflare keeps traffic aggregations and may share those publicly from time to time.

Cloudflare is fully compliant the policy that Firefox has published AND they have NO access to query data
--
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com<http://www.cloudflare.com> blog.cloudflare.com<http://blog.cloudflare.com>

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Aug 2019 14:31:58 -0400

Hi Jacques!

> On 1 Aug 2019, at 13:59, Jacques Latour <[email-masked]> wrote:
> 
> From the department of this-could-be-a-bad-idea and the department of omg-this-goes-against-everything-we’re-trying-do, but here it goes: a DoH operator should have a policy to blacklist IP address as requested by the network operator, since we can’t effectively block DoH at the edge of the enterprise network,

We can though, right? Depending on what you mean by "effective". It's just more expensive than blocking DoT and Do53 if all you care about is blocking the well-known ports.

We can even do this without affecting end-user privacy in some (many? most?) cases since in some (many? most?) corporate networks there's no expectation of end-user privacy in the first place. There are certainly some corporate networks that were stripping TLS using privately-issued trust anchors for client devices in order to police content long before DoH had been specified.

Given that the number of end-users who inhabit enterprise networks is a rounding error compared to the total number of users of the Internet globally, I continue to be surprised at the amount of focus the enterprise deployment case gets in these discussions.

> an enterprise network should have the ability to request the well behaved DoH recursive operators to block requests coming from their network IP address. Perhaps have some sort of trusted clearing house of IP addresses that the well behaved DoH recursive operators should blacklist from. Enterprises can block non well behaving DoH recursive operators.
> 

If we know that, I don't know how we know.

Is there a potential benefit in some enterprise security architectures to having DNS resolution not being visible across the network, perhaps?

Perhaps not being complicit in enabling DNS resolution for particular clients and particular content is a benefit in arguing for a lack of liability in some legal framework?

In the case where an enterprise is deliberately using external recursive services (e.g. the ones that CIRA and OpenDNS sell) perhaps there's a benefit to having that DNS traffic protected by TLS?

Are we conflating DoH as a protocol with the specific case of a client on an enterprise network using a non-blessed third-party DoH service when we talk about DoH and the enterprise, or an application on a client device that is acting contrary to the device's system-wide configuration? Is that helpful?

I like the questions you're asking about risk analysis for the enterprise (although it still feels a bit like a corner case) but I think there are a lot more questions to ask about the implications of DoH before we can assume that there's no benefit.

Joe

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 01 Aug 2019 20:36:25 +0200

Moin!

On 1 Aug 2019, at 19:59, Jacques Latour wrote:

> From the department of this-could-be-a-bad-idea and the department of 
> omg-this-goes-against-everything-we’re-trying-do, but here it goes: 
> a DoH operator should have a policy to blacklist IP address as 
> requested by the network operator, since we can’t effectively block 
> DoH at the edge of the enterprise network, an enterprise network 
> should have the ability to request the well behaved DoH recursive 
> operators to block requests coming from their network IP address.  
> Perhaps have some sort of trusted clearing house of IP addresses that 
> the well behaved DoH recursive operators should blacklist from. 
> Enterprises can block non well behaving DoH recursive operators.
Interesting idea. I think that in addition to discovery mechanism for 
DoH servers we need some best practices rules for DoH server operators 
so that white hat operators of DoH servers don’t interfere with 
enterprise security and maybe a blacklist for those who use DoH for 
exfiltration. While the idea of the operators blocking requests from 
known enterprises is technically interesting I don’t think it fits 
into enterprise security requirements, as they want the packets not to 
leave their perimeter. So running DoH servers on know addresses (that 
some providers like Google already said they would do) and let the 
enterprise block them outbound might be the better way.

So long
-Ralf
—--
Ralf Weber

---

From: 神明達哉 <[email-masked]>
Date: Thu, 1 Aug 2019 11:38:10 -0700

At Wed, 24 Jul 2019 13:15:49 -0400,
Stephane Bortzmeyer <[email-masked]> wrote:

> > I’m also trying to understand why there seems to be resistance to
> > providing ISPs with advice on deploying DoH.
>
> I'm tempted to say that I don't see the point for an access network to
> deploy DoH. If the network is safe, DoH is not really necessary
> (paranoid may use DoT, since the access network can ensure that port
> 853 is clear). If it is not, for instance because the resolver
> modifies the answers, then users will want to bypass it, anyway.
>
> My guess is that DoH operators will be different from access network
> operators.

I've been wondering about this, too.  Although DoH has some other
(potentially) cool features like "push", my understanding is that its
primary and much more important purpose is to hide DNS resolution
attempts in a normal HTTPS connection that is also used for normal,
popular web services.  And (again in my understanding) the point here
is to make it very hard and mostly impossible for an intermediate
player to even block the resolution (because such a player can't do
this without also blocking the "popular web service", which such a
player is assumed to not want/afford to do).  I don't see why a
resolver in "an access network" needs this capability.  Could someone
enlighten me about what I'm missing?

--
JINMEI, Tatuya

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Aug 2019 14:45:54 -0400

On 1 Aug 2019, at 14:38, 神明達哉 <[email-masked]> wrote:

> Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I've been wondering about this, too.

Lots of access network providers don't control all of the infrastructure between their network and their end-users. Examples are ISPs that use wholesale DSL and CATV access networks operated by incumbents who are required to allow third-party access by regulators.

I have heard concerns before that such access wholesalers might interfere (e.g. block, rate-limit) traffic that was in competition with their own services, or for other reasons. I've also heard concerns that such wholesalers routinely target retail customers of other ISPs when trying to sell their own retail services, and that visibility of the traffic of the end-users allows them to be tempted with targeted promotions.

I'm not saying any of this has happened, anywhere; I'm just saying I have heard concerns about these kinds of things.

To the extent that any of this kind of thing can be enabled by surveillance of DNS traffic between an end-user and a resolver, this to me is a plausible reason to want privacy protection. DoH is arguably a better mechanism than DoT for anybody whose primary focus is privacy (as has been discussed from many angles, many times) because the existence of the channel is obfuscated along with its content.

Joe

---

From: Eric Orth <[email-masked]>
Date: Thu, 1 Aug 2019 16:49:29 -0400

On Thu, Aug 1, 2019 at 1:59 PM Jacques Latour <[email-masked]>
wrote:

> omg-this-goes-against-everything-we’re-trying-do, but here it goes: a DoH
> operator should have a policy to blacklist IP address as requested by the
> network operator, since we can’t effectively block DoH at the edge of the
> enterprise network, an enterprise network should have the ability to
> request the well behaved DoH recursive operators to block requests coming
> from their network IP address.  Perhaps have some sort of trusted clearing
> house of IP addresses that the well behaved DoH recursive operators should
> blacklist from. Enterprises can block non well behaving DoH recursive
> operators.
>
>
>
> Since the major problems of DoH is for all to understand the
> multidimensional matrix of deployment models vs. value proposition vs. user
> (vantage) point of view, it’s almost impossible to assess the value
> proposition of the above example against all the currently
> possible/available scenarios. But we know that DoH has a negative value
> proposition for Enterprises.
>
>
>

I can't speak for any DoH server operators, but I would imagine most would
not be willing to trust a please-block-these-IPs/names signal unless the
agent sending the signal could prove it has authority over the user/device
making the request.  Could be very damaging for an enterprise's operations
if an unauthorized attacker can disrupt their access to websites the
enterprise wants to be able to access.  Maybe there's a way I'm missing,
but I'm having trouble thinking of any way for the blocking agent to prove
that authority without having control of the requesting user/device.  And
if any enterprise has that control, they should be able to just block
IPs/names from the device or control from there what DNS server is used.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 1 Aug 2019 23:11:02 -0700

On 8/1/2019 10:59 AM, Jacques Latour wrote:

> omg-this-goes-against-everything-we’re-trying-do, but here it goes: a
> DoH operator should have a policy to blacklist IP address as requested
> by the network operator, since we can’t effectively block DoH at the
> edge of the enterprise network, an enterprise network should have the
> ability to request the well behaved DoH recursive operators to block
> requests coming from their network IP address.  Perhaps have some sort
> of trusted clearing house of IP addresses that the well behaved DoH
> recursive operators should blacklist from. Enterprises can block non
> well behaving DoH recursive operators.

Not only does this come from the bad ideas department, but blocking at
the DoH operator is not going to scale, given the number of enterprise
policies. It also assumes the DoH operator can identify the enterprise
network from which the query originated, which is non trivial -- what if
the query arrives with DoH over Tor, for example?

If you want to enforce an enterprise policy, you are much more likely to
succeed at the local end point. I understand that Mozilla is willing to
use an heuristic to detect enterprise networks that would require
blocking DoH. If you don't trust that, your best bet is to enforce your
blocked lists through a browser plug-in, the same kind of plugin that is
also used for parental control. I suppose that security software
companies will be willing to provide such plug-ins.

-- Christian Huitema

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 2 Aug 2019 08:49:19 +0200 (CEST)

> companies will be willing to provide such plug-ins.

I don't see any way that any heuristic can work with the use-cases. You 
either trust the network or you don't. There is no way to say this with 
heuristics based on what the network says, GEO-IP or anything else.

1. Devices under Parental / enterprise control: You don't get to do that 
choice (choose if you trust the network or not, that's been chosen by the 
administrator)

2. Networks with pervasive surveillence due to local laws : Of course you 
want to be able to make that choice on your device, and either follow 
local law or not

3. Most other cases: There is no sensible default because we have no idea 
if the user trusts their ISP / network or not, or if they want to send 
their queries to a 3rd party DoH operator or not.

I'm in 3 and I want to be able to choose this based on network attachment 
(SSID for instance). This means the operating system network connection 
manager comes into play.

I don't see any other way to do all of this than to get the operating 
system vendor involved. This means to me that Android/Google, 
Windows/Microsoft, and Apple needs to come up with APIs to communicate 
this choice to the application if the application doesn't want to ask the 
user on a case-by-case basis.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 2 Aug 2019 10:52:14 +0100

神明達哉 <[email-masked]> wrote:
> > deploy DoH.

University not access network, but providing encrypted DNS to my users
means DoT for most cases and DoH for Firefox users. There's also the vague
notion from the early days of DoH that javascript in the browser might
make DNS queries but I haven't seen any evidence of that or even any
signs of interest in the idea.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Viking: Northerly 3 to 5. Slight or moderate. Mainly fair. Good,
occasionally poor at first.

---

From: "Robert Mortimer" <[email-masked]>
Date: Fri, 02 Aug 2019 12:17:19 +0100

Tony,

 Just on the javascript in browser making DNS queries, already been done to control a spam campaign.
https://www.bleepingcomputer.com/news/security/new-spam-campaign-controlled-by-attackers-via-dns-txt-records/ [https://www.bleepingcomputer.com/news/security/new-spam-campaign-controlled-by-attackers-via-dns-txt-records/]

So the bad guys at least are already doing this. They could of course use other methods etc. etc.

-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden
On 02/08/2019 10:53:31, Tony Finch <[email-masked]> wrote:
神明達哉 wrote:
> Stephane Bortzmeyer wrote:
> >

Tony.
--
f.anthony.n.finch http://dotat.at/
West Viking: Northerly 3 to 5. Slight or moderate. Mainly fair. Good,
occasionally poor at first.--
Add mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/add

---

From: Alec Muffett <[email-masked]>
Date: Fri, 2 Aug 2019 12:37:48 +0100

On Fri, 2 Aug 2019 at 12:18, Robert Mortimer <robm=
[email-masked]> wrote:

> https://www.bleepingcomputer.com/news/security/new-spam-campaign-controlled-by-attackers-via-dns-txt-records/
>

For anyone else who hasn't been through the archives, this one has already
been discussed on this maillist:

    https://mailarchive.ietf.org/arch/msg/add/6lkOu-0D6OWNfHwnsK7S1NkG6Oo

    https://mailarchive.ietf.org/arch/msg/add/OoEVkT3IdLnTqhBuE777MKPAlRo

- alec

--
http://dropsafe.crypticide.com/aboutalecm

---

From: Ted Lemon <[email-masked]>
Date: Fri, 2 Aug 2019 08:35:52 -0400

Someone in another thread pointed out that it’s too soon to create a wiki. This discussion is a clear example of why a wiki would be good. 

It’s fairly clear to me that there isn’t a clear understanding of the threat models for which mitigations are being discussed. Clearly describing the threat models we believe exist in a wiki would allow us to evaluate proposed solutions to see if they address these threat models. 

Right now we are discussing mitigations that have already been shown not to address actual threats, but because we aren’t documenting the discussion, that has been forgotten and so we are repeating ourselves. 

Sent from my iPhone

> On Aug 2, 2019, at 7:37 AM, Alec Muffett <[email-masked]> wrote:
> 
>> On Fri, 2 Aug 2019 at 12:18, Robert Mortimer <robm=[email-masked]> wrote:
> 
> For anyone else who hasn't been through the archives, this one has already been discussed on this maillist:
>

---

From: Simon Hicks <[email-masked]>
Date: Fri, 2 Aug 2019 13:42:03 +0100

>
> Indeed, a wiki allows us to assemble material and thoughts in one place,
> rather than repeat (and forget) the same arguments in an  email chain.  It
> does not presuppose the need, or not, for a group.   It just gets on one
> page the arguments and allows us to see what a group could do
>
Regards
Simon

On Fri, 2 Aug 2019 at 13:36, Ted Lemon <[email-masked]> wrote:

> Someone in another thread pointed out that it’s too soon to create a wiki.
> This discussion is a clear example of why a wiki would be good.
>
> It’s fairly clear to me that there isn’t a clear understanding of the
> threat models for which mitigations are being discussed. Clearly describing
> the threat models we believe exist in a wiki would allow us to evaluate
> proposed solutions to see if they address these threat models.
>
> Right now we are discussing mitigations that have already been shown not
> to address actual threats, but because we aren’t documenting the
> discussion, that has been forgotten and so we are repeating ourselves.
>
> Sent from my iPhone
>
> http://dropsafe.crypticide..com/aboutalecm
> <http://dropsafe.crypticide.com/aboutalecm>
>
> --
> Add mailing list
> [email-masked]

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 2 Aug 2019 17:17:12 +0200

On 8/2/19 11:52 AM, Tony Finch wrote:
> There's also the vague

RFC 8484 lists "two primary use cases", and this is one of the two,
though most of the DoH discussions have been around unblockability (i.e.
the other primary use case).

We (cz.nic) plan to soon release a new version of a browser plugin
reworked to utilize DoH: https://dnssec-validator.cz  The original
in-browser validation of DNSSEC got unfortunately killed by Firefox 57+
API changes, and we found it very difficult to do something like that
again with the new APIs, which is why DoH will be used instead to
out-source validation.

--Vladimir