Re: [dane] An AD bit discussion

Mark Andrews <marka@isc.org> Wed, 26 February 2014 14:41 UTC

Return-Path: <marka@isc.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 8F3D21A03AA for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 06:41:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 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, SPF_PASS=-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 8y98vIe-qZ_C for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 06:41:47 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDAA1A0390 for <dane@ietf.org>; Wed, 26 Feb 2014 06:41:47 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7F93CC94D1; Wed, 26 Feb 2014 14:41:33 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393425706; bh=bjhKlkl8KzV1zhhipMrCEeWXHahiL4E8q80i+Ud3NmA=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=oFfZHKzArst1wluXSS3NpLfrww2l/HF15Reiv1P4URnW2r1O8a8APv1uSwKk1XMQc AY+0KYJKJGbYaS4OLx1LdIWBPKAORtCgekqGHRjgNWY/cncgJ9xW5jPVs+b7yyDIqt 4VhsRDSQFo6kexN+fiTJp5P7vdpVr0YHsKOpJhqU=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Feb 2014 14:41:33 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DF18F16005C; Wed, 26 Feb 2014 14:42:25 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B21E416004A; Wed, 26 Feb 2014 14:42:15 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 72FEA106BCFB; Thu, 27 Feb 2014 01:41:21 +1100 (EST)
To: Paul Wouters <paul@nohats.ca>
From: Mark Andrews <marka@isc.org>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
In-reply-to: Your message of "Wed, 26 Feb 2014 09:12:20 -0500." <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
Date: Thu, 27 Feb 2014 01:41:21 +1100
Message-Id: <20140226144121.72FEA106BCFB@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OMwmC4SRpAaVJ0IOL6tTAbqHjzI
Cc: dane WG list <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: Wed, 26 Feb 2014 14:41:49 -0000

In message <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>;, Paul Wouters writes:
> 
> Hi,
> 
> I've been part of a very long and heated discussion about the trust of
> the AD bit. I would like to hear from people here what they think.
> 
> I'm currently aware of two (non-dns utilities) applications that make
> security decisions based on "blindly" trusting the AD bit: ssh with
> VerifyHostKeyDNS=yes|ask and Postfix.
> 
> libreswan and strongswan are examples of applications that use libunbound
> for in-application DNSSEC validation to avoid needing to trust
> /etc/resolv.conf DNS servers for the AD bit.
> 
> First, let me list 4 items everyone seems to agree on:

Actually 2 is very much not agreeded apon by everyone.

> 1 Applications can either do dnssec validation themselves, or trust the
>    AD bit.
> 
> 2 It is undesirable that each application has its own DNSSEC validation
>    code, trust anchors and DNS cache.
> 
> 3 It is undesirable that applications blindly trust the AD bit when
>    resolv.conf points to another host as the AD bit could have been modified
>    on the network.
> 
> 4 In the ideal world tomorrow, each host has its own automatically
>    configured, perfectly working validing DNS server and resolv.conf can
>    be ignored or is always hardcoded with nameserver 127.0.0.1
> 
> Now for my question. Until we reach 4), what should we do with the AD
> bit in getaddrinfo() ?
> 
> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
>     configuration mechanism will allow white-listing nameservers and 127.0.0.1
>     will always be on the whitelist.
> 
> B) do nothing
> 
> C) Something else, please specify
> 
> Paul
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org