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

From: George Michaelson <[email-masked]>
Date: Thu, 20 Jul 2017 19:00:23 +0200

I probably will not carry the WG with me on this, but I find myself
thinking the PII aspect of client-ID makes it a wider-internet
question and we might have views as a WG, and promote questions as a
WG, but I think the "final call" on this is something which needs more
than WG approval.

Its a big question. I'd actually welcome adoption on many levels, but
that isn't to pre-empt that it goes to WGLC. I think we need to
formalize the issues and take them out of the WG for review and
discussion.

documenting current practice is ok btw, but .. PII.

-G

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jul 2017 19:54:03 +0200

It would be nice if there were an RFC to point to that used a method that
didn't include PII.   For the use cases of which I am ware, there is no
need to identify individual devices: only policies.   What's lacking is a
way to do this in the home router, so the PII winds up getting exported to
the cloud not because that's necessary to accomplish the filtering but
because it's the only available place where the translation from
PII->policy can be done in practice.   Unfortunately, solving _that_
problem is definitely out of scope for DNSOP.

On Thu, Jul 20, 2017 at 7:00 PM, George Michaelson <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 21 Jul 2017 05:13:41 -0400

George,

> On Jul 20, 2017, at 1:00 PM, George Michaelson <[email-masked]> wrote:
> 

A couple of points of precision on this: first, I’m not sure “PII” is rigorously defined in our context, so we might need to be more specific on that (although I agree with the intuitive sense you seem to have about it).

Second, technically the WG doesn’t approve publication of a document anyway; a decision by the WG to advance a particular document along the process is neither necessary nor sufficient to get it published; there are several additional steps to publication approval.

> documenting current practice is ok btw, but .. PII.

Agreed there are some aspects here that need cross-area review, and making sure that happens is part of the chairs’ followup from discussion of the draft to date.

Suzanne

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 24 Jul 2017 19:44:16 -0400

RFC 7217 ("A Method for Generating Semantically Opaque Interface
Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)") is
sort of relevant. From the introduction of that document, which
describes drawbacks of traditional IPv6 SLAAC addresses:

   o  Since the resulting Interface Identifiers are constant across
      networks, the resulting IPv6 addresses can be leveraged to track
      and correlate the activity of a host across multiple networks
      (e.g., track and correlate the activities of a typical client
      connecting to the public Internet from different locations), thus
      negatively affecting the privacy of users.

That drawback translates pretty much directly to the 48-bit MAC
CLIENT-IDENTIFIER variant in draft-tale-dnsop-edns0-clientid.

For the dnsmasq use case, I would guess there's a CPE router/gateway
device involved, in which case the CPE device has a unique
device-specific value burned in (e.g., a WAN-facing MAC address, or
serial number) which could easily be hashed together with the client's
MAC address to produce a stable but opaque identifier specific to the
particular CPE device involved. (That is, if the client device travels
to a different network gatewayed by a CPE device implementing the same
scheme, the identifier generated would be different, because the CPE
device has a different WAN-facing MAC address.) So, the cloud would
still wind up executing the PII -> policy translation, but you take the
'P' out of 'PII', and don't need to store any extra state on the CPE
device.

-- 
Robert Edmonds

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 24 Jul 2017 20:59:05 -0400

On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon <[email-masked]> wrote:

> isn't the query path here: (largely)
  client  -> cpe-router -> provider-cache-resolver -> auth-dns

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.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Jul 2017 09:23:16 +0200

And then there are mobile phones with wifi and LTE tracking, already massively abused by AP's and companies like Apple are randomising macs.

This draft is good for the ad business, not good for the enduser.

Paul

Sent from my iPhone

> On Jul 25, 2017, at 02:59, Christopher Morrow <[email-masked]> wrote:
> 
> 
> 
>> It would be nice if there were an RFC to point to that used a method that didn't include PII.   For the use cases of which I am ware, there is no need to identify individual devices: only policies.   What's lacking is a way to do this in the home router, so the PII winds up getting exported to the cloud not because that's necessary to accomplish the filtering but because it's the only available place where the translation from PII->policy can be done in practice.   Unfortunately, solving _that_ problem is definitely out of scope for DNSOP.
>> 
> 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.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 25 Jul 2017 00:51:04 -0700

I agree: The EDN0 Client ID draft seems quite bad from a privacy
perspective, and I believe it should not be adopted.

More broadly, enforcing content blocks with DNS is an anti-pattern. If
we're assuming that the entity doing the content blocking has
administrative access to DNS clients, they can simply install content
blockers there. That allows much finer-grained blocked, like blocking
individual pages rather than having to block all of Tumblr because of a
request to block a single page.

The draft even acknowledges the ineffectiveness of DNS-based content
blocking:

>   DNS filtering products are easy circumvented and should not be
>   considered real security measures.  With commonly available tools it
>   is trivial to discover the non-filtered DNS responses and use them in
>   place of the filtered responses.

So it seems incorrect to propagate a privacy-harming DNS extension that
is ineffective at its stated goals.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 25 Jul 2017 01:07:49 -0700

Jacob Hoffman-Andrews wrote:
> blockers there.

i think content blocking is a reach -- in your interpretation.

this is about CDN. as in, how to decide which address record set to give 
a dns client, given that all you know is the recursive server address, 
yet you're trying to implement policy for an expected tcp session that 
might immediately follow.

> ... The draft even acknowledges the ineffectiveness of DNS-based content
> blocking:
>

your reasoning is flawed. there are indeed privacy problems here. the 
data miners and data scientists and aggregators of the world will have a 
much better idea which end user a dns request was generated for, in the 
case where all they see is above the recursive not below, and this 
option is used. that's a fine reason to oppose adoption.

but it's got precious little to do with content filtering. as i wrote in 
a recent circleid article, dns-level content filtering will only work 
when end users believe that the recursive name server operator has 
aligned interests, and for that reason one shouldn't say "it's easy to 
bypass" but rather "end-user cooperation is required."

this draft would be more adoption-worthy if it used similar language.

see also:

http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Jul 2017 04:22:28 -0400 (EDT)

On Tue, 25 Jul 2017, Paul Vixie wrote:

> users believe that the recursive name server operator has aligned interests, 
> and for that reason one shouldn't say "it's easy to bypass" but rather 
> "end-user cooperation is required."

So if 8.8.8.8 and your local ISP's nameserver do this to track you, what
choice does an average enduser have?

> might immediately follow.

This draft, unlike ECS, is about pinning individual users and tracking
them. You saying this is needed for an optimized CDN based TCP stream
is not fairly covering the use case of gathering PII.

 	Because this option trasmits information that is meant to identify
 	specific clients

You should really have said "This draft attempts to link the DNS query
to the individual TCP stream following to identify the specific user,
to then apply specific filtering/censoring/protecting policies to the
identified individual users (eg children, dissidents) for their own
good".

If you just wanted CDN optimalization, the ISP recursive server could
simply use ECS.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Jul 2017 05:55:10 -0400

> 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 th…

There is no such thing as an upstream authoritative cache.   The filtering is being 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 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.

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

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.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 25 Jul 2017 09:53:18 -0400

On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon <[email-masked]> wrote:

> 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

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 25 Jul 2017 10:38:31 -0400

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 <[email-masked]
> wrote:

>> There is no such thing as an upstream authoritative cache.   The
>> filtering is being
>>
>
>> 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.
>
>

---

From: Barry Raveendran Greene <[email-masked]>
Date: Tue, 25 Jul 2017 21:44:42 +0700

> On Jul 25, 2017, at 8:53 PM, Christopher Morrow <[email-masked]> wrote:
> 

The goal of the draft is to provide options. How those options are deployed is between the customer and the operator as defined by their contract.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 25 Jul 2017 11:29:53 -0700

On 07/25/2017 01:07 AM, Paul Vixie wrote:
> this is about CDN. as in, how to decide which address record set to
> give a dns client, given that all you know is the recursive server
> address, yet you're trying to implement policy for an expected tcp
> session that might immediately follow.
Perhaps I'm reading the wrong RFC? I was basing my comments on
https://tools.ietf.org/html/draft-tale-dnsop-edns0-clientid-01, which
very explicitly talks about content blocking:

> For example, a parental control service that restricts access to
particular domains from particular devices needs to have a
device-specific identifier.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 25 Jul 2017 12:26:32 -0700

Paul Wouters wrote:
>> users believe that the recursive name server operator has aligned
>> interests, and for that reason one shouldn't say "it's easy to bypass"
>> but rather "end-user cooperation is required."
>

some of run our own rdns. some use vpn's. some use opendns or similar.

> Because this option trasmits information that is meant to identify

and that's a reason to oppose adoption, as far as i'm concerned.

> identified individual users (eg children, dissidents) for their own

that's a significant overstatement. the user is more likely to send an 
http cookie than to have the rdns server send a per-user ID on their 
behalf. moreover, parental controls are a fig leaf, almost a joke, and 
so is dns-level filtering. as i wrote the other day:

<< I fought SOPA not because I believed that content somehow "wanted to
be free", but because this kind of filtering will only be effective
where the end-users see it as a benefit — see it, in other words, as
aligned with their interests. >>

when you invoke "for their own good" you're worrying about internet 
unilateralism that does not actually or in any effective way exist.

if tale wants to create a signaling pattern that's so bypassable that 
noone will ever use it unless they want its impacts, let him.

-- 
P Vixie

---

From: Robert Edmonds <[email-masked]>
Date: Tue, 25 Jul 2017 16:41:58 -0400

> some of run our own rdns. some use vpn's. some use opendns or similar.

The internet now has billions of users. With the possible exception of
OpenDNS who have gone to admirable lengths to populate their knowledge
base with device-specific configuration instructions [0], I don't think
any of the choices you've listed are available to the "average enduser",
who almost by definition lacks the specialized technical knowledge
needed to select an alternative DNS resolution provider.

[0] https://support.opendns.com/hc/en-us/categories/204012907-OpenDNS-Device-Configuration

-- 
Robert Edmonds

---

From: Barry Raveendran Greene <[email-masked]>
Date: Wed, 26 Jul 2017 08:00:07 +0700

The irony to the privacy and client-id discussion is that we have another “DNS Privacy” WG which gives me wonderful ID from the crypto termination on the resolver.

The reality with client ID is just like RPZ adoption. Operators need flexibility to face reality. If the DNSOP’s choice is to not face reality, so be it. The code will still get deployed. Operators will still drive adoption.

The choice is to have client ID and RPZ in the working group process.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Jul 2017 13:18:58 -0700

> Paul Vixie wrote:
...
> needed to select an alternative DNS resolution provider.

italy's experience in blocking unlicensed online gambling sites proved 
otherwise, as would would SOPA had it passed. any rDNS service that 
blocks lookups in a way that does not align with a user's interests, 
will not be used, other than to locate the nec'y bypass recipes. most of 
those recipes do not require deep technical knowledge.

a minute or so of searching turned up these:

https://www.howtogeek.com/167533/the-ultimate-guide-to-changing-your-dns-server/

https://support.hidemyass.com/hc/en-us/articles/202720776-Changing-your-DNS-settings-on-Windows-Mac-Android-iOS-Linux

also, there's an app for that:

https://play.google.com/store/search?q=dns%20changer%20no%20root

foot-on-neck disease, and unilateralism in general, have never been 
practical where the internet was involved. humans are only sheep-like 
when presented with a politician's lies. if you try to take away their 
porn or gambling or $whatever, they will balk, and become thuggish.

-- 
P Vixie

---

From: Robert Edmonds <[email-masked]>
Date: Wed, 26 Jul 2017 16:35:30 -0400

Paul Vixie wrote:
> otherwise, as would would SOPA had it passed. any rDNS service that blocks
> lookups in a way that does not align with a user's interests, will not be
> used, other than to locate the nec'y bypass recipes. most of those recipes
> do not require deep technical knowledge.
> 

Yes, you and I are well aware that there are apps and howtos for
changing DNS settings available online. If you can find, read, and
execute one of those guides -- congrats, you're not an average user.

-- 
Robert Edmonds

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Jul 2017 14:01:36 -0700

> execute one of those guides -- congrats, you're not an average user.

i think that when 8.8.8.8 started getting spray painted on walls during 
political upheaval, the average user's capabilities were changed.

see also the GFW which has made bypass expertise common within china.

see also italy, where the gov't mandated dns-level filtering by all 
isp's of known-to-not-pay-taxes online gambling sites. gamblers shared 
information about what 8.8.8.8 was and how to reach it, in online forums.

cussedness can be predicted, and in this case, relied upon. people learn 
what they have to learn. the average, can change.

-- 
P Vixie