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

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

Now, this isn't an issue for a situation in which the user has
explicitly enabled DoH with a preference or setting, because the user
has indicated they want that (just as if they installed a VPN). And I
agree that if the user has done that, then the client should insist on
DoH whatever the local network environment. This is more analagous
to the TLS 1.3 case where we know that the user wants TLS.

The more difficult situation, however, is if you want to switch the
client's defaults, in which case you risk changing the user's
experience in a way they didn't want, which is also suboptimal.  So,
it would be good to determine when that is the case and avoid doing
it/warn the user/something. In some cases, it's possible to do this in
a secure way (e.g., see if there are enterprise settings for a
specific resolver), but sometimes there is no local setting and I'm
not aware of a secure way to detect that case (I agree that the
mechanism in this draft is insecure). In this case, the problem seems
more difficult.

In any case, hopefully this clarifies the situation. If you have
good ideas for the best way to address the problem, I would certainly
be interested.

-Ekr

[0] We can debate who the user in parental controls cases is, but
general the parent is the one who owns the device.

On Tue, Jul 16, 2019 at 4:26 AM Alec Muffett <alec.muffett@gmail.com> wrote:

> On Tue, 16 Jul 2019, 11:31 Dixon, Hugh, <Hugh.Dixon@sky.uk> wrote:
>
>> Hi Alec –
>>
>
> Hi Hugh!
>
> Given that this is at its core (just) a protocol for asking (any) DNS
>> server whether it has a filtering policy, won’t “non-compliant software”
>> will be the sort of software which does not beacon?
>>
>
> That's kinda the whole point; the problem is that innocent people might
> try using Firefox to access Twitter from Turkey during a civil rights
> crackdown, their Firefox-implementing-this-mechanism will give them away as
> trying to evade Government blocking of Twitter, and they will end up
> arrested or worse.
>
> Not everyone is in a position to welcome or appreciate upstream DNS
> filtering "for their own good" - for instance, this example from Turkey:
>
>
> https://www.mic.com/articles/85987/turkish-protesters-are-spray-painting-8-8-8-8-and-8-8-4-4-on-walls-here-s-what-it-means
>
> It would seem regressive of Mozilla's principles to assist someone getting
> identified & thrown in jail for non-compliance with repressive blocking;
> not to mention - to repeat - the other obvious possibility is that any IP
> address which beacons-out a lookup of TBD.arpa will immediately be
> blackholed / firewalled, again to dissuade people from fact-checking their
> government's spokespeople.
>
> Or, perhaps you would consider this non-compliant-behaviour, worthy of
> such sanction?
>
> - alec
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>