On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon <mel...@fugue.com> wrote:

> On Jul 24, 2017, at 8:59 PM, Christopher Morrow <morrowc.li...@gmail.com>
> wrote:
>
> and at the cache->auth layer it's potentially the case that the provider
> can say: "use precision of /24" or "use precision of /17" ? So, there's
> really not much "pii" that can be worried over at the
> provider-cache-resolver (they already know who you are...) and they
> (provider) can decide how much granularity is "important" to release to the
> upstream authoritative cache.
>
>
> There is no such thing as an upstream authoritative cache.   The filtering
> is being
>

apologies, 'upstream (from the cache resolver's perspective) authoritative
SERVER'.


> done at the cache.   This is not client subnet: this is client ID.   So
> the cache, which is not authoritative, is receiving PII about a specific
> client machine.   Being able to
>

I agree with this, the cache resolver sees the client's IP address.


> filter the PII at the CPE would indeed improve privacy in this case; the
> problem is that the CPE has to have a UI or API that allows that to happen,
> and they don't.
>
>
I don't think the CPE is the answer, the cache-resolver CAN decide to send
along in it's edns0 option: "1.2.128.0/17" instead of "1.2.3.0/24". Or it
seems to me that this is a fine knob to add to resolver software... granted
you'd need some extra config about your client subnets in use.


> The reason DNS filtering is useful is not that it is forced upon the end
> user, but that it allows devices that use the default cache to get
> filtering in a way that does not
>

I don't believe the goal of the draft is to enable filtering.
Certainly for a nation-state actor you could see: "Oh, now I know what
subnets use the resolver over there, so I can limit useful replies, or
steer requestors toward 'better/approved' content'


> depend on the software installed on them.   So e.g. your IoT device can be
> infected by a worm but not actually exfiltrate any private information to
> the attacker, because the attacker's DNS is blocked.
>
>
you seem to be conflating a few things here... or using 'content filtering'
in a different way here than before in this response.


> Being able to know that a particular device is a particular device is
> actually quite useful in this context; unfortunately, there is no way to
> distinguish "useful" and "personally-identifying".   Even if you only
> identify the IoT devices in your home, by doing so you reduce the search
> space for identifying the other devices.
>
>
I don't think the draft is aiming at 'device' as much as 'region of the
network'. The cache resovler COULD choose to send /32 (or /128) level data
in the edns0 option, but that seems counterproductive, and a bit invasive.

-chris
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to