Re: [Add] [EXTERNAL] Re: draft-grover-add-policy-detection-00

[Michael Sinatra <[e-mail]>]

On 7/16/19 8:38 AM, Eric Rescorla wrote:
> 
> 
> On Tue, Jul 16, 2019 at 8:24 AM Rob Sayre <sayrer@gmail..com 
> <mailto:[e-mail]>> wrote:
> 
> 
> 
>     On Tue, Jul 16, 2019 at 7:22 AM Eric Rescorla <ekr@rtfm..com
>     <mailto:[e-mail]>> wrote:
> 
>         Hi Alec,
> 
>         This is a good question.
> 
>         As I alluded to in my response to Robert Sayre, DoH has a difficult
>         deployment problem. Specifically, whether we like it or not,
>         there are
>         some environments in which DNS filtering is in place and the user
>         wants it that way (parental [0] or anti-malware filtering are good
>         examples of this).
> 
> 
>     Parental controls and malware detection are usually done on the device.
> 
>     https://www.apple.com/newsroom/2019/04/the-facts-about-parental-control-apps/
>     https://blog.google/products/chrome/cleaner-safer-web-chrome-cleanup/
> 
> 
> They are often done, but not always. For instance:
> https://www.xfinity.com/support/articles/set-up-parental-controls-with-comcast-networking
> https://www.quad9.net/faq/#How_does_Quad9_protect_me_from_malicious_domains

Also, note that parental controls are but one use-case.  There are a 
number of enterprises which require DNS-based filtering, *in addition 
to* other controls on the endpoint.  The entire USG and many of its 
contractors are required to do DNS filtering.  Many organizations that 
provide grants to educational institutions have conditions that the 
recipient of the grant must make efforts to "block porn" (and yes, 
that's about the extent of the definition).  DNS filtering is a very 
reasonable way of complying.  Institutional DNS filtering works well 
with DoT configured at the system level on the stub resolver, and 
supported by the institution.  DoH can be made compatible with 
institutional filtering requirements, but it can also easily skirt those 
requirements: the devil is in the defaults.

Mozilla, with its documented plans to circumvent institutional DNS with 
Mozilla-blessed services running DoH, exemplifies the case where the 
default behavior is going to be incompatible with institutional 
requirements and regulatory frameworks.  The result is predictable: 
Where endpoints are under strict control, Mozilla will be uninstalled 
and effectively banned.  Where endpoint controls are not as strict, 
attempts will be made to block well-known DoH services.  This is already 
being done in some sectors.

Unless we find ways of making DoH compatible with institutional 
controls, the banhammer will come down and we will end up in an arguably 
worse spot (think proxy decryption of all HTTPS, banning of certain 
browsers, blocking of well-known services, etc.).  Personally, I don't 
want that to happen, but I fear it will if we don't make DoH more 
flexible by default.

michael