Re: [http-state] phase 2 work? (was: cake spec: server-side initiation only?)

[Adam Barth <[e-mail]>]

On Fri, Jan 28, 2011 at 12:58 PM, =JeffH <[e-mail]> wrote:
> Adam said..
>> 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.
>
> sure, at this point it seems draft-ietf-httpstate-cookie is essentially done
> (fingers crossed), so it seems appropriate to discuss where we might want to
> take HTTP State Management (and where we might want to at all).
>
> So please feel free to discuss what you think may be on the proverbial table
> for "phase 2" work if we were to recharter the working group.

I'm still interested in "phase 2" work.  We've been kicking around
with a bunch of different designs.  The main problems I'd like to
solve are the following:

1) Privacy.  Cookies have terrible privacy.  If we could design a
state management mechanism with better privacy properties, the world
would be a happier place.

2) Integrity.  If you run an HTTPS site, you can protect the
confidentiality of your session from eavesdroppers, but you can't
prevent active network attackers from overwriting your cookies and
disrupting the integrity of your sessions.

3) Federation.  To share a session between two servers with cookies,
you need to use a shared secret, which means both parties can
impersonate the user to the other.  Ideally, you'd be able to federate
your session (e.g., between login.example.com, mail.example.com, and
photos.example.com) without giving away your credentials.

At this point, we have some reasonable designs that address (2) and
(3), but we don't have much of a handle on how to address (1).  I'm
happy to share those ideas with the working group.  I'd also like to
invite folks to suggest problems that they'd like to see "phase 2"
work address.

Adam