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

Adam Barth <ietf@adambarth.com> Sat, 04 December 2010 00:03 UTC

MIME-Version: 1.0
In-Reply-To: <SNT129-DS18EED7DB682AB192036942A4280@phx.gbl>
References: <AANLkTimDRJkwXoXt-2Lm6qNjEVcRN5bqdN01_G2+8Df_@mail.gmail.com> <SNT129-DS18EED7DB682AB192036942A4280@phx.gbl>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 03 Dec 2010 16:04:22 -0800
Message-ID: <AANLkTinOOF5gFnr-duygSarpE1LzsbP1EAgoYW2y-y-v@mail.gmail.com>
To: Mike Wilson <mikewse@hotmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state@ietf.org
Subject: Re: [http-state] cake spec: server-side initiation only?
Precedence: list

On Fri, Dec 3, 2010 at 3:48 PM, Mike Wilson <mikewse@hotmail.com> wrote:
> Adam Barth wrote:
>> On Fri, Dec 3, 2010 at 12:01 PM, Mike Wilson
>> <mikewse@hotmail.com> wrote:
>> > 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?
>>
>> [...]
>>
>> 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.
>
> Ok, so you are thinking about an extension to cookies instead of
> a new cake mechanism.

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.

>> On Fri, Dec 3, 2010 at 12:02 PM, Mike Wilson
>> <mikewse@hotmail.com> 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.
>
> 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?

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

[http-state] cake spec: server-side initiation on… Mike Wilson
Re: [http-state] cake spec: server-side initiatio… Adam Barth
Re: [http-state] cake spec: server-side initiatio… Mike Wilson
Re: [http-state] cake spec: server-side initiatio… Adam Barth