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

["Emily Stark (Dunn)" <[e-mail]>]

On Thu, Jan 7, 2016 at 7:36 AM, Mike West <[e-mail]> wrote:

> 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 <[e-mail]> 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?
>

I know these are ugly, so don't throw eggs at me, but I would maybe suggest
__RequireSecureFlag- and __RequireHostScoped- ...? On the plus side,
they're more descriptive, but they are definitely longer and uglier.


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