Re: HTML5 and Public Suffix

On Thu, 29 Jan 2009, Andrew Sullivan wrote:
> On Thu, Jan 29, 2009 at 08:16:30PM +0000, Ian Hickson wrote:
> > Our requirements are:
> > 
> >  * given a domain/hostname, it should be possible to determine if this is 
> >    a domain whose next level can have hosts from different authorities.
> >    Specifically, the desire here is to be able to distinguish 
> >    foo.example.com/bar.example.com (which is fine) from 
> >    example.com/sample.com (which is not).
> 
> But this is exactly the mistake.  The DNS is divided into zones for 
> administrative purposes _of the DNS_ (I'll call that dns-administrative 
> division).  There is nothing whatever about it that determines whether a 
> given zone is under the same authority-administrative control.  You 
> cannot get that information out of a DNS name, period.  It's not there, 
> and it never was there.

I'm not attempting to make any judgements on whether this is a good idea 
or not. I'm just speccing an already-existing API with an already-existing 
security model, and attempting to patch it up as best as possible to avoid 
blatent cross-site scripting attacks.


> To illustrate this, let's consider some use cases. In your example 
> foo.example.com and bar.example.com, let's substitute "blogspot" for 
> "example".  Is it ok now that these hosts are not considered to be "from 
> different authorities"?

Yes. It's Google's responsibility to ensure that the authors on those 
domains can't screw around with each other.


> If you think that one's ok, well, then, what about if we substitute 
> "dyndns.org" for "example.com"?

I don't think that's a particularly great case, no. dyndns.org sub-domains 
aren't safe from XSS attacks. It would be nice if they could be. Right 
now, the state of the art I have available to me in terms of what I can 
spec into HTML5 doesn't allow that. If it could, that would be awesome, 
and I would happily switch to it.

(There are other examples that I raised when the Public Suffix List was 
being discussed, like uk.com. It saddens me that there is no answer to 
these problems.)


> Ah, but now you will say, "Exactly.  This is what the list is supposed 
> to accomplish!"  But it doesn't, I submit, because you simply can't know 
> this from the labels.  Some of the zones inside dyndns.com probably 
> _are_ from the same authority, and ought perfectly well to be able to be 
> treated the same.  But this mechanism can't do it.

It's the best I know of so far. If there is something better, I'd be happy 
to use it.


> Moreover, what about the impending release of all the new TLDs?
> Imagine IBM buys one.  Do we somehow get ibm.com == .ibm as well?  If
> so, who maintains the list of equivalencies?

We don't need equivalencies; going forward, we can rely on cross-site 
communication like XHR2's Access-Control headers. Having said that, if we 
could get equivalencies that certainly would be pretty cool.


> The reason could only be because of the broken assumptions you're trying 
> to paper over: that there is some authority-administrative relationship 
> to be divined from labels in the DNS.

Yes, that is indeed the case. Unfortunately, those assumptions shipped 
over a decade ago and I am stuck with papering over them. :-(


> From the point of view of the consumer of the DNS, the protocol was 
> designed as a single tree without the kind of barrier markings that you 
> want.  All of the mechanisms I've seen so far to pull those barriers out 
> of the existing DNS are badly broken, because they either make a number 
> of assumptions about the way the DNS tree is broken up, or they have 
> what I regard as seriously objectionable social baggage (e.g. control 
> over the definition divorced from the registration and operation 
> authorities for the label in question), or both.

I don't have a horse in this race. If there's a better solution that 
works, I'm all for using it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 29 January 2009 21:28:31 UTC