Re: [http-state] draft-salgueiro-secure-state-management

Adam Barth <> Fri, 19 February 2010 21:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16C793A7D86 for <>; Fri, 19 Feb 2010 13:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.868
X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6OVFQt5pzZip for <>; Fri, 19 Feb 2010 13:30:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EE2CC3A7B77 for <>; Fri, 19 Feb 2010 13:30:19 -0800 (PST)
Received: by yxe3 with SMTP id 3so575207yxe.32 for <>; Fri, 19 Feb 2010 13:32:04 -0800 (PST)
Received: by with SMTP id u33mr2571825ybi.298.1266615119796; Fri, 19 Feb 2010 13:31:59 -0800 (PST)
Received: from ( []) by with ESMTPS id 4sm245900yxd.16.2010. (version=SSLv3 cipher=RC4-MD5); Fri, 19 Feb 2010 13:31:59 -0800 (PST)
Received: by yxe3 with SMTP id 3so575051yxe.32 for <>; Fri, 19 Feb 2010 13:31:56 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id i19mr137726ibv.22.1266615116238; Fri, 19 Feb 2010 13:31:56 -0800 (PST)
In-Reply-To: <>
References: <>
From: Adam Barth <>
Date: Fri, 19 Feb 2010 13:31:36 -0800
Message-ID: <>
To: Gonzalo Salgueiro <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [http-state] draft-salgueiro-secure-state-management
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Feb 2010 21:30:21 -0000

Thanks for the interesting read.

This working group is current in "phase one," which is to create a
specification for the de facto cookie protocol in use today.  In phase
two, we'll be considering way of improving HTTP state management.
This document looks like useful input for phase two.

The document isn't entirely clear about what security problem with the
current cookie protocol you're trying to solve.  It would be helpful
if you included a threat model and an explanation of your security
goals.  You argue against using TLS for all HTTP traffic on the basis
of requiring a different IP for each host name.  This problem will be
solved in the intermediate term by the SNI extension, which will
undoubtably beat any improved state management protocol to market.

The document preserves some of the syntax from the cookie protocol.
I'd advise dumping the current syntax entirely.

The document seems quite concerned about passive network attackers,
but doesn't seem that concerned abou the other security issues with
cookies.  You might consult the Security Considerations section of for a survey of
security problems a new protocol might improve.  (Note that this
section will be improved markedly in the next version of the draft,
which you can see here


On Thu, Feb 18, 2010 at 3:45 PM, Gonzalo Salgueiro <> wrote:
> Folks -
> I have posted the following draft:
> This draft provides a simple method for providing a reasonable level of security when exchanging state management information through HTTP in situations where TLS is not employed.
> We would appreciate receiving any comments you have and input on whether you think this might be a complementary addition to the work the WG is already undertaking.
> Thanks,
> Gonzalo
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
> For corporate legal information go to: