[gnso-rds-pdp-wg] Principle on Proportionality for "Thin Data"access
John Bambenek
jcb at bambenekconsulting.com
Tue May 30 23:24:31 UTC 2017
I mean if we're gonna go there, let's just hit the gas. IP addresses are
PII too
(http://moritzlaw.osu.edu/students/groups/is/files/2012/02/Lah_Formatted_Final.pdf)
which means DNS and RDS should be cognizant of that. I see the only
solution to this using the logic of some in this group is the immediate
deprecation of DNS and closing down the root servers. Privacy would be
dramatically increased in such a scenario.
On 05/30/2017 05:27 PM, allison nixon wrote:
> This leads me to my next question. Should members of the public be
> allowed to resolve DNS records at all without authentication and
> without prior authorization?
>
>
> >>Data that is gleaned from a file related to an individual, ie in
> this case their registration data, even if it is nameservers and the
> like, is their personal data
>
> Very good point. I applaud registrars who want to take a stand for
> privacy and stop sharing all nameserver data. It should remain
> completely private, so members of the public can stop resolving their
> domains.*
>
> *This compliment only applies to registrars in Spamhaus's list of top
> abused registrars. For the rest of you, if you want to do that you are
> essentially shutting down your entire business. If that is really what
> you want.............
>
>
>
> On Tue, May 30, 2017 at 6:19 PM, Chris Pelling <chris at netearth.net
> <mailto:chris at netearth.net>> wrote:
>
> Rob,
>
> As I said, it was a way of abuse. Not all DNS providers (or
> registrars for that matter) point out that the persons email
> address could be placed into the DNS zone file. Nor mentioning
> that it could be changed for that matter.
>
>
> Kind regards,
>
> Chris
>
> ------------------------------------------------------------------------
> *From: *"Rod Rasmussen" <rod at rodrasmussen.com
> <mailto:rod at rodrasmussen.com>>
> *To: *"Chris Pelling" <chris at netearth.net <mailto:chris at netearth.net>>
> *Cc: *"allison nixon" <elsakoo at gmail.com
> <mailto:elsakoo at gmail.com>>, "gnso-rds-pdp-wg"
> <gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>>
> *Sent: *Tuesday, 30 May, 2017 23:07:43
>
> *Subject: *Re: [gnso-rds-pdp-wg] Principle on Proportionality for
> "Thin Data"access
>
> Sorry, that’s not likely a valid example. That information is
> made public by publishing it in the DNS in the first place, by the
> direct decision of the publisher (DNS operator). If the
> nameserver records aren’t in the DNS, the domain doesn’t work and
> if the nameserver records aren’t in the DNS, you can’t get the SOA
> record. All I need is the domain name to start with, dig the
> nameservers for the domain, and then dig the SOA. Importantly, I
> DO NOT NEED “whois” or anything else similar to get to these data
> records, so these are all public data points that anyone can
> anonymously access at any scale for all operational domains on the
> Internet. Publishing the same data (nameserver related to domain)
> in a different database (whois, RDS, whatever) doesn’t make it
> more public - it’s been put out there already.
>
> For those of you not familiar with the intricacies of how DNS SOA
> (Start of Authority) records work, the third entry on each line in
> the examples below is actually an e-mail address, where the first
> dot should be replaced by an “@“ symbol. So for the first one,
> the e-mail address for the entity claiming authority over the
> gmail.com <http://gmail.com> zone is dns-admin at google.com
> <mailto:dns-admin at google.com>. As Chris mentioned, these are
> going to largely be technical contacts, but not always. However,
> that’s the purpose for the field - technical authority over the
> zone, so putting your “personal” information into that field would
> mean you want to publicly publish your e-mail address in the DNS
> so anyone can reach it. I don’t think we’re trying to tell people
> to *not* do things like that in this WP. Regardless, you have to
> supply a validly formatted SOA record for DNS to work, including
> an entry that is plausible as an e-mail address for that field.
> That doesn’t require the e-mail address to be answered, monitored,
> or even deliverable, so you could put test.test.com
> <http://test.test.com> (test at test.com <mailto:test at test.com>) in
> there if you don’t want things to be sent to you. If I remember
> right, some ccTLD’s would require that you actually answer a query
> to the SOA e-mail “back in the day” to delegate your domain - not
> sure if any do anymore. For far more arcane trivia around SOA
> records etc. see the wikipedia entry
> (https://en.wikipedia.org/wiki/SOA_Resource_Record
> <https://en.wikipedia.org/wiki/SOA_Resource_Record>) or this handy
> tutorial (https://bobcares.com/blog/understanding-soa-records/
> <https://bobcares.com/blog/understanding-soa-records/>). It goes
> all the way back to the original DNS spec in RFC 1035.
>
> Cheers,
>
> Rod
>
>
> On May 30, 2017, at 2:22 PM, Chris Pelling <chris at netearth.net
> <mailto:chris at netearth.net>> wrote:
>
> ok - a thought :
>
> Thin data includes nameservers, being able to *mass* collect
> thin data gaining NS information then allows you to do a DIG
> of a SOA record on the DNS service to gain the email address
> of the hostmaster :
>
> Some examples (radomly picked from the list) :
> gmail.com <http://gmail.com> :
> SOA ns1.google.com <http://ns1.google.com>.
> dns-admin.google.com <http://dns-admin.google.com>. 157458041
> 900 900 1800 60
> netearthone.com <http://netearthone.com>
> SOA ns1.netearth.net <http://ns1.netearth.net>.
> root.netearthone.com <http://root.netearthone.com>. 2016090201
> <tel:%28201%29%20609-0201> 14400 3600 1209600 86400
> law.es <http://law.es>
> SOA ns1.eurodns.com <http://ns1.eurodns.com>.
> hostmaster.eurodns.com <http://hostmaster.eurodns.com>.
> 2016061402 <tel:%28201%29%20606-1402> 43200 7200 1209600 86400
> riskiq.net <http://riskiq.net>
> SOA ns-1754.awsdns-27.co.uk
> <http://ns-1754.awsdns-27.co.uk>. awsdns-hostmaster.amazon.com
> <http://awsdns-hostmaster.amazon.com>. 1 7200 900 1209600 86400
>
> Now as you can see - those above examples allow you to get (or
> build) an email list. Most will normally point to the
> providers service, but, some that are DIY'ing their hosting,
> it might not be.
>
> Kind regards,
>
> Chris
>
> ------------------------------------------------------------------------
> *From: *"allison nixon" <elsakoo at gmail.com
> <mailto:elsakoo at gmail.com>>
> *To: *"nathalie coupet" <nathaliecoupet at yahoo.com
> <mailto:nathaliecoupet at yahoo.com>>
> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Sent: *Tuesday, 30 May, 2017 21:52:32
> *Subject: *Re: [gnso-rds-pdp-wg] Principle on Proportionality
> for "Thin Data"access
>
> so can you name one specific example of how someone could
> abuse thin data?
>
> On Tue, May 30, 2017 at 4:50 PM, nathalie coupet via
> gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>> wrote:
>
> *Abuse* is the improper usage or treatment of an entity
> <https://en.wikipedia.org/wiki/Entity>, often to unfairly
> <https://en.wikipedia.org/wiki/Distributive_justice> or
> improperly gain benefit. In our context, abuse is the
> improper usage of WHOIS/RDS to unfairly or improperly gain
> access to information or to game the system.
>
> Here are some of the overarching principles which should
> guide us when building RDS:
>
> DATA LIFECYCLE PRIVACY PRINCIPLE
> PROTECTION MEASURE
> Collection Proportionality and
> purpose specification Data
> minimisation, Data quality
> Storage Accountability, Security
> measures, Sensitive data Confidentiality,
> Encryption, Pseudonomisation
> Sharing and processing Lawfulness and fairness, Consent,
> Right of access Data access control, Data leakage prevention
> Deletion Openness, Right to
> erasure Retention,
> Archival, Erasure
>
>
> If such principles are not respected, ICANN will be
> liable. Consumers don't need to have all the thin data
> when making a query. This could protect them and enable
> them to have access to the RDS without raising much
> opposition.
>
> Now, we could discuss the possibility for broader query
> types. These principles would still apply, but would be
> contextualized in order to take into account new sets of
> parameters for each broader query. By increasing
> granularity as much as possible, while applying these
> aformentioned principles, we just might find a way to
> accomodate everyone.
>
>
>
> Nathalie
>
>
> On Tuesday, May 30, 2017 4:00 PM, John Horton
> <john.horton at legitscript.com
> <mailto:john.horton at legitscript.com>> wrote:
>
>
> I was going to reply to Natalie's email as well, but
> Paul's comments capture my thoughts, so: *+1. *
>
> John Horton
> President and CEO, LegitScript
>
>
> *FollowLegitScript*: LinkedIn
> <http://www.linkedin.com/company/legitscript-com> |
> Facebook <https://www.facebook.com/LegitScript> |
> Twitter <https://twitter.com/legitscript> | Blog
> <http://blog.legitscript.com/> | Google+
> <https://plus.google.com/112436813474708014933/posts>
>
>
>
> On Tue, May 30, 2017 at 12:57 PM, Paul Keating
> <paul at law.es <mailto:paul at law.es>> wrote:
>
> Natalie,
>
> Thank you for the email. Im copying the list because
> i see others have replied to your comment.
>
> I strenuously object to the concept. We are
> discussing THIN DATA ONLY HERE. Unless someone can
> explain to me why any of this data set has privacy
> concerns this is a non-issue. I would certainly
> appreciate someone explaining what, if any, privacy
> issues are perceived to be at issue here.
>
> Moreover, while you suggest that the idea escapes the
> need to declare a purpose, it does nothing but
> reinforce a subjective criteria based system in which
> the declared purpose is used to somehow limit the data
> being retrieved.
>
> If i am missing something please let me know.
>
> Paul
>
> Sent from my iPad
>
> On 30 May 2017, at 21:08, nathalie coupet via
> gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>> wrote:
>
> Hi Paul,
>
> In the context of thin data, in view of the
> opposition of some to allow unauthenticated access
> to all the thin data, the principle of
> proportionality serves as an over-arching
> principle at this particular phase in our work in
> order to protect data from abuse while not
> restricting access.
> Thin data must be proportionate to the query, be
> useful for that particular query. All and any
> other thin data foreign to this query should not
> be shared. This principle potentially avoids
> having to resort to 'legitimate purposes' which
> cannot be verified for unauthenticated access.
>
>
> Nathalie
>
>
> On Tuesday, May 30, 2017 2:44 PM, "Gomes, Chuck
> via gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>> wrote:
>
>
> Because Nathalie was the originator and was unable
> to speak on the call, I encourage her to describe
> the nature of the issue on this thread.
>
> Chuck
>
> *From:*gnso-rds-pdp-wg-bounces at icann. org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>
> [mailto:gnso-rds-pdp-wg- bounces at icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>] *On
> Behalf Of *Paul Keating
> *Sent:* Tuesday, May 30, 2017 2:17 PM
> *To:* Lisa Phifer <lisa at corecom.com
> <mailto:lisa at corecom.com>>; RDS PDP WG
> <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg]
> Principle on Proportionality for "Thin Data"access
>
> Im sorry to have missed the call but had a client
> engagement.
>
> Can someone briefly describe the nature of the issue?
>
> Thanks
> Paul
>
> *From: *<gnso-rds-pdp-wg-bounces@ icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>> on
> behalf of Lisa Phifer <lisa at corecom.com
> <mailto:lisa at corecom.com>>
> *Date: *Tuesday, May 30, 2017 at 7:52 PM
> *To: *RDS PDP WG <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Subject: *[gnso-rds-pdp-wg] Principle on
> Proportionality for "Thin Data"access
>
>
> All, per today's call action item:
>
> *Action Item: Nathalie Coupet and any other WG
> members who wish to do so to propose to the WG
> list a new principle on proportionality for
> "thin data." All WG members to comment on that
> proposed principle in advance of next call.
>
> *we are starting a new thread here which
> anyone may reply to if they wish to propose
> (or respond to) a new principle on
> proportionality for "thin data" access.
>
> Best, Lisa
> ______________________________
> _________________ gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/
> listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
> ______________________________ _________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/
> listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
> ______________________________ _________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/
> listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
> ______________________________ _________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
>
>
> --
> _________________________________
> Note to self: Pillage BEFORE burning.
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
>
>
>
>
> --
> _________________________________
> Note to self: Pillage BEFORE burning.
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170530/6283d2cd/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list