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

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

Thanks Ross,

I was assuming that "do-ability" is part of "implementation" -- at the very
least it is a parameter that constrains any potential implementation.

My basic question here is: what is do-able with regard to the blob model
and "multiple keys"?

That is, how does it work in detail?  Until I understand what exactly you
are proposing with regard to multiple keys, I can't even begin to think
about whether it is do-able, or whether it would constitute sound policy.

How exactly would use of multiple keys work?  And how would that affect the
question of breaches and protection of privacy?

In short: is the creation of a "multiple-key decryption" paradigm for
encrypted blobs actually do-able?

If it is, I don't currently understand how, or perhaps I simply don't
understand what you mean by it.  Could you give me just one clear and
tangible example as a demonstration/description of the idea?  It doesn't
have to be etched in stone, we're just brainstorming here right now, aren't
we?

Thanks,
Dan



At 5:23 PM -0400 5/10/07, Ross Rader wrote:
>Most policy recommendations go out for an implementation review prior to
>their final consideration by Council. This is phase at which
>"do-ability" and real perceived costs are analysed. Anything that I or
>any other registrar might say on the subject at this early stage would
>be very high-level and not entirely useful for the purposes of this
>Working Group.
>
>Dan Krimm wrote:
>> Thanks again Ross,
>>
>> I think it would be wasteful for this WG to consider any policies that are
>> not implementable, so we should probably consider implementation as part of
>> our current deliberations.  Otherwise we waste time in additional amendment
>> cycles, but we have only a finite time period to get this right.
>>
>> I understand that registrars are concerned with efficiency and cost, and we
>> certainly need to take that into account -- whatever we recommend needs to
>> be able to be implemented in the most cost-effective manner possible.
>>
>> Costs can come from technical development and from operational human
>> resources.  I would assume that the human component is the most onerous
>> from the registrar PoV?  If so we should talk about automating the process
>> as much as possible, and distributing whatever human resources are
>> necessary to operate the process.
>>
>> In that regard, I think the idea of a distributed access authority tree
>> makes a lot of sense, especially if that tree is explicitly tracked and
>> audited automatically, with hierarchical authority and responsibility going
>> hand in hand.
>>
>> The technical platform might still be implemented by registrars, but the
>> control of authority on that platform could be distributed among
>> legitimately certified LEAs.  Registrars would only have to validate the
>> certification at the top level (a single certification, or a small number
>> of certifications), as you suggest, and then those certified authorities
>> would become responsible for sub-certifications, tracked in the registrars'
>> systems.  This would also allow for national laws to control how authority
>> is assigned down the tree.
>>
>> Perhaps the blob technique per se is not the most effective tool to use for
>> that sort of structure.  Do you have concerns with using a
>> password-protected database platform for this, or do you have other ideas
>> for an ideal implementation for such a paradigm?
>>
>> Dan
>>
>>
>>
>> At 4:37 PM -0400 5/10/07, Ross Rader wrote:
>>> Generally speaking, the policy framework precedes the implementation. I
>>> haven't thought about it to the level of detail that you are.
>>> Appropriate technical mechanisms would need to be identified or created
>>> to fulfill the requirements of the policy (i.e. as we did with EPP and
>>> other standards track technology).
>>>
>>> It may be not be implementable, in which case, the policy would need
>>> amendment.
>>>
>>> Dan Krimm wrote:
>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>
>>