Re: [dane] An AD bit discussion

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