Re: [gnso-acc-sgb] elaboration on the Blob topology

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

Thanks Ross,

Again, how many keys for how many (and which) blobs, and what happens in
case of a breach?  Does each sub-LEA get the *same* key that the super-LEA
gets, or are you suggesting that there is a chain of *different* keys
reaching down the hierarchy?

And if so, how can a single blob that has already been encrypted and
retrieved from a Whois query get decrypted by more than one key?  I'm still
trying to understand what the mechanism would be for any paradigm involving
multiple keys.

I can understand how an access tree can work with passwords into a
protected database (a super-account has authority to issue access to
sub-accounts, most likely with auto-generated passwords so that only the
sub-account holder has the sub-account password, but the super-account can
control whether the sub-account has privileged access or even exists), but
not with encrypted blobs that presumably get encrypted once for all time
with a single key (and which can be decrypted for all time with a single
key).

Perhaps I'm simply uninformed about the potentials for "multi-key
encryption" (or more precisely: multi-key *decryption*), and if so I would
benefit greatly from a technical explanation at this point, as I am
completely puzzled by the suggestion, having never heard of such a thing.

In any case, the issue of how keys get distributed among LEAs doesn't seem
to affect the underlying potential for damage to privacy in case of a
breach.  That requires a clear understanding of how multi-key
encryption/decryption could work, if it exists at all.

Thanks,
Dan



At 3:17 PM -0400 5/10/07, Ross Rader wrote:
>There is another alternative to using a centralized body which would
>require registrars to only provide their whois decryption key to their
>senior law enforcement agency (or LE oversight body) which would then
>extend the chain of trust by chaining new keys to other law enforcement
>interests in the same country in addition to foreign law enforcement
>agencies per local custom, regulation and legislation.
>
>This approach avoids the whole issue of who gets which keys under which
>rules because it relies on national law.
>
>Dan Krimm wrote:
>> I would think this is a prime opportunity to get input from Bertrand, as
>> our observing GAC member.  I believe Bertrand is very well informed on many
>> of these items, and can gather additional information in cases where he
>> does not have the specific answer himself.
>>
>> While GNSO is not formally bound by any specific policy positions taken by
>> GAC, relevant factual information would definitely be useful to take into
>> account in this context, I would think.
>>
>> Dan
>>
>>
>>
>> At 11:52 AM -0400 5/10/07, Carole Bird wrote:
>>> One approach to ponder to simply ask the GAC these questions.
>>>
>>> Many of these issues run into the diplomatic realm and as such they may
>>> well be in the best position to recommend or identify the way ahead.
>>>
>>> Carole
>>>
>>>>>> "Anthony Harris" <harris@xxxxxxxxxxxxx> 05/10/07 11:21 AM >>>
>>> This is very interesting. There are however a couple of
>>> points the WG may need to ponder:
>>>
>>> 1) The question of which parties have the need to access
>>> WHOIS data has been, in my opinion, quite well
>>> summarized in the GAC comments on WHOIS which
>>> emerged during the ICANN Lisbon meeting. See:
>>> http://gac.icann.org/web/communiques/gac27com.pdf
>>>
>>> 2) I hesitate to imagine who would supervise access of
>>> law enforcement agencies in countries with 'a history of
>>> miscreant behaviour'...Who would decide on this, the United
>>> Nations?
>>>
>>> 3) The core of this long-running discussion on WHOIS
>>> is the registrant privacy concern. The instruments for
>>> protecting privacy are determined by national laws,
>>> and these in some instances may occur even in those
>>> countries with 'a history of miscreant behaviour'. IOW
>>> countries make up their own minds about privacy
>>> protection, and they also run their own law enforcement
>>> agencies as they feel appropriate.
>>>
>>> Tony Harris
>>>
>>>
>>> ----- Original Message -----
>>> From: "Jeff Williams" <jwkckid1@xxxxxxxxxxxxx>
>>> To: <gnso-acc-sgb@xxxxxxxxx>
>>> Cc: <contactustr@xxxxxxxxxxxx>
>>> Sent: Thursday, May 10, 2007 2:36 AM
>>> Subject: Re: [gnso-acc-sgb] elaboration on the Blob topology
>>>
>>>
>>>> Dan and all sgb members,
>>>>
>>>>  Excellent reverse logic analysis here.  And one that I indirectly
>>>> eluded to with respect what type if entities should and should not
>>>> be considered for third party access.  My examples were for
>>>> entities that should not become third parties for access were:
>>>> Law firms, trade associations or trade related organizations,
>>>> educational institutions, financial institutions of any sort,
>>>> auditing/accounting firms, or private security firms.
>>>>
>>>>  Additionally SOME law enforcement entities, including a few
>>>> which are INTERPOL members should also NOT have
>>>> unsupervised access to any private/protected registrant
>>>> Whois data.  I consider as a guide line for determining
>>>> which of the law enforcement entities whom should NOT have
>>>> unsupervised access to any private/protected registrant
>>>> Whois data, the USTR 301 list which I provided the
>>>> link for.  The countries in which these law enforcement entities
>>>> serve, have a history of miscreant behavior as well as in far
>>>> too many instances, engaged in criminal activity on a number
>>>> of fronts which gives me a far less than comfortable feeling.
>>>>
>>>> Dan Krimm wrote:
>>>>
>>>>> Hi Paul and registrars,
>>>>>
>>>>> Due to time constraints I didn't follow up with this on today's phone
>>>>> call,
>>>>> but perhaps you can elaborate here on email.
>>>>>
>>>>> My question with respect to the Blob proposal is: how many keys would be
>>>>> involved, and how would they correspond with what data and what users,
>>>>> specifically?
>>>>>
>>>>> I assume that encryption for any specific blob is limited to a single
>>>>> key,
>>>>> and once encrypted and distributed broadly (and publicly, given that it
>>>>> is
>>>>> included with all queries on that domain) that key will work on that blob
>>>>> forever.
>>>>>
>>>>> So, in the event of a breach of the key into the general public, or at
>>>>> least into a broader population than is properly certified for access,
>>>>> there is no mechanism for further protection of the encrypted data in the
>>>>> blob.
>>>>>
>>>>> Given the statistics on the failings of human beings, one must expect
>>>>> that
>>>>> a certain number of breaches will inevitably happen over time.  And, we
>>>>> will not know about many of them (if they are contained to private but
>>>>> uncertified entities).
>>>>>
>>>>> In the May 2 call, it was suggested that perhaps there could be multiple
>>>>> keys. so that a single public breach does not open up the entire set of
>>>>> all
>>>>> blobs to public access (or at least to unauthorized access).
>>>>>
>>>>> Can you explain how a topology of multiple keys might work?  How many
>>>>> blobs
>>>>> would a single key provide access to, and do different LEAs get different
>>>>> keys or do they all share the same key(s)?
>>>>>
>>>>> It seemed to me that the simplest case was that a single key would
>>>>> provide
>>>>> access to all blobs across all registrars.  In the opposite extreme, each
>>>>> blob would be uniquely encrypted for each individual real-time query, but
>>>>> then distribution of keys would be a major undertaking, and one may as
>>>>> well
>>>>> set up a password-access database system anyway.
>>>>>
>>>>> One particular concern I have is that some wealthy entity that wants to
>>>>> do
>>>>> data mining could build up a database that combines both unencrypted as
>>>>> well as encrypted data, and simply await an opportunity to acquire a key
>>>>> or
>>>>> keys to be able to decrypt the blobs that are stored in an integrated
>>>>> database.  If a single key would unlock all encrypted data in that
>>>>> database, then that key would become quite valuable, and that increases
>>>>> the
>>>>> incentive (and thus the chance) of a breach in return for quite
>>>>> substantial
>>>>> payment under the table.  This seems to constitute a sort of "time bomb"
>>>>> given the potential for a single breach across the full realm of
>>>>> certified
>>>>> individuals in all LEAs assigned access across the globe.
>>>>>
>>>>> This would almost be worse than a fully public breach, because it would
>>>>> presumably be mostly unknown, and it would place such wealthy entities at
>>>>> a
>>>>> great advantage in gaining unauthorized access.
>>>>>
>>>>> So, while this scheme would seem to work as long as everyone with access
>>>>> behaves properly, I would suggest that we need to consider the real
>>>>> potentials for breaches and what the ramifications would be in such
>>>>> cases.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Dan
>>>>>
>>>>> PS -- Today you pointed out that with this scheme there would be no trace
>>>>> of specific use of the keys to gain access to specific data.  However, if
>>>>> indeed there is consideration of Bertrand's suggestion of creating an
>>>>> individualized audit trail of queries into the private data in order to
>>>>> provide post-facto accountability for data use, this might present an
>>>>> impediment to enforcement of any laws against abuse of the privileged
>>>>> data
>>>>> by particular individuals, including those legitimately certified for
>>>>> access initially.
>>>> Regards,
>>>> --
>>>> Jeffrey A. Williams
>>>> Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
>>>> "Obedience of the law is the greatest freedom" -
>>>>   Abraham Lincoln
>>>>
>>>> "Credit should go with the performance of duty and not with what is
>>>> very often the accident of glory" - Theodore Roosevelt
>>>>
>>>> "If the probability be called P; the injury, L; and the burden, B;
>>>> liability depends upon whether B is less than L multiplied by
>>>> P: i.e., whether B is less than PL."
>>>> United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
>>>> ===============================================================
>>>> Updated 1/26/04
>>>> CSO/DIR. Internet Network Eng. SR. Eng. Network data security
>>>> IDNS. div. of Information Network Eng.  INEG. INC.
>>>> ABA member in good standing member ID 01257402
>>>> E-Mail jwkckid1@xxxxxxxxxxxxx
>>>> Registered Email addr with the USPS
>>>> Contact Number: 214-244-4827
>>>>
>>>>
>>>>
>>>>
>>
>>