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:

1. English-only responses only merits a 'moderate' response. I am sure the rest of the world thinks their language is only 'moderately' important.
2. 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?
3. 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.
4. 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 .
5. 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.
6. 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.

After the presentation, the transcript shows some good feedback from the audience -ripping into the end user survey, for example, and trying to understand the relationship with other registrars. It is notable that the only two user groups considered are (a) registrars and (b) end users. The wants and needs of people who implement networked applications or support them are neglected because we are seemingly invisible.

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."

Comments

Re:Verisign's view on potential issues:

[steve_l]

Yes, it would be funny if it wasnt true. In exchange for the search revenue they are prepared to break everything.

Only one person in the transcript (read it, if you havent), asked 'what about the app developers -dont you have an implicit contract not to return wildcards', and Verisign replied "we only care about the standards", meaning no.

So the people who write the apps that make DNS lookups dont get consulted, dont get listened to, just get given extra work.

Yet if hadnt been for the app developers, the DNS business would be nothing. They should recognise that we dont need to use DNS, and if they try hard we can use alternate directory mechanisms: DOI, google, UDDI, IM directories even napster usernames are alternatives.