Re: Origin cookies

On 24 October 2014 22:49, Mike West <mkwst@google.com> wrote:
> This is where I wave my hands and say "header compression", and we all nod
> wisely, right? :)

It's been watered down enough that a big header still does some
damage.  And your new mechanism won't be in the static table, so you
still want a short name.  Request header fields are still expensive :(

> I see some distinct problems with the way cookies work. I think harmonizing
> cookies with the same-origin policy is a nicely minimal way to offer servers
> the ability to avoid those problems. I suspect that minimal changes will be
> significantly easier to come to agreement on and deploy.

That's true.  But this is just disruptive enough that I think we can
at least lay the groundwork for further incremental changes.  But I'm
concerned that this is already a fairly big change.  Either that, or
it's not going to do that much good.

Anything that requires support from both peers to work might as well
be a little more ambitious.

I don't think we're talking about making a fundamental change to how
server developers interact with this stuff.  That's where things like
channel bindings and origin certs tend to break down.  That suggests
that a name change or new attribute is probably OK, but it might be
too much to force them to say, remove randomized masking, which would
poodle- or beast-proof cookies.  But if we're using new fields, new
protections are possible, or, more specifically, we could structure
those new fields to enable new protections.

A simple change would be to require that origin cookies that are set
with an attribute the client didn't understand must be ignored.  That
would make it possible to develop new protections without the risks
I'm concerned about (new scopes of applicability, or things like the
randomized masking).  That's a modest improvement that could enable
incremental fixes later.  Those sorts of things aren't really possible
with Cookie/Set-Cookie, though it might be with Cake/Bake.

New header fields would also allow us to jettison that awful
[Set-]Cookie syntax, which doesn't play nice with the protocol.

I think that's all I'm asking for: new names and some very minor
tweaks to the grammar and semantics.

Received on Saturday, 25 October 2014 07:00:51 UTC