W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Stateful compression of cookies (Re: Delta Compression and UTF-8 Header Values)

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Mon, 11 Feb 2013 11:05:01 -0500
Message-ID: <CAMm+Lwjtvng7XdTWm5EQwRgsEMbp9itsoN=m9PnSYu5ry7TF1A@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Zhong Yu <zhong.j.yu@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, James M Snell <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Mon, Feb 11, 2013 at 10:24 AM, Nico Williams <nico@cryptonector.com>wrote:

> On Mon, Feb 11, 2013 at 1:20 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
> > I really don't see why it should be the clients problem to store
> > the servers state.
> >
> > If somebody needs 8k of storage for each browser that visits their
> > website, they can bloody well buy their own disks...
>
> It's a common implementation pattern.  I'm not ready to tell
> application implementors to stop doing this.
>
> It's not just the disk space, but also the need to fetch it and the
> need to distribute it across related servers.  Using the client to do
> this has some benefits.
>
> (Also, a note about small session IDs: they can't be so small as to be
> guessable.  32-bit session IDs would be a disaster.  I think I'd not
> feel comfortable with session IDs smaller than 96-bits.)
>

Please, lets not repeat the mistake of doing bearer tokens.

I would very much like to separate out authentication tokens from state
tokens so that we can get some sanity. But the replacement for the use of a
session cookie for authentication should be a proof of knowledge of the
shared secret rather than presentation of the shared secret itself.

Doing this would render the various BEAST and CRIME attacks ineffective
along with most cookie stealing as the  confidential data would only go
across the wire in plaintext at most once.

So the communication pattern might be:


Client: Request 1
Server:  Authentication key is XY3i9dij993==, NonceS is 299w3i34=

Client: NonceC is 299eu393=, NonceS is 299w3i34=, MAC (XY3i9dij993==,
299w3i34=, 299eu393=)
Server: NonceS is w8828w9w==, NonceC is 299eu393=,, MAC ( ... )


The basic idea being that the key only goes across the transport once and
both sides are responsible for encoding sufficient checksum info into their
nonces as to be able to check for freshness. Alternatively a counter could
be used (etc. etc.).



-- 
Website: http://hallambaker.com/
Received on Monday, 11 February 2013 16:05:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 11 February 2013 16:05:41 GMT