[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 02:53 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 2C5B53A82B0 for <http-state@core3.amsl.com>; Tue, 23 Feb 2010 18:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.883
X-Spam-Level:
X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.094, 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 nFUpAXElpBBx for <http-state@core3.amsl.com>; Tue, 23 Feb 2010 18:53:35 -0800 (PST)
Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 613293A829F for <http-state@ietf.org>; Tue, 23 Feb 2010 18:53:35 -0800 (PST)
Received: by ywh3 with SMTP id 3so2810001ywh.31 for <http-state@ietf.org>; Tue, 23 Feb 2010 18:55:36 -0800 (PST)
Received: by 10.101.11.17 with SMTP id o17mr925573ani.198.1266980136460; Tue, 23 Feb 2010 18:55:36 -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 14sm307798gxk.7.2010.02.23.18.55.34 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 18:55:35 -0800 (PST)
Received: by iwn29 with SMTP id 29so2922458iwn.31 for <http-state@ietf.org>; Tue, 23 Feb 2010 18:55:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.146.79 with SMTP id g15mr235364ibv.49.1266980134070; Tue, 23 Feb 2010 18:55:34 -0800 (PST)
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 23 Feb 2010 18:55:14 -0800
Message-ID: <5c4444771002231855s36391fdfgd30a1ebc57722915@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>, Blake Frantz <bfrantz@cisecurity.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: http-state <http-state@ietf.org>
Subject: [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 02:53:36 -0000

On Tue, Feb 23, 2010 at 9:10 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 23 Feb 2010 17:15:04 +0100, <Internet-Drafts@ietf.org> wrote:
>> The cookie protocol has many
>> historical infelicities and should be avoided for new applications of
>> HTTP.
>
> What exactly does this mean?

It means that we don't think new applications of HTTP (e.g., SIP)
should use the cookie protocol.  Cookies have caused significant
security problems for the web.  For new applications, it's probably a
good idea to use another state management mechanism.

> There's no suitable replacement for cookies
> available currently so giving this advice seems a bit premature, but maybe I
> misunderstand what it says.

Hopefully we'll create a suitable replacement in phase two.  If not,
necessity is the mother of invention...

On Tue, Feb 23, 2010 at 9:15 AM, Blake Frantz <bfrantz@cisecurity.org> wrote:
> Similarly, the top of section '7.1 General Recommendations' states:
>
> "The cookie protocol is NOT RECOMMENDED for new applications".
>
> This statement may require the same clarification as the one noted by Anne.

What clarification do you have in mind?  Keep in mind that we're
writing this document for the long term.  Just because we don't have
an alternative in mind doesn't mean we won't have better options in
the future.

Would you really recommend that new applications of HTTP use cookies?

Adam