Re: [DNSOP] Public Suffix List

Gervase Markham <gerv@mozilla.org> Mon, 09 June 2008 11:50 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 B7C2D3A6A62; Mon, 9 Jun 2008 04:50:30 -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 D08AE3A6C4C for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 04:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.201
X-Spam-Level:
X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_00=-2.599, SARE_RMML_Stock10=0.13]
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 mLJ6RabqTFrN for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 04:50:27 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [91.135.15.56]) by core3.amsl.com (Postfix) with ESMTP id 666883A6A62 for <dnsop@ietf.org>; Mon, 9 Jun 2008 04:50:27 -0700 (PDT)
Received: from grmarkham.plus.com ([80.229.30.161] helo=[192.168.1.6]) by haggis.mythic-beasts.com with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <gerv@mozilla.org>) id 1K5fpV-0007kg-Ok; Mon, 09 Jun 2008 12:46:50 +0100
Message-ID: <484D1883.4060002@mozilla.org>
Date: Mon, 09 Jun 2008 12:48:19 +0100
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Thunderbird 3.0a1 (X11/2008050714)
MIME-Version: 1.0
To: Jeroen Massar <jeroen@unfix.org>
References: <484CFF47.1050106@mozilla.org> <484D1533.4060300@spaghetti.zurich.ibm.com>
In-Reply-To: <484D1533.4060300@spaghetti.zurich.ibm.com>
X-BlackCat-Spam-Score: -12
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

Jeroen Massar wrote:
> [Why not go DNSSEC first instead of solving a problem which is not a
> real problem? See below... ]

I'm not sure that DNSSEC solves the problem we are trying to solve, but
would be happy to be enlightened.

> You are *hard-coding* such a list into a 'product'? You do realize that
> a lot of people simply don't update their software I hope. Unfortunately
> for the OS's that need updating the most those people don't tend to update.

Fortunately, Firefox has an extremely good and fast update and uptake
rate. This is partly because we don't give users a choice about taking
non-major-version updates.

> You might want to consider using at least an RBL-style way for this.
> Though, you will of course hit off on all the privacy folks when you are
> doing another DNS query for www.spooks.gov.rbl.mozilla.org every hit and
> collecting all that information. 

Indeed. This is why this type of scheme is not a runner.

Yngve Pettersen of Opera has suggested something like this in his
internet draft; however, my view is that getting comprehensive buy-in
would take quite a lot more time and effort than this method.
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt

> How can non-TLD's get into this list!? 

Just by asking; I already got an email from CentralNIC.

> If you are going to push this 'technology', you might want to consider
> doing an SPF-alike test, thus getting that information from the provider
> of the label, or better: fix the cookie standards.

Yngve has several suggestions about how this may be fixed longer-term:
http://my.opera.com/yngve/blog/2008/02/25/refreshed-internet-drafts-0208

However, this is what we have that works here and now.

> And another much better step which I think the rest of this group (as of
> course this message is just and only my personal opinion and not that of
> the group in anyway... that is how the IETF works afterall ;) would
> actually also like is the use of DNSSEC. Which actually tells you that
> the domain you are looking at is really the domain you are requesting
> records from. 

That's a different problem, though. Even if DNSSEC was deployed, it
wouldn't teach browsers about the structure of the DNS.

Gerv
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop