Re: [dane] An AD bit discussion

Olafur Gudmundsson <ogud@ogud.com> Wed, 26 February 2014 18:09 UTC

Return-Path: <ogud@ogud.com>
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 02A5A1A00E8 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 10:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 v-IOHZxxx8Fp for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 10:09:32 -0800 (PST)
Received: from smtp100.ord1c.emailsrvr.com (smtp100.ord1c.emailsrvr.com [108.166.43.100]) by ietfa.amsl.com (Postfix) with ESMTP id 03D9B1A005B for <dane@ietf.org>; Wed, 26 Feb 2014 10:09:31 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id BC71A1B16AA; Wed, 26 Feb 2014 13:09:30 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7042B1B0A05; Wed, 26 Feb 2014 13:09:28 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
Date: Wed, 26 Feb 2014 13:09:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1ECDE2FC-CA24-43BF-8DAF-DAA8D98721B1@ogud.com>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/SRzoLHfjBULC0BLcb8f6dJFvJIQ
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 18:09:39 -0000

On Feb 26, 2014, at 9:12 AM, Paul Wouters <paul@nohats.ca>; wrote:

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

<no-hat Just an old time DNSSEC promoter>
I agree with most of what you said. 

Strictly the AD bit "problem" is twofold, 
	a) Application does not know where the AD bit came from nor if the bit/data has been changed in flight. 
	b) Application does not know the security policy of the "entity" that set the AD bit or who operates it. 

a) is caused by the fact that most systems do not do 4) but blindly accept DNS resolvers supplied by 
network configuration protocols like DHCP and RA.  For all practical purposes this while a nice "convenience" it 
is a  security hole that someone will drive a truck though one day (actually they have it is called a coffee shop network) 
To further make things worse there is frequently no integrity protection on the last "hop/mile" between the recursive resolver and 
host stub-resolver. 
 
There is a large hotel chain that advertises that the resolvers used in their hotels are 8.8.8.8 (Google) and two others ISP's 
the answers when sent to directly 8.8.8.8 only about 1/3 of the time look like they come from 8.8.8.8. When asking OpenDNS directly 
the answers are supplied by the resolvers in the DHCP list. This can only be defeated by sending queries to a port != 53 and in some cases
requires TCP connections.

b) This is a big issue, and without some research you can not find this out what the resolver is doing, and then you can 
not be sure if the resolver has special cases where it will not give you the real answers but the ones it is told by higher authority to
give out. 

As what a DNS library should do, IMHO work on setting up a trusted path to a trusted Recursive resolver,
and then add info in the returned structure that gives credibility of the AD bit. 

DNS cookies are one option, TSIG and DNScurve are better, SIG(0) will scale to random servers, 
TLS over long lived TCP/SCCP are also possible, IPsec to resolver will work as well. 
If someone can figure out how to do Encrypted DNS over UDP that would be great. 
If you trust 127.0.0.1 fine but make sure all the answers come from it. 

The biggest difficulty you will face is encryption and Anycast DNS are unfriendly to integrity, 

In summary we need to 
   - deploy security for the last mile
   - extend API's to return info that the application can USE (not what we think it wants) 

	Olafur


> Paul
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane