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

Adam Barth <ietf@adambarth.com> Wed, 24 February 2010 21:26 UTC

Return-Path: <ietf@adambarth.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 58CF73A85C4 for <http-state@core3.amsl.com>; Wed, 24 Feb 2010 13:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 SzFszjG06CQH for <http-state@core3.amsl.com>; Wed, 24 Feb 2010 13:26:28 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 7A85C3A84FF for <http-state@ietf.org>; Wed, 24 Feb 2010 13:26:28 -0800 (PST)
Received: by gyg13 with SMTP id 13so987269gyg.31 for <http-state@ietf.org>; Wed, 24 Feb 2010 13:28:33 -0800 (PST)
Received: by 10.90.7.29 with SMTP id 29mr650354agg.16.1267046907608; Wed, 24 Feb 2010 13:28:27 -0800 (PST)
Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by mx.google.com with ESMTPS id 8sm942859yxb.43.2010.02.24.13.28.26 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Feb 2010 13:28:26 -0800 (PST)
Received: by iwn29 with SMTP id 29so3748720iwn.31 for <http-state@ietf.org>; Wed, 24 Feb 2010 13:28:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.147.148 with SMTP id l20mr597442ibv.77.1267046905633; Wed, 24 Feb 2010 13:28:25 -0800 (PST)
In-Reply-To: <Pine.LNX.4.64.1002241305230.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>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 24 Feb 2010 13:28:05 -0800
Message-ID: <5c4444771002241328l12b25be9q2f2a5e8b57229762@mail.gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 21:26:29 -0000

On Wed, Feb 24, 2010 at 1:19 PM, David Morris <dwm@xpasc.com> wrote:
> On Wed, 24 Feb 2010, Adam Barth wrote:
>>
>> [[
>>       The cookie protocol has many
>>       historical infelicities that degrade its security and privacy.
>> ]]
>
> Better, but I think 'infelicities' is not a common word and its use would
> make the docuemnt harder to read.

That sounds like an editorial decision.  On a previous thread someone
mentioned that they happened to like this word.  :)

>> How do folks feel about this related statement in Security Considerations:
>>
>> [[
>>         <t>For applications that use the cookie protocol, servers SHOULD
>>         NOT rely upon cookies for security.</t>
>> ]]
>
> Given that we are documenting an existing protocol, a SHOULD NOT statement
> is probabaly excessive.
>
> I think we should instead stress (and document those that are known) that
> there are many opportunities to compromise the content of cookies
> including insertion of rogue cookies and/or removing valid cookies. Hence,
> the design of applications which depend on cookies should carefully
> consider the impact on application data integrity (and security) if
> the cookie mechanism is subverted. In this context, I use application
> in the classic sense of a set of computer software which delivers some
> form of service to people or other computer applications.

We now have a fairly detailed Security Considerations section that
discusses all the security issues I know of with the cookie protocol.
If you know of things that aren't covered, please let me know and I'll
add them.

I'm somewhat on the fence as to whether the general advice is helpful.

Adam