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

[Eran Hammer-Lahav]

Thanks Adam.

> -----Original Message-----
> From: ietf-http-wg-request@... [mailto:ietf-http-wg-request@...]
> On Behalf Of Adam Barth
> Sent: Tuesday, February 10, 2009 8:58 AM
>
> Wow, this draft is scary.

No the emotion I was looking for but at least it moved you... :-)

> In particular, you should require that
> the host-meta file should be served with a specific mime type (ignore
> the response if the mime type is wrong.  This protects servers that
> let users upload content from having attackers upload a bogus
> host-meta file.

I am not sure the value added in security (which I find hard to buy) is worth excluding many hosting solutions where people not always have access to setting content-type headers. After all, focusing on an HTTP GET based solution was based on getting the most accessible approach.

> Also, if you want this feature to be useful for Web browsers, you
> should align the scope of the host-meta file with the notion or origin
> (not authority).

The scope is host/port/protocol. The protocol is not said explicitly but is very much implied. I'll leave it up to Mark to address wordings. As for the term 'origin', I rather do anything but get involved with another term at this point.

EHL

[Adam Barth-5]

On Tue, Feb 10, 2009 at 11:51 PM, Eran Hammer-Lahav <eran@...> wrote:

>> In particular, you should require that
>> the host-meta file should be served with a specific mime type (ignore
>> the response if the mime type is wrong.  This protects servers that
>> let users upload content from having attackers upload a bogus
>> host-meta file.
>
> I am not sure the value added in security (which I find hard to buy) is worth excluding many
> hosting solutions where people not always have access to setting content-type headers.
> After all, focusing on an HTTP GET based solution was based on getting the most
> accessible approach.

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.  For example,

$ wget http://mail.google.com/crossdomain.xml --save-headers
$ cat crossdomain.xml
HTTP/1.0 200 OK
Content-Type: text/x-cross-domain-policy
Last-Modified: Tue, 04 Mar 2008 21:38:05 GMT
Set-Cookie: ***REDACTED***
Date: Wed, 11 Feb 2009 18:07:40 GMT
Server: gws
Cache-Control: private, x-gzip-ok=""
Expires: Wed, 11 Feb 2009 18:07:40 GMT

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <site-control permitted-cross-domain-policies="by-content-type" />
</cross-domain-policy>

Google Gears has also recently issued a security patch enforcing the
same Content-Type checks to protect their users from similar attacks.

>> Also, if you want this feature to be useful for Web browsers, you
>> should align the scope of the host-meta file with the notion or origin
>> (not authority).
>
> The scope is host/port/protocol. The protocol is not said explicitly but is very much implied.
> I'll leave it up to Mark to address wordings. As for the term 'origin', I rather do anything but
> get involved with another term at this point.

I'd greatly prefer that is this was stated explicitly.  Why leave such
a critical security requirement implied?

Adam

[Adam Barth-5]

On Wed, Feb 11, 2009 at 10:14 AM, Adam Barth <w3c@...> 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

[Eran Hammer-Lahav]

How about clearly identifying the threat in the spec instead of making this a requirement?

EHL


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

On Tue, Feb 10, 2009 at 11:51 PM, Eran Hammer-Lahav <eran@...> wrote:
>> In particular, you should require that
>> the host-meta file should be served with a specific mime type (ignore
>> the response if the mime type is wrong.  This protects servers that
>> let users upload content from having attackers upload a bogus
>> host-meta file.
>
> I am not sure the value added in security (which I find hard to buy) is worth excluding many
> hosting solutions where people not always have access to setting content-type headers.
> After all, focusing on an HTTP GET based solution was based on getting the most
> accessible approach.

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.  For example,

$ wget http://mail.google.com/crossdomain.xml --save-headers
$ cat crossdomain.xml
HTTP/1.0 200 OK
Content-Type: text/x-cross-domain-policy
Last-Modified: Tue, 04 Mar 2008 21:38:05 GMT
Set-Cookie: ***REDACTED***
Date: Wed, 11 Feb 2009 18:07:40 GMT
Server: gws
Cache-Control: private, x-gzip-ok=""
Expires: Wed, 11 Feb 2009 18:07:40 GMT

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
  <site-control permitted-cross-domain-policies="by-content-type" />
</cross-domain-policy>

Google Gears has also recently issued a security patch enforcing the
same Content-Type checks to protect their users from similar attacks.

>> Also, if you want this feature to be useful for Web browsers, you
>> should align the scope of the host-meta file with the notion or origin
>> (not authority).
>
> The scope is host/port/protocol. The protocol is not said explicitly but is very much implied.
> I'll leave it up to Mark to address wordings. As for the term 'origin', I rather do anything but
> get involved with another term at this point.

I'd greatly prefer that is this was stated explicitly.  Why leave such
a critical security requirement implied?

Adam

[Eran Hammer-Lahav]

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@...> wrote:

On Wed, Feb 11, 2009 at 10:14 AM, Adam Barth <w3c@...> 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

[Adam Barth-5]

That would cause interoperability problems where user agents that care
about security would be incompatible with sites implemented with
insecure user agents in mind.  Based on past history, this leads to a
race to the bottom where no user agents can be both popular and
secure.


On Wed, Feb 11, 2009 at 11:46 AM, Eran Hammer-Lahav <eran@...> wrote:

> How about clearly identifying the threat in the spec instead of making this
> a requirement?
>
> EHL
>
>
> On 2/11/09 10:14 AM, "Adam Barth" <w3c@...> wrote:
>
> On Tue, Feb 10, 2009 at 11:51 PM, Eran Hammer-Lahav <eran@...>
> wrote:
>>> In particular, you should require that
>>> the host-meta file should be served with a specific mime type (ignore
>>> the response if the mime type is wrong.  This protects servers that
>>> let users upload content from having attackers upload a bogus
>>> host-meta file.
>>
>> I am not sure the value added in security (which I find hard to buy) is
>> worth excluding many
>> hosting solutions where people not always have access to setting
>> content-type headers.
>> After all, focusing on an HTTP GET based solution was based on getting the
>> most
>> accessible approach.
>
> 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.  For example,
>
> $ wget http://mail.google.com/crossdomain.xml --save-headers
> $ cat crossdomain.xml
> HTTP/1.0 200 OK
> Content-Type: text/x-cross-domain-policy
> Last-Modified: Tue, 04 Mar 2008 21:38:05 GMT
> Set-Cookie: ***REDACTED***
> Date: Wed, 11 Feb 2009 18:07:40 GMT
> Server: gws
> Cache-Control: private, x-gzip-ok=""
> Expires: Wed, 11 Feb 2009 18:07:40 GMT
>
> <?xml version="1.0"?>
> <!DOCTYPE cross-domain-policy SYSTEM
> "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
> <cross-domain-policy>
>   <site-control permitted-cross-domain-policies="by-content-type" />
> </cross-domain-policy>
>
> Google Gears has also recently issued a security patch enforcing the
> same Content-Type checks to protect their users from similar attacks.
>
>>> Also, if you want this feature to be useful for Web browsers, you
>>> should align the scope of the host-meta file with the notion or origin
>>> (not authority).
>>
>> The scope is host/port/protocol. The protocol is not said explicitly but
>> is very much implied.
>> I'll leave it up to Mark to address wordings. As for the term 'origin', I
>> rather do anything but
>> get involved with another term at this point.
>
> I'd greatly prefer that is this was stated explicitly.  Why leave such
> a critical security requirement implied?
>
> Adam
>
>

[Adam Barth-5]

On Wed, Feb 11, 2009 at 11:52 AM, Eran Hammer-Lahav <eran@...> wrote:
> Your approach is wrong. Host-meta should not be trying to address such
> security concerns.

Ignoring security problems doesn't make them go away.  It just means
you'll have to pay the piper more later.

> 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.

What's the point of a central metadata repository that can't handle
the most popular use case of metadata?

> 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.

Here's what I recommend:

1) Change the scope of the host-meta to default to the origin of the
URL from which it was retrieved (as computed by the algorithm in
draft-abarth-origin).

2) Let particular applications narrow this scope if they require
additional granularity.

Adam

[Eran Hammer-Lahav]

But you are missing the entire application layer here! A browser will not use host-meta. It will use an application spec that will use host-meta and that application, it security is a concern, will specify such requirements to ensure interoperability. It is not the job of host-meta to tell applications what is good for them.

EHL


On 2/11/09 12:27 PM, "Adam Barth" <w3c@...> wrote:

That would cause interoperability problems where user agents that care
about security would be incompatible with sites implemented with
insecure user agents in mind.  Based on past history, this leads to a
race to the bottom where no user agents can be both popular and
secure.


On Wed, Feb 11, 2009 at 11:46 AM, Eran Hammer-Lahav <eran@...> wrote:
> How about clearly identifying the threat in the spec instead of making this
> a requirement?
>
> EHL
>
>
> On 2/11/09 10:14 AM, "Adam Barth" <w3c@...> wrote:
>
> On Tue, Feb 10, 2009 at 11:51 PM, Eran Hammer-Lahav <eran@...>
> wrote:
>>> In particular, you should require that
>>> the host-meta file should be served with a specific mime type (ignore
>>> the response if the mime type is wrong.  This protects servers that
>>> let users upload content from having attackers upload a bogus
>>> host-meta file.
>>
>> I am not sure the value added in security (which I find hard to buy) is
>> worth excluding many
>> hosting solutions where people not always have access to setting
>> content-type headers.
>> After all, focusing on an HTTP GET based solution was based on getting the
>> most
>> accessible approach.
>
> 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.  For example,
>
> $ wget http://mail.google.com/crossdomain.xml --save-headers
> $ cat crossdomain.xml
> HTTP/1.0 200 OK
> Content-Type: text/x-cross-domain-policy
> Last-Modified: Tue, 04 Mar 2008 21:38:05 GMT
> Set-Cookie: ***REDACTED***
> Date: Wed, 11 Feb 2009 18:07:40 GMT
> Server: gws
> Cache-Control: private, x-gzip-ok=""
> Expires: Wed, 11 Feb 2009 18:07:40 GMT
>
> <?xml version="1.0"?>
> <!DOCTYPE cross-domain-policy SYSTEM
> "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
> <cross-domain-policy>
>   <site-control permitted-cross-domain-policies="by-content-type" />
> </cross-domain-policy>
>
> Google Gears has also recently issued a security patch enforcing the
> same Content-Type checks to protect their users from similar attacks.
>
>>> Also, if you want this feature to be useful for Web browsers, you
>>> should align the scope of the host-meta file with the notion or origin
>>> (not authority).
>>
>> The scope is host/port/protocol. The protocol is not said explicitly but
>> is very much implied.
>> I'll leave it up to Mark to address wordings. As for the term 'origin', I
>> rather do anything but
>> get involved with another term at this point.
>
> I'd greatly prefer that is this was stated explicitly.  Why leave such
> a critical security requirement implied?
>
> Adam
>
>

[Adam Barth-5]

On Wed, Feb 11, 2009 at 2:26 PM, Eran Hammer-Lahav <eran@...> wrote:
> But you are missing the entire application layer here! A browser will not
> use host-meta. It will use an application spec that will use host-meta and
> that application, it security is a concern, will specify such requirements
> to ensure interoperability. It is not the job of host-meta to tell
> applications what is good for them.

In that case, the draft should not define a default scope for
host-meta files at all.  Each application that uses the host-meta file
should define the scope that it finds most useful.

As currently written, the draft is downright dangerous because it
defines a scope that is almost (but not quite!) right for Web
browsers.

Adam

[mnot]

WRT DNS rebinding - my initial reaction is that this isn't the proper  
place to fix this problem; it's not unique by any means to this  
proposal.

My inclination, then, would be to note DNS rebinding as a risk in  
Security Considerations that prudent clients can protect themselves  
against, if necessary.

Luckily, the IETF has mechanisms in place to get security reviews of  
proposals, so we can avail ourselves of that to get more definitive  
advice.

Cheers,



On 12/02/2009, at 7:31 AM, Adam Barth wrote:

> On Wed, Feb 11, 2009 at 11:52 AM, Eran Hammer-Lahav <eran@...
> > wrote:
>> Your approach is wrong. Host-meta should not be trying to address  
>> such
>> security concerns.
>
> Ignoring security problems doesn't make them go away.  It just means
> you'll have to pay the piper more later.
>
>> 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.
>
> What's the point of a central metadata repository that can't handle
> the most popular use case of metadata?
>
>> 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.
>
> Here's what I recommend:
>
> 1) Change the scope of the host-meta to default to the origin of the
> URL from which it was retrieved (as computed by the algorithm in
> draft-abarth-origin).
>
> 2) Let particular applications narrow this scope if they require
> additional granularity.
>
> Adam

--
Mark Nottingham     http://www.mnot.net/

[mnot]

On 12/02/2009, at 5:26 AM, Adam Barth wrote:

> On Wed, Feb 11, 2009 at 10:14 AM, Adam Barth <w3c@...>  
> 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

 From that document;
> Valid content-type values are:
>
> • text/* (any text type)
> • application/xml
> • application/xhtml+xml

That's hardly "an explicit Content-Type"; it would be the default for  
a file with that name on the majority of servers on the planet; the  
only thing it's likely to affect is application/octet-stream, for  
those servers that don't have a clue about what XML is.

> 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, my experience with security work is that there always needs to  
be a trade-off with usability (both implementer and end-user). While  
DNS rebinding is a concerning attack for *some* use cases, it doesn't  
affect all uses of this proposal; making such a requirement would  
needlessly burden implementers (as you point out). It's a bad trade-off.

Cheers,


--
Mark Nottingham     http://www.mnot.net/

[Adam Barth-5]

On Thu, Feb 12, 2009 at 3:13 AM, Mark Nottingham <mnot@...> wrote:
> My inclination, then, would be to note DNS rebinding as a risk in Security
> Considerations that prudent clients can protect themselves against, if
> necessary.

That sounds reasonable.

On Thu, Feb 12, 2009 at 3:22 AM, Mark Nottingham <mnot@...> wrote:

> From that document;
>>
>> Valid content-type values are:
>>
>>        • text/* (any text type)
>>        • application/xml
>>        • application/xhtml+xml
>
> That's hardly "an explicit Content-Type"; it would be the default for a file
> with that name on the majority of servers on the planet; the only thing it's
> likely to affect is application/octet-stream, for those servers that don't
> have a clue about what XML is.

Interesting.  I wonder how they came up with this list.  The "text/*"
value is particularly unsettling.  /me should go hack them.

By the way, Breno asked for examples of sites were users can control
content at arbitrary paths.  Two extremely popular ones are MySpace
and Twitter.  For example, I signed up for a MySpace account at
http://www.myspace.com/hostmeta and I could do the same for Twitter.
As it happens, these two services don't let you pick URLs with a "-"
character in them, but I wouldn't hang my hat on that for security.

> Adam, my experience with security work is that there always needs to be a
> trade-off with usability (both implementer and end-user). While DNS
> rebinding is a concerning attack for *some* use cases, it doesn't affect all
> uses of this proposal; making such a requirement would needlessly burden
> implementers (as you point out). It's a bad trade-off.

I agree.  Certainly not every use case will care about DNS Rebinding.
Unfortunately, it will bite some application of host-meta at some
point.

Adam

[Breno de Medeiros]

Adam, did you try to create myspace.com/favicon.ico ?

You may not consider that a threat by companies do. If they were caught distributing illegal images to every browser that navigates to the root of their domain, they might be liable to crippling prosecution.

This is a common problem with all well-known-locations. That is why host-meta was written in a generic format so that it can be the _last_ well-known-location. WKLs are evil, but also necessary.

On Thu, Feb 12, 2009 at 10:10 AM, Adam Barth <w3c@...> wrote:

On Thu, Feb 12, 2009 at 3:13 AM, Mark Nottingham <mnot@...> wrote:
> My inclination, then, would be to note DNS rebinding as a risk in Security
> Considerations that prudent clients can protect themselves against, if
> necessary.

That sounds reasonable.

On Thu, Feb 12, 2009 at 3:22 AM, Mark Nottingham <mnot@...> wrote:
> From that document;
>>
>> Valid content-type values are:
>>
>>        • text/* (any text type)
>>        • application/xml
>>        • application/xhtml+xml
>
> That's hardly "an explicit Content-Type"; it would be the default for a file
> with that name on the majority of servers on the planet; the only thing it's
> likely to affect is application/octet-stream, for those servers that don't
> have a clue about what XML is.

Interesting.  I wonder how they came up with this list.  The "text/*"
value is particularly unsettling.  /me should go hack them.

By the way, Breno asked for examples of sites were users can control
content at arbitrary paths.  Two extremely popular ones are MySpace
and Twitter.  For example, I signed up for a MySpace account at
http://www.myspace.com/hostmeta and I could do the same for Twitter.
As it happens, these two services don't let you pick URLs with a "-"
character in them, but I wouldn't hang my hat on that for security.

> Adam, my experience with security work is that there always needs to be a
> trade-off with usability (both implementer and end-user). While DNS
> rebinding is a concerning attack for *some* use cases, it doesn't affect all
> uses of this proposal; making such a requirement would needlessly burden
> implementers (as you point out). It's a bad trade-off.

I agree.  Certainly not every use case will care about DNS Rebinding.
Unfortunately, it will bite some application of host-meta at some
point.

Adam

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[Adam Barth-5]

On Thu, Feb 12, 2009 at 11:38 AM, Breno de Medeiros <breno@...> wrote:
> Adam, did you try to create myspace.com/favicon.ico ?

I didn't try, but they already have their favicon there, so I suspect
it wouldn't work.

> You may not consider that a threat by companies do. If they were caught
> distributing illegal images to every browser that navigates to the root of
> their domain, they might be liable to crippling prosecution.

I mean, considering I can upload arbitrary images to my MySpace
profile, I doubt this would cause them much consternation.

> This is a common problem with all well-known-locations. That is why
> host-meta was written in a generic format so that it can be the _last_
> well-known-location. WKLs are evil, but also necessary.

Yeah, as I said in my first email, I think host-meta will be super useful.

Adam

[mnot]

Hi Adam,

I'm collecting changes for the next rev of the draft, and found this  
dangling:

On 12/02/2009, at 7:31 AM, Adam Barth wrote:

> Here's what I recommend:
>
> 1) Change the scope of the host-meta to default to the origin of the
> URL from which it was retrieved (as computed by the algorithm in
> draft-abarth-origin).


A common use case (we think) will be to have <http://www.us.example.com/host-meta 
 > HTTP redirect to <http://www.hq.example.com/host-meta>, or some  
other URI that's not on the same origin (as you defined it).

I think that the disconnect here is that your use case for 'origin'  
and this one -- while similar in many ways -- differ in this one, for  
good reasons.

We still intend, BTW, to re-introduce the protocol used to the mix, to  
disambiguate that point. It's just the redirect handling that's  
different.

As such, I'm wondering whether or not it's useful to use the term  
'origin' in this draft -- potentially going as far as renaming it  
(again!) to /origin-meta, although Eran is a bit concerned about  
confusing early adopters (with good cause, I think).

What are your thoughts?

Cheers,


--
Mark Nottingham     http://www.mnot.net/

[Adam Barth-5]

On Sun, Feb 22, 2009 at 6:14 PM, Mark Nottingham <mnot@...> wrote:
> A common use case (we think) will be to have
> <http://www.us.example.com/host-meta> HTTP redirect to
> <http://www.hq.example.com/host-meta>, or some other URI that's not on the
> same origin (as you defined it).

What behavior do you think is desirable here?  From a security point
of view, I would expect the host-meta from http://www.hq.example.com
to apply to http://www.hq.example.com (and not to
http://www.us.example.com).

> I think that the disconnect here is that your use case for 'origin' and this
> one -- while similar in many ways -- differ in this one, for good reasons.

I don't understand this comment.  In draft-abarth-origin, we need to
compute the origin of a HTTP request.  In this draft, we're interested
in computing the origin of an HTTP response.

> As such, I'm wondering whether or not it's useful to use the term 'origin'
> in this draft -- potentially going as far as renaming it (again!) to
> /origin-meta, although Eran is a bit concerned about confusing early
> adopters (with good cause, I think).

I don't have strong feelings about naming, but I wouldn't call it
origin-meta because different applications of the file might have
different (i.e., non-origin) scopes.

Adam

[Ben Laurie-3]

On Mon, Feb 23, 2009 at 7:10 AM, Adam Barth <w3c@...> wrote:

> On Sun, Feb 22, 2009 at 6:14 PM, Mark Nottingham <mnot@...> wrote:
>> A common use case (we think) will be to have
>> <http://www.us.example.com/host-meta> HTTP redirect to
>> <http://www.hq.example.com/host-meta>, or some other URI that's not on the
>> same origin (as you defined it).
>
> What behavior do you think is desirable here?  From a security point
> of view, I would expect the host-meta from http://www.hq.example.com
> to apply to http://www.hq.example.com (and not to
> http://www.us.example.com).

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?

It does complicate matters if you are expecting host-meta to be signed, though.

>
>> I think that the disconnect here is that your use case for 'origin' and this
>> one -- while similar in many ways -- differ in this one, for good reasons.
>
> I don't understand this comment.  In draft-abarth-origin, we need to
> compute the origin of a HTTP request.  In this draft, we're interested
> in computing the origin of an HTTP response.
>
>> As such, I'm wondering whether or not it's useful to use the term 'origin'
>> in this draft -- potentially going as far as renaming it (again!) to
>> /origin-meta, although Eran is a bit concerned about confusing early
>> adopters (with good cause, I think).
>
> I don't have strong feelings about naming, but I wouldn't call it
> origin-meta because different applications of the file might have
> different (i.e., non-origin) scopes.
>
> Adam
>
>

[Adam Barth-5]

On Mon, Feb 23, 2009 at 5:38 AM, Ben Laurie <benl@...> 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.

Adam

[Breno de Medeiros]

On Mon, Feb 23, 2009 at 9:32 AM, Adam Barth <w3c@...> wrote:

On Mon, Feb 23, 2009 at 5:38 AM, Ben Laurie <benl@...> 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

--
--Breno

[phone] desk
[phone] (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

[Adam Barth-5]

On Mon, Feb 23, 2009 at 9:44 AM, Breno de Medeiros <breno@...> wrote:

> On Mon, Feb 23, 2009 at 9:32 AM, Adam Barth <w3c@...> 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