[TSG-Access-RD] Comment and question re 4 June 2018 letter from APWG to ICANN re hashing PoC data

Thu Feb 7 13:07:54 UTC 2019

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.

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.

I agree the past and current situation is a mess.  I think we disagree on
the best forward.

Steve

On Thu, Feb 7, 2019 at 5:36 AM <securitysceptic at gmail.com> wrote:

> 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.
>
> - the GDPR is intended for EU natural persons.
> - ICANN applies it to all records.
>
> Moreover...
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Sent from my iPad
>
> > On Feb 7, 2019, at 05:05, Gavin Brown <gavin.brown at centralnic.com>
> wrote:
> >
> > Hi Steve,
> >
> >> On 07/02/2019 00:18, Steve Crocker wrote:
> >> I was using salt in the sense you’re using pepper :)
> >>
> >> And in my subsequent note, I was indeed suggesting a common service.  It
> >> could be run by icann or by another group.
> >
> > Such a service would have to operate at significant scale. As a backend
> > RSP, we (CentralNic) handle tens to hundreds of thousands of contact
> > object creates and updates each day. We are only one of many RSPs.
> >
> > Each contact object create and update would result in a call out to this
> > service in order to obtain the hashes: some of this could be mitigated
> > by caching, but many registrars generate (and frequently update)
> > pseudo-random email addresses for their customers which would defeat
> > that caching.
> >
> > Since it would be in the critical path for handling domain
> > registrations, we (meaning contracted parties and their service
> > providers) would require it have at least 4-5 nines of availability (as
> > well as sub-decisecond RTTs) in order to ensure we can meet our own SLAs.
> >
> > It would probably cost a non-trivial amount to run: a cost that would
> > have to be born by someone.
> >
> > The above notwithstanding, I still think it's a feasible idea, since the
> > service would not need to hold any state beyond the "pepper". You could
> > run it on a "serverless" cloud platform quite well I think.
> >
> > G.
> >
> >>
> >> Steve
> >>
> >> On Wed, Feb 6, 2019 at 6:14 PM joe <joe at stsauver.com
> >> <mailto:joe at stsauver.com>> wrote:
> >>
> >>    Hi,
> >>
> >>    You mentioned:
> >>
> >>> I understand the
> >>> intended use, and it looks like you're simply using this as a salt.
> >>
> >>    Actually, the secret value is being used as a pepper, not a salt, see
> >>    https://en.wikipedia.org/wiki/Pepper_(cryptography)
> >>
> >>> Therefore, why not generate a suitably strong salt?
> >>
> >>    A per-entry salt wouldn't yield the same hashed output for two cases
> >>    where the same input was presented and processed. That property is
> great
> >>    (and exactly what we want if we're creating salted passwords and we
> want
> >>    to ensure that someone reviewing hashed passwords can't spot accounts
> >>    that share a common password), but in this case we WANT the ability
> to
> >>    identity different domains with the same point of contact information
> >>    (even if that's only within a given registry's portfolio of domains).
> >>
> >>    Quoting https://en.wikipedia.org/wiki/Salt_(cryptography) , "Since
> >>    salts are
> >>    different in each case, they also protect commonly used passwords,
> >>    or those
> >>    users who use the same password on several sites, by making all
> >>    salted hash
> >>    instances for the same password different from each other."
> >>
> >>    In the instant case, however, we WANT the same input to yield the
> same
> >>    hashed value so that domains with the same point of contact details
> can
> >>    be identified and linked, just as it used to be possible to use
> reverse
> >>    Whois search engines to look up all domains that had the same point
> of
> >>    contact phone number "555-867-5309" (or whatever).
> >>
> >>    If hashing were to be done as proposed:
> >>
> >>    -- we'd find a domain of interest and look up its *hashed* values in
> >>    Whois
> >>    -- we'd then check for other domains which have the same hashed
> value or
> >>       values in Whois (I'm assuming that commercial reverse Whois
> providers
> >>       would step up to the plate to handle the mechanics of that, just
> >>    as they
> >>       did for non-hashed Whois).
> >>
> >>    We could thus link the domains, even if we couldn't link those
> >>    domain to a
> >>    particular meat-space identity.
> >>
> >>> If you want to use
> >>> something related to strong crypto keys, then I guess the way to do it
> >>> would be to generate a public-private key pair and use the
> >>    *public* part as
> >>> the salt.
> >>
> >>    The pepper doesn't need to be related to strong crypto, it just
> >>    needs to be
> >>    a long, random and secret value.
> >>
> >>    With a secret pepper, users can still "buy mappings" one at a time by
> >>    registering domains with specific details of interest and then seeing
> >>    what "pops out" (in hashed form) in Whois.
> >>
> >>    But for fields of reasonable length, purchasing all possible values
> >>    for each registrar would be prohibitively expensive.
> >>
> >>    And even if I know a few hundred or thousand plain text-to-hashed
> >>    mappings,
> >>    that will not let me derive the secret pepper even if I know the
> >>    algorithm
> >>    used, the plain text, and the hashed result.
> >>
> >>> Question: Can you say more about the reasoning related to
> >>    different keys
> >>> (salts) across different registries?
> >>
> >>    A common pepper shared across hundreds or thousands of parties
> >>    ( https://www.icann.org/registrar-reports/accredited-list.html )
> would
> >>    "leak", and any such "leak" would be non-attributable since every
> >>    registry
> >>    would know the same common secret, and fingers would be pointed
> hither
> >>    and yon.
> >>
> >>    A unique pepper created at each registry and never exported to any
> third
> >>    party would limit that exposure, and each registry would presumably
> >>    exercise
> >>    appropriate care to secure their pepper (since failure to do so
> >>    would likely
> >>    result in litigation, regulatory penalties, loss of market share,
> etc.)
> >>
> >>> I understand that it might be hard to
> >>> design a system that yields the same hash across all registries --
> >>    and all
> >>> registrars for a thin registry -- so that might be the reason for your
> >>> decision,
> >>
> >>    I'd love to have comparable hashes (same input --> same output) for
> ALL
> >>    registries, but that will only be possible if a single central
> authority
> >>    (ICANN itself?) were to perform all the hashing. My subjective
> >>    impression
> >>    (which may be wrong) is that ICANN would shy away from performing
> such a
> >>    role.
> >>
> >>> but that seems like a decision determined by the pragmatics of
> >>> keeping the salt(s) safe and not because it was the preferred result.
> >>
> >>    I'm a very pragmatic person, and domain Whois is a very pragmatic
> topic,
> >>    sorry about that.
> >>
> >>    My preferred result would be for natural persons who are concerned
> about
> >>    the exposure of their personal data to just use Whois proxy/privacy
> >>    services,
> >>    status quo ante (e.g., as was previously the case).
> >>
> >>    However, because that is apparently not sufficient in a GDPR-enhanced
> >>    world, the hashing option is the best technical option I've been
> able to
> >>    come up with for domain Whois that will preserve at least some
> >>    ability to
> >>    identify multiple domains that are all controlled by a common party.
> >>
> >>    Is it perfect? No.
> >>
> >>    But will it be better than the currently crippled domain Whois
> system?
> >>    Yes, I think it would be.
> >>
> >>> This
> >>> issue leaped out at me as I read through the document and when I
> >>    got to the
> >>> FAQs, I saw the question was asked but the answer was simply it was an
> >>> intentional design choice.
> >>
> >>    Thanks for reaching out, and let me know if there are other
> questions I
> >>    can help address.
> >>
> >>    Regards,
> >>
> >>    Joe
> >>
> >>
> >>
> >
> > --
> > Gavin Brown
> > Chief Technology Officer
> > CentralNic Group plc (LSE:CNIC)
> > Innovative, Reliable and Flexible Registry Services
> > for ccTLD, gTLD and private domain name registries
> > https://www.centralnic.com/
> > +44.7548243029
> >
> > CentralNic Group plc is a company registered in England and Wales with
> > company number 8576358. Registered Offices: 35-39 Moorgate, London,
> > EC2R 6AR.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20190207/d2fd395a/attachment-0001.html>