On Sun, 09 Nov 2008 00:30:54 +0100, Dean Anderson <[EMAIL PROTECTED]> 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 providing
the information (in a machinereadable fashion, at least), and
alternative
discovery 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: [EMAIL PROTECTED]
Opera Software ASA http://www.opera.com/
Phone: +47 24 16 42 60 Fax: +47 24 16 40 01
********************************************************************
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
