Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 21 March 2017 00:48 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB2F1294D0 for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 17:48:30 -0700 (PDT)
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 autolearn_force=no
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 hzkgWrOhfaBz for <dnsop@ietfa.amsl.com>; Mon, 20 Mar 2017 17:48:28 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26D0126BF7 for <dnsop@ietf.org>; Mon, 20 Mar 2017 17:48:28 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8E1DC7A3309; Tue, 21 Mar 2017 00:48:27 +0000 (UTC)
Date: Tue, 21 Mar 2017 00:48:27 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop <dnsop@ietf.org>
Message-ID: <20170321004827.GA25754@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <BE2A3845-D8AA-433A-9F00-1056ECFD335F@fugue.com> <21C8F856-FE3F-42A6-A8ED-888D0797B68B@vigilsec.com> <60C85486-E351-4C42-ADEB-FCBB56F4EA27@fugue.com> <AB11455F-7E43-4CB3-9F13-DB6A09F739EB@vigilsec.com> <CEC8CC6A-861A-471C-B7FA-4BB05C81CCF0@gmail.com> <F7AA49EF-2708-4948-9B60-6660DA6BC841@vigilsec.com> <734EC35A-4B1F-43EB-BE37-C34CA46BDA26@fugue.com> <203D2BEA-1008-48A0-9CE2-1FD621C6117F@shinkuro.com> <3134EDC2-FB00-41EA-8338-6E6B196137F1@fugue.com> <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <572B4EBA-F37F-4E92-A252-44BAF5DE7FF5@shinkuro.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZDsIA4gbnm5mNE93o31fy96iVyg>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 00:48:30 -0000

On Mon, Mar 20, 2017 at 05:44:27PM -0400, Steve Crocker wrote:

> > You should bear in mind that homenet is assuming the Internet of maybe
> > five years from now, more so than the Internet of now, although obviously
> > we'd like to get done sooner than that.   So you should assume that stub
> > resolvers never, ever do anything so foolish as to trust a recursive
> > resolver to validate for them.  And, indeed, as you say, any resolver that
> > doesn�t use the host's resolver configuration to figure out which resolver
> > to talk to isn't going to be able to resolve queries in the .homenet
> > domain.
> 
> It is hard to predict how things are going to evolve.  The idea that all
> stub resolvers will be validating everything they get is a nice goal, and
> I certainly wouldn�t want to choose a path that precludes that, but I
> think it�s prudent to also design for the present.  Assume we�ll be
> somewhere along the path between here and there.

>From a system and software engineering perspective I continue to
be surprised at suggestions that stub resolvers are the *right*
place to do DNSSEC validation.  As much as much as this may maximize
security, it is such poor separation of duties that I don't see it
being at all attractive in practice.

FWIW, when adding DANE support to Postfix, it was plainly obvious
that DNSSEC validation belongs in the local resolver, and Postfix
just needs to trust its "AD" bit.  The only thing missing from the
traditional libresolv API is some way for the application to specify
the resolver address list from the application (as "127.0.0.1"
and/or "::1").  Some systems have a newer stub API (res_nquery,
...), but this API is not yet sufficiently universal.

Indeed, if it becomes important to be able to locally exclude
various namespaces from DNSSEC, this is far more easily done in a
local "unbound" and the like, than in the stub resolver.

So I am making a bold prediction that the maximally secure validating
stub resolvers are not likely to catch on.  The necessary DNS
sophistication belongs squarely in a dedicated separate resolver.
 
-- 
	Viktor.