Re: [http-state] http-state charter

Dan Winship <dan.winship@gmail.com> Fri, 31 July 2009 16:46 UTC

Return-Path: <dan.winship@gmail.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 4DAAF3A68B2 for <http-state@core3.amsl.com>; Fri, 31 Jul 2009 09:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 ZBPs+cuQacuY for <http-state@core3.amsl.com>; Fri, 31 Jul 2009 09:46:05 -0700 (PDT)
Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id 7A7EA3A6B8A for <http-state@ietf.org>; Fri, 31 Jul 2009 09:46:05 -0700 (PDT)
Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPA id 19735802AE; Fri, 31 Jul 2009 12:46:05 -0400 (EDT)
Message-ID: <4A731FCC.5040102@gmail.com>
Date: Fri, 31 Jul 2009 12:46:04 -0400
From: Dan Winship <dan.winship@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
MIME-Version: 1.0
To: Bil Corry <bil@corry.biz>
References: <4A70D2D2.9050900@corry.biz>
In-Reply-To: <4A70D2D2.9050900@corry.biz>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "http-state@ietf.org" <http-state@ietf.org>
Subject: Re: [http-state] http-state charter
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: Fri, 31 Jul 2009 16:46:06 -0000

On 07/29/2009 06:53 PM, Bil Corry wrote:
> Much delayed, but I'm now working on creating our charter.  I've included
> a first draft below; it borrows heavily from the httpbis charter.

I'm not sure that really works; httpbis was starting from a good spec
and trying to make it better. We're starting from either a non-existent
spec (real-world cookies) or a spec that does not reflect reality in any
way (RFC 2965), depending on how you look at it, so our tasks are fairly
different from theirs.

You said in a follow-up:

> If this WG can produce an updated Cookie RFC that documents how
> cookies are actually widely implemented (including HTTPOnly),
> I think that would be an excellent start.

As I understand things, we cannot do this as a revision to 2965, because
2965 is Standards Track, and this new document would have to be merely
Informational, since we'd be documenting the existing lousy security
model and violations of the HTTP spec in real-world cookies, and that
would not be acceptable in a Standards Track protocol.

So I think the goal should be to first produce an Informational RFC,
describing real-world cookies, and then either (a) have 2965
reclassified as historical, or (b) write a second RFC obsoleting 2965
and providing a new profile of Cookie/Set-Cookie usage that is both
acceptable to the IETF and compatible with existing usage. (So it would
end up being a lot more like 2109 then 2965.)

> I'd really like to eventually build a new type of cookie that
> incorporates security features that cookies today lack (such as
> having the Secure flag turned on by default for HTTPS unless
> explicitly made non-Secure).

Or more generically, cookies shouldn't bake in the assumption that all
ports on a given host are part of the same "cookie domain"...

But this is the sort of thing that would be tricky to add; you need to
encode the secure-by-default cookie in some way such that older browsers
would not be able to see it (since if they saw it, they would treat it
as insecure). But that would mean that either (a) the web site would not
work with older browsers, or (b) the site would have to also separately
encode the information in some way that the older browsers could use it
too, in which case there is no reason to also use the new encoding. So
this runs the risk of turning into Set-Cookie2 again.

-- Dan