Re: Some half-baked thoughts about cookies.

On Wed, Aug 15, 2018 at 9:18 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Wed, Aug 15, 2018 at 4:05 PM Daniel Stenberg <daniel@haxx.se> wrote:
> > So, looking into the crystal ball, won't this lead to clients using both
> > cookies *and* Sec-HTTP-State ?
>
> To Daniel's point here (and Mark said something similar), this does
> several things at once.  It removes the option for state offload at
> the HTTP layer in favor of a (long) fixed string.  It also resets the
> scope of identifiers that can be persisted.
>
> I really like the idea of narrowing the scope problem of cookies;
> cookies are awful, mostly because they cross origin boundaries in
> awful ways.  And document.cookie is similarly terrible.  Bundling
> those two changes with the removal of state offload might be too much
> though.  Other HTTP clients don't have indexedDB or service workers to
> fall back on for this use case.
>

That's a very reasonable point.

I've gone back and forth a few times about what changes would be good to
push for here (https://github.com/mikewest/http-state-tokens#pivot-points
outlines some of those considerations). My intuition is that it would be
better to try something with more radical properties if we're confident
that the radical thing would actually be better than the status quo. I
agree with you, however, that more radical proposals will have longer and
shallower adoption curves, and that we might end up in a world with both
the old thing and the new thing. Cookies' ubiquity make that a pretty
likely outcome, honestly, regardless of the new thing's amazing properties.

My hope is that having a new thing will allow us to ratchet down on the old
thing more aggressively than we'd be able to otherwise.

Cookies are - from the perspective of a user - superior in almost
> every way.


Superior in what sense?


> The CSRF benefits here seem fairly hard to get excited
> about enough to use this new, more limited thing.  I can maybe see
> sites doing this for high value state, if it comes to that, but that's
> being optimistic.
>
> I don't understand how the cross-origin use of these is intended to
> work (what requests do the options apply to?).
>

The options are meant to apply to the token itself; the `delivery` token in
particular is similar to the `SameSite` attribute if you squint a bit. That
is, when the server says "This token should be delivered cross-site.", then
it will be delivered along with any request that would deliver cookies that
weren't set with a `SameSite` attribute. If the server says "This token
should be delivered same-origin.", then it would be delivered along with
any request that would deliver a cookie set with a theoretical `SameOrigin`
attribute.


> p.s., Not sure that son-of-token-binding is worth doing here.  Proving
> that you know a cookie-analogue as opposed to just providing the value
> might be neat, but it's still leap of faith.  Besides, token binding
> was a ton of work to get right.
>

I agree that the sketch in the proposal document is not at all fleshed out,
but it aims to solve a smaller problem than either token binding or channel
ID did. I hope that means that it will be simpler to analyze, but it
certainly needs more discussion, both in terms of the threat model, and in
terms of the implementation.

-mike