Re: [dane] An AD bit discussion

Tony Finch <dot@dotat.at> Wed, 26 February 2014 17:24 UTC

Return-Path: <fanf2@hermes.cam.ac.uk>
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 0F0481A0730 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 09:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.253
X-Spam-Level:
X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4n8F-TFReL7N for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 09:24:41 -0800 (PST)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id 1F98B1A0725 for <dane@ietf.org>; Wed, 26 Feb 2014 09:24:40 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:56138) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1WIiDl-00087X-2u (Exim 4.82_3-c0e5623) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 26 Feb 2014 17:24:37 +0000
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1WIiDl-00072a-R4 (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 26 Feb 2014 17:24:37 +0000
Date: Wed, 26 Feb 2014 17:24:37 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Paul Wouters <paul@nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
Message-ID: <alpine.LSU.2.00.1402261638490.13302@hermes-1.csi.cam.ac.uk>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NGEFT4-AFnbosGsXOfesXRsvsXc
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 17:24:44 -0000

Paul Wouters <paul@nohats.ca>; wrote:

> 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.

Note that OpenSSH can be linked with ldns to do its own validation.

> 1 Applications can either do dnssec validation themselves, or trust the
>   AD bit.

At the moment I consider in-process validation to be the safer way to do
it, because apps do not have any sane way to verify that it is safe to
trust the AD bit (more about that below). That is, by doing its own
validation the app is better able to guarantee safety, without assuming
that there is an expert and diligent sysadmin who is able to do arcane
things like override the DHCP server's suggested nameserver addresses.

> 2 It is undesirable that each application has its own DNSSEC validation
>   code, trust anchors and DNS cache.

Agreed, but there are some subtleties. It's probably not too bad if the
validation code is in a shared library that is centrally configured - like
the traditional resolver or ldns's resolver. However if ldns's resolver
were to be more widely used it will need MUCH better trust anchor
management. Even so a system-wide cache should perform better. Perhaps
multi-user systems should have per-user validating caches so that users
don't have to trust each other too much :-)

> 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.

Right. What makes this particularly pernicious is that the resolver API
does not give an app any reasonable way to find out if it would be safe to
trust the AD bit.

To do so the app would have to extract the name server addresses from the
__res_state and compare that with the system's list of network interface
addresses. The layout of __res_state is private and the way IPv6 support
has been added varies wildly between different flavours of unix. Utterly
horrible.

> 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

That would be nice :-)

> 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.

That sounds like a fair plan.

Note that what ssh does is use the low-level res_query() API which returns
a raw DNS packet, and examines the AD bit in the packet header.
http://svnweb.freebsd.org/base/vendor-crypto/openssh/6.5p1/openbsd-compat/getrrsetbyname.c?revision=261288&view=markup#l274
Exim's preliminary DNSSEC support does the same.
http://git.exim.org/exim.git/blob/HEAD:/src/src/dns.c#l430

So you should change the low-level parts of the traditional resolver to
clear the AD bit in the packet header before returning to any higher level
code, unless the connection to the nameserver is known to be safe.

Question: along with this change are you planning to change the resolver
to set the AD flag in queries when the nameserver is known to be safe?

Usually the AD flag only appears in responses if the query had the AD or
DO flags set. DO is a bit wasteful for clients that only care about the AD
bit. However the only DNSSEC switch that libc resolvers currently have is
options edns0 (which implies DO).

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>;  http://dotat.at/
Malin: West or southwest 5 to 7, backing south 6 to gale 8 for a time. Rough
or very rough. Showers, rain for a time. Good, occasionally poor.