[35673] in North American Network Operators' Group
RE: Statements against new.net?
daemon@ATHENA.MIT.EDU (Mathew Butler)
Wed Mar 14 15:28:02 2001
Message-ID: <F062E72E4BA2D4119F1700B0D03D205F3B83@mail.tonbu.com>
From: Mathew Butler <mbutler@tonbu.com>
To: 'Patrick Greenwell' <patrick@cybernothing.org>,
Valdis.Kletnieks@vt.edu
Cc: nanog@merit.edu
Date: Wed, 14 Mar 2001 10:47:22 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C0ACB7.34562F70"
Errors-To: owner-nanog-outgoing@merit.edu
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C0ACB7.34562F70
Content-Type: text/plain;
charset="iso-8859-1"
Y'know, I upon reading this again, I have to point something out: The
current set of root servers is not administered by a unique naming
authority. The root zone itself is administered by the unique naming
authority.
The zone needs to have a Single Point of Contact. The root servers
themselves need to have a unique PoC for each, and it is much more desirable
to the Internet at large to each root server administered by a separate
entity -- be it vix.com, isi.edu, APNIC, whatever and whoever has the
bandwidth, knowledge, expertise, and money to support it. But the zone
itself needs to have an entity who is ultimately responsible for what goes
into the zone and what doesn't.
Now, I'm going to say something here (and these are my own opinions):
In the context of Certifying Authorities for SSL certificates, we have
multiple, unique roots. Lots of them. In Internet Explorer alone, there
are more than 80 that are embedded upon installation, and my set of CA roots
is different from your set of CA roots [this is a fact, since I run a CA
internal to my company]. This is roughly akin to the idea of including a
root.zone on each client, that makes it almost impossible to determine which
roots each client trusts. [PLEASE do not say anything about 'barrier to
entry' or 'a trusted root can't sign an intermediate root' -- the first is
high indeed, and the second is patently false. I'm only bringing this up to
explain a concept.]
Now, in the case a website has a CA that doesn't match anything that's in
the browser, there's an interactive dialog to determine which action to take
-- whether to accept it anyway, or to cancel the connection. In the event
of multiple, conflicting TLDs, though, there's no way for that interactive
exchange with the user to occur. Say I have an email address of
'winged@wolf.animal-lover', and someone doesn't like the way the
'animal-lover.' TLD is being run, so they set another root up with the
'animal-lover.' TLD and assign it to someone else. And one of my friends is
on an ISP that uses this alternate root. And my friend tries to send me an
email.
So, where will mail to my mail address 'winged@wolf.animal-lover' go to?
The client on my friend's system will send it to the ISP's mail server,
which will look up MX wolf.animal-lover on the conflicting root. Which will
almost certainly not be the MX wolf.animal-lover that I use. So at best it
gets bounced, at worst it goes to a completely uninvolved third party -- and
my friend would never even know. (And neither would I.) And the next time
my friend saw me, he'd ask me about it, and I'd have to say "it works for
me", and then we'd spend a lot of time figuring out where the problem was.
And then we'd yell and scream and curse and swear at the anarchy that led to
Usenet being what it is today... and most likely create our own little VPN
for the exchange of mail between our sites. Do we really -want- more VPN
traffic flowing over the backbone?
An implicit assumption made on the Internet today is that "e-mail addresses
will be unique and will route to the proper person unless there is a
technical reason that that is impossible". (Don't laugh, this is the view
of everyone I've ever talked with -- they don't think it's possible that
someone could take over their email account.) So 'mbutler@tonbu.com' will
always route to me, unless the MX is wrong or my mail server's down.
However, if we have conflicting zones, we'll never be able to guarantee
communication is going to work properly across the Internet, and we'll be
forced back to phone or pen&paper for REALLY important stuff. (Which will
also have the effect of completely removing the trust essential for
e-commerce to occur, since it'll never be truly possible to determine which
TLD root you're going through.)
It may be possible for larger corporations to buy through ALL registries for
a given TLD... but that is inefficient, and if someone set up a registry for
net. or com. or org. or mil., and then set up an alternate root for it, and
someone else used that root... can you imagine the carnage? (Especially
given ~$20/year per registry.)
Name hijacking would be what it is, and there are laws against it (all the
trademark laws, much less the fraud, malfeasance, misrepresentation, and
many others) all around the world. Personally, I hope that the ICANN files
a misrepresentation/fraud suit against new.net, and soon... though ICANN's
way of doing things must not be condoned, at this moment the new.net system
is NOT the correct way to fix the issue.
-Mat Butler
Speaking for himself, not his company
-----Original Message-----
From: Patrick Greenwell [mailto:patrick@cybernothing.org]
Sent: Tuesday, March 13, 2001 8:40 PM
To: Valdis.Kletnieks@vt.edu
Cc: nanog@merit.edu
Subject: Re: Statements against new.net?
"...That one root must be supported by a set of coordinated root servers
administered by a unique naming authority."
------_=_NextPart_001_01C0ACB7.34562F70
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Statements against new.net? </TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Y'know, I upon reading this again, I have to point =
something out: The current set of root servers is not =
administered by a unique naming authority. The root zone itself =
is administered by the unique naming authority.</FONT></P>
<P><FONT SIZE=3D2>The zone needs to have a Single Point of =
Contact. The root servers themselves need to have a unique PoC =
for each, and it is much more desirable to the Internet at large to =
each root server administered by a separate entity -- be it vix.com, =
isi.edu, APNIC, whatever and whoever has the bandwidth, knowledge, =
expertise, and money to support it. But the zone itself needs to =
have an entity who is ultimately responsible for what goes into the =
zone and what doesn't.</FONT></P>
<P><FONT SIZE=3D2>Now, I'm going to say something here (and these are =
my own opinions):</FONT>
</P>
<P><FONT SIZE=3D2>In the context of Certifying Authorities for SSL =
certificates, we have multiple, unique roots. Lots of them. =
In Internet Explorer alone, there are more than 80 that are embedded =
upon installation, and my set of CA roots is different from your set of =
CA roots [this is a fact, since I run a CA internal to my =
company]. This is roughly akin to the idea of including a =
root.zone on each client, that makes it almost impossible to determine =
which roots each client trusts. [PLEASE do not say anything about =
'barrier to entry' or 'a trusted root can't sign an intermediate root' =
-- the first is high indeed, and the second is patently false. =
I'm only bringing this up to explain a concept.]</FONT></P>
<P><FONT SIZE=3D2>Now, in the case a website has a CA that doesn't =
match anything that's in the browser, there's an interactive dialog to =
determine which action to take -- whether to accept it anyway, or to =
cancel the connection. In the event of multiple, conflicting =
TLDs, though, there's no way for that interactive exchange with the =
user to occur. Say I have an email address of =
'winged@wolf.animal-lover', and someone doesn't like the way the =
'animal-lover.' TLD is being run, so they set another root up with the =
'animal-lover.' TLD and assign it to someone else. And one of my =
friends is on an ISP that uses this alternate root. And my friend =
tries to send me an email.</FONT></P>
<P><FONT SIZE=3D2>So, where will mail to my mail address =
'winged@wolf.animal-lover' go to? The client on my friend's =
system will send it to the ISP's mail server, which will look up MX =
wolf.animal-lover on the conflicting root. Which will almost =
certainly not be the MX wolf.animal-lover that I use. So at best =
it gets bounced, at worst it goes to a completely uninvolved third =
party -- and my friend would never even know. (And neither would =
I.) And the next time my friend saw me, he'd ask me about it, and =
I'd have to say "it works for me", and then we'd spend a lot =
of time figuring out where the problem was. And then we'd yell =
and scream and curse and swear at the anarchy that led to Usenet being =
what it is today... and most likely create our own little VPN for the =
exchange of mail between our sites. Do we really -want- more VPN =
traffic flowing over the backbone?</FONT></P>
<P><FONT SIZE=3D2>An implicit assumption made on the Internet today is =
that "e-mail addresses will be unique and will route to the proper =
person unless there is a technical reason that that is =
impossible". (Don't laugh, this is the view of everyone I've =
ever talked with -- they don't think it's possible that someone could =
take over their email account.) So 'mbutler@tonbu.com' will =
always route to me, unless the MX is wrong or my mail server's =
down. However, if we have conflicting zones, we'll never be able =
to guarantee communication is going to work properly across the =
Internet, and we'll be forced back to phone or pen&paper for REALLY =
important stuff. (Which will also have the effect of completely =
removing the trust essential for e-commerce to occur, since it'll never =
be truly possible to determine which TLD root you're going =
through.)</FONT></P>
<P><FONT SIZE=3D2>It may be possible for larger corporations to buy =
through ALL registries for a given TLD... but that is inefficient, and =
if someone set up a registry for net. or com. or org. or mil., and then =
set up an alternate root for it, and someone else used that =
root... can you imagine the carnage? (Especially given =
~$20/year per registry.)</FONT></P>
<P><FONT SIZE=3D2>Name hijacking would be what it is, and there are =
laws against it (all the trademark laws, much less the fraud, =
malfeasance, misrepresentation, and many others) all around the =
world. Personally, I hope that the ICANN files a =
misrepresentation/fraud suit against new.net, and soon... though =
ICANN's way of doing things must not be condoned, at this moment the =
new.net system is NOT the correct way to fix the issue.</FONT></P>
<P><FONT SIZE=3D2>-Mat Butler</FONT>
<BR><FONT SIZE=3D2>Speaking for himself, not his company</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Patrick Greenwell [<A =
HREF=3D"mailto:patrick@cybernothing.org">mailto:patrick@cybernothing.org=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 13, 2001 8:40 PM</FONT>
<BR><FONT SIZE=3D2>To: Valdis.Kletnieks@vt.edu</FONT>
<BR><FONT SIZE=3D2>Cc: nanog@merit.edu</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Statements against new.net? </FONT>
</P>
<P><FONT SIZE=3D2>"...That one root must be supported by a set of =
coordinated root servers</FONT>
<BR><FONT SIZE=3D2>administered by a unique naming =
authority."</FONT>
</P>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C0ACB7.34562F70--
