W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2009

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

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 11 Feb 2009 15:22:18 -0800
Message-ID: <7789133a0902111522m4666f69ag8550abebabd0f11d@mail.gmail.com>
To: Breno de Medeiros <breno@google.com>
Cc: Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>

On Wed, Feb 11, 2009 at 2:46 PM, Breno de Medeiros <breno@google.com> wrote:
> However, such applications could handle
> specifying content-type as a requirement, as Eran rightly pointed out.

Why force everyone interested in use case (1) to add this requirement?
 This will have two results:

1) Some application will forget to add this requirement and be
vulnerable to attack.

2) A service that requires the well-known Content-Type will not be
able to inter-operate with a server that takes advantage of the laxity
of this spec.

>> What is different about your
>> policy file system that will prevent you from falling into the same
>> trap?
> The difference being that cross-domain.xml is intended primarily for browser
> use and therefore optimization for that case sounds legitimate. This is not
> the case here.

We're discussing security-critical server-to-server discovery, which
is the first use-case you listed.

> Again, again, there is an application layer where browsers can implement
> such policies.

Sure, you can punt all security problems to the application layer
because I can't construct attacks without a complete system.

It sounds like there are three resolutions to this issues:

1) Require host-meta to be served with a particular, novel Content-Type.

2) Add a section to Security Considerations that explains that
applications using host-meta should consider adding requirement (1).

3) Ignore these attacks.

My opinion is that (3) will cause users of this spec a great deal of
pain.  I also think that (2) will cause users of this spec pain
because they'll ignore the warning and construct insecure systems.

By the way, there is a fourth solution, which I suspect you'll find
unappealing for the same reason you find (1) unappealing: use a method
other than GET to retrieve host-meta.  For example, CORS uses OPTIONS
for a similar purpose.

Received on Wednesday, 11 February 2009 23:23:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:07 UTC