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: Breno de Medeiros <breno@google.com>
Date: Mon, 23 Feb 2009 09:44:42 -0800
Message-ID: <29fb00360902230944h6c12d923rd4925925031e2107@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Ben Laurie <benl@google.com>, Mark Nottingham <mnot@mnot.net>, Eran Hammer-Lahav <eran@hueniverse.com>, "www-talk@w3.org" <www-talk@w3.org>
On Mon, Feb 23, 2009 at 9:32 AM, Adam Barth <w3c@adambarth.com> wrote:

> On Mon, Feb 23, 2009 at 5:38 AM, Ben Laurie <benl@google.com> wrote:
> > I don't see why - if www.us.example.com chooses to delegate to
> > www.hq.example.com, that that is its affair, not ours, surely?
> Following redirects is insecure for sites that let users configure
> redirects.
> Every time you trade away security like this, you make it more likely
> that host-meta will be unusable for secure metadata.  If host-meta is
> unsuitable for secure metadata, folks that require security will just
> work around host-meta by creating a "secure-meta."  I can't tell you
> which of the security compromises will cause this to happen.  Security
> is often a "death of a thousand paper cuts" that eventually add up to
> you being owned.

I don't understand this reasoning.

1. The host-meta spec allows delegation to other domains/hosts

2. Secure app does not allow redirection to other domains/hosts

3. Secure app does not use host-meta and instead secure-meta, as apposed to,
say, using host-meta and not following redirects to other sites?
For secure app to be secure re:no-redirect-rule it must in any way perform
the check that the redirection is to another realm, surely?

There is enormous value in allowing redirects for host-meta. Applications
with higher levels of security should implement their own security policies.

> Adam


+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
Received on Monday, 23 February 2009 17:45:28 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:31 UTC