SiteFinder: the Verisign Slides
Steve Loughran writes "It's been pretty quiet in public on the SiteFinder front, but it does
not mean that VeriSign are accepting defeat.
On October 15, the ICANN Security and Stability committee met to discuss it, as
can be seen from the long
transcript. The new item from this is a VeriSign
review of Site Finder,
which is very interesting." Loughran further analyzes the Verisign presentation, below.
Some key points:
- English-only responses only merits a 'moderate' response. I am sure the rest of the world thinks their language is only 'moderately' important.
- A lot of problems are viewed as minor, fixable with 'user education' or 'application patch'. I wonder if DNS patches were the application VeriSign expected us to patch?
- Apparently most spam doesnt forge sender domains; only 3-5%. So checking domain validity doesn't help much as an effective spam filter. A SpamAssassin representative commented that there are so few invalid domains in their corpus is that they get filtered earlier, so this data may be bogus.
- An acknowledged troublespot could be automated HTTP programs getting confused by the new responses, but they hadn't heard of that, and using HTTP over port 80 in this way by automated tool is discouraged according to BCP 56 .
- User studies liked it, but since the core finding was "there's more functionality than you get with a 404 so it's helpful for me", the study may have been flawed. Site Finder did nothing for 404 pages, only for unknown hosts.
- Most of the problems with services such as SMTP relate to misconfigured systems, and these did not show up with the small scale tests VeriSign tried.
I myself am most offended by the "we shouldn't be automating access over port 80" comment. Hello? VeriSign? What do you think Web Services are?
While Site Finder was up, I tested how SOAP stacks handled misconfigured addresses: the results are published on xml.com. Both SOAP stacks tested choked on the 302 response, giving errors to the clients that are nowhere near user intelligible. So VeriSign are making things harder, despite their apparent obliviousness or denials. I shall be sharing my data with VeriSign, and encourage anyone else to do the same."
Yeah, they should have exported it to SVG using OpenOffice.org.
Here is the google html cache of it.
Phillip
PDF available here.
(posting anonymous - just say no to karma whoring)
I am sure that a lot of people will like Verisign's comments about handling traffic other than http.
Instead of returning a host not found, we will return another type of error (TCP reset for example) to the client application.
I know that some computer users know nothing about DNS, IP addresses, etc. But, who is there to say for sure that something will send a TCP reset? What if someone were to change it to now accept mail (using SMTP as an example)?
While it most likely won't happen, I can't trust these folks further than they can throw the person responsible for false renewal notices. I think the Verisign marketing departement takes the cake by coming up with the most destructive ideas to boost their bottom line.