Re: [DNSOP] EDNS0 clientID is a wider-internet question
Robert Edmonds wrote: also, there's an app for that: https://play.google.com/store/search?q=dns%20changer%20no%20root 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
Paul Vixie wrote: > Robert Edmonds wrote: > > Paul Vixie wrote: > ... > > > 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. > > 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 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
Robert Edmonds wrote: Paul Vixie wrote: ... 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
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. signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
Paul Vixie wrote: > Paul Wouters wrote: > > 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? > > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
Paul Wouters wrote: 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? 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 specific clients and that's a reason to oppose adoption, as far as i'm concerned. 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". 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. >> http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/ 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
On 07/25/2017 01:07 AM, Paul Vixie wrote: > 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. 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
> On Jul 25, 2017, at 8:53 PM, Christopher Morrow > wrote: > > I don't believe the goal of the draft is to enable filtering. 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. signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
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 wrote: > > > On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon wrote: > >> On Jul 24, 2017, at 8:59 PM, Christopher Morrow >> 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
Re: [DNSOP] EDNS0 clientID is a wider-internet question
On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon wrote: > On Jul 24, 2017, at 8:59 PM, Christopher Morrow > 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
Re: [DNSOP] EDNS0 clientID is a wider-internet question
On Jul 24, 2017, at 8:59 PM, Christopher Morrow 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 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
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? 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
Jacob Hoffman-Andrews wrote: 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. 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: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
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 wrote: > > > >> On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon 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. >> > 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. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
On Thu, Jul 20, 2017 at 1:54 PM, Ted Lemon 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. > > 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
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.
Ted Lemon 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.
>
> On Thu, Jul 20, 2017 at 7:00 PM, George Michaelson wrote:
>
> > 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
> >
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Robert Edmonds
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
George, > On Jul 20, 2017, at 1:00 PM, George Michaelson wrote: > > 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. 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. With those things said, however: > > 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. > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] EDNS0 clientID is a wider-internet question
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 wrote: > 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 > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
