Re: [dane] An AD bit discussion

Paul Wouters <paul@nohats.ca> Thu, 27 February 2014 05:30 UTC

Return-Path: <paul@nohats.ca>
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 79FF61A03D4 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 21:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level:
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547] 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 OE0-EeEr5AlA for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 21:30:02 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA271A02CE for <dane@ietf.org>; Wed, 26 Feb 2014 21:30:01 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5167F80D7E for <dane@ietf.org>; Thu, 27 Feb 2014 00:29:58 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393478998; bh=lglVGsOc1fHnPIW25LN9ab35eJVAa8RxRAZk/hURio8=; h=Date:From:To:Subject:In-Reply-To:References; b=EoTH8a+FpE7HaIdRsi5rT+CRfIDAEa/+iVfJmb+1gIC1KPyOS8OifKtfG1GWFI4Sw j28WKsleUGq6Zrh3vGqsK9KK8MQ7wL16D8a1eDqVrq2Ru6Ldw8HQRYPAvOA7JEF0PL i8zF356BQfh+WD/VOSMeWXCG8ZBmlyveurHPNAjs=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1R5TvWA012572 for <dane@ietf.org>; Thu, 27 Feb 2014 00:29:57 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 27 Feb 2014 00:29:57 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dane@ietf.org
In-Reply-To: <20140227044213.GO21390@mournblade.imrryr.org>
Message-ID: <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca>
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>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-_CgJ4_LqIGIljNEo-hxZcXYf30
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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:30:04 -0000

On Thu, 27 Feb 2014, Viktor Dukhovni wrote:

> It sounds like there is no strong objection to defaulting to no
> trust.

Well, Andrew and I voiced concerns about breaking current common
deployments.

> 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.

The only really difficult case is the roaming device that has to deal
with captive portals. dnssec-trigger+unbound isn't cutting it for the
average user yet. While the glibc change would protect them, without
dnssec-trigger+unbound they are in a complete insecure dns mess anyway,
that I think a bogus AD flag is the least of the trouble.

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.

Paul