Re: Fixing cookies (Re: Some half-baked thoughts about cookies.)

On Tue, Aug 28, 2018 at 3:28 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

> Resetting on this, because I want to make a meta-level comment after
> having spent some time thinking about it more.
>

I've also been thinking some on this and came to a similar conclusion as
Martin.
In particular, two big gaps we seem to face with Cookies today are:
* The defaults are generally unsafe (and/or surprising in ways cookies
differ from the Origin model).
* The available mitigations can only be applied when setting cookies,
meaning that sites/origins/domains have no way to control their exposure.

Ideally we'd find some way to transition to safer defaults, even if it
takes 10+ years to get there.  I suspect we'll have better luck if we can
provide a way to slowly migrate most sites to a safer default cookie
behavior than we'll have if we introduce a radically different programming
model (that may not cover many cookie use-cases).

Migrations to safer behavior are more likely to succeed if we have ways to
give service operators and application owners way of safely rolling out
those safer behaviors, rather than relying purely on client-side
deprecation.

One approach to consider would be to introduce an HSTS-style model to allow
sites to switch defaults to be more sticky in a stateful manner.  In
particular, to allow specifying that some of the rfc6265bis improvements
can be applied to a site in a sticky manner for some time period.

For example:

    Cookie-Limit: HostOnly; SecureDefault; ttl=604800

which would mean that for the next week cookies on that site would be
constrained to be host-only and the default would be "Secure".  Cookies set
on a broader domain would then not be sent to this origin, document.cookie
would be unable to set cookies with a Domain, and the default for HTTPS
cookies would be "Secure" even if that attribute was missing (or
maliciously removed, e.g., see resolved Chrome issue 244260).

Policy attributes to constrain behavior would be cumulative (ie, you can
add them with a TTL but they stick around until that TTL expires within
that context).

Operationally I'd expect operators would start with a low TTL for a policy
and crank them up over time.
(One could see extending this to also include properties such as a max
cookie lifetime.)

Having a mechanism such as this also means that site operators could start
to get behaviors such as "cookies-over-http-bad" without needing to wait
for browser adoption and/or without needing to enable HSTS.  The HTTP
cookie one is perhaps less compelling as HSTS exists, but there are other
controls like this where there may be a pattern of getting sites to deploy
a more secure profile for a bunch of years prior to client-side deprecation
of the less secure behaviors.

(There's been a discussion on the W3 AppSec forum around enabling servers
to constrain cookies to be site-specific.  This is somewhat of an
extrapolation from that.  On that thread Mike West indicated that CSP is
unlikely to get more added into it.  As a result it is unclear where the
best destination for something like this would be.  Given the special
history of cookies, a dedicated cookie-specific header/feature might almost
make sense.  I'm not sure if we'd be willing to put something like this
into rfc6265bis or if every little thing we add there will just make it
less likely to ever ship.)

      Erik