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

From: Nico Williams <[email-masked]>
Date: Sun, 10 Feb 2013 20:09:15 -0600

... sounds like an oxymoron.

HOWEVER, we can probably use a combination of server-side state stored
[encrypted] in state cookies, small session identifiers, and
server-side caching of state cookies.  Clients would normally only
send the [small] session IDs, and would send the cookies only when the
server needs them to [re-]establish state after it falls off the
server's cache.

On Sun, Feb 10, 2013 at 6:15 PM, Poul-Henning Kamp <[email-masked]> wrote:
> [1] We can probably do much more for transmission efficiency by killing
> cookies and adding client provided session-identifieres, than any
> kind of encoding or compression will ever be able to...[2]

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 11 Feb 2013 07:20:22 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <CAK3OfOieNOsN7=[email-masked]>
, Nico Williams writes:

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...

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Roberto Peon <[email-masked]>
Date: Sun, 10 Feb 2013 23:38:46 -0800

Also... nothing stops a site from implementing something like what Nico
described today with what already exists in HTTP, though the logic would be
encoded  in the server business logic and page javascript instead of done
automatically by browser and server.
-=R

On Sun, Feb 10, 2013 at 11:20 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <CAK3OfOieNOsN7=
> [email-masked]>
> , Nico Williams writes:
>

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 09:18:49 -0600

> automatically by browser and server.

I don't see how to do this without JS and without redirects.  Also a
standard way to do this seems much better than ad-hoc ways.  Finally,
this is clearly better than stateful compression as discussed in
earlier threads -- at least for cookies.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 09:24:34 -0600

> 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.)

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Feb 2013 11:05:01 -0500

> 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/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 11 Feb 2013 16:07:10 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <[email-masked]>

>need to distribute it across related servers.  Using the client to do

... for the server, yes.

And a lot of disadvantages for the client, such as not having your
context coming along to a different computer, privacy, bandwidth etc.

I'm a big beliver in making disadvantages follow advantages, and
therefore the servers should bear this cost.

>feel comfortable with session IDs smaller than 96-bits.)

Sure, 128 bits would be a minimum, 256 should be enough.

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 10:36:53 -0600

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

Heh, well, you know that I'm with you on this, as we both have I-Ds
that involve the use of MACs to authenticate access to sessions on
each request.

> shared secret rather than presentation of the shared secret itself.

Right.

> across the wire in plaintext at most once.

Although BEAST/CRIME are not the only reasons to want this.

> So the communication pattern might be:

But we still need a) a session ID, and/or b) server-side state stored
as encrypted cookies (in the generic sense, not "web cookies") on the
client side.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 10:39:05 -0600

> context coming along to a different computer, privacy, bandwidth etc.

Bandwidth costs can be addressed by having the server cache its state,
using the client only to rebuild that state when it gets pushed out of
the cache (e.g., due to client idle time).

As for privacy, encrypted state cookies do not compromise privacy any
more than random session IDs.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Feb 2013 11:44:21 -0500

> more than random session IDs.

I should have made this clear earlier, there should be only two types of
cookie-type data:

Authentication tokens - which only go over the wire exactly once.

Encrypted state tokens - which only the server should be able to decrypt.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 11 Feb 2013 16:50:27 +0000

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <[email-masked]>

>more than random session IDs.

...unless of course, they are used to track your on-line behaviour to
such an degree that the EU finds reason to regulate them ?

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Feb 2013 10:58:48 -0600

> such an degree that the EU finds reason to regulate them ?

But I'm not talking about web cookies.  Just state cookies in the
general sense -- these clearly are no different than session IDs with
unconstrained size.

Nico
--