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

On Wed, Aug 29, 2018 at 7:25 PM Erik Nygren <erik@nygren.org> wrote:

> 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.
>

I think this is a good idea. I'm somewhat embarrassed that we let it drop
~years ago when mnot@ made a similar proposal, but adding this kind of
opt-in tightening is an important part of any migration story away from
today's morass into a better world.

I'd like to do this in addition to introducing a new thing. :)


> 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).
>

As Martin noted, this will likely not get substantial adoption unless we
have ways to carve out specific cookies in order to allow them to bypass
the kinds of default protections the `Cookie-Limit` header expresses. For
example, folks often rely on a cookie set at the apex of a registrable
domain in order to push sign-in state across subdomains. There are good
reasons to encourage folks to migrate to a more explicit SSO model, but
doing it all in one step will be a tough sell.

(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.)
>

It's true that I don't want to put anything new into CSP. For completeness,
we also talked about Feature Policy as a delivery mechanism, but that
feature's developers aren't terribly interested in extending it past its
current focus on documents to include things like subresource requests.

A separate header makes sense to me. I'm not opposed to adding it to
rfc6265bis, with the caveat that it's already taken forever for me to find
bandwidth to work on that document. Now that +John Wilander
<wilander@apple.com> is joining in, perhaps things will go more smoothly?
Putting the header in a separate document seems equally reasonable, though
it might make it more difficult to introduce the kinds of `NotX` flags
we'll need.

-mike

>