Subject: [Add] thinking in new directions -- draft-hardaker-dprive-add-doh-dnsop-filter-request

From: Wes Hardaker <[email-masked]>
Date: Fri, 27 Sep 2019 14:12:34 -0700

I spent some time trying to see what else we could do to better support
all parties in an ADD world.  I wrote up the following in an effort to
spur thinking in new directions.  You'll probably hate it :-)

https://datatracker.ietf.org/doc/draft-hardaker-dprive-add-doh-dnsop-filter-request/

-- 
Wes Hardaker
USC/ISI

---

From: Paul Ebersman <[email-masked]>
Date: Sat, 28 Sep 2019 09:35:34 -0600

wjhns1> I spent some time trying to see what else we could do to better
wjhns1> support all parties in an ADD world.  I wrote up the following
wjhns1> in an effort to spur thinking in new directions.  You'll
wjhns1> probably hate it :-)

I don't hate it but I think it's the tail wagging the dog.

Expecting individual device users to be network admins and security
experts is never going to scale. It's why real informed consent is so
hard (if not a myth).

Individuals don't design blueprints for their own houses, build their
own cars, perform surgery on themselves or act as their own lawyers
(hopefull). At some point, we choose to "trust" an expert to do
complicated things or make complicated decisions for us.

One of the key things we keep bumping into here and other places
discussing DoH is who those experts making default choices are and to at
least give users the chance to pick that expert (or alert the user that
the app is choosing something different so they get some chance to
object).

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 28 Sep 2019 21:13:02 -0700

> experts is never going to scale. It's why real informed consent is so

I actually think that it's more likely users will get their policy
bundled with some other software.  IE, they install an anti-virus
package and one of the things it does is configure the local OS policy
to request the anti-virus black list in outgoing DNS requests.

So yes, we need to handle the case where people
won't/can't/don't-understand the details, but they do understand
companies they trust and have *choices* about what company they want to
trust to make their privacy decisions.

> the app is choosing something different so they get some chance to

Note that multiple TRR selections would already let users pick a TRR
with the right policy.  The point of my suggestion was to try and stop
tying part of the "trusted" with the "resolver" and separate the
functionality.

-- 
Wes Hardaker
USC/ISI

---

From: Will Hawkins <[email-masked]>
Date: Mon, 30 Sep 2019 02:35:18 -0400

> trust to make their privacy decisions.

I agree with you both: users may not necessarily want to (or be able
to) configure their resolver to use lists like this but the software
that those users trust (e.g., AV software, as Mr. Hardaker said) may
do so.

Would a potential compromise make sense: In addition to offering this
option as a way to point to filter lists, this option can be used to
point to locations that will, in turn, set the filter lists? The
benefit may be that the feature is easier for the end user to
configure *and* the delegate organization can maintain an up-to-date
list of filter lists on behalf of its users.

Just a thought ... I'm sure that's is stupid, has shortcomings or has
already been discussed.

> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 30 Sep 2019 14:34:54 +0200 (CEST)

> Il 27 settembre 2019 23:12 Wes Hardaker <[email-masked]> ha scritto:
> 
>  

Thanks for daring to do this :-)

My feeling is also that standardization work in the field of expressing, communicating and implementing DNS filtering lists would help many use cases (by the way, there already is a de-facto standard for a good part of this, i.e. RPZ, so it should be part of the picture). However, we also know that some people here believe that DNS filtering is always wrong, even when requested by the user. We could still have a standard for those that want to use it, though.

Also, you'd possibly need to flesh out a relatively complex architecture. For example, there are cases in which the compiler of the filtering list does not want to make it accessible to everyone, and there could be attacks based on forging/spoofing legitimate lists, so you would want to have authentication, channel security and access control. 

Then, there is the issue of which filters should be applied, which is a policy and regulatory one; resolver operators could honor the user's request for a given filter, but at the same time they might want to do their own malware filtering on top of it, or they might be required by law to block yet other stuff. So the communication of active filtering frameworks could go in both directions.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy