[gnso-rds-pdp-wg] ICANN Blog re Session with European DPAs

[Rubens Kuhl]

> On 30 Mar 2018, at 13:08, jonathan m <jonathan.matkowsky at riskiq.net> wrote:
> 
> Hi Chuck—I’d like to get a discussion going if that’s okay with you. I’d like to know whether for the public data set, it is feasible to have the following solution for the registrant email. It’s based in part on both technical implications and policy requirements.

While the discussion sounds more like a GDPR discussion than an RDS discussion, there is always something that might be applicable to the PDP. For the GDPR part of this discussion, writing to the specific ICANN section sounds more productive.


> 
> 1) Registrar required to notify registrants that starting on x date, the registrant org field will be relied on for purposes of treating the Whois record as an organizational domain rather than as belonging to a natural person. Check your record for accuracy because it may have implications for your privacy if you do not already have or subscribe to proxy or privacy services. A few reminders go out. Educate registrants they may want to update to “Domain Admin” instead of having their first and last name for organizational domains because starting on x date, existing organizational records will otherwise obfuscate or mask the local part of the registrant email in public Whois

While a policy implementation can specify a transition period and triggers, the elevated number of gTLD registrations suggest that to be an Hercules work. Issues with this type of procedure include outdated e-mail addresses, fake messages pretending to be the real thing etc.

> 
> 2) For organizational domains, ICANN will prohibit masking the organizational domain name in the registrant email address. Registrars are free to mask the local part of the registrant email address in accordance with applicable law in the public Whois.

If that is done with a different syntax, they it could work. For instance, REMOVED at example.com <mailto:REMOVED at example.com> would look a valid e-mail address, so that should be avoided. REMOVED at example.com <http://example.com/> would be better.

> 
> 3) for natural persons, registrars will be required to use the same encrypted hash algorith so there is parity across databases even though there is no centralized database to manage the encryption. The policy will be enforced by ICANN and subject to auditing. They can warn registrants of the associated risks of compromise to give them a chance to take added precautions and purchase proxy or privacy services.

This assumes that allowing others to correlate domains registered by the same e-mail address is not a violation of privacy rights. This is very debatable, and I've seen both angles being advocated for.

On the cryptography part, I believe that this unsalted encrypted hash applied to such a large number of objects will be too weak, requiring constant updating. Some type of asymmetric encryption would likely be more appropriate for the task, although expanding the response size quite a bit.

> 
> This would be the minimum requirements for modifying public Whois registrant email address to avoid damaging the security and stability of the unique identifiers and DNS.

This is yet another attempt to confuse security and stability of the identifier system with security of applications using this identifier system such as Web and e-mail. While ICANN and ICANN community needs to be aware of the security implications of RDS choices, they do not impact security and stability of the identifier system. There is a continued attempt to equate the two, but that doesn't hold. It doesn't mean ICANN gTLD policies can't try taking it into account; for instance, if a gTLD policy would bring poverty and hunger to the world, we should avoid doing so. But this is different from being tasked with eliminating poverty and hunger.


> If the downside of doing this is prohibitive, than ICANN should seek guidance in the April meeting on whether the public interest in not damaging security and stability outweighs the privacy interference of having email addresses remain in the phone books given its not a particularly strong personal indicator to begin with as privacy and proxy services are available to those that mind as long as they are notified.

This sounds more like a GDPR discussion than a PDP discussion, again. I believe the WG is fully capable already of discussing this topic, either thru the list or thru calls if this topic gets into the agenda.

> 
> This would result in emails in Whois of natural data subjects being uniformly hashed so that you can freely see which hash owns what, and Whois of organizations being freely listed with any local part of such organizational emails being masked if required by applible law.

See above.

> 
> I would like to hear a discussion on this from the group this week. Not on the legality of it under GDPR as the Article 29 working group can weigh in but first we need to discuss the architectural and policy issues.

I believe the GDPR exercise will be very instructive in providing legal basis to do things one way, or legal basis to not things another way. Still, there might be some gray areas not covered by such basis requiring further enlightenment on its legality in jurisdictions across the world. We might have to wait to see which is which.


Rubens




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180330/f56c076d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20180330/f56c076d/signature-0001.asc>