Re: [http-state] Security considerations overview

Adam Barth <ietf@adambarth.com> Sat, 06 March 2010 15:45 UTC

Return-Path: <ietf@adambarth.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 DE0C128C103 for <http-state@core3.amsl.com>; Sat, 6 Mar 2010 07:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 OKHb1dJvpHV6 for <http-state@core3.amsl.com>; Sat, 6 Mar 2010 07:45:47 -0800 (PST)
Received: from mail-yw0-f202.google.com (mail-yw0-f202.google.com [209.85.211.202]) by core3.amsl.com (Postfix) with ESMTP id BF45428C115 for <http-state@ietf.org>; Sat, 6 Mar 2010 07:45:47 -0800 (PST)
Received: by ywh40 with SMTP id 40so1685056ywh.19 for <http-state@ietf.org>; Sat, 06 Mar 2010 07:45:45 -0800 (PST)
Received: by 10.150.70.32 with SMTP id s32mr2313922yba.66.1267890345276; Sat, 06 Mar 2010 07:45:45 -0800 (PST)
Received: from mail-iw0-f173.google.com (mail-iw0-f173.google.com [209.85.223.173]) by mx.google.com with ESMTPS id 22sm2533801iwn.12.2010.03.06.07.45.43 (version=SSLv3 cipher=RC4-MD5); Sat, 06 Mar 2010 07:45:43 -0800 (PST)
Received: by iwn3 with SMTP id 3so227733iwn.13 for <http-state@ietf.org>; Sat, 06 Mar 2010 07:45:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.144.207 with SMTP id a15mr488601ibv.94.1267890343139; Sat, 06 Mar 2010 07:45:43 -0800 (PST)
In-Reply-To: <4B8DAD83.1010602@KingsMountain.com>
References: <4B8DAD83.1010602@KingsMountain.com>
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 6 Mar 2010 07:45:23 -0800
Message-ID: <5c4444771003060745n683ec374j921a85a6604400da@mail.gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: IETF HTTP State WG <http-state@ietf.org>
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: Sat, 06 Mar 2010 15:45:49 -0000

On Tue, Mar 2, 2010 at 4:29 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
> <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.

Since no one seemed to object to this wording, I've adopted it (with
minor variations).

Adam


> (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>
>
> _______________________________________________
> http-state mailing list
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state
>