Re: [dane] An AD bit discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 27 February 2014 01:32 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E0A1A07A0 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 17:32:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNw7TXtuJNf9 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 17:31:59 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9814F1A07CD for <dane@ietf.org>; Wed, 26 Feb 2014 17:31:59 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F1D352AAC73; Thu, 27 Feb 2014 01:31:56 +0000 (UTC)
Date: Thu, 27 Feb 2014 01:31:56 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140227013156.GL21390@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <m3txbly9ui.fsf@carbon.jhcloos.org> <alpine.LFD.2.10.1402261930400.3528@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1402261930400.3528@bofh.nohats.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2YO2QicQtq3V4dHbW49Fe9YPO5Q
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 01:32:01 -0000

On Wed, Feb 26, 2014 at 07:41:00PM -0500, Paul Wouters wrote:

> That and I prefer solutions working on obsoleting resolv.conf
> over extending it and I think most cases can already be covered by
> running a DNS server on localhost - with the exception of laptops
> (dnssec-trigger+unbound does not cut it yet for non-techies)

I think obsoleting resolv.conf would be a grave mistake.  More
precisely, control over the security properties of the default list
of recursive resolvers needs to be by default in the hands of the
party that sets up the set of resolvers.  Some applications may
want to tweak this, but out of the box the system administrator
sets the resolver list, and designates them trusted or not.

Applications that delegate validation are rarely well positioned
to know all the gory details, certainly not by default.

So while system configuration may default to fail safe (not lie),
it should be up to the administrator, not the application user or
developer to vouch for the safety of a given configuration.

> So far it seems people are leaning towards A) over B) while everyone
> seems to agree doing DNSSEC on the host itself (server or in-app) is
> still the preferred method.

Modulo some adamant administrators who insist that multiple resolvers
on a physically secured firewalled LAN obviate the need for a local
resolver on each machine, and desperately want to configure trust
in nearby, but not on-host local resolvers.  (See earlier link to
postfix-users list).

For them, I am proposing a damn-the-torpedoes flag in resolv.conf,
global boolean, rather than a one nameserver at a time white-list.

-- 
	Viktor.