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

[Jeff Williams <jwkckid1@xxxxxxxxxxxxx>]

Dan and all sgb members,

  From my vast long term experience "multiple keys" is the
worst way to go as too many keys will be generated eventually,
and in my opinion in very short order and in doing so the likelihood
of so many keys more opportunity of theft, and misuse is possible.

  Rather a single key with multiple users is better, but still a
very bad idea or approach.

  Frankly such methods are ill conceived for reasons of both
scalability and/or lack of "do-ability" and are not necessary
as only registrants should be able to change what is and what
is not accessible in their Whois data.  OR, all commercial
registrants data by law/regulation must be fully publicly
except financially related data, available and non commercial
registrants will have an opt out option, all of which is subject
to national law/regulation with any and/or all due process
protections recognized, enforced, as is appropriate, relevant,
or otherwise considered.

  Registries and registrars only should only have the ability
to delete a Whois registration data for non payment after
due process under relevant law if and when appropriate.

  Therefore only registrants or their designated representative,
will have the ability to change their domain names registration
data for Whois for commercial registrants, and for non commercial
registrants, only the registrant of non commercial domain names
or their designated representative, will have a key or the ability to
change their domain names registration data for Whois or otherwise.
And only trusted law enforcement and/or other designated agencies
will have the ability to override non commercial registrant registration
data for Whois or otherwise.

Dan Krimm wrote:

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

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