Re: [http-state] Welcome to http-state
"Blake Frantz" <bfrantz@cisecurity.org> Mon, 12 January 2009 19:52 UTC
Return-Path: <http-state-bounces@ietf.org>
X-Original-To: http-state-archive@ietf.org
Delivered-To: ietfarch-http-state-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D893A6843; Mon, 12 Jan 2009 11:52:22 -0800 (PST)
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 933893A6843 for <http-state@core3.amsl.com>; Mon, 12 Jan 2009 11:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 6fg72xtocu2F for <http-state@core3.amsl.com>; Mon, 12 Jan 2009 11:52:18 -0800 (PST)
Received: from Nexus.cisecurity.org (nexus.cisecurity.org [128.121.47.218]) by core3.amsl.com (Postfix) with ESMTP id 8B4F83A6783 for <http-state@ietf.org>; Mon, 12 Jan 2009 11:52:17 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 12 Jan 2009 14:51:54 -0500
Message-ID: <120206B6A348CA498C70E738A2E963514C0CCC@Nexus.cisecurity.lan>
In-Reply-To: <49679299.6060703@corry.biz>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [http-state] Welcome to http-state
Thread-Index: AclyhU2PajZaBG1YSXO05KniMbpMogAJRiSA
References: <49679299.6060703@corry.biz>
From: Blake Frantz <bfrantz@cisecurity.org>
To: Discuss HTTP State Management Mechanism <http-state@ietf.org>
Subject: Re: [http-state] Welcome to http-state
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Discuss HTTP State Management Mechanism <http-state@ietf.org>
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: http-state-bounces@ietf.org
Errors-To: http-state-bounces@ietf.org
A couple other quick items that may be worth chewing over: 1. While RFC2109 and draft-pettersen-cookie-v2-03.txt define the 'Secure' cookie-av to advise the user-agent against sending the cookie over an insecure transport they do not define the desired user-agent behavior for cross scheme writing. For example, http://foo.bar clobbering a cookie set by https://foo.bar. 2. RFC2109 and draft-pettersen-cookie-v2-03.txt define rules for path-matching but fail to clearly indicate if these are case sensitive comparisons. Removing some ambiguity in this area may be beneficial. Let me know if I have overlooked something that defines the above - it's more than possible :) Blake -----Original Message----- From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org] On Behalf Of Bil Corry Sent: Friday, January 09, 2009 10:08 AM To: http-state@ietf.org Subject: [http-state] Welcome to http-state It appears the subscriptions have subsided, so thank you to everyone who has joined so far. == First, some background history == Some time ago on OWASP's Intrinsic Security list, I brought up the issue of HTTPOnly not being consistently implemented (or lacking implementation altogether) across the major browsers, based mostly on OWASP's HTTPOnly resource page: http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly Jim Manico responded that he was actively promoting HTTPOnly implementation to various browsers and welcomed help to do more. In that conversation, we agreed that a uniform specification would probably be beneficial for the browser vendors and we started a group to do so. In promoting the group across various lists, I consistently received feedback that *cookies* needed a specification, and why were we bothering with HTTPOnly. This group at IETF is the result of our decision to take on the entire cookie spec, not just HTTPOnly. == Goal for this group == Ultimately, the purpose of this group is to create an updated HTTP State Management Mechanism RFC (aka cookies) that will supersede the Netscape spec, RFCs 2109, 2964, 2965 then add in real-world usage (e.g. HTTPOnly), and possibly add in additional features and possibly merge in draft-broyer-http-cookie-auth-00.txt and draft-pettersen-cookie-v2-03.txt. I'm assuming an update to bcp44 is probably needed as well, but truthfully I haven't looked at it. Did I miss anything relevant to creating an update cookie RFC? == Creating a Working Group == In order to create a RFC, we need a Working Group. In order to create a Working Group, we need enough interested people to join a BOF at an IETF meeting and to volunteer to help run the Working Group: http://www.ietf.org/tao.html#rfc.section.6 I'll be attending the next IETF meeting and don't mind taking on the role of Working Group Chair, but I will need others to also attend, lend support and volunteer for the various responsibilities required. The next IETF meeting is March 22-27, 2009 in San Francisco: http://www.ietf.org/meetings/74/ If you will be attending, please let me know. I'll approach Lisa Dusseault about having a BOF at the next IETF meeting and would like to give her an idea of how many people are already interested in it. == Initial first steps == While we work on forming a Working Group, we can start the actual RFC process now by working on creating an Internet Draft: http://www.ietf.org/tao.html#rfc.section.8.1 There are a few ways to get started; I'm thinking that taking an inventory of what is wrong or missing from RFC2109 as compared to the "real world" may be a good place to start. Thoughts? - Bil _______________________________________________ http-state mailing list http-state@ietf.org https://www.ietf.org/mailman/listinfo/http-state _______________________________________________ http-state mailing list http-state@ietf.org https://www.ietf.org/mailman/listinfo/http-state
- [http-state] Welcome to http-state Bil Corry
- Re: [http-state] Welcome to http-state Daniel Stenberg
- Re: [http-state] Welcome to http-state Blake Frantz
- Re: [http-state] Welcome to http-state Adam Barth
- Re: [http-state] Welcome to http-state Blake Frantz
- Re: [http-state] Welcome to http-state Adam Barth
- Re: [http-state] Welcome to http-state Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [http-state] Welcome to http-state Bil Corry
- Re: [http-state] Welcome to http-state Adam Barth
- Re: [http-state] Welcome to http-state Adam Barth
- Re: [http-state] Welcome to http-state Daniel Stenberg
- Re: [http-state] Welcome to http-state Blake Frantz
- Re: [http-state] Welcome to http-state Adam Barth
- Re: [http-state] Welcome to http-state Blake Frantz
- Re: [http-state] Welcome to http-state Blake Frantz
- Re: [http-state] Welcome to http-state Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [http-state] Welcome to http-state Adam Barth
- Re: [http-state] Welcome to http-state Adam Barth
- Re: [http-state] Welcome to http-state Blake Frantz
- Re: [http-state] Welcome to http-state Dan Winship
- Re: [http-state] Welcome to http-state Blake Frantz
- Re: [http-state] Welcome to http-state Bil Corry