Re: [DNSOP] Public Suffix List

[Florian Weimer <[e-mail]>]

* Gervase Markham:

> If www.flirble.co.zz and www.widget.co.zz wished to conspire to track
> users across the two sites, they would simply both say that they are
> happy to accept co.zz cookies.

Right now, they're sharing that bit of information through one of
Google's web bug services.  Cross-domain cookies would at least provide
some level of transparency.

So this argument is a bit questionable.

> I am not particularly interested in a long discussion about whether we
> need this data. Please be assured that we need it. I am, on the other
> hand, open to suggestions about better ways to obtain it.

You need some sort of out-of-band service.  The information you are
looking for is not encoded in DNS.  Whether it's necessary to provide
automatic, non-code updates of the out-of-band data is a difficult
question.  However, this looks somewhat like the IP bogon prefixes list,
where hard-coding that ever-changing part into router configurations
turned out to be a big mistake.

For the DNS folks: The web security model requires that www.example.$TLD
and login.example.$TLD (where $TLD may contain multiple labels) can
share cookies (and probably HTTP requests, but I don't do that AJAX
stuff).  This must work by default, without explicit marking by the web
site operator, or tons of deployed applications will break.  At the same
time, it shoFrom [e-mail]  Tue Jun 10 12:05:44 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 9287B3A6A6D;
	Tue, 10 Jun 2008 12:05:44 -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 8E9703A686C
	for <[e-mail]>; Tue, 10 Jun 2008 12:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5
	tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35,
	J_CHICKENPOX_22=0.6]
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 pugeIWRvin4W for <[e-mail]>;
	Tue, 10 Jun 2008 12:05:42 -0700 (PDT)
Received: from mail.enyo.de (mail.enyo.de [IPv6:2001:14b0:202:1::a7])
	by core3.amsl.com (Postfix) with ESMTP id 971F93A67E2
	for <[e-mail]>; Tue, 10 Jun 2008 12:05:41 -0700 (PDT)
Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de)
	by mail.enyo.de with esmtp id 1K69AL-0003LJ-6S;
	Tue, 10 Jun 2008 21:05:57 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.69)
	(envelope-from <[e-mail]>)
	id 1K69AK-0006sZ-Lq; Tue, 10 Jun 2008 21:05:56 +0200
From: Florian Weimer <[e-mail]>
To: Gervase Markham <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]> <[e-mail]>
	<[e-mail]>
Date: Tue, 10 Jun 2008 21:05:56 +0200
In-Reply-To: <[e-mail]> (Gervase Markham's message of
	"Mon, 09 Jun 2008 15:21:11 +0100")
Message-ID: <[e-mail]>
MIME-Version: 1.0
Cc: [e-mail], [e-mail], Wes Hardaker <[e-mail]>
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
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]

* Gervase Markham:

> If www.flirble.co.zz and www.widget.co.zz wished to conspire to track
> users across the two sites, they would simply both say that they are
> happy to accept co.zz cookies.

Right now, they're sharing that bit of information through one of
Google's web bug services.  Cross-domain cookies would at least provide
some level of transparency.

So this argument is a bit questionable.

> I am not particularly interested in a long discussion about whether we
> need this data. Please be assured that we need it. I am, on the other
> hand, open to suggestions about better ways to obtain it.

You need some sort of out-of-band service.  The information you are
looking for is not encoded in DNS.  Whether it's necessary to provide
automatic, non-code updates of the out-of-band data is a difficult
question.  However, this looks somewhat like the IP bogon prefixes list,
where hard-coding that ever-changing part into router configurations
turned out to be a big mistake.

For the DNS folks: The web security model requires that www.example.$TLD
and login.example.$TLD (where $TLD may contain multiple labels) can
share cookies (and probably HTTP requests, but I don't do that AJAX
stuff).  This must work by default, without explicit marking by the web
site operator, or tons of deployed applications will break.  At the same
time, it suld not be possible to set cross-domain cookies (that is, a
cookie for login.example.$TLD by serving a HTTP request for
login.otherexample.$TLD).  Well-written web applications should be
immune to that, but lots of them apparently aren't.

This is the status quo.  Javascript is constantly enhanced with database
and stuff like that.  As a result, you aren't just protecting mere
cookies, but much more.  Obviously, this approach is not sound.  But
even with those later changes, some means to divine administrative
boundaries from DNS names are required for plain cookie management.
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


hould not be possible to set cross-domain cookies (that is, a
cookie for login.example.$TLD by serving a HTTP request for
login.otherexample.$TLD).  Well-written web applications should be
immune to that, but lots of them apparently aren't.

This is the status quo.  Javascript is constantly enhanced with database
and stuff like that.  As a result, you aren't just protecting mere
cookies, but much more.  Obviously, this approach is not sound.  But
even with those later changes, some means to divine administrative
boundaries from DNS names are required for plain cookie management.
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop