Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises

Wes Hardaker <wjhns1@hardakers.net> Tue, 08 April 2014 17:19 UTC

Return-Path: <wjhns1@hardakers.net>
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 5E5391A065D for <dane@ietfa.amsl.com>; Tue, 8 Apr 2014 10:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.172
X-Spam-Level:
X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 EYoRh8oFcygy for <dane@ietfa.amsl.com>; Tue, 8 Apr 2014 10:19:34 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4CE1A065B for <dane@ietf.org>; Tue, 8 Apr 2014 10:19:33 -0700 (PDT)
Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 6D2642206E; Tue, 8 Apr 2014 10:19:33 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Petr Spacek <pspacek@redhat.com>
References: <533EB433.5060204@redhat.com>
Date: Tue, 08 Apr 2014 10:19:33 -0700
In-Reply-To: <533EB433.5060204@redhat.com> (Petr Spacek's message of "Fri, 04 Apr 2014 15:31:31 +0200")
Message-ID: <0lha63rb6i.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/O21dSJ26IRBL_a6zzzWoLMb7pmM
Cc: dane@ietf.org
Subject: Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises
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: Tue, 08 Apr 2014 17:19:36 -0000

Petr Spacek <pspacek@redhat.com>; writes:

> It seems that almost everyone agree that local validating resolver is the
> best option.

I failed to pipe up before, unfortunately.

But, no I don't agree that's the best solution.  The reality is that in
some cases we're making *security decisions* based on the results of a
flag that we're not 100% sure of the source.  Without doing something
like replacing the system library's notion of even looking at
resolv.conf and only looking for 127.0.0.1, then you can't be 100% sure
that the bit you get back is actually trustable.  If the default install
of the OS does the right thing, who's to say it'll stay that way.

As an application author who might want absolute assurance that DNSSEC
was done (because I'm bootstrapping TLS or SSH or ... off of it), then
my ideal situation is to have a local resolver for caching purposes, but
to actually do validation in-application.

-- 
Wes Hardaker
Parsons