IETF Logo Mail Archive

[dane] An AD bit discussion

Paul Wouters <paul@nohats.ca> Wed, 26 February 2014 14:12 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 A10211A0321 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 06:12:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.147
X-Spam-Level:
X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 zT7KMYfoM7iH for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 06:12:24 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 599AC1A033F for <dane@ietf.org>; Wed, 26 Feb 2014 06:12:23 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 10F5380D6D for <dane@ietf.org>; Wed, 26 Feb 2014 09:12:21 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393423941; bh=cLV0xaIVnVjB3prMf9VxmHMGM51Iufx/JWtDdWylITw=; h=Date:From:To:Subject; b=pZdsyICfkJX2DNTnPvPYaEitfTPPT6SJAgzYv6YqN4ddL800lwuX4lxfYjfePjwze TDHRd192V3GT5MZG1boZWdLiDqVQnZIpt+nuF4VYmOoIRraigprgZVUl1WJw48dwyX fFl+p5funEkRU2oJZEVohuAvgV8DoLiT1WFVJD8Y=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s1QECKTX025055 for <dane@ietf.org>; Wed, 26 Feb 2014 09:12:20 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 26 Feb 2014 09:12:20 -0500
From: Paul Wouters <paul@nohats.ca>
To: dane WG list <dane@ietf.org>
Message-ID: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
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/sOBR_H2su4lTdvCysFj8OQymimQ
Subject: [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:12:27 -0000

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:

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

v2.23.0 | Report a Bug | By Email