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

From: Adam Barth <[email-masked]>
Date: Tue, 22 Dec 2015 21:12:01 -0800

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

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.

== 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: [/]-

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.

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 23 Dec 2015 06:48:26 +0100

Hi Adam,

> depreciate the scoping attributes.

I'm seeing some interesting points raised above. I've also been bothered
in the past by the fact that the client couldn't send back the attributes
so that the server could check where the cookie came from, and your proposal
indeed addresses this.

Sure, the syntax will cause some discussion, especially for those who
need to lookup cookies indexed by name, or those who have to rename them
on reverse-proxies because the application server doesn't know the public
name/port. But that's just something to keep in mind for the discussion
and which must not divert the work.

However I'm seeing new difficulties which can arise from this method,
the first one being the non-unicity of the cookies sent to the server.
For example, a client could now send :

  Cookie: [*.example.com:*]-SID=12345; [/foo/bar]-SID=12346; ['self']-SID=12347; [*.example.com]-SID=12348; [*.example.com:*]-SID=12349; [/foo/bar]-SID=12350

and create confusion on the server side. Some implementations may grab one
instance, other ones may grab another one. And this will definitely happen
based on the crap we're seeing in field (eg: servers sending back set-cookie
that concatenate all learned cookies, etc).

Based on Mike's and your proposal, I'm wondering if a solution would not
be to use special name cookies in addition to the regular ones to pass
back *all* attributes and even to help define new attributes. We could
have something like this :

  Set-Cookie: __SID=12345; secure; path=/; domain=example.com;

  Cookie: __SID=12345; __attr_secure__SID=1; __attr_path__SID=/; __attr_domain__SID=example.com; __attr_origin__SID=https://example.com

etc... The idea being that "__attr_<attribute_name>" being prefixed in
front of the cookie name in requests so that the client can pass the
attributes it learned. This way, a cookie learned from the wrong
location (eg: injected from HTTP, JS or anything) could be detected
and replaced by the server. And it still provides unicity on the cookie
names and value in the request.

Just my two cents,
Willy