Subject: GA-DIGEST V1 #1427
From: [email-masked] (GA-DIGEST)
To: [email-masked]

GA-DIGEST         Friday, September 20 2002         Volume 01 : Number 1427

----------------------------------------------------------------------

Date: Wed, 18 Sep 2002 11:03:01 +0200
From: [email-masked]
Subject: Re: [ga] Cyberspace Security and the Root(s)

I think the answer is obvious.
You can test it for yourself with the plug-in from Nameslinger or with the
Plug-in from PacificRoot (both are the same, made by nameslinger).
You can set this plug-in in this way:
1. try to resolve a internet address in the USG root
2. if that fails (e.g. root server destroyed), try to resolve that address
in another root (e.g. PacificRoot)

But don't ask me how likely it is or how easy it is to bring the USG root
down...I'm not an engineer

Simon

p.s.: this way you could also resolve ARNI's .BIZ AND NeuLevels .BIZ

- ----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 18, 2002 9:31 PM
Subject: [ga] Cyberspace Security and the Root(s)

> In reading the recently published "National Strategy to Secure
Cyberspace",
> my attention was drawn to one particular remark:
>
> "To combat these vulnerabilities, the security of the infrastructure must
not
> be dependent on a single layer, group or focal point, but rather must be
> found in multiple layers, distributed defenses, and the ability to recover
> quickly from any attack."
> http://www.whitehouse.gov/pcipb/cyberstrategy-draft.pdf
>
> Doesn't this seem to argue against the concept of the desirability of a
> single root?  From strictly a security perspective, can someone
sufficiently
> knowledgable advise as to which is better -- having a single root or
having
> multiple roots?
> --
> This message was passed to you via the [email-masked] list.
> Send mail to [email-masked] to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
>

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Wed, 18 Sep 2002 11:13:15 +0200
From: [email-masked]
Subject: Re: [ga] Cyberspace Security and the Root(s)

- ----- Original Message -----
From: "Allan Liska" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 19, 2002 4:23 AM
Subject: Re: [ga] Cyberspace Security and the Root(s)

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: MD5
>
> Hello DannyYounger,
>
> Wednesday, September 18, 2002, 3:31:38 PM, you wrote:
>
> Dcc> Doesn't this seem to argue against the concept of the desirability of
a
> Dcc> single root?  From strictly a security perspective, can someone
sufficiently
> Dcc> knowledgable advise as to which is better -- having a single root or
having
> Dcc> multiple roots?
>
> A single root is infinitely more secure than multiple roots.  The
> primary goal of information security is to maintain the integrity of
> information.  Having multiple roots makes it much more difficult to
> maintain the integrity of the information -- the root namespace.  Just
> as a company would not have multiple customer databases, a court
> system would not keep multiple criminal records or a doctor would not
> keep multiple records for a patient.

a .com address is keeps the same information regardless of the root.
there are problems ("multiple databases") with .info, .biz, .museum, .name,
.pro

simon
http://www.steinle.law.pro
http://www.nic.pro

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 16:22:01 +0200 (CEST)
From: Marc Schneiders <[email-masked]>
Subject: Re: [ga] Cyberspace Security and the Root(s)

On Wed, 18 Sep 2002, at 22:23 [=GMT-0400], Allan Liska wrote:

> A single root is infinitely more secure than multiple roots.  The
> primary goal of information security is to maintain the integrity of
> information.

I would say that another primary goal is the availability of the
information.

> Having multiple roots makes it much more difficult to
> maintain the integrity of the information -- the root namespace.  Just
> as a company would not have multiple customer databases, a court
> system would not keep multiple criminal records or a doctor would not
> keep multiple records for a patient.

True, any one doctor should not keep multiple databases. But we are not
talking about the database of one physician, but about the database of
databases. It would be a bad thing, if we could only locate a doctor over
a single top entry point for the whole world. Such is the case with DNS.
If the root fails, it doesn't work at all anymore.

Several independant sets of rootservers are better than just one.
Naturally these sets do not have to have different information. Ideally
they carry identical data.

For an attempt to replicate the ICANN root (with which I am NOT in any way
affiliated) for exactly the reasons given above, see:

http://orsn.org/

- --
[email-masked]

http://www.bijt.net/

"I find it bizare that we are talking about hypothetical applications
of enum in Andora..."

Phillip Hallam-Baker
(http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01632.html)

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 10:55:42 EDT
From: [email-masked]
Subject: [ga] Escrow

Allan, thanks for your reply.

On a related note I would ask what is happening with the ICANN escrow testbed 
program?  Last November ICANN posted a document on this topic at 
http://www.icann.org/escrow/registrar-escrow-08nov01.htm which seemed to 
indicate that not all registrars are currently escrowing their data, that 
plans are moving forward for implementing periodic escrow of gTLD registrar 
data as soon as possible, and that prior to a full rollout of the escrow 
system to all accredited registrars, implementation will begin with a testbed 
consisting of a small number of volunteer registrars.

In conjunction with this tesbed program, ICANN asked a series of questions 
(but no replies seem to have been posted, although I might have missed them 
if they were):

1.  How should the testbed voluntary program be broadened to other 
registrars, and under what schedule?
2.  Should a list of approved third-party escrow agents be established, or 
should they be selected and approved on a case-by-case basis?
3.  Should other options for deposit transmission (such as by mailed 
tape/CD-R) be opened in a further rollout of the program?
4.  Should registrar escrow success results be published to the public? If 
so, on what level of granularity and with what frequency?
5.  What disaster recovery procedures should be established to enable the use 
of the escrowed data in the event it becomes necessary?
6.  Should customers of a failed registrar all be allocated to one registrar, 
or be split among several registrars, or should customers choose?

Perhaps someone in the registrar community or on ICANN staff can give us an 
update on this program, and let us know which registrars are still not in 
conformity with escrow requirements as set out in the Registrar Accreditation 
Agreement (section 3.6).  

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 10:36:56 -0500
From: Andy Gardner <[email-masked]>
Subject: Re: [ga] icannatlarge.com

At 10:45 PM +1200 9/19/02, Joop Teernstra wrote:
>If there is anything  misleading and deceptive, it has been the gradual
>abandoning of ICANN's founding principle to be a membership organization.

Ain't that the truth!

But what to do?

- -- 
Andrew P. Gardner
barcelona.com stolen, stmoritz.com stays. What's uniform about the UDRP?
We could ask ICANN to send WIPO a clue, but do they have any to spare?
Get active: http://www.tldlobby.com
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 18:08:33 +0200
From: Alexander Svensson <[email-masked]>
Subject: [ga] Fwd: LACTLD comments on Zone Transfers

This has been forwarded by Oscar Robles to the Names Council list:
(http://www.dnso.org/clubpublic/council/Arc11/msg00045.html)

>To: [email-masked], [email-masked], [email-masked]
>Subject: [cctld-discuss] LACTLD comments on Zone Transfers
>Date: Thu, 19 Sep 2002 07:55:35 -0600
>
>Hello all:
>
>For your information:
>
>----------------------------------------------------------------------
>Comments of LACTLD on zone transfers
>---------------------------------------------------------------------
>
>As a result of several questions raised by the ccTLDs to ICANN
>(IANA) about the reasons to require zone file transfer to IANA, and
>the process they follow to review that information, ICANN issued
>recently a FAQ http://www.iana.org/faqs/tld-zone-access-faq.htm
>
>After reviewing this FAQ, we find the explanation provided by
>ICANN to be unconvincing. If these are the reasons why IANA has
>refused to update the name server configuration of ccTLDs that
>required urgent changes, changes that were needed to avoid
>possible chaos caused by the sudden bankrupcy of a major ISP, we
>believe that, in doing so, IANA may have been risking endangering
>the very operational stability of the Internet it is charged to
>preserve.
>
>We cannot deny that during the emergency created by the failure of
>KPNQuest, IANA personnel worked very hard to process the
>changes for many ccTLDs, but we also believe that their good work
>has been hampered by an unreasonable policy that has not allowed
>them to perform the changes for all the ccTLDs that required them.
>The fact that ns.eu.net is still operating has helped avoid a crisis,
>but this is in spite of the policy in question, not thanks to it.
>
>We believe that the tests that IANA needs to perform to ensure the
>DNS operational stability and performance may be done without
>the requirement of zone file transfers. The two examples provided
>to illustrate why zone transfer would be required, namely to check
>that two independent name servers be provided for the sub-
>domains of a TLD and to check for proper format, do not survive
>close examination. We do agree that it is IANA's job to check that
>each TLD has two independent functional DNS servers (which can
>be tested without zone access), but we think that IANA going
>routinely deeper down the tree goes against the principle of
>delegation of authority on which the DNS is based. Furthermore,
>current technology makes it possible that many servers be
>operating using a single IP address, through the use of anycast. As
>far as checking that the zone file follows the proper format, we think
>this is not necessary nor sufficient, as some versions of BIND are
>not RFC 1034 compliant.
>
>We also remain unconvinced of the need for IANA to have a copy
>of the zone file to allow the operation of the TLD in case of
>catastrophic failure. In case of a disaster, the TLD should have
>proper recovery mechanisms, because their operation is not limited
>to a single DNS server, but involves a much more complex IT
>infrastrucure which is needed to maintain the DNS operation.
>ICANN could not do anything more with the zone file than to
>preserve for a few hours an operation that is needed for many days
>in the event of a disaster and total loss of information. We firmly
>believe in the need to have a robust infraestructure and procedures
>in place to minimize the probability of this kind of failure, and to
>have sound contingency plans available, but the IANA policy might
>even work against this, by generating a false sense of security.
>
>Since ICANN is yet to provide a reasonable explanation for the
>requirement to open the zone files for transfer to IANA, we
>understand very well the position of those ccTLD administrators
>that have decided not to allow such transfers. It is quite possible
>that allowing this transfers might create a security hole. Even if
>transmission could be done in a completely secure way, it would be
>very hard for ICANN to provide a guarantee that the storage of the
>zone files in its servers would not be vulnerable to the frequent
>attacks that those servers suffer.
>
>Given that RFC 1591 does not explicitly require that zone files be
>available to IANA, and given that, until recently (two years after it
>appeared in ICP-1) IANA had not enforced this rule, we believe that
>this requirement should be eliminated. We are not against some
>ccTLD administrators making their zone files voluntarily available
>to IANA --in fact some of us do allow such access-- but we strongly
>reject IANA's policy of delaying urgent technical updates until it
>gets access to the zone file.
>
>It would be possible to argue endlessly about whether ICP-1 is valid
>ICANN policy or not, given that it did not go through the proper
>policy development process and that it appears that the Board only
>approved its number, and not its substance. However, we think that
>this is a matter of the greatest urgency and that it cannot wait for
>such a discussion to be settled. There is no rule anywhere that says
>that IANA is forbidden to process changes of TLD name servers
>unless the zone file is available to it, and we call therefore to IANA
>to stop demanding these transfers as a precondition to make these
>changes. Such a step would go a long way towards showing that
>IANA and the ccTLDs are able to work together to achieve the goal
>of Internet stability that we all share.
>
>LACTLD
>
>-----------------------------
>Rafael (Lito) Ibarra
>UCA Jose´ Simeo´n Can~as
>San Salvador, El Salvador (SV)
>Tel +(503) 210-6600, ext. 270, 271
>Fax +(503) 210-6640

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 13:16:31 -0400 (EDT)
From: Jonathan Weinberg <[email-masked]>
Subject: Re: [ga] Fwd: LACTLD comments on Zone Transfers

	I'm impressed by the degree to which everyone has managed to avoid
talking about the elephant under the bed here.  As the LACTLD message
below states, and as Karl's message at
<http://www.dnso.org/clubpublic/ga/Arc11/msg00268.html> explains in
detail, the ICANN position that it needs zone file access "for purposes of
verifying and ensuring DNS operational stability and performance" seems
problematic.  On the other hand, I'd guess that zone file access would
simplify ICANN's task if it chose to redelegate a ccTLD away from an
operator unhappy with that change.  Anyone want to talk about this
explicitly?

Jon

Jon Weinberg
weinbergmsen.com

On Thu, 19 Sep 2002, Alexander Svensson wrote:
> 
> This has been forwarded by Oscar Robles to the Names Council list:
> (http://www.dnso.org/clubpublic/council/Arc11/msg00045.html)
> 
> >To: [email-masked], [email-masked], [email-masked]
> >Subject: [cctld-discuss] LACTLD comments on Zone Transfers
> >Date: Thu, 19 Sep 2002 07:55:35 -0600
> >
> >Hello all:
> >
> >For your information:
> >
> >----------------------------------------------------------------------
> >Comments of LACTLD on zone transfers
> >---------------------------------------------------------------------
> >
> >As a result of several questions raised by the ccTLDs to ICANN
> >(IANA) about the reasons to require zone file transfer to IANA, and
> >the process they follow to review that information, ICANN issued
> >recently a FAQ http://www.iana.org/faqs/tld-zone-access-faq.htm
> >
> >After reviewing this FAQ, we find the explanation provided by
> >ICANN to be unconvincing. If these are the reasons why IANA has
> >refused to update the name server configuration of ccTLDs that
> >required urgent changes, changes that were needed to avoid
> >possible chaos caused by the sudden bankrupcy of a major ISP, we
> >believe that, in doing so, IANA may have been risking endangering
> >the very operational stability of the Internet it is charged to
> >preserve.
> >
> >We cannot deny that during the emergency created by the failure of
> >KPNQuest, IANA personnel worked very hard to process the
> >changes for many ccTLDs, but we also believe that their good work
> >has been hampered by an unreasonable policy that has not allowed
> >them to perform the changes for all the ccTLDs that required them.
> >The fact that ns.eu.net is still operating has helped avoid a crisis,
> >but this is in spite of the policy in question, not thanks to it.
> >
> >We believe that the tests that IANA needs to perform to ensure the
> >DNS operational stability and performance may be done without
> >the requirement of zone file transfers. The two examples provided
> >to illustrate why zone transfer would be required, namely to check
> >that two independent name servers be provided for the sub-
> >domains of a TLD and to check for proper format, do not survive
> >close examination. We do agree that it is IANA's job to check that
> >each TLD has two independent functional DNS servers (which can
> >be tested without zone access), but we think that IANA going
> >routinely deeper down the tree goes against the principle of
> >delegation of authority on which the DNS is based. Furthermore,
> >current technology makes it possible that many servers be
> >operating using a single IP address, through the use of anycast. As
> >far as checking that the zone file follows the proper format, we think
> >this is not necessary nor sufficient, as some versions of BIND are
> >not RFC 1034 compliant.
> >
> >We also remain unconvinced of the need for IANA to have a copy
> >of the zone file to allow the operation of the TLD in case of
> >catastrophic failure. In case of a disaster, the TLD should have
> >proper recovery mechanisms, because their operation is not limited
> >to a single DNS server, but involves a much more complex IT
> >infrastrucure which is needed to maintain the DNS operation.
> >ICANN could not do anything more with the zone file than to
> >preserve for a few hours an operation that is needed for many days
> >in the event of a disaster and total loss of information. We firmly
> >believe in the need to have a robust infraestructure and procedures
> >in place to minimize the probability of this kind of failure, and to
> >have sound contingency plans available, but the IANA policy might
> >even work against this, by generating a false sense of security.
> >
> >Since ICANN is yet to provide a reasonable explanation for the
> >requirement to open the zone files for transfer to IANA, we
> >understand very well the position of those ccTLD administrators
> >that have decided not to allow such transfers. It is quite possible
> >that allowing this transfers might create a security hole. Even if
> >transmission could be done in a completely secure way, it would be
> >very hard for ICANN to provide a guarantee that the storage of the
> >zone files in its servers would not be vulnerable to the frequent
> >attacks that those servers suffer.
> >
> >Given that RFC 1591 does not explicitly require that zone files be
> >available to IANA, and given that, until recently (two years after it
> >appeared in ICP-1) IANA had not enforced this rule, we believe that
> >this requirement should be eliminated. We are not against some
> >ccTLD administrators making their zone files voluntarily available
> >to IANA --in fact some of us do allow such access-- but we strongly
> >reject IANA's policy of delaying urgent technical updates until it
> >gets access to the zone file.
> >
> >It would be possible to argue endlessly about whether ICP-1 is valid
> >ICANN policy or not, given that it did not go through the proper
> >policy development process and that it appears that the Board only
> >approved its number, and not its substance. However, we think that
> >this is a matter of the greatest urgency and that it cannot wait for
> >such a discussion to be settled. There is no rule anywhere that says
> >that IANA is forbidden to process changes of TLD name servers
> >unless the zone file is available to it, and we call therefore to IANA
> >to stop demanding these transfers as a precondition to make these
> >changes. Such a step would go a long way towards showing that
> >IANA and the ccTLDs are able to work together to achieve the goal
> >of Internet stability that we all share.
> >
> >LACTLD
> >
> >-----------------------------
> >Rafael (Lito) Ibarra
> >UCA Jose´ Simeo´n Can~as
> >San Salvador, El Salvador (SV)
> >Tel +(503) 210-6600, ext. 270, 271
> >Fax +(503) 210-6640
> 
> --
> This message was passed to you via the [email-masked] list.
> Send mail to [email-masked] to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
> 

Jonathan Weinberg
[email-masked]

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 13:52:26 -0400
From: "John Berryhill Ph.D. J.D." <[email-masked]>
Subject: [ga] Update On Whois Enforcement

Yes, this works very well as expected.  Exactly 15 days, too...

Step 1:

http://www.icann.org/correspondence/touton-letter-to-beckwith-03sep02.htm
"7. visosite.com: On 15 May 2002, we forwarded to you a report concerning
inaccurate data for visosite.com."

Step 2:

http://www.icann.org/correspondence/mitchell-letter-to-touton-11sep02.htm
"We also have deleted 3 of the domain name registrations for not timely
complying [...]"

Step 3:

Domain Name: visosite.com
Registrant: John Berryhill
Date Registered: Sep 18 2002

Any questions?

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 12:02:33 -0700 (PDT)
From: George Kirikos <[email-masked]>
Subject: Re: [ga] Update On Whois Enforcement

Hi John,

- --- "John Berryhill Ph.D. J.D." <[email-masked]> wrote:
> Step 3:
> 
> Domain Name: visosite.com
> Registrant: John Berryhill
> Date Registered: Sep 18 2002
> 
> Any questions?

Worked *very* well, indeed. My only question is, what's a "viso"??? I
couldn't figure out how that domain had any value??

Sincerely,

George Kirikos
http://www.GlobalDomination.com/

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 12:35:04 -0700 (PDT)
From: Rick Wesson <[email-masked]>
Subject: Re: [ga] Update On Whois Enforcement

John,

visosite.com seems to be a domain which large amounts of SPAM/UCE
originated from.

congrads!

- -rick

On Thu, 19 Sep 2002, George Kirikos wrote:

> Hi John,
>
> --- "John Berryhill Ph.D. J.D." <[email-masked]> wrote:
> > Step 3:
> >
> > Domain Name: visosite.com
> > Registrant: John Berryhill
> > Date Registered: Sep 18 2002
> >
> > Any questions?
>
> Worked *very* well, indeed. My only question is, what's a "viso"??? I
> couldn't figure out how that domain had any value??
>
> Sincerely,
>
> George Kirikos
> http://www.GlobalDomination.com/
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> --
> This message was passed to you via the [email-masked] list.
> Send mail to [email-masked] to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html
>

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 20 Sep 2002 07:57:16 +1200
From: DPF <[email-masked]>
Subject: Re: [ga] Fwd: LACTLD comments on Zone Transfers

On Thu, 19 Sep 2002 13:16:31 -0400 (EDT), Jonathan Weinberg
<[email-masked]> wrote:

>	I'm impressed by the degree to which everyone has managed to avoid
>talking about the elephant under the bed here.  As the LACTLD message
>below states, and as Karl's message at
><http://www.dnso.org/clubpublic/ga/Arc11/msg00268.html> explains in
>detail, the ICANN position that it needs zone file access "for purposes of
>verifying and ensuring DNS operational stability and performance" seems
>problematic.  On the other hand, I'd guess that zone file access would
>simplify ICANN's task if it chose to redelegate a ccTLD away from an
>operator unhappy with that change.  Anyone want to talk about this
>explicitly?

From my point of view that has certainly been a suspicion.   However
without details from the register of who holds each name etc just
having a zone file would not make it possible to run the ccTLD for
more than a few days I suspect.

DPF
- --
[email-masked]
ICQ 29964527
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 16:32:10 -0700
From: Jeff Williams <[email-masked]>
Subject: Re: [ga] Cyberspace Security and the Root(s)

Steinle and all assembly members,

  With our SROOTS, both name server based and browser mod. based
you don't even need a plugin to access any number of Root structures
TLD's.  It is also configurable on the browser side "on the fly" or
set up configurable on the name server side...

[email-masked] wrote:

> I think the answer is obvious.
> You can test it for yourself with the plug-in from Nameslinger or with the
> Plug-in from PacificRoot (both are the same, made by nameslinger).
> You can set this plug-in in this way:
> 1. try to resolve a internet address in the USG root
> 2. if that fails (e.g. root server destroyed), try to resolve that address
> in another root (e.g. PacificRoot)
>
> But don't ask me how likely it is or how easy it is to bring the USG root
> down...I'm not an engineer
>
> Simon
>
> p.s.: this way you could also resolve ARNI's .BIZ AND NeuLevels .BIZ
>
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, September 18, 2002 9:31 PM
> Subject: [ga] Cyberspace Security and the Root(s)
>
> > In reading the recently published "National Strategy to Secure
> Cyberspace",
> > my attention was drawn to one particular remark:
> >
> > "To combat these vulnerabilities, the security of the infrastructure must
> not
> > be dependent on a single layer, group or focal point, but rather must be
> > found in multiple layers, distributed defenses, and the ability to recover
> > quickly from any attack."
> > http://www.whitehouse.gov/pcipb/cyberstrategy-draft.pdf
> >
> > Doesn't this seem to argue against the concept of the desirability of a
> > single root?  From strictly a security perspective, can someone
> sufficiently
> > knowledgable advise as to which is better -- having a single root or
> having
> > multiple roots?
> > --
> > This message was passed to you via the [email-masked] list.
> > Send mail to [email-masked] to unsubscribe
> > ("unsubscribe ga" in the body of the message).
> > Archives at http://www.dnso.org/archives.html
> >
>
> --
> This message was passed to you via the [email-masked] list.
> Send mail to [email-masked] to unsubscribe
> ("unsubscribe ga" in the body of the message).
> Archives at http://www.dnso.org/archives.html

Regards,
- --
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 23:55:33 +0200 (MET DST)
From: Elisabeth Porteneuve <[email-masked]>
Subject: Re: [ga] Fwd: LACTLD comments on Zone Transfers

Dear Jon,

Could you elaborate more what do you mean by ICANN "to chose 
to redelegate a ccTLD" ? Upon request ? By whom and to whom ?

I am unaware of any elephant under the .DE bed, neither .AT
nor .GR. They all operate for the benefit of their Local Internet
Community, private and public sector alike (the public institutions
including governmental ones are registered under .de, .at or .gr),
and within their jurisdiction. 

Could you be more explicit ?

Kind regards,
Elisabeth Porteneuve
- --

> On the other hand, I'd guess that zone file access would
> simplify ICANN's task if it chose to redelegate a ccTLD away from an
> operator unhappy with that change.  Anyone want to talk about this
> explicitly?
> 
> Jon
> 
> 
> Jon Weinberg
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Thu, 19 Sep 2002 17:11:21 -0700
From: Jeff Williams <[email-masked]>
Subject: [ga] Re: [ecdiscuss] US Cyberspace Security Draft

Phillip and all,

  Excellent and informative response here Phil.  Well done!
I am taking the liberty of also sending this along with my comments
and observations to the DOC/NTIA folks responsible, the DNSO
GA, and the Cyberspace Security Draft folks for their consideration
as well.

======== Some of my response comments follow ======

  Indeed the problem you outline is a real one for .COM and the
implementation of DNSSEC for .COM.  Agreed the DNSEXT
working group of the IETF, of which I am on but not very active
of late, has been taken over as you rightly indicate by those
that are anti-Verisign and have let that fact blind them to the
potential fix for DNSSEC that is very workable.  As such,
and amongst a number of other areas such as IPSEC, it is
no small wonder that the current US Administration headed
up by Richard Clarke wishes or believes in the draft report,
that the IETF lost of is loosing it's way.  This too has IMHO
been very evident in several of the IETF's own general
mailing lists archives by various members participating.

  My concern and fear however in this report draft is that
should the IETF be taken over or replaced as indicated,
than the independence of technical standards will be
damaged, lost forever or politicized to the extent of being
harmful to the future of this medium, the internet...  Like ICANN,
the problem with the IETF is it's current leadership, and it's
club mentality and structure...  Those can be fixed however, but
would require some direct intervention of some sort unfortunately...

Hallam-Baker, Phillip wrote:

> DNSSEC cannot be deployed in .com as presently specified.
>
> The current spec would increase the size of the in memory image
> of the zone file by six to eight times. Since the zone file
> is already 2-3 Gigabytes and the transaction volume is 6 billion
> lookups a day there is simply no way that the original proposal
> (now eight years old) is going to be deployed.
>
> There is a fix for this issue which provides the same degree
> of security. Certain members of the DNSEXT working group have
> been attempting to sabotage the fix for their own petty political
> ends, the argument being that the issue 'only affects one party'.
>
> Members of this faction have in the past stated that 'if .com
> is too big then that is the problem we should fix'.
>
> I assure you I am not making this up.
>
> Consensus was reached in the group to accept the OPTIN fix for
> the deployment. One of the chairs deliberately avoided stating
> that there was consensus by sending the OPTIN draft to the 'DNS
> Directorate' which is a body appointed by him and has not felt
> fit to share any of its discussions with the group.
>
> The faction appear to have the idea that VeriSign is somehow
> bound by its decisions which is why I have been saying, well
> err, no and particularly not if you are going to go about
> making those decisions in that fashion and after you have
> told me that you do not intend to take any notice of my
> requirements.
>
> The strategy, which has been stated in the WG meetings is that
> by preventing VeriSign from deploying DNSSEC the group will
> save the internet from VeriSign.
>
> Meanwhile take a read of Richard Clark's essay at the Whitehouse.
> Recommendations 4-1 through 4-4 essentially propose taking over
> the IETF if it does not do the administrations bidding.
>
> And yes, I know that I am not being all nice and friendly on
> the list. Mark Kosters tried that for six years. The only way
> to deal with this is to point out to the members of that group
> that I am not attending their meetings as a substitute social
> life and I am more than willing to match their tactics.
>
>                 Phill
>
> > -----Original Message-----
> > From: Jeff Williams [mailto:[email-masked]]
> > Sent: Thursday, September 19, 2002 1:22 AM
> > Cc: J-F C. (Jefsey) Morfin; [email-masked]; [email-masked]
> > Subject: Re: [ecdiscuss] US Cyberspace Security Draft
> >
> >
> > Nikolaj and all,
> >
> >   I frankly am wondering where Phillip got this strange idea?
> > Phillip, perhaps you could elaborate on what or how DNSSEC
> > is broken?
> >
> > Nikolaj Nyholm wrote:
> >
> > > While there have been reports on the recommendations of the
> > use of DNSSEC,
> > > it's somewhat of a paradox that, the chief scientist at
> > Verisign, Phill
> > > Hallam-Baker, recently declared that "DNSSEC in its current
> > form is BROKEN".
> > >
> > >
> > http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01619.html
> > >
> > > Best regards,
> > > Ascio Technologies Inc.
> > >
> > > Nikolaj Nyholm
> > > Vice President & CTO
> > >
> > > Digital identity weblog at
> > > http://weblog.digital-identity.info
> > >
> > > > -----Original Message-----
> > > > From: J-F C. (Jefsey) Morfin [mailto:[email-masked]]
> > > > Sent: 18. september 2002 19:30
> > > > To: [email-masked]
> > > > Subject: [ecdiscuss] US Cyberspace Security Draft
> > > >
> > > >
> > > > an important document to read and probably discuss:
> > > > http://www.whitehouse.gov/pcipb/cyberstrategy-draft.pdf
> > > > jfc
> > > >
> >
> > Regards,
> > --
> > Jeffrey A. Williams
> > Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
> > CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
> > Information Network Eng. Group. INEG. INC.
> > E-Mail [email-masked]
> > Contact Number: 214-244-4827 or 972-244-3801
> > Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
> >
> >

Regards,
- --
Jeffrey A. Williams
Spokesman for INEGroup - (Over 127k members/stakeholders strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number: 214-244-4827 or 972-244-3801
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

Date: Fri, 20 Sep 2002 10:32:30 +1200
From: Steven Heath <[email-masked]>
Subject: RE: [ga] Fwd: LACTLD comments on Zone Transfers

> On the other hand, I'd guess that zone file access would
> simplify ICANN's task if it chose to redelegate a ccTLD away from an
> operator unhappy with that change.  Anyone want to talk about this
> explicitly?

Sure, you could _operate_ the ccTLD if you had a copy of the zone file and
update the root servers to point to the new name servers. But what does this
get you?

How would you prove who 'owned' what names?

How would you update it for required changes?

How would you collect payments/renewals?

Things would get very messy very quick unless you planned to forever freeze
the TLD at that date and time. This could be a DRP approach but the local
ccTLD manager to be competent should have a BCP and DRP plan already in
place and tested.

Steven Heath
.nz news & views
http://radio.weblogs.com/0110729/

 
- --
This message was passed to you via the [email-masked] list.
Send mail to [email-masked] to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html

------------------------------

End of GA-DIGEST V1 #1427
*************************