Re: [http-state] http-state Digest, Vol 1, Issue 1

"Micah Tapman" <m.tapman@questconsultantsllc.com> Fri, 09 January 2009 20:15 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 711433A67EA; Fri, 9 Jan 2009 12:15:57 -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 46EF53A67EA for <http-state@core3.amsl.com>; Fri, 9 Jan 2009 12:15:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MSGID_MULTIPLE_AT=1.449, RDNS_NONE=0.1, SARE_URI_4_BIZ=0.144]
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 A1NuG5MYkJBC for <http-state@core3.amsl.com>; Fri, 9 Jan 2009 12:15:54 -0800 (PST)
Received: from mx1.questconsultantsllc.com (unknown [173.8.9.229]) by core3.amsl.com (Postfix) with ESMTP id 0993F3A63D2 for <http-state@ietf.org>; Fri, 9 Jan 2009 12:15:54 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.questconsultantsllc.com (Postfix) with ESMTP id EE030D86A0 for <http-state@ietf.org>; Fri, 9 Jan 2009 15:15:39 -0500 (EST)
X-Virus-Scanned: amavisd-new at
Received: from mx1.questconsultantsllc.com ([127.0.0.1]) by localhost (mx1.questconsultantsllc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL9+Aj7kU4US for <http-state@ietf.org>; Fri, 9 Jan 2009 15:15:38 -0500 (EST)
Received: from cliff.questconsultantsllc.com (cliff.questconsultantsllc.com [10.8.1.249]) by mx1.questconsultantsllc.com (Postfix) with ESMTP id 7C6EFD868B for <http-state@ietf.org>; Fri, 9 Jan 2009 15:15:38 -0500 (EST)
From: Micah Tapman <m.tapman@questconsultantsllc.com>
To: http-state@ietf.org
References: <mailman.51.1231531204.17652.http-state@ietf.org>
In-Reply-To: <mailman.51.1231531204.17652.http-state@ietf.org>
Date: Fri, 09 Jan 2009 15:15:37 -0500
Message-ID: <007701c97297$0875b610$19612230$@tapman>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 5.0.10_GA_2638.RHEL5 (ZimbraConnectorForOutlook/5.0.2767.10)
Thread-Index: AclylOnMvWJ7g5XfStaPgYg7rnZGOgAAbQ/g
Content-Language: en-us
X-Originating-IP: [10.8.1.125]
Subject: Re: [http-state] http-state Digest, Vol 1, Issue 1
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: multipart/mixed; boundary="===============0164570335=="
Sender: http-state-bounces@ietf.org
Errors-To: http-state-bounces@ietf.org

Speaking to the "browser" idea, and expanding on the libcurl comment from
Daniel, I think we should consider changing the terminology to something
like "client object" instead of "browser".

Micah

-----Original Message-----
From: http-state-bounces@ietf.org [mailto:http-state-bounces@ietf.org] On
Behalf Of http-state-request@ietf.org
Sent: Friday, January 09, 2009 3:00 PM
To: http-state@ietf.org
Subject: http-state Digest, Vol 1, Issue 1

Send http-state mailing list submissions to
	http-state@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/http-state
or, via email, send a message with subject or body 'help' to
	http-state-request@ietf.org

You can reach the person managing the list at
	http-state-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of http-state digest..."


Today's Topics:

   1. Welcome to http-state (Bil Corry)
   2. Re: Welcome to http-state (Daniel Stenberg)


----------------------------------------------------------------------

Message: 1
Date: Fri, 09 Jan 2009 12:08:25 -0600
From: Bil Corry <bil@corry.biz>
Subject: [http-state] Welcome to http-state
To: "http-state@ietf.org" <http-state@ietf.org>
Message-ID: <49679299.6060703@corry.biz>
Content-Type: text/plain; charset=UTF-8

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








------------------------------

Message: 2
Date: Fri, 9 Jan 2009 20:02:48 +0100 (CET)
From: Daniel Stenberg <daniel@haxx.se>
Subject: Re: [http-state] Welcome to http-state
To: Discuss HTTP State Management Mechanism <http-state@ietf.org>
Message-ID: <alpine.LRH.2.00.0901091958090.20014@yvahk3.pbagnpgbe.fr>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Fri, 9 Jan 2009, Bil Corry wrote:

> 	http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly

While not being a browser, libcurl is a HTTP library that supports cookies
and 
even HTTPOnly ones and it is used in browsers (and browser-like
applications) 
at times.

> 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.

It sounds like a fair way to get started, but RFC2109 is quite far away from

how cookies work in real life so the differences are going to be
substantial.

-- 

  / daniel.haxx.se


------------------------------

_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state


End of http-state Digest, Vol 1, Issue 1
****************************************
_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state