Re: Revising RFC6265 ("Cookies")

On 11/12/15, 4:16 PM, "Mark Nottingham" <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:

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

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:

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

Agreed.

On 11/13/15, 3:20 AM, "Cory Benfield" <cory@lukasa.co.uk<mailto:cory@lukasa.co.uk>> wrote:

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

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