Subject: [http-state] cake spec: server-side initiation only?

From: Mike Wilson <[email-masked]>
Date: Fri, 3 Dec 2010 21:01:44 +0100

Hi Adam,

Reading http://www.ietf.org/id/draft-abarth-cake-00.txt,
I wonder if client-side nonce generation (as initially
proposed on the mailing list) was dropped altogether or 
just hasn't been speced yet?

Best regards
Mike Wilson

---

From: Adam Barth <[email-masked]>
Date: Fri, 3 Dec 2010 14:49:18 -0800

> just hasn't been speced yet?

Yeah, I haven't updated that document with my current thinking.  I've
been looking at a bunch of different variations in code.  Here's one
recent prototype:

http://codereview.chromium.org/4630001/

In case you're not familiar with Chrome's code base, the way this
works is as follows:

Set-Cookie: foo=bar; Origin

Using the Origin attribute sets the scope of the cookie to the current
origin (scheme, host, and port).  The Origin attribute overrides the
Domain and Path attributes.  Additionally, the cookie is returned to
the server in the Origin-Cookie header:

Origin-Cookie: foo=bar

The reason we return the cookie in a separate header is so the server
can know that the cookie was set by its own origin.  If we returned
the cookie in the Cookie header, then an attacker could inject a
non-Origin cookie with the same name and confuse the server.

On Fri, Dec 3, 2010 at 12:02 PM, Mike Wilson <[email-masked]> wrote:
> Earlier this year [1] we discussed state scoped on individual
> windows or tabs:
>
> [...]
>
> I see that you have addressed CSRF in cakes. Were/are you thinking
> that cakes is the better place to add future window scopes to?

Independently of the Origin attribute, I think an "instance" attribute
make sense.  Here we'd want to follow the same scoping rules as
sessionStorage (at the application layer).  In particular, each tab
has a separate scope, but if one tab is created from another, it
starts off with a clone of the previous tab's state.

These attributes are independent but combine nicely (as well as
combining nicely with the HttpOnly attribute).

Adam

---

From: Mike Wilson <[email-masked]>
Date: Sat, 4 Dec 2010 00:48:28 +0100

> non-Origin cookie with the same name and confuse the server.

Ok, so you are thinking about an extension to cookies instead of
a new cake mechanism.

> starts off with a clone of the previous tab's state.

I think more scopes than user_agent and browsing_context could be 
interesting so I would not go for a boolean attribute.
Anyway, is now a good time to start looking at these factors, or
is there other work you want to finish first?

Best regards
Mike

---

From: Adam Barth <[email-masked]>
Date: Fri, 3 Dec 2010 16:04:22 -0800

> Ok, so you are thinking about an extension to cookies instead of

The question boils down to how you expect web sites to interact with
both new and old user agents.  I don't think this is a settled
question.  Originally, I didn't see how to integrate with cookies and
still get the security properties we want.

> is there other work you want to finish first?

I've been holding off discussing these topics until we're done with
the basic cookie spec.  That seems to be mostly wrapping up.  This
working group isn't charted to work on improvements to the cookie
protocol, but I suspect Jeff would indulge us if we wanted to discuss
it for a bit.

Adam