Verisign's public opinion play (fwd)

Wed Oct 8 16:46:02 UTC 2003

Forwarding by request.  Please direct replies to John Fraizer.

------------ Forwarded Message ------------
Date: Wednesday, October 8, 2003 11:41 AM -0400
From: John Fraizer <nanog at overkill.enterzone.net>
To: Owen DeLong <owen at delong.com>
Cc: Brian Bruns <bruns at 2mbit.com>, nanog at merit.edu, 
charles.cooper at cnet.com, cook at cookreport.com, nanog at merit.edu
Subject: Re: Verisign's public opinion play

Owen, et all:

I wrote a piece as soon as I read McLaughlin's PR spewage. I sent it to
the addresses I could find at cnet but, I have not geard from them.

PS: Owen, I don't have NANOG-post access.  Can you echo this to the list
for me?

Dear Editor,

In response to the article presented by Mark McLaughlin on October 6, 2003
at  CNET.News.Com, "Innovation and the Internet," I would like to present
the following rebuttal.

McLaughlin states when a user mistypes a URL and are presented with an
error, "That error page can lead to a dead end, with no options on how to
get to where you tried to go."  I guess we should thank our lucky stars
that VeriSign is there to save us from ourselves.  After all, none of us
are resourceful enough to actually look at the URL we typed and notice that
we have made a typo.  In the event that we are unsure of the exact domain
name, none of us are resourceful enough to consult Google, Yahoo or any one
of the numerous other search engines.  We will simply sit and stare at the
error page and our personal productivity will suddenly screech to a halt.
VeriSign to the rescue, right?  Not quite.

McLaughlin states that someone typos a domain name 20 million times per day
and that "people have used [Site Finder] more than 40 million times".
VeriSign deployed "Site Finder" on September 15th 2003, and subsequently
bowed to overwhelming public pressure to remove the wildcard entries in the
.COM and .NET DNS Zones that facilitated their directing "lost" users to
their "Site Finder" service on October 4th, 2003.  So, according to
McLaughlin's own numbers, over the 20-days that "Site Finder" was in
service, of the 400 million "typos" that VeriSign redirected to its "Site
Finder" service, only 10% of those who were redirected made use of the
service.  It would seem to me that this would indicate that 90% of the
users do not find the "Site Finder" service as useful.

McLaughlin goes on to say, "ICANN cast a vote last week for the status quo
by forcing VeriSign to shut down the service."  This is an inaccurate claim
and is obviously worded to incite the public perception that ICANN has
forced VeriSign to shut their "Site Finder" service down.  Nothing could be
further from the truth.  ICANN demanded that VeriSign remove the "wildcard"
records from the .COM and .NET DNS Zone files.  The "Site Finder" service
is still operational at http://sitefinder.verisign.com/ and any person who
desires to use that service can do so by simply typing that URL into their
browser.  The difference is that users are not being FORCED to use the "Site
Finder" service.

This brings us to a very important point - one that VeriSign, with much
help from the press, has gone to great lengths to obfuscate. "Wildcard"
records in the .COM and .NET DNS Zones are NOT the "Site Finder" service.
The wildcard records in question were implemented in the following form:

"*    IN    A     [IP address of Site Finder service]"

ICANN did not demand that VeriSign shut down it's "Site Finder" service.
They simply demanded that VeriSign remove the "wildcard" records from the
.COM and .NET TLD DNS Zones.

In operation, the existence of this record in the .COM and .NET DNS Zones
would cause any typo in the domain portion of a fully qualified domain name
to be redirected to an IP address operated by VeriSign on which they had
implemented their "Site Finder" service.  This "hijacking" of typos has
many security, privacy and interoperability implications, all of which
VeriSign have failed to address in a satisfactory manner.

(1) The "Site Finder" service is subject to "man-in-the-middle" type
attacks in which traffic to/from "Site Finder" can be intercepted.  For a
person using a web browser, this will expose information about the site(s)
they are attempting to access.  In the case of email, the entire contents
of an email message may be captured by a third party.  This email may very
well contain sensitive information that has now been compromised.  Prior to
the implementation of "wildcard" records in the .COM and .NET DNS Zones by
VeriSign, a simple typo in an email or URL did not expose users to this very
probable and easy to implement attack.

(2) Anthony F. Lo Cicero, Esq., on behalf of Register.com, outlined several
interoperability implications in his letter to Brian Davis, Esq., Chief
Litigation Counsel, VeriSign, Inc., dated September 19, 2003.  Lo Cicero
states, "As VeriSign is well aware, many registrars, including Register.com
have long-established business practices of disabling the DNS of
recently-expired domain names, as a means of notifying the customers of
their need to renew their registrations.  Contrary to its public claims,
VeriSigns SiteFinder service interferes with these active registrations,
hijacking their DNS and pointing them to a monetized search engine."  Lo
Cicero goes on to say, "Certain other names being redirected by VeriSign to
the SiteFinder web site are also active registrations for which the
registry fee has been paid.  For example, names for which customers have
chosen to disable the DNS and registrations that have been seized by
Register.com, and for which it has disabled the DNS, all now point to
SiteFinder."

(3) Dr. Paul Twomey, President and CEO, ICANN, in his letter dated
September 22, 2003 states, "Because the VeriSign Site Finder server makes
it appear that a non-existent domain exists, the service introduces
significant problems to the critical Internet infrastructure.  Many other
important Internet protocols rely heavily on proper DNS behavior.  The
impact of VeriSigns Site Finder is unclear with respect to security of the
DNS.  Site Finder unilaterally precludes the use of a prevalent type of
anti-spam filter that uses DNS to validate the domain of legitimate emails.
Because VeriSign's servers are authoritative for the .COM and .NET TLDs,
the most prevalent of the TLDs, Internet users have little protection
against the implication of this flawed system."

(4) Web browsers all over the world stopped displaying "page not found" in
the local language and character set of the users when given incorrect URLs
rooted under the .COM and .NET TLDs.   Instead, browsers presented an
English language search page from a web server operated by VeriSign.  For
visually impaired users who make use of computer generated voice software
to dictate the contents of web sites to them, the actions of VeriSign
present a significant barrier to their enjoyment of the Internet.  As
stated by the Internet Architecture Board on September 19, 2003, "Even if
these were acceptable changes, the new mechanism has poor scaling
properties, and unless the operator [VeriSign] chooses to invest
significant resources in maintaining a large, robust web server setup, the
user experience is going to get even worse: instead of either a local
language error message or an English search page, the user is going to get
'attempting to connect...' followed by a long wait."

(5) All email addressed to misspelled or nonexistent domains flowed to
VeriSign's server where it was bounced back to the sender.  This has many
ramifications.  Operators now have heavier mail handling load than they did
under the previous DNS operation where the email would be bounced locally.
Operators were dependent on the performance of the bounce server operated
by VeriSign.  If VeriSign's server slowed or failed, mail that would
previously have been bounced by the operators server would queue at the
SMTP relay for that relay's queue time before bouncing back to the user.
Emails that would have previously bounced back to the user immediately went
unnoticed for days while they sat in the SMTP delivery queue.  Operators
were also dependent on the correct operation of VeriSign's bounce server.
VeriSign's bounce server experienced bugs that caused mail that would have
previously bounced to not bounce at all and may have been reported to the
user as having been delivered when in all actuality, it simply vanished
without a trace.  In cases where domain owners had misconfigured backup
mail exchangers (MX's) with a particular MX pointing to a non-existent
domain name, mail that would have previously been eventually delivered
bounced.  If a user misconfigured their mail client to point to a
non-existent domain name, the client would connect to the bounce server and
be presented with an error indicating that the recipient address was wrong
when in all actuality, this was not the problem.

(6) Network printer configuration tools commonly check the validity of the
print spooler.  With VeriSign's wildcard records in place in the .COM and
.NET TLDs, an error that would have been reported early in the
configuration process would have only been noticed when printing failed to
work.  Additionally, it is quite possible that proprietary and confidential
information was routed to VeriSign's servers when users attempted to print
to misconfigured network printer spools.

(7) The wildcards installed in the .COM and .NET TLDs broke several simple
spam filtering techniques commonly used on mail servers as well as more
complex filtering that checked for the existence of a sending domain to
screen out obviously bogus senders.

(8) VeriSign intercepted HTTP and SMTP requests that were routed to their
server as a result of the wildcards they placed in the .COM and .NET TLDs.
The internet is much more than the Web and Email however.  FTP, Telnet and
SSH, as well as an enormous number of other protocols that are in use on
the internet that made connection attempts to a misspelled domain name
received at best a TCP reset message and in some cases, simply had their
packets dropped with no error.  Prior to VeriSign's implementation of the
wildcard records in the .NET and .COM TLDs, these attempts would have
received DNS error messages.  With VeriSign's wildcard scheme in place,
these messages were replaced by mysterious connection failures.

(9) The response from the VeriSign "Site Finder" service was typically
around 17000 bytes of information.  Prior to VeriSign's implementation of
wildcard records in the .COM and .NET TLDs, the user would have received a
response that was typically more than 10 times smaller.  In the case of
transfer based billing for Internet access (as in the case of most wireless
data services) the recipient had to pay significantly more in access
charges.

McLaughlin states, "ICANN appears to have bought into claims that the
Internet has broken or will break. Anyone who has used it in the last three
weeks knows that claim to be false. More likely, ICANN caved under the
pressure from some in the Internet community for whom this is a
technology-religion issue about whether the Internet should be used for
these purposes."

The claims that ICANN "bought into" are not unfounded or anecdotal.  They
are documented cases of previously functioning systems and protocols that
ceased to function as desired when VeriSign implemented the wildcard
records in the .COM and .NET TLDs.  VeriSign does NOT OWN .COM and .NET. -
They are entrusted with their stewardship.  Their actions with respect to
adding wildcard records to those Zones, with the purpose of profiting
millions of dollars by selling the traffic generated by typos under the
thin veil of "offering a service" was not consistent with the terms of
their contract.

DNS operates much in the same way that the telephone translations database
operates.  Much in the same manner that you receive a recorded announcement
indicating "the number you have dialed is not in service" if you dial a
non-existent telephone number, the DNS protocol presents a "no such name"
response when a lookup is performed against a non-existent domain name.
There would be bloody hell to pay if AT&T, for example, poisoned the
telephone translations database and routed all non-existent telephone
numbers to an automated "directory assistance" service that featured
recorded "commercials" from third parties yet, VeriSign seems to think it
is OK to do practically the same thing with the TLD DNS Zones for .COM and
.NET, sending all "typos" to their "Site Finder" server, complete with paid
advertisements and listings by third parties.

VeriSign has spared no expense in their attempts to sway public opinion.
They have tried to portray the image that they are being attacked for their
generous offering of the "Site Finder" service.  It would appear that a
staggering number of news outlets have bought into this obvious spin of the
facts.  I sincerely hope that you will publish this article so that the
general public has opportunity to digest the technical FACTS of the matter
to draw their own conclusions rather than basing those conclusions on
knee-jerk reactions to the fodder being spewed by the Public Relations army
at VeriSign.

Biography

John Fraizer is the President of EnterZone Network Services, LLC.  He is
also an active member of the Internet Security community.  Prior to
founding EnterZone, Fraizer worked for Digital Equipment Corporation and
Alltel Mobile Communications.  Fraizer is also an honorably discharged
United States Marine.

---------- End Forwarded Message ----------