IETF Logo Mail Archive

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

"Shelby Moore" <shelby@coolpage.com> Thu, 26 August 2010 08:56 UTC

Return-Path: <shelby@coolpage.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B353A6877 for <http-state@core3.amsl.com>; Thu, 26 Aug 2010 01:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Level:
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjZLFJUb5ejC for <http-state@core3.amsl.com>; Thu, 26 Aug 2010 01:56:09 -0700 (PDT)
Received: from www5.webmail.pair.com (www5.webmail.pair.com [66.39.3.83]) by core3.amsl.com (Postfix) with SMTP id 68DEE3A6862 for <http-state@ietf.org>; Thu, 26 Aug 2010 01:56:09 -0700 (PDT)
Received: (qmail 71515 invoked by uid 65534); 26 Aug 2010 08:56:41 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Thu, 26 Aug 2010 04:56:41 -0400
Message-ID: <e0c8bfd63e8126b00fee4aa47b8d9506.squirrel@sm.webmail.pair.com>
Date: Thu, 26 Aug 2010 04:56:41 -0400
From: Shelby Moore <shelby@coolpage.com>
To: http-state@ietf.org
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: Re: [http-state] IETF-wide Last Call for -httpstate-cookie-10 ?
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Aug 2010 08:56:11 -0000

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.

v2.23.0 | Report a Bug | By Email