Re: Harmonizing draft-west-cookie-prefixes-05 with the web origin concept

Thanks for your feedback, Adam. This is helpful. CCing Emily, who has put
together the implementation in Chrome that we're hoping to ship shortly.

Before diving into the issues and suggestions, I'd like to back up just a
moment: One of the things I like about the prefix proposal in
draft-west-cookie-prefixes is that it doesn't actually introduce anything
new. The behaviors required by the two defined prefixes are entirely
explained by the cookie flags that exist today, and are implemented by
simply requiring those flags to be present or absent in particular
combinations.  This means that cookies created with these prefixes will
behave exactly the same in today's browsers as they will in future browsers
that enforce restrictions on prefixed cookies. I think there's value there.

My intuition is that these two behaviors cover some large percentage of the
ways cookies are used today. My goal was to pave those cowpaths, not to
blaze new trails. I'd suggest that session management is probably ripe for
some trailblazing, but it's not clear to me that bending cookies around in
new directions is the best way of doing that. Personally, I'd like to
introduce as little new complexity as possible while addressing the most
dire needs.

On Wed, Dec 23, 2015 at 6:12 AM, Adam Barth <w3c@adambarth.com> wrote:

> == Issues with draft-west-cookie-prefixes-05 ==
>
> 1) As currently written, the __Secure- prefix is not as secure as the
> __Host- prefix because it supports the Domain attribute.  For example, if
> you wanted to recommend the most secure way to use cookies (including this
> feature), you'd recommend using __Host- rather than __Secure-.  In order
> for the names of the protocol elements to be self-describing, we should use
> __Secure- for the most secure option.
>

I understand the concern. On the other hand, we have a cookie attribute
named "secure", and it makes some degree of sense for the prefix to match
the attribute it requires. Do you have a suggestion for a name that would
force that flag to be set, while not causing the confusion you've flagged?


> 2) Even with these extensions, there's still no way to use cookies in a
> way that matches the web origin concept.  Specifically, even if you use
> __Host- and set all the attribute correctly, your cookies are still shared
> between all the ports on a given host, which is different than web origins
> because web origins are determined by the scheme, host, and port.  Security
> problems commonly arise because these sorts of "cracks" between different
> security models.  For better security, there should be a way to use cookies
> with a security model that matches up with web origins.
>

An earlier draft did define an "Origin" prefix. When I realized that that
was inaccurate I changed the prefix to "Host" to reflect the things that
status quo cookies could lock down without additions instead of adding
support for ports, due to the considerations noted at the top of this email.

I'm not fundamentally opposed to adding support for ports to (prefixed)
cookies if folks think that's a good use of our time. It doesn't seem like
it would be terribly difficult to do. It forgoes a bit of the simplicity of
the current draft, but might make up for it with the more robust alignment
with the origin model.


> == Proposal ==
>
> I'm sure there will be endless bikeshedding about the syntax for cookie
> prefixes, but I'd like to make a proposal for a slightly different syntax
> (with different semantics) that addresses the issues I've raised above:
>
> Set-Cookie: ['self']-SID=12345; Secure; Path=/
> Set-Cookie: [*.example.com]-SID=12345; Secure; Domain=example.com
> Set-Cookie: [*.example.com:*]-SID=12345; Secure; Domain=example.com
> Set-Cookie: [/foo/bar]-SID=12345; Secure; Path=/foo/bar
>
> In this approach, the cookie prefix indicates the scope of the cookie:
>
>  * In the first example, the prefix ['self']- restricts the scope of the
> cookie to the scheme, host, and port from which the cookie was set.
>  * In the second example, the cookie's scope is example.com and all of
> its subdomains, but restricted to the original port.
>  * In the third example, the scope is expanded to include all the ports.
>  * In the fourth example, the scope is the current scheme, host, and port
> as well as the path /foo/bar.
>
> I've borrowed the syntax from CSP's source-list: <
> http://www.w3.org/TR/CSP2/#source-list-syntax>.  Specifically, the
> grammar for what goes inside the brackets would be roughly:
>
> "'self'" / host-source / path-part
>
> Obviously, we can continue to bikeshed the syntax, but this syntax also
> lets you use a short sequence when you want to match the web origin
> exactly: [/]-
>

My initial reaction is that, aesthetically, this is a bit beyond the pale.
`__Secure-` is ugly, source lists are even uglier. :) More constructively,
I agree completely that the syntax is more expressive, but I wonder whether
it is helpful.

That is, it certainly gives the server more information about a particular
cookie's scope, but it's not clear to me that we'd actually want developers
to use many of the options it provides. For instance, I'd prefer to provide
no special affordance for the `path` attribute, because doing so encourages
the belief that there's a relevant security boundary between
`[origin]/path1` and `[origin]/path2`. Likewise, the `*.example.com` case
seems to encourage usage patterns that allow important data to slip between
origins in a way that I'd prefer to discourage.

Where would you expect to see this syntax used? Would it solve problems
that `__Secure` and `__Host` or `__Origin` wouldn't?

More controversially, we might want to make these prefixes *authoritative*
> for the scope, meaning they would override any scope-related cookie
> attributes.  In the near term, we would still recommend that servers send
> the cookie attributes as well as the prefixes, but having the prefixes
> override the attributes gives us the flexibility in the future to
> depreciate the scoping attributes.
>

Could you explain this a bit more? I don't follow what you mean by making
the prefixes authoritative for the scope.

Thanks!

-mike