Re: [DNSOP] Public Suffix List
Doug Barton <dougb@dougbarton.us> Mon, 09 June 2008 22:02 UTC
Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F92C3A6A55; Mon, 9 Jun 2008 15:02:24 -0700 (PDT)
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F0E3A6AD5 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 15:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ASKUEknNhHLJ for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 15:02:21 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by core3.amsl.com (Postfix) with ESMTP id CEE1A3A6A49 for <dnsop@ietf.org>; Mon, 9 Jun 2008 15:02:20 -0700 (PDT)
Received: (qmail 4674 invoked by uid 399); 9 Jun 2008 22:02:40 -0000
Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Jun 2008 22:02:40 -0000
X-Originating-IP: 127.0.0.1
X-Sender: dougb@dougbarton.us
Message-ID: <484DA87B.1000903@dougbarton.us>
Date: Mon, 09 Jun 2008 15:02:35 -0700
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Gervase Markham <gerv@mozilla.org>
References: <484CFF47.1050106@mozilla.org>
In-Reply-To: <484CFF47.1050106@mozilla.org>
X-Enigmail-Version: 0.95.6
Cc: dnsop@ietf.org, ietf-http-wg@w3.org
Subject: Re: [DNSOP] Public Suffix List
X-BeenThere: dnsop@ietf.org
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:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Yngve and Gerv, As you have no doubt concluded by now, you've touched a nerve. :) It doesn't seem to me that you have, but I hope that you will not interpret the strong reaction you've received as an attack. It's simply the case that what you're planning to do sounds (and in some ways is) painfully similar to other ideas that haven't worked out so well in the past, and you're dealing with a lot of people here who do not want to see history repeat itself. 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. I apologize if this sounds like self-aggrandizement, but I think I'm pretty well qualified to comment on your plan: 1. I dealt with almost all of the TLDs in my role as dns administrator for Yahoo!, and maintained a similar list of valid registration points there for several years. 2. My first job at Yahoo! was programming CGI apps, including domain name registration and authentication modules, both of which used cookies. 3. I used to manage the IANA, so I have a lot of experience working with the TLD operator community on various topics, including policy matters and updates to their records. All that said, I think that there is some merit in what you're trying to do. Such a list has utility (to the extent that it is kept up to date) and it would be nice to have that information collected in one location. In an ideal world that location would be ICANN (specifically IANA) but for a variety of reasons, some of which David already mentioned, that probably isn't possible at this time. I would like to refer you to one similar (although limited) resource that IS managed by IANA, the list of valid TLDs that we set up while I was there. 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 When I was maintaining the list of valid registration points (IIUC what you're referring to as "public suffixes") I was dealing with a limited number of TLDs, and received updates to the list roughly every week and a half or so. A lot of these updates were additions, which IIUC your software will handle as a "soft fail" if they are not present in the list already. More troublesome for the topic at hand is that roughly twice a month I received an update about a registry that had changed its policy, usually making it more permissive (i.e., adding additional registration points). Indeed, that has been the trend amongst virtually all of the TLDs since I started caring about this topic in 1998. 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. 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. :) You're dealing with a wide variety of business models (often with competing interests), policies, levels of technical ability, levels of operating capacity, and dare I say it, personalities. You will never get full cooperation, and as you can see by Stephane's response you will definitely irritate at least some of the TLD operators with this change. You might want to rethink socializing this concept before you launch. There is also the issue raised here by others already that new TLD introduction (and the corresponding churn on registration policies that will come as each new TLD matures) will soon become much, much more common. This will (IMO) be especially true of the new IDN TLDs. If this cookie security issue in particular is valuable, you do your users a disservice by treating new TLDs differently from old ones. One of the key features of the DNS is that it is supposed to work the same for everyone. What you're proposing places artificial, and immutable categorization into the name space that it is not only not designed, but I would say not intended to have. 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. 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. Even assuming perfect uptake (which we know won't happen) your update frequency cannot be high enough to make this useful without annoying your users. And no matter how many updates you make available, you will always have a substantial number (I would expect a majority, but I could be wrong) of your users "stuck" at an older version. For these reasons, and the others that have been mentioned already, I encourage you to make the list dynamic so that updates will happen for the user automatically in the background. It should be fairly simple to do. Someone else already mentioned the idea of piggybacking the check for this list with the browser update check, which would substantially reduce the bandwidth needed. As long as the frequency is no more than one week, that should suffice. I would also suggest that if the user gets a hard fail for setting a cookie that should trigger an update check, and reset the timer. How you implement "dynamic" is an open question, but there are at least two obvious answers in your complete control, https and dns(sec). I would further suggest that this should be a user-configurable option. Certainly it should be under some sort of "advanced" category, but I'm concerned by the trend of less and less things being easily configured by the user. That's not why I choose to use mozilla products. It's always difficult balancing the user experience between advanced users and those who want it to "just work." I hope you can find a middle way. 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. I have been using the CookieSafe extension for a long time now (recently switched to CookieSafe Lite by the same author) and it works great for me. If that functionality were included in the base and enabled by default, it'd be a whole new world. https://addons.mozilla.org/en-US/firefox/search?q=cookiesafe&cat=1%2C12 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. Regards, Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEAREDAAYFAkhNqHsACgkQyIakK9Wy8Pt3XQCgxzi1Pvv91eTyfPTEUBT7Zi95 ZMAAoLa3wDtmdb/nvLybhsjhCd0aeNF/ =WdS0 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
- [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Antoin Verschuren
- Re: [DNSOP] Public Suffix List bert hubert
- Re: [DNSOP] Public Suffix List Antoin Verschuren
- Re: [DNSOP] Public Suffix List Elmar K. Bins
- Re: [DNSOP] Public Suffix List Edward Lewis
- Re: [DNSOP] Public Suffix List bert hubert
- Re: [DNSOP] Public Suffix List bert hubert
- Re: [DNSOP] Public Suffix List Patrik Fältström
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Patrik Fältström
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Wes Hardaker
- Re: [DNSOP] Public Suffix List Edward Lewis
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Andrew Sullivan
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Andrew Sullivan
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Brian Dickson
- Re: [DNSOP] Public Suffix List Peter Koch
- Re: [DNSOP] Public Suffix List Eric Brunner-Williams
- Re: [DNSOP] Public Suffix List Eric Brunner-Williams
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Kim Davies
- Re: [DNSOP] Public Suffix List Paul Hoffman
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Joe Abley
- Re: [DNSOP] Public Suffix List Phil Regnauld
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Andrew Sullivan
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Doug Barton
- Re: [DNSOP] Public Suffix List Paul Hoffman
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Adrien de Croy
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Wes Hardaker
- Re: [DNSOP] Public Suffix List Dean Anderson
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Paul Hoffman
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Doug Barton
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Mark Foster
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Mark Foster
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jelte Jansen
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List Henrik Nordstrom
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Jeroen Massar
- Re: [DNSOP] Public Suffix List Joe Baptista
- Re: [DNSOP] Public Suffix List - Please move disc… Mark Nottingham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… Edward Lewis
- Re: [DNSOP] Public Suffix List Jamie Lokier
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… bmanning
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… Joe Baptista
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List - Please move disc… Ted Lemon
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List Brian Dickson
- Re: [DNSOP] Public Suffix List - Please move disc… Joe Baptista
- Re: [DNSOP] Public Suffix List David Conrad
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Florian Weimer
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List SM
- Re: [DNSOP] Public Suffix List Dean Anderson
- Re: [DNSOP] Public Suffix List - Please move disc… Antoin Verschuren
- Re: [DNSOP] Public Suffix List - Please move disc… Stephane Bortzmeyer
- Re: [DNSOP] Public Suffix List - Please move disc… Antoin Verschuren
- Re: [DNSOP] Public Suffix List - Please move disc… Gervase Markham
- Re: [DNSOP] Public Suffix List Gervase Markham
- Re: [DNSOP] Public Suffix List Niall O'Reilly
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Ted Lemon
- Re: [DNSOP] Public Suffix List Yngve Nysaeter Pettersen
- Re: [DNSOP] Public Suffix List Brian Dickson