Re: [http-state] Seeking feedback on Security Considerations

Dan Winship <dan.winship@gmail.com> Sat, 13 February 2010 14:37 UTC

Return-Path: <dan.winship@gmail.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 55C6E28C14A for <http-state@core3.amsl.com>; Sat, 13 Feb 2010 06:37:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.152
X-Spam-Level:
X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=-0.887, 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 Xhfwd7TvHWf3 for <http-state@core3.amsl.com>; Sat, 13 Feb 2010 06:37:50 -0800 (PST)
Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id 89C7028C14D for <http-state@ietf.org>; Sat, 13 Feb 2010 06:37:50 -0800 (PST)
Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPA id F0FF6802AE; Sat, 13 Feb 2010 09:39:12 -0500 (EST)
Message-ID: <4B76B98E.9040606@gmail.com>
Date: Sat, 13 Feb 2010 09:39:10 -0500
From: Dan Winship <dan.winship@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <7789133a1002130001l6137f704va9e04a4edade1ee7@mail.gmail.com>
In-Reply-To: <7789133a1002130001l6137f704va9e04a4edade1ee7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Seeking feedback on Security Considerations
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, 13 Feb 2010 14:37:51 -0000

On 02/13/2010 03:01 AM, Adam Barth wrote:
> 7.3.  Clear Text

>    In addition to encrypting and signing the contents of every cookie,
>    servers that require a higher level of security SHOULD use the cookie
>    protocol only over a secure channel.

Should probably mention the problem of having to explicitly set the
"Secure" flag too.

> 7.4.  Weak Confidentiality

>    Cookies do not provide isolation by port. 
>    Cookies do not provide isolation by scheme.

Also path.

>    Although most commonly
>    used with the http and https schemes, the cookies for a given host
>    are also available to other schemes, such as ftp and gopher.

Do we know that this is consistent across browsers? Should have some
tests for that. If it's not, we can just change "are also available" to
"may also be available" though.

>    This
>    lack of isolation is most easily seen when a user agent retrieves a
>    URI with a gopher scheme via HTTP, but the lack of isolation by
>    scheme is also apparent via non-HTTP APIs that permit access to
>    cookies, such as HTML's document.cookie API.

I think retrieving an HTML+javascript page via ftp is about a zillion
times more "easily seen" than anything involving gopher. :)

-- Dan