darn, I keep reading 'client-id' as 'client subnet' :( back in my hole I go.
On Tue, Jul 25, 2017 at 9:53 AM, Christopher Morrow <morrowc.li...@gmail.com > wrote: > > > 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
