Subject: Calls for Adoption -- Cookie-Related Specifications

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Dec 2015 17:18:39 +1100

As discussed earlier <http://www.w3.org/mid/[email-masked]>, we are going to use a Call for Adoption process to assure that what we specify in terms of changes to Cookies -- if anything -- will actually get implemented.

Based on what we've talked about so far, I believe two specifications are ready for consideration:

* https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone-04
* https://tools.ietf.org/html/draft-west-cookie-prefixes-05

So, please discuss on-list:

1) Your intent to implement these specifications (or lack thereof). 
2) Your support for these specifications (or lack thereof).
3) Any other Internet-Drafts that you believe we should consider in a revision of the Cookie specification.

We'll talk about this over the next few weeks, and develop a plan for RFC6265bis based upon those discussions.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 22 Dec 2015 08:39:37 +0100 (CET)

> 2) Your support for these specifications (or lack thereof).

I particapted in the RFC 6265 process on the http-state list.

As the main author of curl and libcurl's cookie parser and logic, I completely 
sympathize and agree with what these drafts are set out to do and I will work 
on implementing them once we agree on the content.

I consider both of them to be clearly written and very good input for making a 
revised cookie spec. Not the least because they have a very small risk of 
actually damaging already deployed sites while adhering to them will improve 
future work.

-- 

  / daniel.haxx.se

---

From: Cory Benfield <[email-masked]>
Date: Tue, 22 Dec 2015 08:33:22 +0000

> On 22 Dec 2015, at 06:18, Mark Nottingham <[email-masked]> wrote:

As a core maintainer on the Python Requests project, I sympathise with and agree with the motivation behind these drafts. Once content is agreed, I’ll start working on adding support for them, both in the Python standard library and in Requests.

Cory

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 22 Dec 2015 10:41:55 +0100

> 2) Your support for these specifications (or lack thereof).

As the main author of haproxy, I definitely support these drafts which
go in the right direction when it comes to securing cookies. In their
current state these drafts apparently don't affect how haproxy uses
cookies, though if updates are needed, we'll have to perform them.

The drafts are quite clear and still open to improvements. I think that
adopting them will help quickly reaching consensus on these proposals.

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 22 Dec 2015 22:56:39 +1300

> adopting them will help quickly reaching consensus on these proposals.

As the maintainer for Squid, my position is the same as above.

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 22 Dec 2015 10:10:26 +0000

--------
>> 2) Your support for these specifications (or lack thereof).

I came to the same conclusion as Willy, there is no proxy involvement
for these drafts, so I'll cast a blank vote.

But I won't miss the chance to point out, that the reason these are
problems that needs fix^H^H^Hbanda^H^H^H^H^Hkludges in the first
place is that cookies are simply the wrong way to keep state.

State should be kept server-side where it belongs, indexed by a
client chosen nonce acting as session-identifier.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mike West <[email-masked]>
Date: Tue, 22 Dec 2015 15:07:06 +0100

On Tue, Dec 22, 2015 at 7:18 AM, Mark Nottingham <[email-masked]> wrote:

> As discussed earlier <
> http://www.w3.org/mid/[email-masked]>, we
> are going to use a Call for Adoption process to assure that what we specify
> in terms of changes to Cookies -- if anything -- will actually get
> implemented.
>

Chrome intends to ship initial implementations of both of these drafts in
~49 (~April, 2016).

I think they're pretty solid, and look forward to polishing them up with
the help of folks in this forum.

> revision of the Cookie specification.

I think https://tools.ietf.org/html/draft-west-origin-cookies-01 is more or
less completely obviated by cookie prefixes. I've let it expire, and don't
intend to pick it back up.

I think https://tools.ietf.org/html/draft-west-first-party-cookies is still
worth experimenting with, and have 90% of an implementation in Chrome
behind a flag. I wouldn't want to hold up progress on the two drafts you've
highlighted above, but I do think the notion is worth exploring.

-mike

---

From: Remy Lebeau <[email-masked]>
Date: Tue, 22 Dec 2015 13:45:20 -0800

I am the primary maintainer of Indy, a popular Internet protocols 
library for the Delphi/C++Builder community.  I implemented most of RFC 
6265 back in 2011 when it was still a draft, and then finalized in 
2012.  I have not updated my implementation since.  I, too, would like 
to wait for the latest drafts to be finalized before I start making more 
code changes.

Remy Lebeau
Lebeau Software

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Dec 2015 14:32:56 +1100

leave-secure-cookies-alone is a no-brainer for me.  I think that
Firefox intends to implement it soon-ish, but I'm not tracking it
closely.

I have more trouble with the prefixes.  However, I think that the
working group should still adopt the draft.

If we have LSCA, then I find the incremental value of __Secure- to be
limited.  Unless I'm being daft, isn't __Secure- just a safeguard
against forgetting to include the Secure flag when setting the cookie?

The choices for __Host- are good from a host perspective, but the Path
restriction doesn't carry any justification and I can't think of any
justification.

Upthread, Mike states:
> I think https://tools.ietf.org/html/draft-west-origin-cookies-01 is more or less completely obviated by cookie prefixes.

This isn't correct because __Host- doesn't bind to the port number.
Though maybe it should (or we should define an __Origin- prefix
instead).

On 23 December 2015 at 08:45, Remy Lebeau <[email-masked]> wrote:
> I am the primary maintainer of Indy, a popular Internet protocols library
> for the Delphi/C++Builder community.  I implemented most of RFC 6265 back in
> 2011 when it was still a draft, and then finalized in 2012.  I have not
> updated my implementation since.  I, too, would like to wait for the latest
> drafts to be finalized before I start making more code changes.
>
> Remy Lebeau
> Lebeau Software
>
>
>> As discussed earlier
>> <http://www.w3.org/mid/[email-masked]>, we

---

From: Mike West <[email-masked]>
Date: Wed, 23 Dec 2015 08:38:27 +0100

> against forgetting to include the Secure flag when setting the cookie?

It's also an assurance that the cookie couldn't have been set from a
non-secure origin. That is, given these two drafts, it's impossible for `
http://example.com/` to set a `__Secure-*` cookie, so `https://example.com/`
has a high degree of assurance that such a cookie is its own.

> restriction doesn't carry any justification and I can't think of any

You're right; I did a poor job explaining that choice. In short, the set of
flags that `__Host-*` mandates are as close as we can get to aligning
cookies with the web's general same-origin policy without adding new
behaviors. By locking them to a host, ensuring that the secure flag is set,
and ensuring that the path is scoped to the root of the host, we have a
pretty good approximation of an origin-bound cookie, that doesn't attempt
to pretend that there's a defensible security boundary between
`[origin]/path1` and `[origin]/path2`.

> Upthread, Mike states:
> > I think https://tools.ietf.org/html/draft-west-origin-cookies-01 is
> more or less completely obviated by cookie prefixes.
>

Right. It "more or less" obviates origin cookies because the hole it leaves
is fairly small. That is, the attack scenario is one in which an attacker
controls a server running on a different port than the application, and can
assert ownership of the host by negotiating a TLS handshake (because of
`secure`). The nice thing about prefixes at the moment is that they only
cement into place behaviors that exist and are widely supported today. It's
not clear to me that closing that hole is worth adding complexity and
backwards incompatible behaviors to cookies' implementation.

Happy to have that discussion though. If I'm missing things, I'm happy to
revive the draft in one form or another.

-mike

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Dec 2015 20:03:57 +1100

On 23 December 2015 at 18:38, Mike West <[email-masked]> wrote:
> non-secure origin. That is, given these two drafts, it's impossible for
> `http://example.com/` to set a `__Secure-*` cookie, so
> `https://example.com/` has a high degree of assurance that such a cookie is
> its own.

Right, that's the hole that Adam pointed out with leave-secure-cookies-alone.

The idea occurs that perhaps it would be possible to avoid making the
same mistake by expressing a origin-wide policy that said "all my
cookies are secure".  The consequence of that being that attempts to
set cookies without Secure fail and only cookies with Secure are sent.

I can also imagine a similar expression being made with respect to
cookies from other names or ports or ....

I'm sure that you've heard that suggestion before.  CSP is one option,
a __Cookie-Policy="" cookie being another possibility.

...
> revive the draft in one form or another.

I think that I can accept that, if we also accept that origin cookies
are out.  But, I think that the alignment with the web security model
is actually important and I would rather have __Origin- with its
associated changes to the storage model than __Host-.  It just seems
like __Host- is a half-measure.