[http-state] SCS and new cookie-value encoding

tho <tho@koanlogic.com> Fri, 25 February 2011 08:07 UTC

From: tho <tho@koanlogic.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Feb 2011 09:07:11 +0100
Message-Id: <54DFC6B8-7DE9-4976-9AAA-6A36634CA6A1@koanlogic.com>
To: http-state@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
Cc: Todd A Ouska <todd@yassl.com>, Lorenzo Cavallaro <lorenzo.cavallaro@gmail.com>, Steven Dorigotti <stewy@koanlogic.com>, tat@koanlogic.com, David Wagner <daw@cs.berkeley.edu>
Subject: [http-state] SCS and new cookie-value encoding
Precedence: list

Hello all,

I greatly appreciate the newly proposed cookie-value encoding, as it can make a slimmer SCS.

We can now pack up the five fields together in one only cookie by using a non-base64 char (e.g. '|') as field separator, like this:

ANY_COOKIE_NAME=430=|MTI5ODU1ODgwNA==|dGlk|L5aJeXxqzD2pJ062ztdc4w==|xFe9Rg+0wqc9KzLFbj62XbXQTLg=

which is a much better solution in terms of:
- protocol and browser friendliness;
- API simplification;
- free choice of cookie naming;
at nearly no cost, except a small reduction of space for state data (still about 3.5KB.)

In the meantime we have had some really valuable feedback from David Wagner for fixing the HMAC computation which was buggy in the published version of the draft.

This is to say that the -00 will soon be made obsolete by a new version which will include such changes and more precise algorithm description based on the implementation experience we've gained so far.

In the meanwhile I'm asking the http-state WG the following question: 
is the whole "authenticated/encrypted cookie" matter worth being adopted as a working item by the group or not ?

My biased opinion is, of course, yes :) at least for the following reasons:
1) there exist real-world use cases where such technique is the only available option (e.g. embedded web servers on severely constrained hardware);
2) there exist real-world use cases where such technique would be a valuable option compared to others (e.g. multi instantiated web apps that would otherwise need a way to synchronize the application state information);
3) anyone facing the same problem would need to reinvent the same wheel, perhaps incorrectly from a cryptographic standpoint (see our HMAC computation bug).
4) there is one important shift in cookie semantics when the cookie producer is not the owner of the cookie bits that is worth making explicit to implementers/users of this facility (see section 7.2.2. of SCS-00);
5) there are security advantages in using SCS over plain cookies at a quite negligible cost -- just some fast symmetric key encryption and HMAC'ing -- which would make SCS an ad-interim fix for some of the cookie model vulnerabilities (e.g. session brute forcing).


Ok I.m here, let me know :)
Bye, t.