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

Adam Barth <ietf@adambarth.com> Fri, 28 January 2011 21:47 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4424C3A697A for <http-state@core3.amsl.com>; Fri, 28 Jan 2011 13:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.725
X-Spam-Level:
X-Spam-Status: No, score=-3.725 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAk4RX3tCi9J for <http-state@core3.amsl.com>; Fri, 28 Jan 2011 13:47:10 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4AAE23A6968 for <http-state@ietf.org>; Fri, 28 Jan 2011 13:47:10 -0800 (PST)
Received: by vws7 with SMTP id 7so1301259vws.31 for <http-state@ietf.org>; Fri, 28 Jan 2011 13:50:17 -0800 (PST)
Received: by 10.220.178.140 with SMTP id bm12mr826051vcb.18.1296251415531; Fri, 28 Jan 2011 13:50:15 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id c4sm6252107vcc.6.2011.01.28.13.50.13 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 13:50:14 -0800 (PST)
Received: by iwn40 with SMTP id 40so3847128iwn.31 for <http-state@ietf.org>; Fri, 28 Jan 2011 13:50:12 -0800 (PST)
Received: by 10.231.30.73 with SMTP id t9mr3358843ibc.64.1296251412900; Fri, 28 Jan 2011 13:50:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.35.13 with HTTP; Fri, 28 Jan 2011 13:49:42 -0800 (PST)
In-Reply-To: <4D432DE2.8010107@KingsMountain.com>
References: <4D432DE2.8010107@KingsMountain.com>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 28 Jan 2011 13:49:42 -0800
Message-ID: <AANLkTi=f3Jw=hffHjjL2vMx2zVWiCQDOjM3PE_DCCQgC@mail.gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: IETF HTTP State WG <http-state@ietf.org>
Subject: Re: [http-state] phase 2 work? (was: cake spec: server-side initiation only?)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2011 21:47:11 -0000

On Fri, Jan 28, 2011 at 12:58 PM, =JeffH <Jeff.Hodges@kingsmountain.com>; 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