ICANN ICANN Email List Archives

[gnso-acc-sgb]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: Dan Krimm <dan@xxxxxxxxxxxxxxxx>
  • Subject: Re: [gnso-acc-sgb] elaboration on the Blob topology
  • From: Ross Rader <ross@xxxxxxxxxx>
  • Date: Thu, 10 May 2007 16:37:47 -0400

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











<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy