Re: Origin cookies

Thanks again for your feedback!

On Fri, Oct 24, 2014 at 6:22 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 24 October 2014 03:06, Mike West <mkwst@google.com> wrote:
> > I agree, however, that the document's examples should be more realistic,
> and
> > should set at least the `Secure` attribute.
>
> That's only one scope-limiting attribute.  You aren't looking to alter
> Path, but there is also HttpOnly.  And then there's the fact that
> cookies historically don't consider port number.
>

1. I'd contest `Path` having any security value at all. :)
2. HttpOnly is quite often valuable. The current draft sets it by default
for origin cookies.
3. Ports are ignored completely, true. There's no mechanism for restricting
ports in today's world. That's bad, but it's the world we've created.

In short; I agree with you that the examples should be updated to include
`Secure` and `HttpOnly`. Leaving out `domain` was intentional, as that
creates a host-only cookie. I've taken a stab at this in
https://github.com/mikewest/internetdrafts/commit/08af3b106782b399268248685d7a5bd213556c6e.
WDYT?

My point here is that you can't safely add something that attempts to
> limit the scope of applicability if it relies on an attribute that
> will be ignored by old implementations.


I think it's much more difficult to get adoption of a feature that tries to
break substantially new ground, as opposed to that same feature layered on
top of existing infrastructure. I see the fact that this falls back
gracefully to status quo as a benefit, not a cost.


>   That means I'm having trouble
> reconciling the design with the fact that confidentiality is an
> important characteristic of cookies.  You wouldn't be able to rely on
> the Origin attribute being honoured, not ever, which makes me sad.
>

I don't understand this argument: you can rely on cookies being limited to
an origin by user agents that support such a concept. You can distinguish
such user agents by looking for an `Origin-Cookie` header, and _only_ sift
through the `Origin-Cookie` header for those agents.

For all other user agents, you get no change from status quo. That seems
like a reasonable path forward.


> The alternative is to ensure that your new stuff is completely ignored
> by old implementations.  There are plenty of options here: you could
> add a value to the Origin attribute, or use a new header field to set
> the value... I recognize that introduces a pretty dire failure mode
> (see Cake).
>

That would certainly add implementation cost, but it's not clear what the
benefit would be. How would one be more able to rely on origin cookies if
we used `Set-Cake-Key` instead of `Set-Cookie`?


> > If we wish to defend against the kinds of annoyances that GitHub
> eloquently
> > documented at https://github.com/blog/1466-yummy-cookies-across-domains,
> > then we need to offer the website the ability to distinguish between
> cookies
> > set by its own origin, and cookies which might have been set by a
> subdomain.
>
> Yeah, maybe we need a way for an origin to block cookies from subdomains.
>

Mark Nottingham has proposed a Content Security Policy directive in the
WebAppSec WG. That sounds like a very reasonable thing to consider.


> Well, it's a cookie, so presumably there's ways to mark cookies that
> were intended to be origin-bound in a way that can be detected by the
> origin.  It's disgustingly inefficient, but I've used a MAC in the
> past (I'm sure that you are aware of the Macaroon work here).
>

Yes. Individual sites can certainly munge cookie values in various ways in
order to prove to themselves that the cookie's value is theirs and no one
else's. That doesn't help with the various cookie tossing annoyances out
there, but it's a good status quo strategy.

-mike