Re: [http-state] Security considerations overview

=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 03 March 2010 00:29 UTC

Return-Path: <Jeff.Hodges@KingsMountain.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 7C9E128C1E6 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 VhQnDjC6MIJ9 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:29:54 -0800 (PST)
Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 98D0E28C1BF for <http-state@ietf.org>; Tue, 2 Mar 2010 16:29:54 -0800 (PST)
Received: (qmail 28302 invoked by uid 0); 3 Mar 2010 00:29:55 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 3 Mar 2010 00:29:55 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=4yMTSBqTKXxJ5WQQHRAm/dliflj8+gU6zTB7CXrfTbKqg5hhHLV4RWSCCOcY9iycggq+IDeYuldfXAZyH5h1I0saDgrSiuUhtzjphMCi5Tt4FdL+mZUPu/GW2INRzB1b;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.223]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1NmcTL-0008Ph-Lq for http-state@ietf.org; Tue, 02 Mar 2010 17:29:55 -0700
Message-ID: <4B8DAD83.1010602@KingsMountain.com>
Date: Tue, 02 Mar 2010 16:29:55 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: IETF HTTP State WG <http-state@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [http-state] Security considerations overview
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 03 Mar 2010 00:29:55 -0000

<individual>

I agree with David Morris wrt that particular paragraph being obtuse, 
especially to those who are not deeply schooled in the intricacies of web 
(in)security.

I think this can be addressed by a combination of (a) further wordsmithing, (b) 
forward reference to the more detailed exposition to follow (which I'm not sure 
folks in the thread have reviewed), and (c) appropriate citations. This para is 
simply part of an overview.


(a) (b) here's a build on Adam's latest suggestion, wrt that paragraph, which 
tries to address David's concerns..

   Transport-layer encryption, such as that employed in HTTPS, is
   insufficient to prevent a network attacker from obtaining or altering a
   victim's cookies because the cookie protocol itself has various
   vulnerabilities (see "Weak Integrity", below). In addition, by default,
   the cookie protocol does not provide confidentiality from network attackers,
   even when used in conjunction with HTTPS.


(c) e.g. informative references such as..

   ForceHTTPS: Protecting High-Security Web Sites from Network Attacks
   https://crypto.stanford.edu/forcehttps/

..which describes many of the issues with the present "cookie protocol".


It seems to me that addressing the details that are being discussed in this 
thread is more properly done in the presently-entitled section "Weak Integrity" 
  of the SecCons section in -05pre...

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


=JeffH


</individual>