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.
- Re: [dane] An AD bit discussion Paul Wouters
- [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Ondřej Surý
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Olafur Gudmundsson
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Wiley, Glen
- Re: [dane] An AD bit discussion James Cloos
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andreas Schulze
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion (correction) Petr Spacek
- Re: [dane] An AD bit discussion (+concerns from g… Petr Spacek
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion (+concerns from g… Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- [dane] Proposal: AD bit handling in stub-resolver… Petr Spacek
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] Proposal: AD bit handling in stub-reso… Viktor Dukhovni
- Re: [dane] An AD bit discussion Florian Weimer
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek