Re: [dane] Proposal: AD bit handling in stub-resolvers (ACK/amend/NACK)
Viktor Dukhovni <viktor1dane@dukhovni.org> Sun, 02 March 2014 19:35 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 B22311A0A17 for <dane@ietfa.amsl.com>; Sun, 2 Mar 2014 11:35:05 -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 oQY5CPn9G2iT for <dane@ietfa.amsl.com>; Sun, 2 Mar 2014 11:35:03 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC01A0A1B for <dane@ietf.org>; Sun, 2 Mar 2014 11:35:02 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 104F72AAD0C; Sun, 2 Mar 2014 19:34:58 +0000 (UTC)
Date: Sun, 02 Mar 2014 19:34:58 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140302193458.GP21390@mournblade.imrryr.org>
References: <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com> <20140227212614.GY21390@mournblade.imrryr.org> <alpine.LFD.2.10.1402271729140.1209@bofh.nohats.ca> <20140227230922.GD21390@mournblade.imrryr.org> <53107D34.1030409@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <53107D34.1030409@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/weDfb4xBxxs5icb4n3rdTCezsVQ
Subject: Re: [dane] Proposal: AD bit handling in stub-resolvers (ACK/amend/NACK)
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: Sun, 02 Mar 2014 19:35:06 -0000
On Fri, Feb 28, 2014 at 01:12:36PM +0100, Petr Spacek wrote: [ Not very comments by others addressing this I'm afraid. :-( ] > 1) Add a new boolean to /etc/resolv.conf: > options resolvers-trusted > - If present, this option states that "admin ensured that recursor > is trustworthy and the communication link between recursor and > stub-resolver is secure". > - If present, the AD bit will be passed from recursors to applications as-is. > - If not present, the AD bit sent to a applications will be always 0. > - E.g. the option will be present on a system with locally running Unbound. > - E.g. the option *will not* be present on thin client, compute node > in data centre, a random laptop installed today with default > configuration etc. > > Objections: > - There is a chance that dhcp client copies "options" from old > resolv.conf to new one. In that case simplest variant "options > resolvers-trusted" is insecure if one configured e.g. local trusted > recursor and DHCP client was started after that. If this concern is well founded, (i.e. there is evidence of at least one DHCP client implementation that does this), then indeed the boolean looks questionable, a white-list in a separate file is more robust. If so, and you want to protect naive applications from possibly insecure AD bits on systems that don't employ a local validating resolver, then the AD bit should be suppressed whenever a non-empty subset of the designated resolvers is not white-listed. It would be a mistake to suppress the AD bit selectively for just a subset of the resolvers based on where the answer came from. > 2) Add a function call for run-time check (for library users): > boolean dns_resolvers_trusted(resolver); Where "resolver" means the complete resolver context, i.e. all nameservers trusted, ... There would ideally (in each updated legacy implementation) be a new macro #defined that promises the existence of this function and the possibility of AD bit suppression. This could be a new option macro that enables applications to request bare AD bits without RRSIG records if both features are introduced together in implementations of the library on multiple platforms (i.e. ultimately by the upstream maintainer, rather than a downstream release-specific patch). -- 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