Subject: [http-state] http-state charter

From: Bil Corry <[email-masked]>
Date: Wed, 29 Jul 2009 17:53:06 -0500

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.  Feedback welcomed.  For a sense of what other WG charters look like, they are here:

	http://www.ietf.org/dyn/wg/charter.html

- Bil

----

Charter: HTTP State Management Mechanism (http-state) WG

Last Modified: 2008-07-29

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/http-state
Archive: http://www.ietf.org/mail-archive/web/http-state/current/maillist.html

Description of Working Group:

The HTTP State Management Mechanism (Cookies) was original created
by Netscape Communications in their Netscape cookie specification,
from which a formal specification followed (RFC 2109, RFC 2965).
Due to years of implementation and extension, several ambiguities
have become evident, impairing interoperability and the ability to
easily implement and use HTTP State Management Mechanism.

The working group will refine RFC2965 to:
* Incorporate errata and updates
* Clarify conformance requirements
* Remove known ambiguities where they affect interoperability
* Clarify existing methods of extensibility
* Remove or deprecate those features that are not widely implemented
and also unduly affect interoperability
* Where necessary, add implementation advice
* Document the security properties of HTTP State Management
Mechanism and its associated echanisms for common applications

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP State Management Mechanism
* Impact on existing implementations and deployments

The Working Group's specification deliverables are:
* A document that is suitable to supersede RFC 2965
* A document cataloguing the security properties of HTTP
State Management Mechanism

Goals and Milestones:
TBD

No Current Internet-Drafts
No Request For Comments

---

From: Ian Hickson <[email-masked]>
Date: Wed, 29 Jul 2009 23:37:29 +0000 (UTC)

On Wed, 29 Jul 2009, 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.  Feedback welcomed.

Looks good.

I would encourage us to also include adding new features that have a 
critical mass of support to the scope of the group's work. It should of 
course be very difficult, process-wise, to add something, but we shouldn't 
require new features to wait for an entire cycle of the cookie spec, if 
something does come up that is widely accepted as being useful.

(We wouldn't want to finish writing this spec only to find that while we 
were at it, the browser vendors got together and added a new feature like 
httpOnly without it getting into the spec.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Prasad Shenoy <[email-masked]>
Date: Thu, 30 Jul 2009 09:17:37 -0400

That's a very good point. Also, would things like CORS have any affect
on how we look (or ignore) HTTP State Management in it's current form.
Is someone out there already thinking about having a CORS cookie?

Thanks & Regards,
Prasad N. Shenoy

On Wed, Jul 29, 2009 at 7:37 PM, Ian Hickson<[email-masked]> wrote:
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: Bil Corry <[email-masked]>
Date: Thu, 30 Jul 2009 13:46:40 -0500

Daniel Stenberg wrote on 7/30/2009 5:54 AM: 
> On Wed, 29 Jul 2009, Ian Hickson wrote:
> 
>> (We wouldn't want to finish writing this spec only to find that while
>> we were at it, the browser vendors got together and added a new
>> feature like httpOnly without it getting into the spec.)
> 
> I agree. httpOnly might be the perfect example as well, as something
> that isn't in any spec anywhere (apart from Microsoft's) but is in wide
> use already.

I added "Add features that are already widely implemented or have a critical mass of support" -- does that work?

I also added two more considerations.

Revised charter below.

- Bil

-----

Last Modified: 2008-07-30

Mailing Lists:

* Add features that are already widely implemented or have a
critical mass of support

In doing so, it should consider:
* Implementer experience
* Demonstrated use of HTTP State Management Mechanism
* Impact on existing implementations and deployments
* Ability to achieve broad implementation.
* Ability to address broader use cases than may be
contemplated by the original authors.

Goals and Milestones:
TBD

---

From: Bil Corry <[email-masked]>
Date: Thu, 30 Jul 2009 14:05:22 -0500

> httpOnly without it getting into the spec.)

BTW, my original goal for this WG was a bit more ambitious, but I've rethought it.  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.  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).

- Bil

---

From: Ian Hickson <[email-masked]>
Date: Thu, 30 Jul 2009 21:45:43 +0000 (UTC)

On Thu, 30 Jul 2009, Bil Corry wrote:
> 
> I added "Add features that are already widely implemented or have a 
> critical mass of support" -- does that work?

Sounds great, thanks!

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 31 Jul 2009 14:42:47 +0200 (CEST)

On Thu, 30 Jul 2009, Bil Corry wrote:

> BTW, my original goal for this WG was a bit more ambitious, but I've 
> rethought it.  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.

Related to this, allow me to mention a pretty good resource for httpOnly 
details:

 	http://www.owasp.org/index.php/HTTPOnly

-- 

  / daniel.haxx.se

---

From: Bil Corry <[email-masked]>
Date: Fri, 31 Jul 2009 09:49:55 -0500

Daniel Stenberg wrote on 7/31/2009 7:42 AM: 
>> rethought it.  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.
> 

That document is the reason for this group -- I started out (along with Jim Manico and others) wanting to create a RFC for HTTPOnly, but was told that doing so without an updated Cookie specification "seems like work bordering to useless".  You might remember the conversation :)

	http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0237.html

- Bil

---

From: Dan Winship <[email-masked]>
Date: Fri, 31 Jul 2009 12:46:04 -0400

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

---

From: Adam Barth <[email-masked]>
Date: Fri, 31 Jul 2009 10:32:40 -0700

> end up being a lot more like 2109 then 2965.)

This perspective seems somewhat unhelpful to implementors.  Perhaps
our efforts would be better spent in a community that values the
document we intend to produce.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 31 Jul 2009 19:39:18 +0200 (CEST)

On Fri, 31 Jul 2009, Bil Corry wrote:

> That document is the reason for this group -- I started out (along with Jim 
> Manico and others) wanting to create a RFC for HTTPOnly, but was told that 
> doing so without an updated Cookie specification "seems like work bordering 
> to useless".  You might remember the conversation :)
>

Oh my. I really am getting old! ;-) Thanks for reminding me...

-- 

  / daniel.haxx.se

---

From: Bil Corry <[email-masked]>
Date: Fri, 31 Jul 2009 16:10:44 -0500

> way (RFC 2965), depending on how you look at it, so our tasks are fairly

I've rewritten the charter to the one at the end of this message.  Specific changes to improve it are appreciated.

> end up being a lot more like 2109 then 2965.)

Do you think we can skip the Informational RFC and jump straight to writing a RFC that obsoletes RFC 2965?

> this runs the risk of turning into Set-Cookie2 again.

I don't have any answers here, just the end result I'd like to see.

- Bil

-----

Last Modified: 2008-07-31

Mailing Lists:

The HTTP State Management Mechanism (Cookies) was original created
by Netscape Communications in their Netscape cookie specification,
from which a formal specification followed (RFC 2109, RFC 2965).
However, the formal specification was never implemented in practice;
Cookie implementation evolved ad-hoc, creating a disparity between
the formal specification and real-world usage.

The working group will create a new RFC that obsoletes RFC 2965 and
specifies Cookies as they are used in existing implementations and
deployments.

In doing so, the working group should consider:
* Implementer experience

The following specifications, RFCs and Internet-Drafts should be
considered:
* Netscape Cookie Specification
    http://curl.haxx.se/rfc/cookie_spec.html
* RFC 2109 - HTTP State Management Mechanism (Obsoleted by RFC 2965)
    http://tools.ietf.org/html/rfc2109
* RFC 2964 - Use of HTTP State Management
    http://tools.ietf.org/html/rfc2964
* RFC 2965 - HTTP State Management Mechanism (Obsoletes RFC 2109)
    http://tools.ietf.org/html/rfc2965
* I-D - HTTP State Management Mechanism v2
    http://tools.ietf.org/html/draft-pettersen-cookie-v2
* I-D - Cookie-based HTTP Authentication
    http://tools.ietf.org/html/draft-broyer-http-cookie-auth
* Widely Implemented - HTTPOnly
    http://www.owasp.org/index.php/HTTPOnly

Goals and Milestones:
TBD