Subject: [httpwg/http-extensions] Cookie removal algorithm (#494)

From: HTTP issue updates <[email-masked]>
Date: Thu, 15 Feb 2018 01:34:13 +0000 (UTC)

This foremost relates to the arbitrary limits that cookie stores place on cookies, both globally and per-domain.

RFC 6265 says the following:

>   At any time, the user agent MAY "remove excess cookies" from the
>   cookie store if the number of cookies sharing a domain field exceeds
>   some implementation-defined upper bound (such as 50 cookies).
>
>   At any time, the user agent MAY "remove excess cookies" from the
>   cookie store if the cookie store exceeds some predetermined upper
>   bound (such as 3000 cookies).
>
>   When the user agent removes excess cookies from the cookie store, the
>   user agent MUST evict cookies in the following priority order:
>
>   1.  Expired cookies.
>
>   2.  Cookies that share a domain field with more than a predetermined
>       number of other cookies.
>
>   3.  All cookies.
>
>   If two cookies have the same removal priority, the user agent MUST
>   evict the cookie with the earliest last-access date first.

We did some investigation into this and discovered some problems with this process as implemented.  Browsers tend to remove a fixed number of cookies once they hit storage limits.  From what I can tell, browsers sort by last-access, but remove up to a fixed number of cookies.

This is bad for the integrity of storage.  Retaining some, but not all cookies is a great recipe for getting incomplete state. That can be a security exposure. That was part of what made some of the attacks in [this paper](https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng.pdf) possible and motivated the the [leave-secure-cookies-alone](https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone) fix.

When we looked at this we first concluded on the following algorithm:

1. If cookies exceed the limit, remove all cookies for other domains (for `foo.example.com`, remove `(!foo).example.com` cookies, but not example.com cookies).
2. If cookies still exceed the limit, remove all cookies for other paths (for `foo.example.com/foo`, remove `foo.example.com/(!foo)`).
3. If cookies still exceed the limit, remove all related cookies (for `foo.example.com`, remove anything ending in `example.com`).

On review, I think that we can continue to use last-access date to drive this, with a much smaller change.  I'm proposing two small changes:

* Require that last-access is set to the same value for every accessed cookie when constructing the Cookie header field (the text currently says the "current date and time".

* Require that when an unexpired cookie is removed, require that all cookies that share a domain and have the same (or older) last-access date also be removed.

This ensures that if a site receives incomplete cookie state, then it is at least an incomplete state that might reasonably have been created by an adjacent site.  For example, say that `foo.example.com` installs and depends on cookies at `example.com`, then if `bar.example.com` triggers deletion, then it will remove only `foo.example.com` cookies.  It can't be perfect because there is a risk that `example.com` cookies are actually specific to `foo.example.com` and have an interdependency on `foo.example.com` cookies, but that's a risk we're already exposed to.

This can result in the same results as the algorithm I described above, but it also might allow for more granular removal.  For instance, if `1.example.com` through `9.example.com` are visited in that order and `9.example.com` causes cookies to exceed the limit, then cookies will be removed for `1.example.com` first The algorithm above would cause cookies for 1 through 8 to be removed at once, which is more severe than we need.

As the people driving this no longer work for Mozilla, I thought that I would record our conclusions.  I don't know if we have the resources to continue to investigate implementation, but I'm happy to create a PR for the relevant section if the WG thinks that this is a reasonable change.

I understand that @mikewest still prefers [cookie priorities](https://tools.ietf.org/html/draft-west-cookie-priority), but no one at Mozilla has any interest in that solution and it didn't seem to get any traction when we discussed it before.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/494