Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 31 July 2017 20:13 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 98566131CA0 for <dnsop@ietfa.amsl.com>; Mon, 31 Jul 2017 13:13:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 Rj9s62DJgSME for <dnsop@ietfa.amsl.com>; Mon, 31 Jul 2017 13:13:12 -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 06EF2127735 for <dnsop@ietf.org>; Mon, 31 Jul 2017 13:13:12 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 24AC17A3309; Mon, 31 Jul 2017 20:13:11 +0000 (UTC)
Date: Mon, 31 Jul 2017 20:13:11 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20170731201310.GI8146@mournblade.imrryr.org>
Reply-To: dnsop@ietf.org
References: <20170731171107.GA42492@isc.org> <306070B3-DD80-41F2-A0AA-2004131D0F23@nohats.ca> <CADyWQ+Ffu8JOn6co184PC-Uvv4G1qYU3d0ZchupRJEDDmfYKaw@mail.gmail.com> <CAJE_bqf7R7ZW5ixcZdOcaHDso+C5QbtGbz+Z1mOs+p9_C2_cAg@mail.gmail.com> <alpine.LRH.2.21.1707290851010.26738@bofh.nohats.ca> <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> <20170730074253.GA33522@isc.org> <alpine.LRH.2.21.1707310953260.21291@bofh.nohats.ca> <20170731171107.GA42492@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <306070B3-DD80-41F2-A0AA-2004131D0F23@nohats.ca> <20170731171107.GA42492@isc.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bKcO8kgTSYKUK3SJmP2pQYNq4BM>
Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error
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: Mon, 31 Jul 2017 20:13:15 -0000

On Mon, Jul 31, 2017 at 05:11:07PM +0000, Evan Hunt wrote:

> Are there applications specifically trusting AD=1 and behaving differently
> than with AD=0?  Or are they just ignoring it and trusting every answer
> equally?  I would have expected the latter, but I confess to being
> surprised if there are people going out of their way to implement "DNSSEC
> validation" by just buying whatever magic beans some dude in the forest
> has for sale.

On Mon, Jul 31, 2017 at 02:16:37PM -0400, Paul Wouters wrote:

> Postfix is one but last I knew only when resolv contains localhost.

Not only Postfix, also Exim, and perhaps also Sendmail some day
if/when DANE support appears there, partial support is already
in the snapshot code:

    ftp://ftp.sendmail.org/pub/sendmail/snapshots/sendmail.8.16.0.21.tar.gz

That code also relies on the (presumably configured local) resolver's
AD bit.  In all three code bases making sure that the resolver is
actually local is up to the MTA administrator.

I expect this implementation strategy will be near universal.

> Software doesn't want to link against a dnssec library.

Correct.  Software similarly also does not want to explicitly add
code to handle Kerberos, ... which is why various indirect approaches
are becoming popular for handling security "out of process".  Having
a local resolver with a trustworthy "AD" bit is a feature, not a
bug.  

The AD bit is exactly the right DNSSEC interface.  All that's
missing from the traditional libresolv (and not missing from recent
innovations in res_ninit(), res_nsearch(), ...) is the ability to
specify the loopback address as the sole resolver in the application.

No matter how much some here might want to discourage the "AD" bit
interface, it is the main one that developers will use, if they
use DNSSEC security signalling at all.  So it is up to the platform
vendors to improve security by delivering systems with a default-on
local validating resolver (that forwards to any upstream servers
that would otherwise have been used directly).  This also improves
latency by bringing the cache closer to the application.

-- 
	Viktor.