Re: [dane] An AD bit discussion

Paul Wouters <paul@nohats.ca> Thu, 27 February 2014 00:41 UTC

Return-Path: <paul@nohats.ca>
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 381141A0816 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 16:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level:
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547] 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 iLDPr5jahZhF for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 16:41:03 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 799E31A074A for <dane@ietf.org>; Wed, 26 Feb 2014 16:41:03 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AFA8C80D6D; Wed, 26 Feb 2014 19:41:00 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393461660; bh=+1XcVUmkxafxLrMHuHdPoWVWTxAXfytkzH0QQ+JDGrM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cyjveZkD/TFDhc0zR52UdEoPidthDcKt79G0NepUumY6Ho1IGDVIRhJYOdoVxHEYG 7zwE94NwQhw/bqzdliqd3RzYpAjo3kSAmYIa2FHTogj3M7lruhhlpzameF6YmFYLBq ZsApAcS43UamiqFVcnJ6q1Xthb3ICX2Ti8u0mB1I=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1R0f0mI006781; Wed, 26 Feb 2014 19:41:00 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 26 Feb 2014 19:41:00 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: James Cloos <cloos@jhcloos.com>
In-Reply-To: <m3txbly9ui.fsf@carbon.jhcloos.org>
Message-ID: <alpine.LFD.2.10.1402261930400.3528@bofh.nohats.ca>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <m3txbly9ui.fsf@carbon.jhcloos.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/RahzGfzzoKvg4ZLCYps1bj-UTLc
Cc: dane@ietf.org
Subject: Re: [dane] An AD bit discussion
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: Thu, 27 Feb 2014 00:41:08 -0000

On Wed, 26 Feb 2014, James Cloos wrote:

[ picking this answer because it brings back this thread to my question ]

>>>>>> "PW" == Paul Wouters <paul@nohats.ca>; writes:
>
> PW> Now for my question. Until we reach 4), what should we do with the AD
> PW> bit in getaddrinfo() ?
>
> PW> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
> PW>    configuration mechanism will allow white-listing nameservers and 127.0.0.1
> PW>    will always be on the whitelist.
>
> PW> B) do nothing
>
> I've always preferred a local resolver, and with dnssec a local
> verifier, on every system.  If there are systems unable or unwilling
> to do that, then A is a reasonable compromize until they can and will.

So my fear of that doing A) are negative consequences. Admins installing
a rack of servers or VMs, and pointing resolv.conf to something trusted
nearby, but not on localhost itself, will get the AD bit stripped without
additional configuration. If those people upgrade their systems to the
new A) solution, their applications will no longer see the AD bit.

But so far, it seems I'm the only one worried about that case.

That and I prefer solutions working on obsoleting resolv.conf
over extending it and I think most cases can already be covered by
running a DNS server on localhost - with the exception of laptops
(dnssec-trigger+unbound does not cut it yet for non-techies)

If there are more people who would like to reply to this issue
specifically (as opposed to other APIs or _sending_ AD bits), that
would be useful.

So far it seems people are leaning towards A) over B) while everyone
seems to agree doing DNSSEC on the host itself (server or in-app) is
still the preferred method.

Paul