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.
- Re: [dane] An AD bit discussion Paul Wouters
- [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Ondřej Surý
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Olafur Gudmundsson
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Wiley, Glen
- Re: [dane] An AD bit discussion James Cloos
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andreas Schulze
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion (correction) Petr Spacek
- Re: [dane] An AD bit discussion (+concerns from g… Petr Spacek
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion (+concerns from g… Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- [dane] Proposal: AD bit handling in stub-resolver… Petr Spacek
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] Proposal: AD bit handling in stub-reso… Viktor Dukhovni
- Re: [dane] An AD bit discussion Florian Weimer
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek