Re: same-origin assertions in the DNS (Fwd: [apps-discuss] draft-sullivan-domain-origin-assert-00)

On Mon, May 07, 2012 at 04:30:34PM -0700, Eric Rescorla wrote:
> I guess I don't see anything wrong with this, but I don't see how it
> is going to be deployable, either. The sticking point is incremental
> deployment In the medium (arguably long) term a large fraction
> of browsers will not understand this mechanism (and an even
> larger one will likely not do DNSSEC). So, that means that any
> information published this way must also be replicated elsewhere,
> or the site won't be usable for a large fraction of browsers, which
> severely reduces the value of the mechanism for site operators.

Yeah, that's my worry too.  On the other hand, the existing public
suffix list is also broken.

For instance, the current list has a large number of entries of
domains held by Dyn (my employer), but not a list of similar entries
for at least some names offered by freedns.afraid.org.  We now know
that ICANN has at least 1200 pending applications for TLDs, which
they'll be awarding in batches starting some time in the next year;
the policies under all of those will also need to be reflected in the
publicsuffix list.  

The basic problem with the publicsuffix list is that it is metadata
about names that has no operational relationship to the operation of
the names themselves.  Moreover, someone who wants to abuse the name
relationships has an interest in retaining this broken linkage.  The
only way I can see that is to hook the metadata back up to the domain
name system itself, despite the barriers to adoption.  I'd certainly
be interested in better (and particularly, more deployable)
suggestions.  A previous suggestion I made, to put URIs to policies in
the DNS instead, was rejected by some people I discussed it with on
performance grounds: it'd take too long to get the data.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

Received on Wednesday, 9 May 2012 21:25:07 UTC