Subject: Re: [http-state] IETF-wide Last Call for -httpstate-cookie-10 ?

From: "Shelby Moore" <[email-masked]>
Date: Thu, 26 Aug 2010 04:56:41 -0400

Respectfully as follows...

http://www.ietf.org/mail-archive/web/http-state/current/msg00925.html

> There've been no comments wrt -10 on the list since then.[snip]
>
>http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpstate-cookie-10.txt
>
> Are there any objections to progressing -httpstate-cookie-10 to
> IETF-wide last call?

I do not know where to submit objections, so I will submit them here and
please make sure they get relayed, even if I am not here to reply again. 
Thank you in advance for your consideration.

1) 4.1.2.6.  The HttpOnly Attribute.  I propose that we need also NoHttp
Attribute, which would be the inverse case of HttpOnly. Not automatically
sending the cookie to the server, when we are holding the session id in a
cookie and submitting it only via scripted requests, eliminates the <form>
CSRF attack. See the following description of how I implement on AsiaDear
so as to prevent <form> CSRF:

https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c0

Athough it is true I can program my server to ignore the cookies, it is
better to not send them automatically via HTTP. Rather I am only accessing
the cookie client via script API. I think as <form> CSRF becomes more well
known, and my solution becomes more well known, it will be emulated if not
already the case.

2) 5.3.  Storage Model. Please recommend that HTTPS cookies be stored
encrypted (it can't hurt):

https://bugzilla.mozilla.org/show_bug.cgi?id=588704

3) 6.2.  Application Programming Interfaces.  Please change "Instead of"
to "In addition to".  Never should semantic APIs be a restriction of the
general capability. Please!

4) 8.7.  Reliance on DNS. If browsers properly implement per website
self-signed certificates:

https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c47

Then what we need to avoid MITM DNS attacks is to simply prevent HTTPS
cookies from being accessed from HTTP.  It is really critical that we do
not allow this by default.  An application should be forced to declare
than HTTPS cookie is to be shared with HTTP.

Please do not copy (Cc:) to me on any reply to list. I am unsubscribed.
Thank you.

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 26 Aug 2010 18:51:32 +0200 (CEST)

On Thu, 26 Aug 2010, Shelby Moore wrote:

Thanks for your feedback. My comments follow inline:

> Attribute

No need to. We don't add or change anything in the protocol, we only document 
it in this step!

> https://bugzilla.mozilla.org/show_bug.cgi?id=588704

Surely it _can_ hurt, for the cases when a second program would like to read 
the cookie storage from a first program. It is for example a rather common way 
to continue a "session" that was begun with one HTTP client to complete it 
with a second one.

But if the cookies are meant to be stored on a medium where no others should 
be able to pick up the cookies from, I figure you could use encryption or 
other means your system, OS and environment allow. Do we really need to say 
that in a protocol spec?

> https://bugzilla.mozilla.org/show_bug.cgi?id=588704#c47

We document the current protocol and practises here. That does not currently 
include "per website self-signed certificates".

-- 

  / daniel.haxx.se