[governance] "Oversight"

Tue Jun 12 10:53:33 EDT 2012

On Wednesday 06 June 2012 10:29 PM, Lee W McKnight wrote:
> McTim's right on this.
>
> And, if I may note once more - there is a trusted human override in the inner workings of the guts of the net of nets: Meaning, the 'root server operators' are not autonamatons.
>
>   I quote:
>
> the root server operators (a quarter of which are not based in the US and
>    
>> with one exception are under no contractual obligation to do anything)
>>      
> Meaning, ultimately, the trusted (redundant and distributed) geeky folks some of you worry about have the responsibility to keep the whole thing up and inter-operating. As long as that remains the case - which is a design feature and not an accident - then we are all, relatively speaking of course, safe from anyone trying to take over anything.
>    

Lee, Since you, and also David, seem to rely a lot on the argument about 
root servers that are under no contractual obligation 'to do anything', 
I must address it. The US based majority of root servers - which is all 
but three -  may not be under any contractual obligations but they are 
subject to US law, and legitimate executive orders. This is the real 
issue, not just the involved contract law. In any condition that US law 
and executive power considers special - whether IP enforcement or 
security/ warfare related, all US based root servers will be obliged to 
fall in line.

As for the three - or is it four - non US based root servers, firstly, 
they are all in US friendly countries, on whom US has great persuasive 
influence. In any case, the cost of non compliance to republishing the 
authentic root version - in terms of possible general disruptions etc - 
is too high for anyone to a make a reasonable assessment that they are 
may not  fall in line. Although David says DNSSEC does not change this 
situation at all, from his own description of the processes involved, I 
see that DNSSEC implementation greatly increases the various costs of 
non publishing of the authoritative root file as communicated from 
Verisign's server.

We need to look at all this against the background that US is the most 
active, perhaps the only, international actor  that very regularly 
imposes unilateral sanctions on other countries which means no 
relationships, including not allowing its companies, and even 
non-profits, from providing any services to the sanctioned countries.

  I am quite sure that under the same law that the US gov prevents its 
companies, for instance,  from providing software security updates to 
residents of Sudan, Iran and some other countries, ICANN/ IANA manager 
can be stopped from providing all services that it provides to the 
residents and organisations in these countries. At present they dont 
apply this law because they are cautious of how it would look to those 
who provide it with so much legitimacy in its CIR oversight role, but 
perceptions and cost-benefit analysis can change, especially in what may 
getasp seen as an exceptional situation by the US. The rest of the world 
cannot remain a hapless aspirant of continued US goodwill... This is 
what is unacceptable to us, outside the US.

As to how much the US cares for even the international documents that it 
signs, It may be pertinent to note that the WSIS Declaration of 
Principles (repeated in Tunis agenda)  speaks against unilateral 
measures of the kind that  Sudan, Iran, Cuba etc get subject to vis a 
vis information society's technology affordances.

    In building the Information Society, States are strongly urged to
    take steps with a view to the avoidance of, and refrain from, any
    unilateral measure not in accordance with international law and the
    Charter of the United Nations that impedes the full achievement of
    economic and social development by the population of the affected
    countries, and that hinders the well-being of their population.

Do you still think other countries can trust the US with oversight 
control over such a vital infrastructure as the Internet?

parminder

> Lee
> ________________________________________
> From: governance-request at lists.igcaucus.org [governance-request at lists.igcaucus.org] on behalf of McTim [dogwallah at gmail.com]
> Sent: Wednesday, June 06, 2012 12:41 PM
> To: governance at lists.igcaucus.org; parminder
> Subject: Re: [governance] "Oversight"
>
> Hu,
>
> for some reason, i cannot quote correctly.
>
> On Wed, Jun 6, 2012 at 4:00 AM, parminder<parminder at itforchange.net>  wrote:
>    
>> Hi David,
>>
>>
>>      
> <snip>
>
> DRC
>    
>> No, ICANN, acting unilaterally, cannot.
>>
>> ICANN, acting as the IANA Functions Manager under contract to the US
>> Government, can at the direction of the administrators for the top-level
>> domain in question _make a request_ to have that top-level domain removed.
>>   That request (once validated by IANA staff) is sent to the US Dept. of
>> Commerce NTIA for approval to ensure that existing policies and processes
>> were followed, and when approved that request is forwarded to Verisign as
>> the Root Zone Manager for that TLD's entry in the root zone to be deleted.
>>   At that point, the modified zone file is DNSSEC-signed (by the Root Zone
>> Manager with a key that is held by (handwave) the IANA Functions Manager)
>> and pushed to the 13 root servers that will make the modified root zone
>> available to the Internet.
>>
>>
>>      
> PJS
>    
>> All actors you mention are subject to US jurisdiction (I will come to the
>> 3
>> non US root servers later)
>>      
> I think that WIDE, RIPE and Autonomica may have different opinions than you.
>
> PJS
> and therefore if US government wants and orders
>    
>> something it applies to all of them.  So the point is, US gov can do it.
>>      
> did you NOT read drc statement above?  I will paraphrase:
>
> 1. IF a ccTLD requests removal of their TLD, IANA CAN request that it
> be removed.
>
> 2.  The NTIA would validate that the removal followed policy
>
> 3. Request fwded to Verisign for actual editing of file
>
> 4. IANA must resign newzone
>
> 5. Publication to rootservers
>
>
> This is a far cry from "US gov can do it."
>
>
>
>
> DRC
>    
>> The only thing DNSSEC-signing the root zone does is ensure that an attempt
>> by someone who doesn't hold the root zone's private key to modify a
>> response
>> from a root server can be detected.
>>
>>
>> This seems to suggest that modifications to query responses made by
>> someone
>> who *does* hold the root zone's private key (ie root zone manager, which
>> is
>> under contract of US gov, and therefore means the US gov) will not be
>> detected.
>>      
> This is not suggested at all.
>
>   That is the problem. And what I read from your email is that due
>    
>> to DNSSEC operation, now US gov can not only remove an entire cctld or
>> gtld,
>> but can modify root zone responses to specific websites level queries,
>>      
> neither are true.
>
>    
>> which
>> is more or less removing them (as we will discuss later) . Is it not so? I
>> was afraid, but unsure, that something like this may now have been made
>> possible. Now, from your email, I am clear about it. Thanks for it. (No
>> irony intended.)
>>      
> no, in fact, you are not at all clear as to how DNSSEC works!
>
>
>    
>>
>>      
> DRC
>    
>>   Responses from the root servers are (almost always) referrals to
>> top-level
>> domain name servers (that is, the root servers when asked 'what's the
>> address for "foo.example.com"' respond with "don't know, but ask the name
>> servers for .COM and here is a list of those name servers").
>>
>>
>>      
> PJS
>    
>> You say 'almost always' which leaves the possibility - with an actor with
>> the relevant intention, and the power of the US gov - that such a referral
>> -
>> 'what's the address for "foo.example.com"' - may not be directed to the
>> concerned tld name server. It may simply be terminated in say, a notice by
>> US custom's authority or US State Dept. Am I right.
>>      
> No, once again, you are incorrect.  The root zone only "knows" where
> .com is..  It doesn't "know"
> where foo.example.com is or even example.com!
>
>
>    
>>
>>      
> DRC
>    
>> DNSSEC allows validating resolvers (typically operated by ISPs) to verify
>> that no one has tried to insert bogus data in that referral.
>>
>> An implication of this is that if the existing processes were somehow
>> subverted and the Root Zone Manager (Verisign, _not_ ICANN) were able to
>> insert something inappropriate into the root zone,
>>
>>
>> yes, that possible eventuality  is 'the' problem with unilateral
>> oversight,
>> it is not a mere side issue.....
>>
>>
>> the root server operators (a quarter of which are not based in the US and
>> with one exception are under no contractual obligation to do anything)
>> would
>> be forced to make a decision: publish the "secure" root zone with the
>> inappropriate data or refuse to publish the entire zone.  If such a
>> subversion were to take place, I suspect a majority of root server
>> operators
>> (yes, even many of those in the US) would choose the latter with
>> consequences so unappealing as to be comparable with Mutual Assured
>> Destruction doctrine.
>>
>>
>>      
> PJS
>    
>> It is here we differ, because in saying 'I suspect' you are expressing an
>> opinion, which I am not at all able to agree with. I am quite sure that
>> the
>> three outside root server operators will go along, however unhappy they
>> may
>> be in doing so, because as you yourself put it, not going along with have
>> catastrophic consequneces for the Internet. The website or websites that
>> US
>> may choose to hit
>>      
>
> I repeat, mucking with the rootzone is NOT hitting "website or
> websites".  The USG seemingly
> can do this via other means.
>
>
> PJS
>   will be of relatively much much less 'global' economic
>    
>> and
>> political consequence - though they may be of life and death importance to
>> some people, groups, or country(s). Rather than interfering so drastically
>> with whole of the Internet, all concerned actors will simply comply.
>>      
> This is also conjecture or "opinion".
>
>
> --
> Cheers,
>
> McTim
> "A name indicates what we seek. An address indicates where it is. A route
> indicates how we get there."  Jon Postel
>
>
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20120612/9f21274b/attachment.htm>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t