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.