Re: [http-state] Comments on draft-ietf-httpstate-cookie-08

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Sat, 29 May 2010 14:48 UTC

Return-Path: <yngve@opera.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 3B6133A68A7 for <http-state@core3.amsl.com>; Sat, 29 May 2010 07:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 exynJv84E-nK for <http-state@core3.amsl.com>; Sat, 29 May 2010 07:48:25 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 8CB593A6820 for <http-state@ietf.org>; Sat, 29 May 2010 07:48:24 -0700 (PDT)
Received: from acorna (30.169.202.84.customer.cdi.no [84.202.169.30]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4TEmAUJ010596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 May 2010 14:48:10 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <op.vdfzz8lovqd7e2@killashandra.oslo.osa> <c33206l4vu67g74dmi7vf1ph46m7nf5o3c@hive.bjoern.hoehrmann.de>
Date: Sat, 29 May 2010 16:48:02 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Organization: Opera Software AS
Message-ID: <op.vdg12cf6qrq7tp@acorna>
In-Reply-To: <c33206l4vu67g74dmi7vf1ph46m7nf5o3c@hive.bjoern.hoehrmann.de>
User-Agent: Opera Mail/10.53 (Win32)
Cc: "http-state@ietf.org" <http-state@ietf.org>
Subject: Re: [http-state] Comments on draft-ietf-httpstate-cookie-08
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, 29 May 2010 14:48:26 -0000

On Sat, 29 May 2010 14:50:47 +0200, Bjoern Hoehrmann <derhoermi@gmx.net>  
wrote:

> * Yngve Nysaeter Pettersen wrote:
>> * Sec 4.1.2.3
>>
>> -   For example, some user agents will reject Domain attributes of "com"
>> or "co.uk".
>>
>> This seems to imply that there are agents that will accept a TLD as a
>> valid domain (except ".local" from 2965, which is a special case). I'd
>> rather have the section say that a domain attribute need to specify at
>> least a second level domain.
>
> As I understand it, there are a number of frameworks that will auto-
> matically use the server name, or failing that its address, as default
> value for the domain attribute. It does not strike me as a good idea to
> prohibit `Domain=localhost` for instance.

The formal hostname for localhost would be "localhost.local", but in any  
case, in such a situation the hostname would also be non-dotted  
("localhost") and it must exactly match the domain attribute (localhost).  
This kind of situation is handled by Opera.

What I am (implicitly) referring to above is a situation where the domain  
attribute is not equal to the hostname, but domain-matches the hostname,  
*and* where the domain attribute is a *single* level (IOW a TLD). Those  
cases should not be allowed, even by a public suffix list.

If somebody creates a server "com" (for example, setting a cookie for it  
will not (in Opera, and probably other browsers) cause the cookie to be  
valid for all the dot-com servers, since the cookie will be set for the  
implied FQDN "com.local".

Come to think of it, is the single label (local intranet server) situation  
covered in the domain sematics?

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************