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

[Steve Crocker]

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.

Steve

On Wed, Feb 6, 2019 at 6:14 PM joe <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20190206/3c9b9c8b/attachment-0001.html>