Re: [http-state] SCS I-D document

tho <tho@koanlogic.com> Wed, 23 February 2011 11:04 UTC

Return-Path: <tho@koanlogic.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 7F6F53A684B for <http-state@core3.amsl.com>; Wed, 23 Feb 2011 03:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.505
X-Spam-Level: *
X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666]
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 8UxOxB8gcxXw for <http-state@core3.amsl.com>; Wed, 23 Feb 2011 03:04:14 -0800 (PST)
Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by core3.amsl.com (Postfix) with ESMTP id 5F8213A680A for <http-state@ietf.org>; Wed, 23 Feb 2011 03:04:14 -0800 (PST)
Received: from 93-63-252-189.ip30.fastwebnet.it ([93.63.252.189]:52534 helo=abergantin2.sunriseitaly.sunrisetelecom.com) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1PsCWY-0008An-4g; Wed, 23 Feb 2011 06:05:00 -0500
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: tho <tho@koanlogic.com>
In-Reply-To: <AANLkTi=Cd7rxUY5s3ZvWr1p66Y772Vvt=EWu2O_FAokq@mail.gmail.com>
Date: Wed, 23 Feb 2011 12:04:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D18537E6-56CC-4080-B68D-A62B49CD27FA@koanlogic.com>
References: <6B225A95-E14E-4178-AF98-689C3161A584@koanlogic.com> <AANLkTinYuzfqGLVvGh-O2TxnVhwVRiOurPS-72B+KQz2@mail.gmail.com> <24FCC78D-AFC9-4B87-93C6-E62EFCB56D83@koanlogic.com> <AANLkTi=Cd7rxUY5s3ZvWr1p66Y772Vvt=EWu2O_FAokq@mail.gmail.com>
To: Adam Barth <ietf@adambarth.com>
X-Mailer: Apple Mail (2.1082)
X-SA-Exim-Connect-IP: 93.63.252.189
X-SA-Exim-Mail-From: tho@koanlogic.com
X-Spam-DCC: :
X-Spam-Pyzor: Reported 0 times.
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com)
Cc: http-state@ietf.org
Subject: Re: [http-state] SCS I-D document
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: Wed, 23 Feb 2011 11:04:15 -0000

Hello Adam,

On Feb 23, 2011, at 11:41 AM, Adam Barth wrote:
> On Wed, Feb 23, 2011 at 2:24 AM, tho <tho@koanlogic.com>; wrote:
>> On Feb 22, 2011, at 11:16 PM, Adam Barth wrote:
>>> Thanks for the draft.  I'm not sure I quite understood what problem
>>> this protocol addresses or how it addresses that problem.
>> 
>> the problem is the following: suppose a web app needs to save its execution state with a given client and has no local storage available to do so.
>> 
>> It can pack the state (say "user=bob;role=admin;auth=ok;lang=en_us;..."), create an SCS cookie out of it, and send the SCS cookie to the client.
>> 
>> An SCS cookie is created such that:
>> a) the state string can be seen in clear-text by no one but the web application;
>> b) it embeds ancillary information that carries the proof of authorship of the given web application over the cookie.
>> 
>> So, when the client returns to the web app, the latter can verify that:
>> a) the supplied SCS cookie was its (i.e. generated by the web app),
>> b) the state string has not been tampered;
>> this way it can safely restore state and continue execution (or reject in case any of the two properties can't be satisfied).
>> 
>> This is especially useful in embedded devices (think for example of an home router with a web app providing configuration and monitoring via HTTP running from firmware), but could also come in handy at a completely different magnitude order.  When you have to deal with a massive web app you usually need to rely on a centralized storage to save/restore session state shared by the multiple nodes.  Using SCS cookies each node can dump/restore global application state independently, provided all the nodes are initially feeded with the same crypto material (i.e. the same ~64 bytes of entropy).
>> 
>> Hope the intent is less opaque now, of course I'm available for any further clarification.
> 
> Why does the server need any help from the user agent?  

It doesn't, as long as the user agent has cookie support enabled, SCS works fine.

> It seems like the server can just encrypt and mac the data itself and store it in a cookie.

There are many ways in which a server could try to do authenticated encryption, and some are plain wrong
(http://www.iacr.org/cryptodb/data/paper.php?pubkey=11891).

SCS uses a scheme which is provably secure, and offers a single interface for doing such things.

It is what standards exist for, right ? :)

ciao, t.