Re: [http-state] I-D Action:draft-ietf-httpstate-cookie-03.txt

Adam Barth <ietf@adambarth.com> Tue, 23 February 2010 06:31 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 60DEA3A73B2 for <http-state@core3.amsl.com>; Mon, 22 Feb 2010 22:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.87
X-Spam-Level:
X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.107, 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 lDW8rlA5PNia for <http-state@core3.amsl.com>; Mon, 22 Feb 2010 22:31:03 -0800 (PST)
Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id A2AFA28C50F for <http-state@ietf.org>; Mon, 22 Feb 2010 22:30:53 -0800 (PST)
Received: by ywh3 with SMTP id 3so2086472ywh.31 for <http-state@ietf.org>; Mon, 22 Feb 2010 22:32:51 -0800 (PST)
Received: by 10.90.177.9 with SMTP id z9mr2452912age.93.1266906771424; Mon, 22 Feb 2010 22:32:51 -0800 (PST)
Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by mx.google.com with ESMTPS id 14sm4178416gxk.15.2010.02.22.22.32.49 (version=SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 22:32:50 -0800 (PST)
Received: by iwn29 with SMTP id 29so1950700iwn.31 for <http-state@ietf.org>; Mon, 22 Feb 2010 22:32:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.85.205 with SMTP id p13mr845988ibl.8.1266906769120; Mon, 22 Feb 2010 22:32:49 -0800 (PST)
In-Reply-To: <4B82C8EE.8000107@securenet.de>
References: <20100213080001.D07A03A73C7@core3.amsl.com> <4B82C8EE.8000107@securenet.de>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 22 Feb 2010 22:32:29 -0800
Message-ID: <5c4444771002222232v5487c592w22e7abef288cf6e5@mail.gmail.com>
To: Achim Hoffmann <ah@securenet.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: http-state@ietf.org
Subject: Re: [http-state] I-D Action:draft-ietf-httpstate-cookie-03.txt
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: Tue, 23 Feb 2010 06:31:09 -0000

On Mon, Feb 22, 2010 at 10:11 AM, Achim Hoffmann <ah@securenet.de> wrote:
> Simple question about the *dates" in this draft:
>
> 1) If I understand 5.1.1. Dates correctly, the format of the date is
>   fixed and must be in GMT.
>   IIRC the date format in RFC2616 allows more variants. Also the timezone
>   may be different to GMT (see RFC2616, 19.3).
>
>   So the definitions in this draft would brake old behaviours.
>   (Though, from a security point of view, I'd prefer the draft definition:)

The date format in 5.1.1. is specifically constructed to avoid
breaking legacy servers.  Is your concern based on a specific legacy
server or general philosophy?

> 2) In 4.1.2. Semantics (third paragraph) we read:
>        " .. by including an Expires attribute with a value in the past."
>   This is a bit missleading unless all date formats are GMT (see 1) above).

This section is non-normative.  If the server behaves as recommended
(e.g., uses rfc1123-date), then this advice is sensible.

Adam