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

Phillip Hallam-Baker <hallam@gmail.com> Mon, 11 February 2013 16:06 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38E221F8AC2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 08:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.211
X-Spam-Level:
X-Spam-Status: No, score=-9.211 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49XohZIdcVOW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 11 Feb 2013 08:06:22 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id BBBF121F8ABD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 11 Feb 2013 08:06:22 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1U4vt4-0002gT-NG for ietf-http-wg-dist@listhub.w3.org; Mon, 11 Feb 2013 16:05:46 +0000
Resent-Date: Mon, 11 Feb 2013 16:05:46 +0000
Resent-Message-Id: <E1U4vt4-0002gT-NG@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1U4vsw-0002fj-B7 for ietf-http-wg@listhub.w3.org; Mon, 11 Feb 2013 16:05:38 +0000
Received: from mail-we0-f172.google.com ([74.125.82.172]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1U4vss-0005zL-MA for ietf-http-wg@w3.org; Mon, 11 Feb 2013 16:05:38 +0000
Received: by mail-we0-f172.google.com with SMTP id x10so4915733wey.31 for <ietf-http-wg@w3.org>; Mon, 11 Feb 2013 08:05:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Hsk2B5a4Fq+hVTGAhL/ygNkoKAzntN4Y2VYmDg3xYnM=; b=ZnAGd6/ZtAdFFbUxQynwhyBNjN563YIUKiMP5stlbUZubBRBbNHCPDezsPCQw+H+4P snd9PknDxRx0avUzgcYHflEB3RT2r018u/OwnR6peBa/2swWlVoTpxIT04go1RdslohH qGI0Lud2KQN7ProOzY8+R/kQhhVB9EU8O8wsGe8I782rvxTddatwGyzSl010Qlh+2D4l kkMB/LKj6f/Mz3ikOL6Pfmb4t1LdWNpNBteKVhkwDAnJ2LKDZKwn64H87w8m5kTHdIni iS0O7cKI6ETcjaHjhqKW0itiuHwqX6H9hJm6DeFDB8PWil7sqLcA5Jyf4g3g9t2ksvnf yTLQ==
MIME-Version: 1.0
X-Received: by 10.194.174.196 with SMTP id bu4mr24862172wjc.35.1360598701735; Mon, 11 Feb 2013 08:05:01 -0800 (PST)
Received: by 10.194.153.104 with HTTP; Mon, 11 Feb 2013 08:05:01 -0800 (PST)
In-Reply-To: <CAK3OfOhGoQ0HtMu4HRo5kne1fgwDkzU6AHceCUTPHEXXW5HypQ@mail.gmail.com>
References: <CAK3OfOieNOsN7=2TV_25nTr+7Y3a-fyjSGV+F7HdbEQT8cB9xg@mail.gmail.com> <85697.1360567222@critter.freebsd.dk> <CAK3OfOhGoQ0HtMu4HRo5kne1fgwDkzU6AHceCUTPHEXXW5HypQ@mail.gmail.com>
Date: Mon, 11 Feb 2013 11:05:01 -0500
Message-ID: <CAMm+Lwjtvng7XdTWm5EQwRgsEMbp9itsoN=m9PnSYu5ry7TF1A@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@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>
Content-Type: multipart/alternative; boundary="089e0149331a4c7dea04d5751250"
Received-SPF: pass client-ip=74.125.82.172; envelope-from=hallam@gmail.com; helo=mail-we0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-2.9
X-W3C-Hub-Spam-Report: AWL=-2.118, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1U4vss-0005zL-MA 1344600802ce67503d827c46cfcc9047
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Stateful compression of cookies (Re: Delta Compression and UTF-8 Header Values)
Archived-At: <http://www.w3.org/mid/CAMm+Lwjtvng7XdTWm5EQwRgsEMbp9itsoN=m9PnSYu5ry7TF1A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16559
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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/