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
- [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Ian Hickson
- Re: [http-state] http-state charter Prasad Shenoy
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Ian Hickson
- Re: [http-state] http-state charter =JeffH
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Dan Winship
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Dan Winship
- Re: [http-state] http-state charter Ian Hickson
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Peter Saint-Andre
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Julian Reschke
- Re: [http-state] http-state charter Pascal Gaudette
- Re: [http-state] http-state charter Mark Nottingham
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Dan Winship
- Re: [http-state] http-state charter Mark Nottingham