Re: [dane] An AD bit discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 27 February 2014 05:46 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 97BBA1A0409 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 21:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VcTG1PmZHoIY for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 21:46:19 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id DA3D51A01B3 for <dane@ietf.org>; Wed, 26 Feb 2014 21:46:18 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 27FFB2AAD0C; Thu, 27 Feb 2014 05:46:17 +0000 (UTC)
Date: Thu, 27 Feb 2014 05:46:17 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140227054617.GP21390@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> <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iYWzSexXTuYOg_sDJZs7Uqik7Wg
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 05:46:20 -0000

On Thu, Feb 27, 2014 at 12:29:57AM -0500, Paul Wouters wrote:

> >So likely RedHat should proceed with extensions to resolv.conf to
> >express the trust status of the nameserver list, and improvements
> >to libresolv.  The default stub-resolver policy can reasonably be
> >non-trust of all nameservers (typically from DHCP).
> 
> But it is so much better for all server installs to just install a
> validating resolver, point resolv.conf to localhost, and use the DHCP
> obtained DNS servers (or admin configured DNS servers) as forwarders.
>
> Then all applications can trust the AD bit. That's a simply a reality
> that's possible today. Even upgrading machines to this is not that hard.

Yes, up-thread, this my ideal future world too.

> That's why I'm not really in favour of adding legacy to glibc or
> resolv.conf. Especially because there are also so few applications that
> actually do anything with AD bits, plus we are still working on API and
> DNSOP documents on how to improve/secure the DNS transport for talking
> to remote servers.

But what to do when things are not ideal, perhaps because someone
disagrees with our ideal.  How do we let them assert that AD should
be trusted?

One could always trust AD, and leave up to the platform vendor and
system administrator to make it so.  Or one could default to not
trust AD unless resolv.conf says so, and the out-of-the-box
"experience" could be made to include a 127.1 nameserver and the
the right new predicate in /etc/resolv.conf, and glue to have DHCP
tweak forwarders (subject to relevant DHCP configuration) rather
than mess with resolv.conf (much better for reasons beyond DNSSEC
IMHO).

Then it is up to adventurous administrators to mess this up.  Some
will want to bless "remote" resolvers, that we might not want
to bless by default.

As to the question of whether always trusting AD when the recursive
resolvers are not "secure" is OK?  I don't know.  Depends what
applications do with that trust.

For Postfix with "smtp_tls_security_level = dane", the worst thing
that happens is misleading logs that claim more security than you
got.  Postfix also has a "dane-only" security level, for folks who
want stronger security to designated destinations.  In this case
trusting an "insecure" AD bit is not so good.

This said, the Postfix administrator is assumed to be involved in
administration of the platform it runs on (needs root for various
Postfix activities anyway).  So Postfix always trusts AD, and
documents that it is the administrators job to ensure that this is
justified.

Can you take the same view across all future applications?  Or is
more caution warranted?  I'm reluctant to claim that good enough
for Postfix, is good enough for everything...

-- 
	Viktor.