Subject: [http-state] draft-abarth-cookie-02 posted

From: Adam Barth <[email-masked]>
Date: Fri, 21 Aug 2009 00:41:10 -0700

I've uploaded a new version of the draft:

http://www.ietf.org/id/draft-abarth-cookie-02.txt

Notable changes:

1) We now parse cookie attributes.
2) We now understand cookie paths.

Test suite size: 143 tests

Lots of stuff left TODO.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 21 Aug 2009 10:01:53 +0200 (CEST)

> http://www.ietf.org/id/draft-abarth-cookie-02.txt

I just read the description for HttpOnly (4.1.2.6) and it certainly is fuzzy:

       The user agent SHOULD protect confidentiality of cookies
       with the HttpOnly attribute by including HttpOnly cookies only
       when generating cookie strings for use in HTTP requests.

This document is called "HTTP State Management Mechanism" so doesn't this 
imply that we only speak of cookies over HTTP? In what other protocol could a 
cookie be used?

Instead, I would suggest a phrasing that explains how HttpOnly is (supposedly) 
protecting the cookie from being accessed or modified by local scripting 
(javascript) and similar but is still used like normal when HTTP requests are 
made.

The name of this attribute is slightly misleading methinks.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Fri, 21 Aug 2009 01:04:37 -0700

> I just read the description for HttpOnly (4.1.2.6) and it certainly is

It certainly is.  :)

> Instead, I would suggest a phrasing that explains how HttpOnly is
> (supposedly) protecting the cookie from being accessed or modified by local
> scripting (javascript) and similar but is still used like normal when HTTP
> requests are made.

Send me some better text and I put it in the draft.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 21 Aug 2009 10:09:45 +0200 (CEST)

> Send me some better text and I put it in the draft.

Ok, here's a first take:

   The user agent SHOULD protect confidentiality of cookies
   with the HttpOnly attribute by not allowing local scripting
   or similar mechnisms to read or modify their contents. Still
   these cookies are kept in the cookie store for use in further
   HTTP requests.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Fri, 21 Aug 2009 01:17:20 -0700

>  these cookies are kept in the cookie store for use in further

Thanks!

Here's what I put in:

<t hangText="Semantics">The user agent SHOULD protect
confidentiality of cookies with the HttpOnly attribute by not
allowing local scripts or other similar mechnisms to read their
contents.</t>

I removed "or modify" for two reasons:

1) There isn't any way to modify existing cookies.  You can only
delete cookies and create new ones.

2) HttpOnly doesn't actually provide any integrity properties.  Sad, but true.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 21 Aug 2009 10:33:44 +0200 (CEST)

On Fri, 21 Aug 2009, Adam Barth wrote:

> 1) There isn't any way to modify existing cookies.  You can only delete 
> cookies and create new ones.

Oh, but...

I'm blissfully ignorant about what you can do or not with existing javascript. 
I'm thinking purely of what the HttpOnly property signals to an user-agent, 
and as far as I see it wants to prevent a client-side script from modifying it 
as well as reading it.

Doesn't HttpOnly imply that a script cannot remove it and add a new cookie 
using the same name that it can change (and read)? Isn't that virtually the 
same effect as modifying it?

If Browser B introduces a ModifyCookie() function, would that function work on 
cookies marked with HttpOnly according to this spec? If the spec says HttpOnly 
only prevents scripts from "reading their contents" I would claim it certainly 
doesn't explicitly forbid Browser B from doing this. Which is why I thought it 
should mention this...

Please take these as questions as much as comments, I'm not that fluent in the 
layers above HTTP! ;-)

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 21 Aug 2009 10:58:31 +0200 (CEST)

> http://www.ietf.org/id/draft-abarth-cookie-02.txt

Typo: Section 5.2 lists "last-access = the date and time the cookie was 
received" twice.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Fri, 21 Aug 2009 09:04:43 -0700

On Fri, Aug 21, 2009 at 1:33 AM, Daniel Stenberg<[email-masked]> wrote:
> I'm blissfully ignorant about what you can do or not with existing
> javascript. I'm thinking purely of what the HttpOnly property signals to an
> user-agent, and as far as I see it wants to prevent a client-side script
> from modifying it as well as reading it.

I agree that would be desirable, but I'm afraid that's not how things work.

> same effect as modifying it?

There actually is some behavior like this.  I haven't worked out the
details precisely, but it's harder to delete HttpOnly cookies from
script.  My plan is to cover this in the UA conformance section
because that's were all the tricky eviction details are currently.
There's already a TODO about this issue in that part of the spec.  To
investigate this, we need to improve the testing harness to be able to
test JavaScript.  That shouldn't be too hard, but figuring out how the
Domain attribute works is higher on my list at the moment.  :)

> If Browser B introduces a ModifyCookie() function, would that function work
> on cookies marked with HttpOnly according to this spec? If the spec says
> HttpOnly only prevents scripts from "reading their contents" I would claim
> it certainly doesn't explicitly forbid Browser B from doing this. Which is
> why I thought it should mention this...

I think we should cross that bridge when we come to it.

> Please take these as questions as much as comments, I'm not that fluent in
> the layers above HTTP! ;-)

This issue came up in the original discussion that lead to the
creation of this group.  These are certainly good questions.

Adam

---

From: Adam Barth <[email-masked]>
Date: Fri, 21 Aug 2009 09:18:02 -0700

> Typo: Section 5.2 lists "last-access = the date and time the cookie was

Thanks.  Fixed.

Adam

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 25 Aug 2009 09:42:44 +0200

On Fri, 21 Aug 2009 10:33:44 +0200, Daniel Stenberg <[email-masked]> wrote:
> Doesn't HttpOnly imply that a script cannot remove it and add a new  
> cookie using the same name that it can change (and read)? Isn't that  
> virtually the same effect as modifying it?
>
> If Browser B introduces a ModifyCookie() function, would that function  
> work on cookies marked with HttpOnly according to this spec? If the spec  
> says HttpOnly only prevents scripts from "reading their contents" I  
> would claim it certainly doesn't explicitly forbid Browser B from doing  
> this. Which is why I thought it should mention this...

I actually think it would be best if this specification defined a hook for specifications that allow mutating cookies to hook into. They can then decide on a per-API basis whether the flag needs to be taken into account. Review will make sure that draft does the correct thing.

As far as I can tell the only API that will be affected by HttpOnly at this point is document.cookie which allows for setting and reading the cookie string.  That API is defined here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#dom-document-cookie

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Adam Barth <[email-masked]>
Date: Tue, 25 Aug 2009 11:06:31 -0700

> I actually think it would be best if this specification defined a hook for specifications that allow mutating cookies to hook into. They can then decide on a per-API basis whether the flag needs to…

Done.  If you define a "non-HTTP" API, then you'll get the HttpOnly
restrictions.  If you think of a better name, let me know.

Adam

---

From: Ian Hickson <[email-masked]>
Date: Mon, 31 Aug 2009 09:17:03 +0000 (UTC)

On Tue, 25 Aug 2009, Adam Barth wrote:
> > I actually think it would be best if this specification defined a hook 
> > for specifications that allow mutating cookies to hook into. They can 
> > then decide on a per-API basis whether the flag needs to be taken into 
> > account. Review will make sure that draft does the correct thing.
> 

I was reading:

   http://tools.ietf.org/html/draft-abarth-cookie-02

...but couldn't find the relevant bit. How should HTML5 be modified here:

   http://www.whatwg.org/specs/web-apps/current-work/#dom-document-cookie

...to be compatible with what you are specifying?

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

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 31 Aug 2009 11:35:04 +0200 (CEST)

On Mon, 31 Aug 2009, Ian Hickson wrote:

> ...but couldn't find the relevant bit.

Right, that's what I found as well and which triggered this mail thread. It is 
lacking but I think Adam will have something more for next round.

> How should HTML5 be modified here:
>

I find it intresting that this HTML5 section mentions that browsers must not 
let a script be "overwriting the values of HTTP-only cookies" - as that is 
pretty much what I was arguing the http-state spec to also say. (And 
explicitly not just limit it for reading or accessing.)

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Mon, 31 Aug 2009 04:28:02 -0700

> ...but couldn't find the relevant bit.

I haven't updated the I-D since I added the relevant text.  I'll do
that later in the week.  You can read the current version here:

http://github.com/abarth/http-state/blob/f3f565011858d206ff8531eb05b11503db59ac59/drafts/cookie.xml

> ...to be compatible with what you are specifying?

On getting, you want to return the cookie-string for the document's
address for a "non-HTTP" API.  (If you can think of a better term than
non-HTTP, please let me know.)

On setting, you want to say that the user agent receives a
set-cookie-string for the document's address via a "non-HTTP" API.
The concept of a "set-cookie-string" isn't quite in the spec yet, but
I'll add it in the next day or two.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 31 Aug 2009 04:30:17 -0700

> explicitly not just limit it for reading or accessing.)

Yes.  It does appear that browsers ignore set-cookie-strings that name
already-existing cookies with the HttpOnly attribute.  I need to write
tests for this behavior and then add it to the Set-Cookie processing
model.

Adam