<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body text="#333333" bgcolor="#ffffff">
<font face="Helvetica, Arial, sans-serif">Hi David,</font><br>
<br>
On Monday 04 June 2012 09:30 PM, David Conrad wrote:
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">Parminder,
  <div><br>
  </div>
  <div>Apologies for the deep dive in the minutiae of root zone
management, but I think clarity here is important.</div>
</blockquote>
<br>
Not at all. I must thank you for the clarity you have provided me.
More below. <br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div><br>
  <div>
  <div>On Jun 4, 2012, at 3:05 AM, parminder wrote:</div>
  <blockquote type="cite">
    <div text="#333333" bgcolor="#ffffff"><font
 face="Helvetica, Arial, sans-serif">For those who have been arguing
that ICANN cannot remove individual
websites, that might be true, but they can remove complete domain
names, like cctlds, isnt it. </font></div>
  </blockquote>
  <div><br>
  </div>
  <div>No, ICANN, acting unilaterally, cannot.  </div>
  <div><br>
  </div>
  <div>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.</div>
  </div>
  </div>
</blockquote>
<br>
All actors you mention are subject to US jurisdiction (I will come to
the 3 non US root servers later) and therefore if US government wants
and orders something it applies to all of them.  So the point is, US
gov can do it. Doesnt matter if ICANN alone can do it or not. The issue
under discussion is US government's unilateral power and control for
CIRs, and its global unacceptability. <br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div>
  <div><br>
  <blockquote type="cite">
    <div text="#333333" bgcolor="#ffffff"><span class="Apple-style-span"
 style="font-family: Helvetica,Arial,sans-serif;">On the other hand, I
am not completely sure what is the impact of the
recent securitisation of the DNS/root zone with regard to possible
domain seizures and other interferences, but I suspect that there are
indeed some important implications of it. </span></div>
  </blockquote>
  <div><br>
  </div>
  <div>There is no impact of DNSSEC-signing the root to domain name
seizures.</div>
  </div>
  </div>
</blockquote>
<br>
Reading the following part of your email, I am not clear on what basis
you
make the above assertion. But you can help me with more clarification. <br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div>
  <div>
  <div><br>
  </div>
  <div>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. </div>
  </div>
  </div>
</blockquote>
<br>
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. 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, 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.)<br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div>
  <div>
  <div> 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 "<a moz-do-not-send="true"
 href="http://foo.example.com">foo.example.com</a>"' respond with
"don't know, but ask the name servers for .COM and here is a list of
those name servers").  <br>
  </div>
  </div>
  </div>
</blockquote>
<br>
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 "<a moz-do-not-send="true"
 href="http://foo.example.com">foo.example.com</a>"' - 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.<br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div>
  <div>
  <div>DNSSEC allows validating resolvers (typically operated by ISPs)
to verify that no one has tried to insert bogus data in that referral.</div>
  <div><br>
  </div>
  <div>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, </div>
  </div>
  </div>
</blockquote>
<br>
yes, that possible eventuality  is 'the' problem with unilateral
oversight, it is not a mere side issue.....<br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div>
  <div>
  <div>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.</div>
  </div>
  </div>
</blockquote>
<br>
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 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. I simply see no
possibility of non US root server operators
not accepting the upstream changes, whatever noises they may make while
doing so. (And your claim that 'even many of those in the US' will
refuse to comply in completely invalid because they will be subject to
any US gov order with the necessary legal force). <br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div>
  <div>
  <div><br>
  </div>
  <div>The point here is that no single party involved in root
management, the TLD administrators, ICANN, NTIA, Verisign, or the root
server operators, is able to unilaterally "remove complete domain
names" and any attempt to do so would be "bad".</div>
  </div>
  </div>
</blockquote>
<br>
After reading your email I am even more convinced that US can hit not
only complete cctlds ot tlds, but also individual websites, because of
the DNSSEC structure, which I understand US government insisted should
be as it is rather than anyway else. Gives no comfort to us outside US.
The case for internationalising CIR oversight is even stronger with
the securitisation of the root. <br>
<br>
I am rather more convinced now that US government by its own power can
effectively cut off any part of the Internet (unless the concerned
traffic is as insular as perhaps is only possible in China). Even if it
does need help of certain outside actors, almost all in the North, you
must not underestimate US's demonstrated persuasive and/or arm twisting
skills to enforce its will internationally, whether it is the case of
Julian Assange or Iran. (I am not even going into the unmentionably
sordid history of US's 'global interferences' - to put it lightly - of
the last century). I dont know on what basis people in the North, or
specifically in the US, can be sermonising to the world that we simply
should trust the US gov. I feel even worse when some aspiring global
citizens from the South so gullibly swallow the bait.  <br>
<br>
Parminder <br>
<br>
<blockquote
 cite="mid:A57637BD-9E30-4A8E-8BA4-EB846550C3F1@virtualized.org"
 type="cite">
  <div>
  <div>
  <div><br>
  </div>
  <div>Regards,</div>
  <div>-drc</div>
  <div><br>
  </div>
  <div>P.S. I have argued that the current root zone management process
has a flaw in that the publication of the root zone should not be done
by the Root Zone Manager, rather it should be done by (or at least
vetted by) the IANA Functions Manager to ensure the requested change
was done correctly before it hits the root servers.  Haven't gotten
much traction as some folks feel it would add yet another step in an
already too Byzantine a process for something as simple as modifying a
zone file.</div>
  <div><br>
  </div>
  </div>
  </div>
</blockquote>
</body>
</html>