Re: [DNSOP] Public Suffix List

Ted Lemon <Ted.Lemon@nominum.com> Thu, 12 June 2008 14:06 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 6967E28C113; Thu, 12 Jun 2008 07:06:35 -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 BB1DD3A6800 for <dnsop@core3.amsl.com>; Thu, 12 Jun 2008 07:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.496
X-Spam-Level:
X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bM-6xfnUQCcm for <dnsop@core3.amsl.com>; Thu, 12 Jun 2008 07:06:32 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 7AA123A68D9 for <dnsop@ietf.org>; Thu, 12 Jun 2008 07:05:45 -0700 (PDT)
Received: from source ([64.89.228.228]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP; Thu, 12 Jun 2008 07:05:55 PDT
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "webmail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-ng.nominum.com (Postfix) with ESMTP id 07ADC56845; Thu, 12 Jun 2008 07:05:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.1.103] (67.9.133.211) by webmail.nominum.com (64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 12 Jun 2008 07:05:54 -0700
Message-ID: <74930956-90C7-405C-90C8-B7AD73330011@nominum.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
To: "yngve@opera.com" <yngve@opera.com>
In-Reply-To: <op.ucm0x2q8vqd7e2@killashandra.oslo.opera.com>
MIME-Version: 1.0 (Apple Message framework v924)
Date: Thu, 12 Jun 2008 09:05:51 -0500
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> <485107C0.3010106@mozilla.org> <37E2260C-9BC3-402D-8155-C8151F91E5B5@ucd.ie> <op.ucm0x2q8vqd7e2@killashandra.oslo.opera.com>
X-Mailer: Apple Mail (2.924)
Cc: IETF DNSOP WG <dnsop@ietf.org>, Gervase Markham <gerv@mozilla.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

On Jun 12, 2008, at 8:26 AM, Yngve Nysaeter Pettersen wrote:
>

>  - Behind (very) closed firewalls, where all access go through a  
> HTTP-only
> proxy. No DNS for external addresses is available. For that matter,  
> when
> going through a proxy you have no way of knowing if the DNS  
> available to
> you know anything about the address space you are accessing through  
> the
> proxy.
>
>  - On a number of systems, in particular phone devices, the  
> application
> does not even have access to DNS to do a name lookup, it must  
> specify the
> hostname, and try From dnsop-bounces@ietf.org  Thu Jun 12 07:06:35 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 6967E28C113;
	Thu, 12 Jun 2008 07:06:35 -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 BB1DD3A6800
	for <dnsop@core3.amsl.com>om>; Thu, 12 Jun 2008 07:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.496
X-Spam-Level: 
X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bM-6xfnUQCcm for <dnsop@core3.amsl.com>om>;
	Thu, 12 Jun 2008 07:06:32 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171])
	by core3.amsl.com (Postfix) with ESMTP id 7AA123A68D9
	for <dnsop@ietf.org>rg>; Thu, 12 Jun 2008 07:05:45 -0700 (PDT)
Received: from source ([64.89.228.228]) (using TLSv1) by
	exprod7ob109.postini.com ([64.18.6.12]) with SMTP; 
	Thu, 12 Jun 2008 07:05:55 PDT
Received: from webmail.nominum.com (webmail.nominum.com [64.89.228.50])
	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
	(Client CN "webmail.nominum.com",
	Issuer "Go Daddy Secure Certification Authority" (verified OK))
	by shell-ng.nominum.com (Postfix) with ESMTP id 07ADC56845;
	Thu, 12 Jun 2008 07:05:55 -0700 (PDT)
	(envelope-from Ted.Lemon@nominum.com)
Received: from [10.0.1.103] (67.9.133.211) by webmail.nominum.com
	(64.89.228.50) with Microsoft SMTP Server (TLS) id 8.1.240.5;
	Thu, 12 Jun 2008 07:05:54 -0700
Message-ID: <74930956-90C7-405C-90C8-B7AD73330011@nominum.com>
From: Ted Lemon <Ted.Lemon@nominum.com>
To: "yngve@opera.com" <yngve@opera.com>
In-Reply-To: <op.ucm0x2q8vqd7e2@killashandra.oslo.opera.com>
MIME-Version: 1.0 (Apple Message framework v924)
Date: Thu, 12 Jun 2008 09:05:51 -0500
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>
	<485107C0.3010106@mozilla.org>	<37E2260C-9BC3-402D-8155-C8151F91E5B5@ucd.ie>
	<op.ucm0x2q8vqd7e2@killashandra.oslo.opera.com>
X-Mailer: Apple Mail (2.924)
Cc: IETF DNSOP WG <dnsop@ietf.org>rg>, Gervase Markham <gerv@mozilla.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

On Jun 12, 2008, at 8:26 AM, Yngve Nysaeter Pettersen wrote:
>

>  - Behind (very) closed firewalls, where all access go through a  
> HTTP-only
> proxy. No DNS for external addresses is available. For that matter,  
> when
> going through a proxy you have no way of knowing if the DNS  
> available to
> you know anything about the address space you are accessing through  
> the
> proxy.
>
>  - On a number of systems, in particular phone devices, the  
> application
> does not even have access to DNS to do a name lookup, it must  
> specify the
> hostname, and try toto connect.

Ouch.   That's really painful.   For those devices I think you'd have  
to fall back to tunneling the DNS request over an HTTP channel.

> Additionally, a DNS-only solution would mean implementing a DNS client
> inside the application, since AFAICT the platform socket APIs  
> usually do
> not provide the necessary functionality needed to access non-IPaddress
> data.

I think Mozilla already has its own DNS resolver.   It might need to  
be enhanced to support DNSSEC if it doesn't already.   The ISC has a  
resolver you can use that's under the BSD license.   The resolver  
isn't very big.   So I think this is a non-issue.

I can see why you're resisting doing it this way.   It does make for  
more work.   But what I'd be worried about if you *don't* do it this  
way is that you're going to wind up making a mistake in your static  
list that's not going to get corrected in time, and somebody's going  
to run into an issue that gets you dinged for another stupid security  
complaint.   And even though it was the fault of the site that allowed  
the bogus cookie, you're still going to get all the bad publicity.

With a just-in-time lazy lookup scheme, you can be much more responsive.

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


 connect.

Ouch.   That's really painful.   For those devices I think you'd have  
to fall back to tunneling the DNS request over an HTTP channel.

> Additionally, a DNS-only solution would mean implementing a DNS client
> inside the application, since AFAICT the platform socket APIs  
> usually do
> not provide the necessary functionality needed to access non-IPaddress
> data.

I think Mozilla already has its own DNS resolver.   It might need to  
be enhanced to support DNSSEC if it doesn't already.   The ISC has a  
resolver you can use that's under the BSD license.   The resolver  
isn't very big.   So I think this is a non-issue.

I can see why you're resisting doing it this way.   It does make for  
more work.   But what I'd be worried about if you *don't* do it this  
way is that you're going to wind up making a mistake in your static  
list that's not going to get corrected in time, and somebody's going  
to run into an issue that gets you dinged for another stupid security  
complaint.   And even though it was the fault of the site that allowed  
the bogus cookie, you're still going to get all the bad publicity.

With a just-in-time lazy lookup scheme, you can be much more responsive.

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