Re: [DNSOP] Public Suffix List

Jeroen Massar <jeroen@unfix.org> Mon, 09 June 2008 11:33 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 1836E28C126; Mon, 9 Jun 2008 04:33:45 -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 9F7B428C103 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 04:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 P9l8+PaAgq49 for <dnsop@core3.amsl.com>; Mon, 9 Jun 2008 04:33:42 -0700 (PDT)
Received: from abaddon.unfix.org (abaddon.unfix.org [IPv6:2001:41e0:ff00:0:216:3eff:fe00:4]) by core3.amsl.com (Postfix) with ESMTP id D485928C0F9 for <dnsop@ietf.org>; Mon, 9 Jun 2008 04:33:41 -0700 (PDT)
Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da] (spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by abaddon.unfix.org (Postfix) with ESMTPSA id 4E406392399; Mon, 9 Jun 2008 13:33:57 +0200 (CEST)
Message-ID: <484D1533.4060300@spaghetti.zurich.ibm.com>
Date: Mon, 09 Jun 2008 13:34:11 +0200
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666
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
OpenPGP: id=333E7C23
X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on abaddon.unfix.org
X-Virus-Status: Clean
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: multipart/mixed; boundary="===============1700265649=="
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

[Why not go DNSSEC first instead of solving a problem which is not a 
real problem? See below... ]

Gervase Markham wrote:
[..]
 > The technology in question, including a version of the list, is about
 > to ship in Firefox 3, but we'd like to verify and improve the quality
 > of the underlying data.

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.

Hard-coding can be fine for most TLD's which are quite static in setup 
and might not ever change, but what about everybody else?

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 whenFrom dnsop-bounces@ietf.org  Mon Jun  9 04:33:45 2008
Return-Path: <dnsop-bounces@ietf.org>
X-Original-To: dnsop-archive@lists.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 1836E28C126;
	Mon,  9 Jun 2008 04:33:45 -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 9F7B428C103
	for <dnsop@core3.amsl.com>; Mon,  9 Jun 2008 04:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
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 P9l8+PaAgq49 for <dnsop@core3.amsl.com>;
	Mon,  9 Jun 2008 04:33:42 -0700 (PDT)
Received: from abaddon.unfix.org (abaddon.unfix.org
	[IPv6:2001:41e0:ff00:0:216:3eff:fe00:4])
	by core3.amsl.com (Postfix) with ESMTP id D485928C0F9
	for <dnsop@ietf.org>; Mon,  9 Jun 2008 04:33:41 -0700 (PDT)
Received: from [IPv6:2001:620:20:1000:216:d3ff:fe25:14da]
	(spaghetti.zurich.ibm.com [IPv6:2001:620:20:1000:216:d3ff:fe25:14da])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested) (Authenticated sender: jeroen)
	by abaddon.unfix.org (Postfix) with ESMTPSA id 4E406392399;
	Mon,  9 Jun 2008 13:33:57 +0200 (CEST)
Message-ID: <484D1533.4060300@spaghetti.zurich.ibm.com>
Date: Mon, 09 Jun 2008 13:34:11 +0200
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14
	Mnenhy/0.7.5.666
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
OpenPGP: id33E7C23
X-Virus-Scanned: ClamAV version 0.93,
	clamav-milter version 0.93 on abaddon.unfix.org
X-Virus-Status: Clean
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: multipart/mixed; boundary="=======00265649="
Sender: dnsop-bounces@ietf.org
Errors-To: dnsop-bounces@ietf.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
[Why not go DNSSEC first instead of solving a problem which is not a 
real problem? See below... ]

Gervase Markham wrote:
[..]
 > The technology in question, including a version of the list, is about
 > to ship in Firefox 3, but we'd like to verify and improve the quality
 > of the underlying data.

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.

Hard-coding can be fine for most TLD's which are quite static in setup 
and might not ever change, but what about everybody else?

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 y you are 
doing another DNS query for www.spooks.gov.rbl.mozilla.org every hit and 
collecting all that information. Guess that quite a few companies would 
also become quite jealous of those kind of data collecting techniques, 
just like the current "domain protection" stuff that exists in FF which 
allows collection of that kind of information.

[..]
> We are maintaining a list of all "Public Suffixes". A Public Suffix is a
> domain label under which internet users can directly register domains.
> Examples of Public Suffixes are ".net", ".org.uk" and ".pvt.k12.ca.us".

How can non-TLD's get into this list!? Eg www.google.com is quite 
different from evilsite.google.com which is not under the same 
administrative control as the first. Of course it is not the smartest 
way of setting up a trusted site, but it happens a lot, eg to save on 
costs for SSL certificates one customer gets cust1.ssl.example.org and 
the next cust2.ssl.example.org, they are not the same and might both be 
evil. Not even going into warring departments or even rival countries 
being put under the same DNS label (tw.example.org, cn.example.org ;)

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.

The latter could be achieved, amongst others, by having the cookie 
include only exactly the domains/sites for which that cookie is valid.
And of course not allowing wild-card cookies anymore...

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. Who cares about the cookie domain if bank.com is actually 
evilbank.com. (of course again not even going to the b4nk.com example 
and all others).

Lastly; DNS does not establish that you are talking to the domain you 
think you are talking to, it only makes it look like that.

Greets,
  Jeroen

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