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

Thu Feb 7 12:15:07 UTC 2019

My sense is there has been an implicit assumption the idea is too expensive, too political, etc and hence was avoided from the outset, even though it’s evident it would be a more complete solution.

To your point, let’s run the numbers.  The number of transactions per second and the cost of operation are likely to be fairly small — perhaps even minuscule — compared to many services on the net.

Steve

Sent from my iPhone

> On Feb 7, 2019, at 5:05 AM, 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.
> 