Re: [http-state] Summary of discussion of Ticket 5 (Cookie ordering)

Achim Hoffmann <ah@securenet.de> Fri, 16 April 2010 10:12 UTC

Return-Path: <ah@securenet.de>
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 5D0AD3A67AB for <http-state@core3.amsl.com>; Fri, 16 Apr 2010 03:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Level:
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35]
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 VtMhcKz7ImMl for <http-state@core3.amsl.com>; Fri, 16 Apr 2010 03:12:07 -0700 (PDT)
Received: from munich.securenet.de (munich.securenet.de [82.135.17.200]) by core3.amsl.com (Postfix) with ESMTP id 3D4AF3A6B0A for <http-state@ietf.org>; Fri, 16 Apr 2010 03:12:01 -0700 (PDT)
Received: from oxee.securenet.de (unknown [10.30.18.40]) by munich.securenet.de (Postfix) with ESMTP id 17AEF27197 for <http-state@ietf.org>; Fri, 16 Apr 2010 12:11:53 +0200 (CEST)
Received: by oxee.securenet.de (Postfix, from userid 65534) id 13029140202A; Fri, 16 Apr 2010 12:11:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by oxee.securenet.de (Postfix) with ESMTP id 054B41402027; Fri, 16 Apr 2010 12:11:51 +0200 (CEST)
Received: from oxee.securenet.de ([127.0.0.1]) by localhost (oxee.securenet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30983-03; Fri, 16 Apr 2010 12:11:50 +0200 (CEST)
Received: from [10.30.18.9] (krakatau.securenet.de [10.30.18.9]) by oxee.securenet.de (Postfix) with ESMTP id E84C41402426; Fri, 16 Apr 2010 12:11:50 +0200 (CEST)
Message-ID: <4BC837C8.80501@securenet.de>
Date: Fri, 16 Apr 2010 12:11:20 +0200
From: Achim Hoffmann <ah@securenet.de>
Organization: SecureNet
User-Agent: who">cares?
MIME-Version: 1.0
To: Adam Barth <ietf@adambarth.com>
References: <5c4444771002151547k75bbd0e7rfd2ccf735bdb2e37@mail.gmail.com> <u2o5c4444771004110954tfbb069ddj6f80356bc4bd47d3@mail.gmail.com> <C779AE1F-EE2B-4D87-A3F1-C91A425E339D@apple.com> <z2m5c4444771004151615r10f95fen683406b64abff6fa@mail.gmail.com> <l2j5c4444771004151627i3cc43a37n9f3783e4be04458a@mail.gmail.com>
In-Reply-To: <l2j5c4444771004151627i3cc43a37n9f3783e4be04458a@mail.gmail.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Summary of discussion of Ticket 5 (Cookie ordering)
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: Fri, 16 Apr 2010 10:12:08 -0000

Adam Barth wrote on 16.04.2010 01:27:

> Ok, here's what I've got:
> 
> [[
>           <t>The user agent SHOULD sort the cookie-list in the following
>           order:
>           <list style="symbols">
>             <t>Cookies with longer paths are listed before cookies
>             with shorter paths.</t>
> 
>             <t>Among cookies that have equal length path fields, cookies
>             with earlier creation-times are listed before cookies with later
>             creation-times.</t>
>           </list>
>           <list style="empty">
>             <t>NOTE: Not all user agents sort the cookie-list in this order,
>             but this order reflects common practice when this document was
>             written. The specific ordering might not be optimal in every
>             metric, but using the consensus ordering is a relatively low cost
>             way to improve interoperability between user agents.</t>
>           </list>
>           </t>
> ]]

hmm, this description leads me to following example:

  * cookies send by www.some.tld in following chronological sequence

	Set-Cookie: key=val0;
	Set-Cookie: key=val1; path=/foo
	Set-Cookie: key=val2; path=/
	Set-Cookie: key=val3; path=/bar
	Set-Cookie: key=val4; domain=.some.tld
	Set-Cookie: key=val5; domain=.some.tld; path=/some/thing/very/long/to/ensure/being/first

  * cookies send by user agent for a request to http://www.some.tld/

	Cookie: key=val5; key=val1; key=val3; key=val2; key=val0; key=val4

I guess (but did not yet prove) that most browsers do not send cookies in this
(above) sequence. It would rather be:

	Cookie: key=val3; key=val1; key=val2; key=val0; key=val5; key=val4

So the new description does not show current practice.

According application security, I already explained that web applications which
rely on the ordering somehow, are prone to some attacks.
As there is no common behaviour according this ordering in current browsers, I'd
recommend that the spec does not recommend the cookie ordering. This is not wrong
and would force web application developers to implement proper measures:
	User agents MAY send cookies in any sequence.

KISS - keep it simple, stupid
Achim