Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

Your approach is wrong. Host-meta should not be trying to address such security concerns. Applications making use of it should. There are plenty of applications where no one care about security. Obviously, crossdomain.xml needs to be secure, since, well, it is all about that. But copyright information about a side, or a summery of its content, or list of social networks with related features, are all examples where abuse is not likely to be part of the threat model.

An application which strict security requirement should pay attention to the experience you are referring to. We certainly agree on that. But that is application-specific.

EHL


On 2/11/09 10:26 AM, "Adam Barth" <w3c@adambarth.com> wrote:

On Wed, Feb 11, 2009 at 10:14 AM, Adam Barth <w3c@adambarth.com> wrote:
> Adobe found the security case compelling enough to break backwards
> compatibility in their crossdomain.xml policy file system to enforce
> this requirement.  Most serious Web sites opt-in to requiring an
> explicit Content-Type.

By the way, here's the chart of the various security protections Adobe
added to crossdomain.xml and which version they first appeared in:

http://www.adobe.com/devnet/flashplayer/articles/fplayer9-10_security.html

There is another one I forgot:

You need to restrict the scope of a host-meta file to a specific IP
address.  For example, if suppose you retrieve
http://example.com/host-meta from 123.123.123.123.  Now, you shouldn't
apply the information you get from that host-meta file to content
retrieved from 34.34.34.34.  You need to fetch another host-meta file
from that IP address.  If you don't do that, the host-meta file will
be vulnerable to DNS Rebinding.  For an explanation of how this caused
problems for crossdomain.xml, see:

http://www.adambarth.com/papers/2007/jackson-barth-bortz-shao-boneh.pdf

Sadly, this makes life much more complicated for implementers.  (Maybe
now you begin to see why this draft scares me.)

Adam