Re: [http-state] Whether to recommend the cookie protocol (was Re: I-D Action:draft-ietf-httpstate-cookie-04.txt)

David Morris <dwm@xpasc.com> Wed, 24 February 2010 22:41 UTC

Return-Path: <dwm@xpasc.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73FE13A80C8 for <http-state@core3.amsl.com>; Wed, 24 Feb 2010 14:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level:
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJFuhnhbdjR7 for <http-state@core3.amsl.com>; Wed, 24 Feb 2010 14:41:36 -0800 (PST)
Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id AF18F3A8253 for <http-state@ietf.org>; Wed, 24 Feb 2010 14:41:36 -0800 (PST)
Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 08A87101853; Wed, 24 Feb 2010 14:43:46 -0800 (PST)
X-Propel-Return-Path: <dwm@xpasc.com>
Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.1.9347 $Rev: 9262 $) id iz6Ura2omHJ0; Wed, 24 Feb 2010 14:43:46 -0800
Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id EB880101852; Wed, 24 Feb 2010 14:43:45 -0800 (PST)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id o1OMhica027280; Wed, 24 Feb 2010 14:43:44 -0800
Date: Wed, 24 Feb 2010 14:43:44 -0800 (PST)
From: David Morris <dwm@xpasc.com>
To: Adam Barth <ietf@adambarth.com>
In-Reply-To: <5c4444771002241411g480a6dfdh9d42c0075026e1f5@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1002241433510.18807@egate.xpasc.com>
References: <5c4444771002231855s36391fdfgd30a1ebc57722915@mail.gmail.com> <4C374A2653EB5E43AF886CE70DFC567213CEF5CE46@34093-MBX-C03.mex07a.mlsrvr.com> <5c4444771002231929m3749c1c2g7903b444155dafa7@mail.gmail.com> <4B84DF96.7070709@gmx.de> <5c4444771002240926j3f4e859cq8bfcf7be34cf7e5f@mail.gmail.com> <Pine.LNX.4.64.1002241305230.18807@egate.xpasc.com> <5c4444771002241328l12b25be9q2f2a5e8b57229762@mail.gmail.com> <Pine.LNX.4.64.1002241344140.18807@egate.xpasc.com> <5c4444771002241411g480a6dfdh9d42c0075026e1f5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Propel-ID: iz6Ura2omHJ0
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Whether to recommend the cookie protocol (was Re: I-D Action:draft-ietf-httpstate-cookie-04.txt)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2010 22:41:37 -0000

On Wed, 24 Feb 2010, Adam Barth wrote:

> 
> These statement don't forbid anything.  They're recommendations at the
> SHOULD level.  Is there a specific reason we can't recommend against
> something without providing an alternative?  For example, I don't know
> of any reasonable solutions to the integrity problems with cookies.
> Because of this issue, it's more or less impossible for a web
> application that relies on cookies for security to be secure against
> an active network attacker.
> 
> There's a lot of detail in the Security Considerations section.  The
> net-net, however, is that you shouldn't rely on cookies for security
> because their security properties are quite weak.

Security is about risk management and is never absolute. We can say here
are the risks we know about. It is not our responsiblity to perform the
risk cost assessment for a given application. This is the responsiblity
of the application owner.

Using SHOULD NOT is pretty strong in my experience. In this context,
it represents a risk management assesment for which we don't have
adequate knowledge. Making that kind of strong recommendation w/o
an alternative marginalizes the recomendation and perhaps the
whole document for at least some readers.