Subject: HTTPOnly Cookies Specification

From: Bil Corry <[email-masked]>
Date: Thu, 20 Nov 2008 16:41:26 -0600

Over on OWASP's Intrinsic Security list, I brought up that HTTPOnly cookies should be better implemented across the major browsers.  Jim Manico replied that he's been actively trying to get the browsers to implement (or better implement) HTTPOnly cookies and it became clear in talking with Yngve Pettersen that the lack of a specification for HTTPOnly was hindering browser vendors.

Out of that, we started a group to discuss and create the HTTPOnly cookie specification.  If you're interested in participating, you can join here:

	http://groups.google.com/group/ietf-httponly-wg

- Bil

---

From: Dan Winship <[email-masked]>
Date: Fri, 21 Nov 2008 08:04:58 -0500

> 	http://groups.google.com/group/ietf-httponly-wg

It seems a little odd to write a specification for the HttpOnly cookie
parameter when there isn't a spec for
cookies-as-they-exist-in-the-real-world in general.

What would really be useful would be for someone to pull an HTML5 on
cookies, documenting how they are actually parsed (ie, not like the
Netscape spec or either RFC says), how the path and domain parameters
are actually used (ie, not like the Netscape spec or either RFC says), etc.

-- Dan

---

From: Bil Corry <[email-masked]>
Date: Fri, 21 Nov 2008 08:42:44 -0600

> cookies-as-they-exist-in-the-real-world in general.

Yngve Pettersen has been working on Cookies v2 -- although he isn't trying to document "cookies-as-they-exist-in-the-real-world":

	http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-03.txt

The reason for the separate spec is because both Mozilla and WebKit are actively working on their implementations of HTTPOnly, and our goal is to help guide them in implementing HTTPOnly in a common way that provides the best security.

We're not opposed to merging our work into a larger cookie spec, but if you're envisioning something beyond what Yngve is actively working on, then it should include his work as well.  Yngve suggested it may be appropriate to resurrect the http-state-wg list if there was enough interest.

- Bil

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 22 Nov 2008 16:50:35 +0100 (CET)

On Fri, 21 Nov 2008, Dan Winship wrote:

> cookies, documenting how they are actually parsed (ie, not like the Netscape 
> spec or either RFC says), how the path and domain parameters are actually 
> used (ie, not like the Netscape spec or either RFC says), etc.

Such a "someone" would preferably come from one of the major browsers' camps 
then as they should have the best knowledge about how this truly works. 
However that would also bring up a fair amount of interepretation issues and 
differences between the browsers and it will not be an easy task to write a 
docs with _single_ "how they are actually done" explanation.

Doing a HTTPOnly spec without properly putting that into its proper place in 
the entire cookie handling landscape seems like work bordering to useless to 
me.

As author of an HTTP library with cookie handling (including HTTPOnly) I would 
be very interested in seeing this complete doc so that I can make sure my work 
interoperate as good as possible.

-- 

  / daniel.haxx.se

---

From: David Morris <[email-masked]>
Date: Sat, 22 Nov 2008 19:48:55 -0800 (PST)

The flaw in this proposal is the assumption that web application builders
will be satisfied with the restrictions imposed by this flag and hence use
it.

I suspect that with the ever increasing level of highly interactive
content achieved with JavaScript, that this flag will be ignored and hence
valueless as a general solution.

More appropriate would be to spend the effort designing a solid security
model which allows JavaScript (and other active content) access to
cookies, but only within the appropriate security rules.

Dave Morris

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 23 Nov 2008 10:20:57 +0000

Daniel Stenberg wrote:
> >Netscape spec or either RFC says), how the path and domain parameters are 
> >actually used (ie, not like the Netscape spec or either RFC says), etc.
> 
> Such a "someone" would preferably come from one of the major browsers' 
> camps then as they should have the best knowledge about how this truly 
> works. However that would also bring up a fair amount of interepretation 
> issues and differences between the browsers and it will not be an easy task 
> to write a docs with _single_ "how they are actually done" explanation.

I think a document which describes the behaviour "actually done" while
acknowledging and explaining differences between major browsers - and
therefore what is identical between them - would be even more useful
than one which pretends they're all the same, like HTML5 seems to.

-- Jamie

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Sun, 23 Nov 2008 16:06:09 +0100

On Fri, 21 Nov 2008 14:04:58 +0100, Dan Winship <[email-masked]>  
wrote:

>
> Bil Corry wrote:
>> Over on OWASP's Intrinsic Security list, I brought up that HTTPOnly  
>> cookies should be better implemented across the major browsers.  Jim  
>> Manico replied that he's been actively trying to get the browsers to  
>> implement (or better implement) HTTPOnly cookies and it became clear in  
>> talking with Yngve Pettersen that the lack of a specification for  
>> HTTPOnly was hindering browser vendors.
>>
>> Out of that, we started a group to discuss and create the HTTPOnly  
>> cookie specification.  If you're interested in participating, you can  
>> join here:
>>

The Netscape spec and the RFCs (2109, 2965, 2964) specify how cookies are  
parsed (syntactically), how their arguments are to be interpreted, and how  
the cookies are to be picked when sending.

For the most part there is AFAIK no major, and very few minor differences  
between the browsers in the processing and picking part.

The parsing/interpretation differences that I am aware of between browsers  
at this time concern mainly what names are permitted (some clients allow  
cookie names with "$" and space, which is not permitted by any of the  
specifications, others doesn't), and in the policies for how they prevent  
malicious sites from setting cookies for domains like co.uk (those are  
discussed in three of the drafts I have published). None of these will  
really affect normal and carefully implemented sites.

Where there are some major differences, is in the policies for processing  
third party cookies, which are not a topic in Netscape's spec, and the  
RFCs specification is not really widely used. But that would in any case  
be a separate specification.

Given that the differences are minor in the area a specification would  
cover, I do not think it is really necessary with a "real world spec".

However, that does not mean that I think the Netscape spec shouldn't be  
republished as an historical RFC, it just does not have to include too  
much information about implementation differences.

In fact, I think having an historical RFC describing the Netscape spec  
cookies would be a good thing now that AOL/Netscape have taken that  
specification offline. But a potential problem with publishing such an RFC  
is the question who have the rights (copyright) to that specification.

In any case, I think an RFC version of that document would require  
substantial reworking compared to the original before it can be published.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sun, 23 Nov 2008 23:44:53 +0100

> than one which pretends they're all the same, like HTML5 seems to.

HTML5 does not pretend all implementations are the same... It merely  
states what implementations ought to do. Representing an implementor I can  
say that is much more useful to us than having a description of what we  
and others currently do, as we'd very much like to converge on behavior  
with other implementations going forward.

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: Dan Winship <[email-masked]>
Date: Mon, 24 Nov 2008 13:53:50 -0500

Yngve Nysaeter Pettersen wrote:
> The Netscape spec and the RFCs (2109, 2965, 2964) specify how cookies
> are parsed (syntactically), how their arguments are to be interpreted,
> and how the cookies are to be picked when sending.

RFC 2109 is nearly irrelevant in the real world, and 2965 is
*completely* irrelevant. The Netscape spec is fairly accurate (as long
as you ignore the grammar for the "expires" parameter, which only about
1/3 of cookies obey), though as you noted later, it is now only
available via archive.org and other caches.

> For the most part there is AFAIK no major, and very few minor
> differences between the browsers in the processing and picking part.

Right, but the way the browsers do it doesn't completely match what the
Netscape spec says. (Eg, if browsers actually obeyed the restriction
that cookie values can't have commas in them, then we wouldn't need the
special "don't merge Set-Cookies headers" warning in 2616bis, because it
would be possible for browsers to unmerge merged headers.) It's exactly
the same situation as with HTML5; the "real" specification of cookie
behavior is not RFC 2109 or the Netscape spec, it's "what Firefox and IE
do". The fact that this isn't documented (and isn't trivial to figure
out) makes it difficult for anyone else to implement cookie-handling in
a way that's fully compatible with the web.

-- Dan

---

From: David Morris <[email-masked]>
Date: Mon, 24 Nov 2008 11:05:09 -0800 (PST)

Here is the top link from my recent Goole search for:
   Netscape Cookie Spec

Looks and smells like a netscape site:
   http://cgi.netscape.com/newsref/std/cookie_spec.html