<div dir="ltr"><div dir="ltr">In my view, GDPR is just the most visible but not the only attempt by governments to protect the privacy of its citizens. There's a privacy wave in full bloom. It isn't going away.<div><br></div><div>Further, and again in my view, the "accuracy problem" is somewhat inaccurate. The registrars have no problem with the accuracy of the contact data they need to manage the relationship with their customers. What's really at issue is whether the registrant and the registrar will provide information to others who have no involvement in the relationship.</div><div><br></div><div>I agree the past and current situation is a mess. I think we disagree on the best forward.</div><div><br></div><div>Steve</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 7, 2019 at 5:36 AM <<a href="mailto:securitysceptic@gmail.com">securitysceptic@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Let’s all acknowledge that this is a lot of work to compensate for an implementation policy that is just bad. Even EU policy makers are surprised.<br>
<br>
- the GDPR is intended for EU natural persons.<br>
- ICANN applies it to all records.<br>
<br>
Moreover...<br>
<br>
This is a dangerous precedent for Internet policy. Every country has the sovereignty to decide what privacy rights apply within its jurisdiction. We didn’t all jump on a China Firewall policy. Would we have adopted GDPR if Russia, China, Iran or ITU countries enacted such a reg? The US has a right and responsibility to enact laws to protect privacy AND provide public safety. So do other countries. This imposes a quality of data obligation for registration data for domain names, similar to what we impose on property records.<br>
<br>
Lawyers at ICANN can argue all they want about domains being property or not but the reality is that they have been treated and used the same way as public property records in many jurisdictions for civil cases and criminal investigations. The gTLD records have always been public so there has never been an expectation of privacy.<br>
<br>
I’m in favor of legislation that insists that registration records for domain names be accurate and readily available thru public Whois. With accuracy, a discrimination between natural persons and legal entities can be implemented and privacy rights can be applied according to jurisdiction. The draft TOSI legislation frames this fairly well.<br>
<br>
This is responsible governance. I don’t want to hear about difficulties or cost. GDPR exposed the elephant in the room: Whois data sucks, the registrars are attempting to duck and cover by redacting every record and telling us that there’s nothing behind the curtain. The anonymity that redaction offers benefits criminal and national security threat actors. Time to reset and fix the system.<br>
<br>
Sent from my iPad<br>
<br>
> On Feb 7, 2019, at 05:05, Gavin Brown <<a href="mailto:gavin.brown@centralnic.com" target="_blank">gavin.brown@centralnic.com</a>> wrote:<br>
> <br>
> Hi Steve,<br>
> <br>
>> On 07/02/2019 00:18, Steve Crocker wrote:<br>
>> I was using salt in the sense you’re using pepper :)<br>
>> <br>
>> And in my subsequent note, I was indeed suggesting a common service. It<br>
>> could be run by icann or by another group. <br>
> <br>
> Such a service would have to operate at significant scale. As a backend<br>
> RSP, we (CentralNic) handle tens to hundreds of thousands of contact<br>
> object creates and updates each day. We are only one of many RSPs.<br>
> <br>
> Each contact object create and update would result in a call out to this<br>
> service in order to obtain the hashes: some of this could be mitigated<br>
> by caching, but many registrars generate (and frequently update)<br>
> pseudo-random email addresses for their customers which would defeat<br>
> that caching.<br>
> <br>
> Since it would be in the critical path for handling domain<br>
> registrations, we (meaning contracted parties and their service<br>
> providers) would require it have at least 4-5 nines of availability (as<br>
> well as sub-decisecond RTTs) in order to ensure we can meet our own SLAs.<br>
> <br>
> It would probably cost a non-trivial amount to run: a cost that would<br>
> have to be born by someone.<br>
> <br>
> The above notwithstanding, I still think it's a feasible idea, since the<br>
> service would not need to hold any state beyond the "pepper". You could<br>
> run it on a "serverless" cloud platform quite well I think.<br>
> <br>
> G.<br>
> <br>
>> <br>
>> Steve<br>
>> <br>
>> On Wed, Feb 6, 2019 at 6:14 PM joe <<a href="mailto:joe@stsauver.com" target="_blank">joe@stsauver.com</a><br>
>> <mailto:<a href="mailto:joe@stsauver.com" target="_blank">joe@stsauver.com</a>>> wrote:<br>
>> <br>
>> Hi,<br>
>> <br>
>> You mentioned:<br>
>> <br>
>>> I understand the<br>
>>> intended use, and it looks like you're simply using this as a salt.<br>
>> <br>
>> Actually, the secret value is being used as a pepper, not a salt, see<br>
>> <a href="https://en.wikipedia.org/wiki/Pepper_(cryptography)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Pepper_(cryptography)</a><br>
>> <br>
>>> Therefore, why not generate a suitably strong salt?<br>
>> <br>
>> A per-entry salt wouldn't yield the same hashed output for two cases<br>
>> where the same input was presented and processed. That property is great<br>
>> (and exactly what we want if we're creating salted passwords and we want<br>
>> to ensure that someone reviewing hashed passwords can't spot accounts<br>
>> that share a common password), but in this case we WANT the ability to<br>
>> identity different domains with the same point of contact information<br>
>> (even if that's only within a given registry's portfolio of domains).<br>
>> <br>
>> Quoting <a href="https://en.wikipedia.org/wiki/Salt_(cryptography)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Salt_(cryptography)</a> , "Since<br>
>> salts are<br>
>> different in each case, they also protect commonly used passwords,<br>
>> or those<br>
>> users who use the same password on several sites, by making all<br>
>> salted hash<br>
>> instances for the same password different from each other."<br>
>> <br>
>> In the instant case, however, we WANT the same input to yield the same<br>
>> hashed value so that domains with the same point of contact details can<br>
>> be identified and linked, just as it used to be possible to use reverse<br>
>> Whois search engines to look up all domains that had the same point of<br>
>> contact phone number "555-867-5309" (or whatever).<br>
>> <br>
>> If hashing were to be done as proposed:<br>
>> <br>
>> -- we'd find a domain of interest and look up its *hashed* values in<br>
>> Whois<br>
>> -- we'd then check for other domains which have the same hashed value or<br>
>> values in Whois (I'm assuming that commercial reverse Whois providers<br>
>> would step up to the plate to handle the mechanics of that, just<br>
>> as they<br>
>> did for non-hashed Whois).<br>
>> <br>
>> We could thus link the domains, even if we couldn't link those<br>
>> domain to a<br>
>> particular meat-space identity.<br>
>> <br>
>>> If you want to use<br>
>>> something related to strong crypto keys, then I guess the way to do it<br>
>>> would be to generate a public-private key pair and use the<br>
>> *public* part as<br>
>>> the salt.<br>
>> <br>
>> The pepper doesn't need to be related to strong crypto, it just<br>
>> needs to be<br>
>> a long, random and secret value.<br>
>> <br>
>> With a secret pepper, users can still "buy mappings" one at a time by<br>
>> registering domains with specific details of interest and then seeing<br>
>> what "pops out" (in hashed form) in Whois.<br>
>> <br>
>> But for fields of reasonable length, purchasing all possible values<br>
>> for each registrar would be prohibitively expensive.<br>
>> <br>
>> And even if I know a few hundred or thousand plain text-to-hashed<br>
>> mappings,<br>
>> that will not let me derive the secret pepper even if I know the<br>
>> algorithm<br>
>> used, the plain text, and the hashed result.<br>
>> <br>
>>> Question: Can you say more about the reasoning related to<br>
>> different keys<br>
>>> (salts) across different registries?<br>
>> <br>
>> A common pepper shared across hundreds or thousands of parties<br>
>> ( <a href="https://www.icann.org/registrar-reports/accredited-list.html" rel="noreferrer" target="_blank">https://www.icann.org/registrar-reports/accredited-list.html</a> ) would<br>
>> "leak", and any such "leak" would be non-attributable since every<br>
>> registry<br>
>> would know the same common secret, and fingers would be pointed hither<br>
>> and yon.<br>
>> <br>
>> A unique pepper created at each registry and never exported to any third<br>
>> party would limit that exposure, and each registry would presumably<br>
>> exercise<br>
>> appropriate care to secure their pepper (since failure to do so<br>
>> would likely<br>
>> result in litigation, regulatory penalties, loss of market share, etc.)<br>
>> <br>
>>> I understand that it might be hard to<br>
>>> design a system that yields the same hash across all registries --<br>
>> and all<br>
>>> registrars for a thin registry -- so that might be the reason for your<br>
>>> decision,<br>
>> <br>
>> I'd love to have comparable hashes (same input --> same output) for ALL<br>
>> registries, but that will only be possible if a single central authority<br>
>> (ICANN itself?) were to perform all the hashing. My subjective<br>
>> impression<br>
>> (which may be wrong) is that ICANN would shy away from performing such a<br>
>> role.<br>
>> <br>
>>> but that seems like a decision determined by the pragmatics of<br>
>>> keeping the salt(s) safe and not because it was the preferred result.<br>
>> <br>
>> I'm a very pragmatic person, and domain Whois is a very pragmatic topic,<br>
>> sorry about that.<br>
>> <br>
>> My preferred result would be for natural persons who are concerned about<br>
>> the exposure of their personal data to just use Whois proxy/privacy<br>
>> services,<br>
>> status quo ante (e.g., as was previously the case).<br>
>> <br>
>> However, because that is apparently not sufficient in a GDPR-enhanced<br>
>> world, the hashing option is the best technical option I've been able to<br>
>> come up with for domain Whois that will preserve at least some<br>
>> ability to<br>
>> identify multiple domains that are all controlled by a common party.<br>
>> <br>
>> Is it perfect? No.<br>
>> <br>
>> But will it be better than the currently crippled domain Whois system?<br>
>> Yes, I think it would be.<br>
>> <br>
>>> This<br>
>>> issue leaped out at me as I read through the document and when I<br>
>> got to the<br>
>>> FAQs, I saw the question was asked but the answer was simply it was an<br>
>>> intentional design choice.<br>
>> <br>
>> Thanks for reaching out, and let me know if there are other questions I<br>
>> can help address.<br>
>> <br>
>> Regards,<br>
>> <br>
>> Joe<br>
>> <br>
>> <br>
>> <br>
> <br>
> -- <br>
> Gavin Brown<br>
> Chief Technology Officer<br>
> CentralNic Group plc (LSE:CNIC)<br>
> Innovative, Reliable and Flexible Registry Services<br>
> for ccTLD, gTLD and private domain name registries<br>
> <a href="https://www.centralnic.com/" rel="noreferrer" target="_blank">https://www.centralnic.com/</a><br>
> +44.7548243029<br>
> <br>
> CentralNic Group plc is a company registered in England and Wales with<br>
> company number 8576358. Registered Offices: 35-39 Moorgate, London,<br>
> EC2R 6AR.<br>
> <br>
</blockquote></div></div>