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

Willy Tarreau <> Wed, 23 December 2015 05:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F157B1ACCED for <>; Tue, 22 Dec 2015 21:52:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BW0Cj2MCIszq for <>; Tue, 22 Dec 2015 21:52:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5D001A1B81 for <>; Tue, 22 Dec 2015 21:52:28 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1aBcIG-00058x-Th for; Wed, 23 Dec 2015 05:49:00 +0000
Resent-Date: Wed, 23 Dec 2015 05:49:00 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1aBcIA-00057E-FV for; Wed, 23 Dec 2015 05:48:54 +0000
Received: from ([] by with esmtp (Exim 4.80) (envelope-from <>) id 1aBcI6-0006iO-Ux for; Wed, 23 Dec 2015 05:48:53 +0000
Received: (from willy@localhost) by pcw.home.local (8.14.3/8.14.3/Submit) id tBN5mQXo008557; Wed, 23 Dec 2015 06:48:27 +0100
Date: Wed, 23 Dec 2015 06:48:26 +0100
From: Willy Tarreau <>
To: Adam Barth <>
Cc: httpbis <>
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.3
X-W3C-Hub-Spam-Report: AWL=1.276, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1aBcI6-0006iO-Ux 7162bc5af6d9566c4fffc6a9504379a0
Subject: Re: Harmonizing draft-west-cookie-prefixes-05 with the web origin concept
Archived-At: <>
X-Mailing-List: <> archive/latest/30820
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Adam,

On Tue, Dec 22, 2015 at 09:12:01PM -0800, Adam Barth 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.
> 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: [*]-SID=12345; Secure;
> Set-Cookie: [**]-SID=12345; Secure;
> 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 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: <
>>.  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.

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: [**]-SID=12345; [/foo/bar]-SID=12346; ['self']-SID=12347; [*]-SID=12348; [**]-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=/;;

  Cookie: __SID=12345; __attr_secure__SID=1; __attr_path__SID=/;; __attr_origin__SID=

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,