Re: [DNSOP] EDNS0 clientID is a wider-internet question

[Christopher Morrow <[e-mail]>]

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 <[e-mail]
> wrote:

>
>
> On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon <[e-mail]> wrote:
>
>> On Jul 24, 2017, at 8:59 PM, Christopher Morrow <[e-mail]>
>> 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
>