Re: [DNSOP] Public Suffix List

Gervase Markham <gerv@mozilla.org> Thu, 12 June 2008 11:25 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 0907228C0E4; Thu, 12 Jun 2008 04:25:32 -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 B0B1E28C0E4 for <dnsop@core3.amsl.com>; Thu, 12 Jun 2008 04:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.892
X-Spam-Level:
X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=-1.533, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
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 QhRdkOCGK3cM for <dnsop@core3.amsl.com>; Thu, 12 Jun 2008 04:25:29 -0700 (PDT)
Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by core3.amsl.com (Postfix) with ESMTP id BE21B3A6A1C for <dnsop@ietf.org>; Thu, 12 Jun 2008 04:25:29 -0700 (PDT)
Received: from [80.229.30.161] (helo=[192.168.1.6]) by ptb-relay01.plus.net with esmtp (Exim) id 1K6kwD-0002iN-SM; Thu, 12 Jun 2008 12:25:54 +0100
Message-ID: <485107C0.3010106@mozilla.org>
Date: Thu, 12 Jun 2008 12:25:52 +0100
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Thunderbird 3.0a1 (X11/2008050714)
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <484CFF47.1050106@mozilla.org> <20080609142926.GC83012@commandprompt.com> <484D4191.104@mozilla.org> <20080609154002.GA93967@commandprompt.com> <484D5206.3000806@mozilla.org> <20080609214215.GF10260@commandprompt.com> <1B8CFAA1-E30A-4461-8B4E-BFF6E3A3A39C@nominum.com> <20080610080209.GA1365@nic.fr> <484E5318.7040502@mozilla.org> <sd8wxdz2it.fsf@wes.hardakers.net> <484FB672.1080703@mozilla.org> <B9478927-1EBC-4363-914E-24839604481A@nominum.com>
In-Reply-To: <B9478927-1EBC-4363-914E-24839604481A@nominum.com>
X-Plusnet-Relay: a55433582059ecc2408eac727f4c541c
Cc: dnsop@ietf.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

Ted Lemon wrote:
> On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote:
>> It's not true that we won't work on any other solution. This is what we
>> have now, and there have been no alternative proposals which (to my
>> mind) look like producing anything workable in the short term.
> 
> Putting the list in the DNS instead of in the browser isn't workable?  

Perhaps, but not in the short term.

> Serious question.   I think several proposals have been advanced here
> that /could/ work.   Mine has the virtue of being completely under your
> control. 

It does. I admit I hadn't thought of something like that, and would be
interested to see what Yngve makes of it. He's done the most work on
protocols for transmitting this information; see:
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt

Is there a particular reason that DNS is a better mechanism than HTTP,
in your view? Or is that an implementation detail?

> I haven't heard you responding that either of these solutions wouldn't
> work, so I'm assuming they would, but perhaps I'm wrong.   It also may
> be the case that for reasons of practicality you need to start with a
> list embedded in the browser; as long as you have a plan to make the
> transition From dnsop-bounces@ietf.org  Thu Jun 12 04:25:32 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 0907228C0E4;
	Thu, 12 Jun 2008 04:25:32 -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 B0B1E28C0E4
	for <dnsop@core3.amsl.com>; Thu, 12 Jun 2008 04:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.892
X-Spam-Level: 
X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5
	tests=[AWL=-1.533, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
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 QhRdkOCGK3cM for <dnsop@core3.amsl.com>;
	Thu, 12 Jun 2008 04:25:29 -0700 (PDT)
Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212])
	by core3.amsl.com (Postfix) with ESMTP id BE21B3A6A1C
	for <dnsop@ietf.org>; Thu, 12 Jun 2008 04:25:29 -0700 (PDT)
Received: from [80.229.30.161] (helo=[192.168.1.6])
	by ptb-relay01.plus.net with esmtp (Exim) id 1K6kwD-0002iN-SM;
	Thu, 12 Jun 2008 12:25:54 +0100
Message-ID: <485107C0.3010106@mozilla.org>
Date: Thu, 12 Jun 2008 12:25:52 +0100
From: Gervase Markham <gerv@mozilla.org>
User-Agent: Thunderbird 3.0a1 (X11/2008050714)
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <484CFF47.1050106@mozilla.org>
	<20080609142926.GC83012@commandprompt.com>
	<484D4191.104@mozilla.org>
	<20080609154002.GA93967@commandprompt.com>	<484D5206.3000806@mozilla.org>
	<20080609214215.GF10260@commandprompt.com>
	<1B8CFAA1-E30A-4461-8B4E-BFF6E3A3A39C@nominum.com>
	<20080610080209.GA1365@nic.fr> <484E5318.7040502@mozilla.org>
	<sd8wxdz2it.fsf@wes.hardakers.net> <484FB672.1080703@mozilla.org>
	<B9478927-1EBC-4363-914E-24839604481A@nominum.com>
In-Reply-To: <B9478927-1EBC-4363-914E-24839604481A@nominum.com>
X-Plusnet-Relay: a55433582059ecc2408eac727f4c541c
Cc: dnsop@ietf.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

Ted Lemon wrote:
> On Jun 11, 2008, at 6:26 AM, Gervase Markham wrote:
>> It's not true that we won't work on any other solution. This is what we
>> have now, and there have been no alternative proposals which (to my
>> mind) look like producing anything workable in the short term.
> 
> Putting the list in the DNS instead of in the browser isn't workable?  

Perhaps, but not in the short term.

> Serious question.   I think several proposals have been advanced here
> that /could/ work.   Mine has the virtue of being completely under your
> control. 

It does. I admit I hadn't thought of something like that, and would be
interested to see what Yngve makes of it. He's done the most work on
protocols for transmitting this information; see:
http://www.ietf.org/internet-drafts/draft-pettersen-subtld-structure-03.txt

Is there a particular reason that DNS is a better mechanism than HTTP,
in your view? Or is that an implementation detail?

> I haven't heard you responding that either of these solutions wouldn't
> work, so I'm assuming they would, but perhaps I'm wrong.   It also may
> be the case that for reasons of practicality you need to start with a
> list embedded in the browser; as long as you have a plan to make the
> transition toto a list that's maintained more dynamically, and as long as
> you actually execute that plan, it seems to me that this is harmless.

The second question is one of resources and client complexity. I am
meeting resistance to the idea of having the existing list regularly
dynamically downloaded, which would be the simplest method of providing
more frequent updates than the six-to-eight week Firefox security
releases. An assemble-and-cache-the-data-from-DNS scheme would be an
order of magnitude more complex.

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


 a list that's maintained more dynamically, and as long as
> you actually execute that plan, it seems to me that this is harmless.

The second question is one of resources and client complexity. I am
meeting resistance to the idea of having the existing list regularly
dynamically downloaded, which would be the simplest method of providing
more frequent updates than the six-to-eight week Firefox security
releases. An assemble-and-cache-the-data-from-DNS scheme would be an
order of magnitude more complex.

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