Re: Some half-baked thoughts about cookies.

On Tue, Aug 28, 2018 at 9:20 AM Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> --------
> In message <CAKXHy=
> d9vHXCtCV1EGs80Was-_VQB42fipEKqyhMiBKa0FQgXw@mail.gmail.com>, Mike West
> writes:
>
> >> * The session-ID lives and dies with a single "UX session"
> >>   (Ie: when the user moves to another site by means exterior
> >>   to the shown content, bookmarks, type URL, close tab etc.
> >>   the session-ID is thrown away.)
> >
> >If the user agent supports a transient session mechanism of some sort,
> then
> >yes, I'd expect the identifier to be cycled whenever the user agent
> >believes that a "session" has ended. I'm not sure it makes sense to
> specify
> >that in great detail, given the diversity of user agents and their
> >propensity to have different ideas about what's best for their users.
>
> I don't know about "great detail", but it is important to make it clear
> that browsers SHALL NOT make it persistent across what users think of as
> sessions.
>

That makes sense.


> >If so, I am not opposed to the server sending back a routing-ID to
> >> be used for subsequent requests in the same "UX-session" and to
> >> be thrown away with the session-ID
> >
> >Are you intentionally distinguishing "routing-ID" and "session-ID"? If so,
> >what is the former?
>
> It's sort of in between what Willy called for in <
> 20180827114546.GA19615@1wt.eu>
> and what you have in your point 3 (token provenance).  I might go
> something like:
>
>         server sends:
>
>                 Sec-HTTP-State-Options: ...,
> route=*UGxlYXNlIHVzZSBlbnRyYW5jZSAjMwo=*
>
>         and the client echoes this in future requests:
>
>                 Sec-HTTP-State: token=*...*,
> route=*UGxlYXNlIHVzZSBlbnRyYW5jZSAjMwo=*
>
>         The client throws the route= token away with the session-id.
>
> This way a CDN can assign you a random(-ish) backend server on first
> request, and
> use the route-ID to make sure all your subsequent requests end there too,
> without the CDN having to hold state on all the client session-IDs.
>

What lead you to accept the server setting a value, rather than the value
being completely client-controlled (as it seemed like we were agreeing upon
yesterday)?


> The crucial point is that the client throws this route-id token away with
> the
> equally transient session-id, so the server cannot use it to track you.
>

If we accept the server controlling some value on the client, did you
consider embedding the routing information in the first X bits of the
identifier? That would make it quite clear that the routing information
would be discarded when the identifier was rotated.

-mike