[governance] "Oversight"

McTim dogwallah at gmail.com
Wed Jun 6 12:41:05 EDT 2012


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


More information about the Governance mailing list