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

[Joe Abley <[e-mail]>]

Hi Jacques!

> On 1 Aug 2019, at 13:59, Jacques Latour <[e-mail]> 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.
> 
> 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.

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