[IP] VeriSign prepares to relaunch "Site Finder" -- calls

Tue Feb 10 15:11:45 UTC 2004

At 08:37 PM 2/9/2004, Paul Vixie wrote:
>  the response you included...
>
> > > There's an easy way to kill sitefinder stone cold dead.
> > > ...
> > > It would be trivial to create a bot to start walking through every
> > > possible 20 letter domain name - and if ICANN held them to the rules,
> > > Verisign would be rather poorer in short order.
>
>...does not describe an operational problem, and gives a financial remedy.

It's apparent that some of today's network operation problems simply do not 
have an "operational" solution - but these problems are still network 
operational in nature even if the solution is not operational in nature.

Take spam, for example.  We are mere weeks from the 10 year anniversary of 
Canter and Siegel's green card spam of April 1994.  The network operations 
community has been trying to develop and implement an "operational fix" for 
this problem ever since; instead the problem exponentially grows worse.  It 
has become clear that the only possible technical solution to spam will be 
one that replaces our present Simple Mail Transport Protocol with something 
else - something certainly less simple - even if it's just an end-to-end 
authentication protocol laid over the present SMTP.

Just as Canter and Siegel's green card spam was a novel way to (ab)use SMTP 
for Canter and Siegel's profit, ten years later Verisign develops 
Sitefinder [1] - a novel way to (ab)use DNS requests for Verisign's 
profit.  Both are abuses because they break the existing protocol - making 
it less functional for those who use it the way it was designed to be 
used.  Both require that network operators patch their systems to try to 
keep the abuse from negatively impacting their networks.  Just as spammers 
keep on finding ways around the anti-spam patches, expect to see Verisign 
find and implement new ways around anti-Sitefinder "patches".  Whack-A-Mole 
over DNS, here we come.

Those who do not know their history are doomed to repeat it.

I believe that there is no good "operational" way to solve either problem.

It is my opinion that we will not solve the spam problem until we do one of 
two things:  Change the protocol so that spam is simply no longer possible, 
or change the financial cost of spam via legal remedies (fines and jail 
terms) worldwide, along with courage and resolve to enforce those remedies 
(worldwide).  It is also my opinion that we will not solve the Sitefinder 
problem without resorting to a similar financial sword, as Verisign has 
shown no signs of caring what the operational community says about the 
wisdom of their breaking this key fundamental infrastructure protocol for 
their selfish corporate financial gain.  Changing DNS worldwide so that 
Sitefinder is impossible would be impossibly and horribly painful - we 
haven't managed to change email to a secure protocol despite 10 years of 
abuse so what chance do we have of changing DNS?

The biggest problem with the proposed "financial" solution is that it 
assumes that ICANN has the courage and resolve to enforce their contract 
with Verisign.  If ICANN was interested in firmly enforcing their contract 
with Verisign, they could simply yank the root database management contract 
from Verisign, citing the several well documented instances of Verisign 
failing to properly manage this public resource as a public trust and 
instead using it as their "owned" property.  In reality, ICANN is useless 
and powerless because key people do not have the courage or resolve to take 
strong action when strong action is clearly called for.

If this isn't a call to arms to everyone in the operational community to 
take back control over ICANN, I don't know what is.

jc

[1]  Where I use "Sitefinder", I am referring to Verisign's entire project 
of adding wildcard records to .com and then pointing all the NXDOMAIN 
domain records to the Sitefinder service.

--

p.s.  Please do not cc me on replies to the list.  Please reply to the list 
only, or to me only (as you prefer) but not to both.  