http://docs.google.com/View?docid=dxxqgkd_0cvcqhsdw
If you have an active interest in participating, our list is here:
http://groups.google.com/group/ietf-httponly-wg
- Bil
This isn't being done by WHAT-WG, then?
> If you have an active interest in participating, our list is here:
>
> http://groups.google.com/group/ietf-httponly-wg
Is this an official IETF group? It seems odd that its list is not on the
IETF mailing list server.
Gerv
We're not officially affiliated with any group, although the plan is to move it to IETF or work with Yngve to add it to his cookie draft. If you're willing to get us added officially to a group, we'd love the help.
- Bil
On Friday 12 December 2008, Bil Corry wrote:
> Gervase Markham wrote on 12/12/2008 11:23 AM:
> > Is this an official IETF group? It seems odd that its list is not on the
> > IETF mailing list server.
>
> We're not officially affiliated with any group, although the plan is to
> move it to IETF or work with Yngve to add it to his cookie draft. If
> you're willing to get us added officially to a group, we'd love the help.
FWIW, some related ietf-http-wg talk about this is listed here:
http://www.nabble.com/HttpOnly-to16117176.html#a16117176
http://www.nabble.com/HTTPOnly-Cookies-Specification-to20611621.html#a20611621
My personal opinion is that any IETF related conversation regarding this issue
should happen at ietf-http-wg list (unless a new WG is created). Otherway it
should be moved to the general purpose apps-discuss mailing list (but I don't
recommend it). People at the ietf-http-wg list are more than helpful.
Since this is the mozilla list I suggest looking at the comment of "Dan
Winship" at the second link :-)
As you point out, I did post to ietf-http-wg and the feedback I received was that someone should document cookies-as-they-exist first, then spec HTTPOnly. Maybe that is the ideal way to handle it, but my primary concern is protecting users via HTTPOnly. Mozilla, WebKit and Microsoft have all recently updated their HTTPOnly features:
https://bugzilla.mozilla.org/show_bug.cgi?id=380418
https://bugs.webkit.org/show_bug.cgi?id=10957
http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx
I haven't had a chance to test them yet against our draft, but vendors are implementing HTTPOnly without the benefit of a well thought-out spec. For example, Microsoft missed Cookie2 for HTTPOnly cookies:
http://ha.ckers.org/blog/20081111/httponly-fix-in-msxml/#comment-88826
That's the mess my group is tackling.
- Bil
My first reaction to all this is: Can you really create a useful spec
for HTTPOnly cookies without first creating a spec for cookies? I.e. as
far as I know there is no useable spec out there for how to parse
HTTPOnly cookies at all, so it'd seem hard to detect what a HTTPOnly
cookie is.
That said, having a spec for cookies as well as HTTPOnly cookies would
be great. However I think that you should try to as soon as possible
bring the work to any of the existing organizations, such as IETF or WHATWG.
/ Jonas
That's what Dan Winship said (more or less):
http://lists.w3.org/Archives/Public/ietf-http-wg/2008OctDec/0235.html
I do agree that cookies could use a massive overhaul, taking the original Netscape cookie spec, RFCs 2109, 2964, and 2965, along with Yngve Pettersen's 2965 replacement draft and merge them all together with the real-world implementations (HTTPOnly, etc) and from that, create one spec to rule them all.
But as I replied to Stefanos; Mozilla, WebKit and Microsoft have all recently updated their HTTPOnly features -- we want to piggyback on that momentum to get HTTPOnly implemented in a standard way without having to wait another year or two for a comprehensive cookie overhaul.
> That said, having a spec for cookies as well as HTTPOnly cookies would
> be great. However I think that you should try to as soon as possible
> bring the work to any of the existing organizations, such as IETF or
> WHATWG.
I'll be doing this in January, thanks.
- Bil
Out of curiosity, what do you want to specify beyond what XMLHttpRequest
and HTML5 specifies?
/ Jonas
HTML5 only contains a disclaimer:
-----
This specification does not define what makes an HTTP-only cookie, and at the time of publication the editor is not aware of any reference for HTTP-only cookies. They are a feature supported by some Web browsers wherein an "httponly" parameter added to the cookie string causes the cookie to be hidden from script.
------
The latest XHR draft does cover sending and receiving the cookie headers (not allowing them to be intercepted or overwritten). Neither really delve into specifics, so we're hoping to add clarification to UA implementers.
But beyond that, there's two more issues that we're working on:
(1) Figuring out how to add integrity protection on top of confidentiality protection. That is, how to prevent an attacker from overwriting HTTPOnly cookies with his/her own cookie.
(2) Figuring out how to add privacy protection on top of confidentiality protection. That is, how to prevent an attacker from learning if a HTTPOnly cookie has been set.
We came to the conclusion that #2 wasn't possible, at least not without creating a "namespace"-type system where HTTPOnly cookies can co-exist along side a JavaScript-created cookie of the same name. And #1 is being debated currently, we may have to drop it too as it will also require some fancy footwork I think.
You can see our current work here, although it doesn't reflect some of the newer discussions we've had:
https://docs.google.com/View?docid=dxxqgkd_0cvcqhsdw
One option I'm considering is doing as you suggest, writing an entire cookie spec as it exists now, then add the features to cookies necessary to provide integrity and privacy. I spoke with Ian Hickson, he said IETF is the proper place for this work, not WHATWG.
- Bil
There is now an official list for discussing changes to the cookie spec here:
https://www.ietf.org/mailman/listinfo/http-state
- Bil