Re: [websec] Use of DNS/DNSSEC for strict security

"Yngve N. Pettersen" <yngve@opera.com> Tue, 12 October 2010 19:02 UTC

Return-Path: <yngve@opera.com>
X-Original-To: websec@core3.amsl.com
Delivered-To: websec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04BBC3A6A44 for <websec@core3.amsl.com>; Tue, 12 Oct 2010 12:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 z52xQ-QJL-N9 for <websec@core3.amsl.com>; Tue, 12 Oct 2010 12:02:49 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 7A6073A6A38 for <websec@ietf.org>; Tue, 12 Oct 2010 12:02:49 -0700 (PDT)
Received: from lessa-ii.oslo.os (173-10-121-193-BusName-Washington.hfc.comcastbusiness.net [173.10.121.193]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9CJ3vr5006533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Oct 2010 19:04:01 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: websec <websec@ietf.org>, Phillip Hallam-Baker <hallam@gmail.com>
References: <AANLkTikt4=dVbTf_tj8HHc=whpU0S+Pv40LrBQHbK6yz@mail.gmail.com>
Date: Tue, 12 Oct 2010 21:04:04 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@opera.com>
Organization: Opera Software ASA
Message-ID: <op.vkg8k2eukvaitl@lessa-ii.oslo.os>
In-Reply-To: <AANLkTikt4=dVbTf_tj8HHc=whpU0S+Pv40LrBQHbK6yz@mail.gmail.com>
User-Agent: Opera Mail/10.62 (Win32)
X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81
Subject: Re: [websec] Use of DNS/DNSSEC for strict security
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HTTP Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2010 19:02:51 -0000

On Tue, 12 Oct 2010 20:21:05 +0200, Phillip Hallam-Baker  
<hallam@gmail.com> wrote:

> I am not arguing against doing the HTTP header approach. Given the  
> attacks
> we are facing I do not want strict security to be dependent on successful
> DNSSEC deployment. But I would like to see a HTTP header approach that is
> consistent with eventual deployment of a DNSSEC based approach.


I am not against the suggestion, and I recognize that there are problems  
with the bootstrapping process, but:

Any such system would need to define an API akin to that specified by RFC  
3493 (the APIs used to do namelookups for IPv6) that must be implemented  
in every Operating System.

Anything else would require the client to implement full DNS(SEC) support,  
discover the network configuration, or go direct to deduced nameservers,  
and as a result cause at least potential interoperability problems and  
inefficiencies due to less use of DNS caching.


Additionally, there is the problem with network configurations that does  
not allow any external network traffic except through an HTTP proxy. IOW:  
General DNS is not always available. A workaround for that might be a  
HTTP(s?) based webservice interface to DNS(SEC).



-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************