Potential changes to cookies in Chrome.

Hello, security-dev@! (And _secretly_ hello to net-dev@, blink-dev@,
dev-security@lists.mozilla.org, and public-webappsec@w3.org, who I've BCC'd)

Cookies are a bit of a rough edge on the web's security model. They don't
respect the same origin policy, and the disconnect between their
persistence model and that of the rest of the platform causes no end of
teeth-gnashing and hair-pulling among developers and auditors alike. We're
planning a few changes to bring things into something more closely
resembling alignment:

1.  `secure` ought to mean "secure": Though it's well-known that cookies
cross back and forth over protocol boundaries, recent research
<https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng.pdf>
from
Zheng, et al. has highlighted the fact that this behavior remains
surprising to developers, and also that there's little practical recourse
without changes in the browser.

We intend to make it more difficult for non-secure origins to influence the
state of secure origins by preventing non-secure origins from writing
cookies with a 'secure' flag and overwriting cookies whose 'secure' flag is
set. We're also planning to tweak the eviction rules to ensure that a
host's non-secure cookies are removed before its secure cookies. These
changes are spelled out in more technical detail in an Internet Draft
<https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone> we've
submitted to the IETF for consideration.

The metrics we've gathered show impact to about 0.02% of `Set-Cookie`
operations. Those numbers exclude deletions. Mozilla's metrics
<https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2015-11-19&keys=__none__!__none__!__none__&max_channel_version=release%252F42&measure=COOKIE_SCHEME_SECURITY&min_channel_version=null&product=Firefox!Fennec&sanitize=1&sort_keys=submissions&start_date=2015-10-29&table=0&trim=1&use_submission_date=0>
show similar impact (and include deletions). We don't have metrics

2.  "secureness" should be verifiable from the server-side: We've
implemented Eric Lawrence's clever Cookie Prefixes proposal
<http://textslashplain.com/2015/10/09/duct-tape-and-baling-wirecookie-prefixes/>
as a lightweight mechanism which gives servers the ability to assert
certain properties about cookies they set and receive.

In short, cookies whose names begin with `$Secure-` may only be set from
secure origins, and must have the `secure` flag. Cookies whose names begin
with `$Host-` have the same restrictions, and must additionally have a path
of `/` and no `domain` attribute. This brings them as close to the
same-origin policy as we can get with existing attributes. These changes
are likewise spelled out in more technical detail in the Internet Draft
<https://tools.ietf.org/html/draft-west-cookie-prefixes> we've submitted.

3. Ambient authority should have an opt-out: We're looking at ways to deal
with the CSRF risks that cookies' ambient authority present. We have a
mostly-complete implementation of First-Party-Only cookies
<https://tools.ietf.org/html/draft-west-first-party-cookies>, which gives
servers the ability to assert that a particular cookie ought only be sent
in a "first-party" context by appending a `first-party-only` flag to the
`Set-Cookie` operation. The hope is that this will make certain kinds of
attacks significantly more difficult by preventing `third-party.com` from
making authenticated requests against `first-party.com`'s endpoints. Again,
details are in the Internet Draft
<https://tools.ietf.org/html/draft-west-first-party-cookies>.

---

All of these new behaviors are currently implemented behind
chrome://flags/#enable-experimental-web-platform-features in Chrome Canary.
We welcome your experimentation and feedback. These are currently targeting
Chrome 49 (which would hit stable in the March/April timeframe), but that's
somewhat dependent on the feedback we get, both from Blink's owners
<http://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process> when we
issue an intent to ship, and from developers at large.

WDYT, folks?

-mike