Subject: Revising RFC6265 ("Cookies")

From: Mark Nottingham <[email-masked]>
Date: Fri, 13 Nov 2015 11:16:17 +1100

As discussed in Yokohama, we have several proposals for modifying RFC6265 ('Cookies'), including:

 - https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone 
 - https://tools.ietf.org/html/draft-west-cookie-prefixes
 - https://tools.ietf.org/html/draft-west-first-party-cookies
 - https://tools.ietf.org/html/draft-west-origin-cookies

Additionally, there are a number of errata against the document:
  http://www.rfc-editor.org/errata_search.php?rfc=6265

A few notes:

* Our Area Director generally supports us taking on work on this specification.

* Because of the way that Cookies are defined, it's not practical to publish modifications to the algorithms as separate documents; rather, I strongly suspect we need to "open up" the Cookie specification itself to incorporate them.

* Many have argued that RFC6265 was more successful than previous efforts because it restricted itself to documenting current behaviours, rather than speculatively adopting what seems like "good ideas" at the time.

Keeping all of that that in mind, my current thinking is that we should:

1. Select a set of proposals (expressed as Internet Drafts) that reflect implementation experience
2. Once we have consensus on their contents, edit the Cookie specification itself to incorporate them, as well as the errata
3. Upon incorporation, go immediately to WGLC to confirm that the proposals have been correctly applied.

The tricky part here is determining what "reflects implementation experience," because some implementers may be reluctant to adopt a pre-standard spec, and because some of these proposals require implementation both on the client and server side (leave-secure-cookies-alone seeming to be the exception here). 

To aid that, I'd like to treat the Call for Adoption process for each proposal draft as a "call for intent to implement" -- with the idea that if we see a significant amount of interest by the relevant parties, that's a good sign for adoption. Then, we can work on the individual specifications in parallel with that implementation.

Importantly, we would NOT be taking non-editoral issues on the Cookie spec itself; changes would have to go through the draft proposal process outlined above.

Of course, we're not limited to the proposals listed above; if you have one, please submit a draft soon (or give me a heads up that you'll be doing so). Likewise, it may be that some of the proposals aren't ready for standardisation, but might be in the future; we're not limited to one revision. 

Does this approach make sense to everyone? 

Cheers,

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

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 13 Nov 2015 16:27:30 +1300

> * Many have argued that RFC6265 was more successful than previous efforts because it restricted itself to documenting current behaviours, rather than speculatively adopting what seems like "good id…

That was a good approach and it also worked well with the RFC2616 overhaul.

> 2. Once we have consensus on their contents, edit the Cookie
specification itself to incorporate them, as well as the errata
> The tricky part here is determining what "reflects implementation
experience," because some implementers may be reluctant to adopt a
pre-standard spec, and because some of these proposals require
implementation both on the client and server side
(leave-secure-cookies-alone seeming to be the exception here).
> 
> To aid that, I'd like to treat the Call for Adoption process for
> each
proposal draft as a "call for intent to implement" -- with the idea that
if we see a significant amount of interest by the relevant parties,
that's a good sign for adoption. Then, we can work on the individual
specifications in parallel with that implementation.
> 
> Importantly, we would NOT be taking non-editoral issues on the
> Cookie
spec itself; changes would have to go through the draft proposal process
outlined above.
> 
> Of course, we're not limited to the proposals listed above; if you
have one, please submit a draft soon (or give me a heads up that you'll
be doing so). Likewise, it may be that some of the proposals aren't
ready for standardisation, but might be in the future; we're not limited
to one revision.

> Does this approach make sense to everyone? 

For the most part. However, I think if we take on Cookies. Adding
non-editorial "good idea" improvement changes should not be prohibited
outright.

Instead we should treat the core spec updates the same way proposed for
the drafts. First get implementer agreement that the change is a
feasible idea, and running code out in the 'Net as widely as possible
converted to doing it that way before the document is altered.

So we would both get the "good idea" change happening, and a realistic
transition path that any remaining implementers can follow. ie. no more
pipe dreams. We want real change to improve Cookies. If that does not
happen this time so be it, we will at least not have made things worse
by adding bloat.

It will also allow us the approach of convincing bad behaviors to be
removed from implementations then the core spec to discourage future
reversions.

Amos

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 13 Nov 2015 09:01:43 +0100 (CET)

> * Our Area Director generally supports us taking on work on this specification.

I'm very positive to this!

> * Many have argued that RFC6265 was more successful than previous efforts 
> because it restricted itself to documenting current behaviours, rather than 
> speculatively adopting what seems like "good ideas" at the time.

I would agree. Writing down how the world looks is much easier than trying to 
agree on a way how it should be improved. Even though I'll also admit that I 
"lost" a few struggles in that spec on how to describe the current world. =)

Let me also just state some obvious facts about cookies from my perspective.

The by far the biggest challange with changing cookies is that the 
server-sides are very very disparate and have been re-implemented over and 
over again by thousands of developers. It is not an as homogeneous world as it 
is on the client-side where there's a smallish set (in the dozens range or so) 
of clients and libraries that cover a large portion of the users.

Thus, changing cookies is much more work in the server side in lots of custom 
written implementations. Work in this group or in the IETF in general has a 
problem to reach those server side developers.

To me, the most sensible way forward is to change cookies in a way that the 
existing server implementations keep working (mostly) the same and only 
introduce changes that will make cookies better for the ones that adopt the 
news. That will then also avoid us having browsers break popular lagacy sites 
to adopt the new cookie ways.

-- 

  / daniel.haxx.se

---

From: Cory Benfield <[email-masked]>
Date: Fri, 13 Nov 2015 11:20:06 +0000

> On 13 Nov 2015, at 08:01, Daniel Stenberg <[email-masked]> wrote:
> 

Me too.

> To me, the most sensible way forward is to change cookies in a way that the existing server implementations keep working (mostly) the same and only introduce changes that will make cookies better for the ones that adopt the news. That will then also avoid us having browsers break popular lagacy sites to adopt the new cookie ways.

I think Daniel is right here. Cookies in general are a massive can of worms, and I have no confidence whatsoever that we’d be able to introduce sweeping breaking changes, or even really any breaking changes at all. Clients will likely be prepared to support the new hotness, whatever that is, but servers and applications will gain absolutely nothing by doing so and will therefore probably simply not do it. For that reason, clients would continue to *also* support cookies, which means the status quo would continue and we’d have gained nothing.

Speaking to call for intent to implement, I think this is reasonable as well. If the rest of the WG decides that these are useful enhancements, I’m willing to do the work to provide them in the Python world at the very least.

Cory

---

From: "Hodges, Jeff" <[email-masked]>
Date: Fri, 13 Nov 2015 20:29:46 +0000

On 11/12/15, 4:16 PM, "Mark Nottingham" <[email-masked]<mailto:[email-masked]>> wrote:

also note that the above work is driven in part from some relatively recent research..

Zheng, X., Jiang, J., Liang, J., Duan, H., Chen, S., Wan, T., and N. Weaver, "Cookies Lack Integrity: Real-World Implications",  <https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng.pdf>.

The above-cited paper is worth reading in detail.

A few notes:

Agreed.

On 11/13/15, 3:20 AM, "Cory Benfield" <[email-masked]<mailto:[email-masked]>> wrote:

I think Daniel is right here. Cookies in general are a massive can of worms, and I have no confidence whatsoever that we'd be able to introduce sweeping breaking changes, or even really any breaking changes at all. Clients will likely be prepared to support the new hotness, whatever that is, but servers and applications will gain absolutely nothing by doing so

ah, not exactly so.  Some of the above proposed "patches" to RFC6265 address real-world security issues and thus I bet security-concious webapps will take advantage of them.

that said, I agree with the sentiment that we shouldn't (cannot) simply have user agents make changes that break server-side assumptions - that might cause even worse security issues than we presently have. We will need to proceed carefully, as mnot describes.

Also, this means the "intent to implement" includes both user agents and server-sides.

HTH,

=JeffH

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Nov 2015 12:42:58 -0800

> Also, this means the "intent to implement" includes both user agents and

Generally, yes.  But we're tentatively planning to ship
leave-secure-cookies-alone unilaterally based on what we are seeing in
terms of usage.  That is, given the Zheng paper, the breakage is a
small enough amount that we're willing to make that call.  I'm not
sure that's true of all browsers, and nothing is final until the code
has shipped.  I was hoping that we could have that conversation for
each of these changes.

For most of the other pieces, some indication of server support would
make a big difference.  If no server is going to use a feature, even
in principle, that would make us much less favourably inclined toward
doing the work.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Nov 2015 09:08:58 +1100

> On 14 Nov 2015, at 7:42 am, Martin Thomson <[email-masked]> wrote:
> 

Yep, that was what I was thinking (and AFAICT leave-secure-cookies-alone is the only one-sided proposal so far).

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 14 Nov 2015 08:43:55 +0100

On Fri, Nov 13, 2015 at 09:01:43AM +0100, Daniel Stenberg wrote:
> >because it restricted itself to documenting current behaviours, rather 
> >than speculatively adopting what seems like "good ideas" at the time.
> 
> I would agree. Writing down how the world looks is much easier than trying 
> to agree on a way how it should be improved.

Same here. 2965 was a failure because it tried to restart from scratch
with something clean, and nobody really adopted Cookie2.

(...)
> news. That will then also avoid us having browsers break popular lagacy 
> sites to adopt the new cookie ways.

That's very important otherwise it will not work. Server-side people are
willing to adopt new standards if they know that what they do remains
compatible with older browsers and doesn't cause bad behaviours. But it
takes time because not every application or component is updated at the
same time.

Willy

---

From: Mike West <[email-masked]>
Date: Fri, 27 Nov 2015 15:07:30 +0100

I'm glad to see that folks are generally supportive!

> in principle, that would make us much less favourably inclined toward

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/2PK3q_VE1rg
outlines Chrome's current plans on these drafts. We have implementations of
leave-secure-cookies-alone and cookie-prefixes done behind a flag. As
Martin suggested, Chrome is also leaning towards shipping
leave-secure-cookies-alone unilaterally; metrics from Chrome and Firefox
show something on the order of 0.02% of cookie set operations would be
effected, and the advantages seem at this point to greatly outweigh any
transitory breakage we would induce. We're poking at developers now to get
a feel for the impact, and we'll decide whether or not to ship the changes
based on that feedback.

first-party-cookies are 90% implemented behind a flag (we have some work to
do to catch up with the latest drafts), and folks like GitHub have been
experimenting with the server-side implementation for several months now.

Assuming cookie-prefixes ships, I don't think it's worth pursuing
origin-cookies, as the `$Host-` prefix does practically everything we'd
need. I've let that draft expire, but I'm happy to pick it up again if
folks disagree about it's cost/benefit ratio.

That said, feedback on those first three drafts in particular would be
greatly appreciated. I'd like to get them cleaned up to the point at which
this group would be comfortable issuing a call for adoption, as Mark
discussed earlier in the thread.

-mike