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

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Ross and all sgb members,

  I don't believe this would work in Russia, Canada, or the
US's case given their current law and/or regulation.

  And again I have trimmed the CC's in accordance with
Maria's insistence.

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
> >>>
> >>>
> >>>
> >>>
> >
> >

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