Re: [DNSOP] Public Suffix List

["Yngve Nysaeter Pettersen" <[e-mail]>]

On Mon, 09 Jun 2008 16:07:10 +0200, Wes Hardaker <[e-mail]>  
wrote:

> EG, if I had "www.example.com" and I received cookies in a request from
> "example.com", "images.example.com" and "hacker.com" I could determine

Not sure if you mean that www.example.com is sending cookies for  
example.com, images.example.com and hacker.com, of which only the first is  
legal, or that www.example.com includes resource that sets cookies for  
those destinations, which can be controlled by third-party cookie filters.

> based on the source which ones I wanted to accept.  The current issue
> with cookie usage is that sites don't have the ability to not accept
> data from external sources.  Fix that problem instead and you'll have a
> much better and more scalable solution.  It'll require work on both the
> server side and the browser side but in the end is a better solution.

RFC 2965 requires the client to send the domain along with the cookie  
under some conditions. My suggested update of RFC 2965 <URL:  
http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-02.txt > ,  
which changes the domain semantics, also suggest sending the domain for  
_all_ cookies, also those set using old versions of the specification, and  
the name of the host setting the cookie (if known) for cookies set using  
the older versions.

For cookies, the primary problem here is limiting what the client can set,  
so that malicious.co.uk cannot set a cookie From [e-mail]  Mon Jun  9 07:37:51 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 888FE3A6C73;
	Mon,  9 Jun 2008 07:37:51 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 01A273A6C73
	for <[e-mail]>; Mon,  9 Jun 2008 07:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level: 
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 
	BAYES_00=-2.599, 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 kp4E5QCAMyIq for <[e-mail]>;
	Mon,  9 Jun 2008 07:37:48 -0700 (PDT)
Received: from mail.opera.com (mail.opera.com [213.236.208.66])
	by core3.amsl.com (Postfix) with ESMTP id 34BD53A6BAA
	for <[e-mail]>; Mon,  9 Jun 2008 07:37:47 -0700 (PDT)
Received: from killashandra.oslo.opera.com (pat-tdc.opera.com [213.236.208.22])
	by mail.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id
	m59Ec28R014092; Mon, 9 Jun 2008 14:38:02 GMT
Date: Mon, 09 Jun 2008 16:38:05 +0200
To: "Wes Hardaker" <[e-mail]>, "Gervase Markham" <[e-mail]>
From: "Yngve Nysaeter Pettersen" <[e-mail]>
Organization: Opera Software
MIME-Version: 1.0
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
User-Agent: Opera Mail/9.27 (Win32)
Cc: [e-mail], [e-mail]
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: [e-mail]
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

On Mon, 09 Jun 2008 16:07:10 +0200, Wes Hardaker <[e-mail]>  
wrote:

> EG, if I had "www.example.com" and I received cookies in a request from
> "example.com", "images.example.com" and "hacker.com" I could determine

Not sure if you mean that www.example.com is sending cookies for  
example.com, images.example.com and hacker.com, of which only the first is  
legal, or that www.example.com includes resource that sets cookies for  
those destinations, which can be controlled by third-party cookie filters.

> based on the source which ones I wanted to accept.  The current issue
> with cookie usage is that sites don't have the ability to not accept
> data from external sources.  Fix that problem instead and you'll have a
> much better and more scalable solution.  It'll require work on both the
> server side and the browser side but in the end is a better solution.

RFC 2965 requires the client to send the domain along with the cookie  
under some conditions. My suggested update of RFC 2965 <URL:  
http://www.ietf.org/internet-drafts/draft-pettersen-cookie-v2-02.txt > ,  
which changes the domain semantics, also suggest sending the domain for  
_all_ cookies, also those set using old versions of the specification, and  
the name of the host setting the cookie (if known) for cookies set using  
the older versions.

For cookies, the primary problem here is limiting what the client can set,  
so that malicious.co.uk cannot set a cookithat will be seen by  
mybank.co.uk, or that can be used to track users across several domains  
(without advertising that they do share the information).

Requesting permission from the server (or individual resources) to send  
cookies will require an extra turnaround, thus reducing performance.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


e that will be seen by  
mybank.co.uk, or that can be used to track users across several domains  
(without advertising that they do share the information).

Requesting permission from the server (or individual resources) to send  
cookies will require an extra turnaround, thus reducing performance.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop