Re: [DNSOP] Public Suffix List

[Gervase Markham <[e-mail]>]

Hi Doug,

Doug Barton wrote:
> Coming as it does late in your development cycle (and especially given
> the "enthusiastic" reaction you've received here today) the temptation
> would be for you to dig your heels in and insist on moving forward as
> planned. I urge you to resist that temptation.

Just as a matter of fact, Firefox 3 ships in a week; there is no
possibility of further change in that release.

The fact that I am working on this question now is not to present a
/fait accompli/; I've just been too busy to get to it.

> It may help you at least
> update your current list, and help keep it up to date:
> http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Thank you. I believe something like that was used initially.

> There is also another issue which I haven't seen addressed, although
> admittedly it's a corner case, of TLD NICs that establish a firm policy
> preventing user registration at the top level, but allow themselves to
> operate sites such as www.nic.tld.

That would be fine if (again, using cookies as an example) they set them
for www.nic.tld and not nic.tld. Or, they could add an exception to the
public suffix data they submitted.

> I'm also not sure you quite understand the magnitude of the task you're
> undertaking. It's a matter of fact that any sentence including the
> phrase "all TLDs" is doomed from the start. :)  

If the scheme relied on getting explicit responses from them all, then
yes, it would be doomed. (That's why I think a model of getting the TLDs
to publish the information via DNS or some other mechanism is doomed.)
But in the absence of their input, we can use public sources and
deduction to makFrom [e-mail]  Tue Jun 10 03:11:25 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 2848628C14A;
	Tue, 10 Jun 2008 03:11:25 -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 91A3F3A69EA
	for <[e-mail]>; Tue, 10 Jun 2008 03:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level: 
X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=-0.821, 
	BAYES_00=-2.599]
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 xiFC6zc8GxAC for <[e-mail]>;
	Tue, 10 Jun 2008 03:11:22 -0700 (PDT)
Received: from pih-relay08.plus.net (pih-relay08.plus.net [212.159.14.134])
	by core3.amsl.com (Postfix) with ESMTP id 333493A6A05
	for <[e-mail]>; Tue, 10 Jun 2008 03:11:22 -0700 (PDT)
Received: from [80.229.30.161] (helo=[192.168.1.6])
	by pih-relay08.plus.net with esmtp (Exim) id 1K60pJ-00086l-JD;
	Tue, 10 Jun 2008 11:11:42 +0100
Message-ID: <[e-mail]>
Date: Tue, 10 Jun 2008 11:11:41 +0100
From: Gervase Markham <[e-mail]>
User-Agent: Thunderbird 3.0a1 (X11/2008050714)
MIME-Version: 1.0
To: Doug Barton <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Plusnet-Relay: c13035f860de177e6d0d1d163014e2a5
Cc: [e-mail], [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]

Hi Doug,

Doug Barton wrote:
> Coming as it does late in your development cycle (and especially given
> the "enthusiastic" reaction you've received here today) the temptation
> would be for you to dig your heels in and insist on moving forward as
> planned. I urge you to resist that temptation.

Just as a matter of fact, Firefox 3 ships in a week; there is no
possibility of further change in that release.

The fact that I am working on this question now is not to present a
/fait accompli/; I've just been too busy to get to it.

> It may help you at least
> update your current list, and help keep it up to date:
> http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Thank you. I believe something like that was used initially.

> There is also another issue which I haven't seen addressed, although
> admittedly it's a corner case, of TLD NICs that establish a firm policy
> preventing user registration at the top level, but allow themselves to
> operate sites such as www.nic.tld.

That would be fine if (again, using cookies as an example) they set them
for www.nic.tld and not nic.tld. Or, they could add an exception to the
public suffix data they submitted.

> I'm also not sure you quite understand the magnitude of the task you're
> undertaking. It's a matter of fact that any sentence including the
> phrase "all TLDs" is doomed from the start. :)  

If the scheme relied on getting explicit responses from them all, then
yes, it would be doomed. (That's why I think a model of getting the TLDs
to publish the information via DNS or some other mechanism is doomed.)
But in the absence of their input, we can use public sources and
deduction to me a good guess - or just not give them an entry. There
aren't many ad networks who are setting cookies for .com.je to track
visitors across different Jersey websites.

> Now all THAT said, let's look at what you're planning to do. Leaving
> aside the "nice to have" stuff like history grouping, I'm very
> interested in your concerns about cookie policy. Is the threat you're
> trying to guard against (cookie collusion) something real that you've
> seen in action, or something that you perceive to be a potential threat?
> Please forgive my ignorance on this topic, it's been a while since I've
> had to deal with cookie issues.

It's real. I recently checked my list and had cookies for both .co.uk
and .com.au.

Yngve probably knows more about this than me, though.

> Others have already said that the proper place to deal with this is in
> the cookie spec, so I won't belabor that. Assuming that you are going to
> go forward with some form of this no matter what, I would urge you in
> the strongest possible terms to reconsider your plan to make it a static
> list that is built into the binary. 

We can certainly look at that for the next release.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

> I would further suggest that this should be a user-configurable option.

As a usability person rather than a security person, I think that a good
principle is to only expose preferences which a significant proportion
of your users will be able to understand.

I wouldn't be the person to make the final decision, but I strongly
suspect that UI to turn this off wouldn't make it into the product.

> Finally, I'd like to make a suggestion that I know you will reject, but
> I feel compelled to make it anyway. :)  You could solve this problem
> much more easily by making the default policy to deny cookies, and ask
> the user to choose to accept cookies from domains that they have a trust
> relationship with. 

As you know, I do reject that :-) It's not one user in a thousand who
has the ability to correctly judge whether accepting a particular cookie
is "safe" or not. In one sense, they are all safe. You won't lose any
money by accepting a cookie, and your box can't get rooted. And cookies
don't come with must-be-truthful purpose statements. "OK, I'll accept
the one which says it's required to make the shopping cart one work, and
reject the one that tracks me for advertising purposes."

> I know this was a long post, but I hope you found the information
> valuable. Please let me know if I can be of any further assistance.

Thanks :-)

Gerv
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


ake a good guess - or just not give them an entry. There
aren't many ad networks who are setting cookies for .com.je to track
visitors across different Jersey websites.

> Now all THAT said, let's look at what you're planning to do. Leaving
> aside the "nice to have" stuff like history grouping, I'm very
> interested in your concerns about cookie policy. Is the threat you're
> trying to guard against (cookie collusion) something real that you've
> seen in action, or something that you perceive to be a potential threat?
> Please forgive my ignorance on this topic, it's been a while since I've
> had to deal with cookie issues.

It's real. I recently checked my list and had cookies for both .co.uk
and .com.au.

Yngve probably knows more about this than me, though.

> Others have already said that the proper place to deal with this is in
> the cookie spec, so I won't belabor that. Assuming that you are going to
> go forward with some form of this no matter what, I would urge you in
> the strongest possible terms to reconsider your plan to make it a static
> list that is built into the binary. 

We can certainly look at that for the next release.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=438304 .

> I would further suggest that this should be a user-configurable option.

As a usability person rather than a security person, I think that a good
principle is to only expose preferences which a significant proportion
of your users will be able to understand.

I wouldn't be the person to make the final decision, but I strongly
suspect that UI to turn this off wouldn't make it into the product.

> Finally, I'd like to make a suggestion that I know you will reject, but
> I feel compelled to make it anyway. :)  You could solve this problem
> much more easily by making the default policy to deny cookies, and ask
> the user to choose to accept cookies from domains that they have a trust
> relationship with. 

As you know, I do reject that :-) It's not one user in a thousand who
has the ability to correctly judge whether accepting a particular cookie
is "safe" or not. In one sense, they are all safe. You won't lose any
money by accepting a cookie, and your box can't get rooted. And cookies
don't come with must-be-truthful purpose statements. "OK, I'll accept
the one which says it's required to make the shopping cart one work, and
reject the one that tracks me for advertising purposes."

> I know this was a long post, but I hope you found the information
> valuable. Please let me know if I can be of any further assistance.

Thanks :-)

Gerv
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop