- From: Eran Hammer-Lahav <eran@hueniverse.com>
- Date: Mon, 23 Feb 2009 11:26:25 -0700
- To: Adam Barth <w3c@adambarth.com>, Breno de Medeiros <breno@google.com>
- CC: Ben Laurie <benl@google.com>, Mark Nottingham <mnot@mnot.net>, "www-talk@w3.org" <www-talk@w3.org>
It is pretty irresponsible to talk about 'security' as if there is a well established standard applicable for the web as a whole. HTTP, as in RFC 2616, isn't secure at all. Even 2617 doesn't make things significantly better. Your entire approach is based on a very narrow viewpoint, biased by worries about known exploits specific to browsers. None of my use cases for host-meta even remotely care about browsers. Are you suggesting we revise HTTP to make it secure? /host-meta offers a simple mechanism to register metadata links. If you have specific application security needs, you need to address them at the appropriate level, that is, the application. If more than one application has the same needs, they can come together and propose a security extension of the /host-meta spec. Not supporting redirects is one such idea (though I find it utterly useless for security). But just for fun, how is a redirect any less secure than changing the content of the /host-meta document at its original URI? Either you know the host-meta file you found is what the host-owner intended or you don't. HTTP (which is really the only tool we are using here) doesn't offer you any such assurances. EHL > -----Original Message----- > From: adam@adambarth.com [mailto:adam@adambarth.com] On Behalf Of Adam > Barth > Sent: Monday, February 23, 2009 9:57 AM > To: Breno de Medeiros > Cc: Ben Laurie; Mark Nottingham; Eran Hammer-Lahav; www-talk@w3.org > Subject: Re: Origin vs Authority; use of HTTPS (draft-nottingham-site- > meta-01) > > On Mon, Feb 23, 2009 at 9:44 AM, Breno de Medeiros <breno@google.com> > wrote: > > On Mon, Feb 23, 2009 at 9:32 AM, Adam Barth <w3c@adambarth.com> > wrote: > >> 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? > > What's the point of standardizing host-meta if every application will > require different processing rules to suit its own needs? > Applications will interoperate better by simply ignoring host-meta and > inventing their own metadata repository. > > > 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? > > To be secure, a user agent should not follow redirects to obtain > host-meta, regardless of where those redirects lead. > > > There is enormous value in allowing redirects for host-meta. > Applications > > with higher levels of security should implement their own security > policies. > > If you follow your current trajectory and continue to compromise away > security, applications that require security will implement their own > version of host-meta that is designed to be secure from the ground up > instead of trying to track down and patch all the gotchas in > host-meta. Sadly, this will defeat the goal of having a central > metadata repository. > > Adam
Received on Monday, 23 February 2009 18:26:55 UTC