Re: [DNSOP] Public Suffix List

[Andrew Sullivan <[e-mail]>]

On Mon, Jun 09, 2008 at 03:43:29PM +0100, Gervase Markham wrote:

> > RFC 3696 explains, I think, most of the reasoning that I would offer
> > for why I think this is a bad idea.  I urge you and others who are
> > planning to ship this kind of feature to go (re)read that RFC.
> 
> Why do you think that the negative consequences explained in that RFC
> would apply in this case? Please think carefully about the consequences
> of possible failure scenarios.

Because what you are proposing to do adds special meaning to certain
labels (and their relative position) and not to others, in exactly the
way that previously people had special interpretations of certain
labels and their positions in the set of labels.  What you're really
trying to do here is extract meaning from the domain name, but you
can't do that reliably.  Previous efforts in that direction have
failed in unexpected ways; and given that you seem to have multiple
ways you want to use this feature, I don't see any reason to believe
you won't have surprising failures too.

The plan is both too narrow and too wide.  First, it will almost
certainly fail to capture 100% of the cases you currently don't want
to succeed.  Second, it will (as we've been arguing in this thread)
not work for new TLDs and other cases.  Your counterargument is that
the behaviFrom [e-mail]  Mon Jun  9 08:39:49 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 BDBDF28C179;
	Mon,  9 Jun 2008 08:39:49 -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 11C7E28C179
	for <[e-mail]>; Mon,  9 Jun 2008 08:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.528
X-Spam-Level: 
X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=0.207, 
	BAYES_00=-2.599, HELO_MISMATCH_COM=0.553,
	HOST_MISMATCH_NET=0.311]
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 Q2BBaoRS8wej for <[e-mail]>;
	Mon,  9 Jun 2008 08:39:48 -0700 (PDT)
Received: from lists.commandprompt.com (host-159.commandprompt.net
	[207.173.203.159])
	by core3.amsl.com (Postfix) with ESMTP id 1DA1328C16A
	for <[e-mail]>; Mon,  9 Jun 2008 08:39:47 -0700 (PDT)
Received: from commandprompt.com (227-54-222-209.mycybernet.net
	[209.222.54.227]) (authenticated bits=0)
	by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m59FfdYu028061
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <[e-mail]>; Mon, 9 Jun 2008 08:41:42 -0700
Date: Mon, 9 Jun 2008 11:40:02 -0400
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]>
	<[e-mail]>
	<[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.17 (2007-11-01)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0
	(lists.commandprompt.com [207.173.203.159]);
	Mon, 09 Jun 2008 08:41:42 -0700 (PDT)
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]

On Mon, Jun 09, 2008 at 03:43:29PM +0100, Gervase Markham wrote:

> > RFC 3696 explains, I think, most of the reasoning that I would offer
> > for why I think this is a bad idea.  I urge you and others who are
> > planning to ship this kind of feature to go (re)read that RFC.
> 
> Why do you think that the negative consequences explained in that RFC
> would apply in this case? Please think carefully about the consequences
> of possible failure scenarios.

Because what you are proposing to do adds special meaning to certain
labels (and their relative position) and not to others, in exactly the
way that previously people had special interpretations of certain
labels and their positions in the set of labels.  What you're really
trying to do here is extract meaning from the domain name, but you
can't do that reliably.  Previous efforts in that direction have
failed in unexpected ways; and given that you seem to have multiple
ways you want to use this feature, I don't see any reason to believe
you won't have surprising failures too.

The plan is both too narrow and too wide.  First, it will almost
certainly fail to capture 100% of the cases you currently don't want
to succeed.  Second, it will (as we've been arguing in this thread)
not work for new TLDs and other cases.  Your counterargument is that
the behaviouour will then fall back to the current arrangement.  This
means that different domains behave in different ways, and the user
can't rely on any behaviour consistently.

> This isn't just about cookies. For example, we would like to group
> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
> history. Grouping together all sites in ".co.uk" does not provide for an
> optimum user experience.

It seems to me that what you want is metadata about certain domains.
Therefore, what you need is a mechanism for publishing metadata, not a
magical list of domains about which you'll have hard-coded
information. 

I agree with Ed Lewis's remarks that operators often want such lists.
I understand the value of them.  I am arguing that coming up with such
a list and hard-coding it anywhere is a very bad idea, because users
will not get predictable behaviour, particularly in new TLDs and other
new areas of the DNS tree.  That unpredictability of behaviour means
that new services have yet more barriers to surmount before success.
I think that's a bad thing.

> As I noted in an earlier message, this may solve security problems but
> does not solve privacy ones.

That seems to be yet more reason to try to fix the cookies
specification, rather than trying to impute metadata to the DNS
labels.

Obviously, it's your code, and you can do what you want with it.  But
I think this is a very bad idea, and I think it's a shame that it
should be adopted anywhere.

A
-- 
Andrew Sullivan
[e-mail]
[phone] x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


r will then fall back to the current arrangement.  This
means that different domains behave in different ways, and the user
can't rely on any behaviour consistently.

> This isn't just about cookies. For example, we would like to group
> together related sites (www.mybank.co.uk, accounts.mybank.co.uk) in
> history. Grouping together all sites in ".co.uk" does not provide for an
> optimum user experience.

It seems to me that what you want is metadata about certain domains.
Therefore, what you need is a mechanism for publishing metadata, not a
magical list of domains about which you'll have hard-coded
information. 

I agree with Ed Lewis's remarks that operators often want such lists.
I understand the value of them.  I am arguing that coming up with such
a list and hard-coding it anywhere is a very bad idea, because users
will not get predictable behaviour, particularly in new TLDs and other
new areas of the DNS tree.  That unpredictability of behaviour means
that new services have yet more barriers to surmount before success.
I think that's a bad thing.

> As I noted in an earlier message, this may solve security problems but
> does not solve privacy ones.

That seems to be yet more reason to try to fix the cookies
specification, rather than trying to impute metadata to the DNS
labels.

Obviously, it's your code, and you can do what you want with it.  But
I think this is a very bad idea, and I think it's a shame that it
should be adopted anywhere.

A
-- 
Andrew Sullivan
[e-mail]
[phone] x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop