On Sun, 09 Nov 2008 00:30:54 +0100, Dean Anderson <dean at av8.com> wrote:
On Sat, 8 Nov 2008, Yngve N. Pettersen (Developer Opera Software ASA) wrote:> So in this case, Opera is creating and maintaining a list, and > offering it to their clients. Other software, including non-browser > software, will have to do the same. The problem is that if TLD's do > not implement a universal dicovery method, any fancy protocol will > come to "someone is making a list somewhere and you need to know > this person and trust them". It also Which is what is currently happening, because the TLDs are not providingthe information (in a machinereadable fashion, at least), and alternativediscovery and database building methods (crowdsourcing) are being used.The TLD's cannot provide this information, since they don't know it themselves. What you are trying to do with 'crowdsourcing' is no different from early anti-spam efforts (that also failed). There is no reliable source of the information you seek outside the admin domains themselves. The TLDs aren't the same as the admin domains, and don't know if, say, bankamerica.com is the same as bankofamerica.com, nor if wachovia.com was bought by wellsfargo.com and so are now the same admin domain.
As an example, the dot-UK registry _ought_ to know that all second level domains in the dot-UK hierarchy are registry-like, except (possibly) parliament.uk and maybe a few others, and should be able to create a specification for that. Similarly, the dot-US registory should be able to provide a list of all state.us, city.state.us, etc. registry-like domains.
What I am after is a blacklist of registry-like domains, for example co.uk, ac.uk, uk.com, ny.us, vgs.no, not a list stating that example.co.uk is an ordinary domain (unless it is an exception on its level of the hierarchy, and it is more efficient to list the exceptions than the registrylike domains), such as www.co.uk and vg.no are ordinary "website" domains. In fact, the less "ordinary" domains there are in the list, the better.
As for cookie encryption: Can't be enforced, and won't work in any case. Just as an example, consider a session fixation attack from one example1.la.ca.us against another site example2.sf.ca.us via the ca.us domain (aka replay attack; the cookie will be recognized by the site since it IS valid, even when encrypted by the site for itself). Another example is that websites could use such wide distribution for some types of tracking of visitors.
And I repeat: Cookies is just one area of at least four that I am aware of where the information covered by my draft is requested, and that is not counting indications I have heard about at least one spec within the IETF itself (DKIM) where information about the structure (to my understanding) might be helpful.
-- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve at opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ DNSOP mailing list DNSOP at ietf.org https://www.ietf.org/mailman/listinfo/dnsop