On Feb 26, 2014, at 9:12 AM, Paul Wouters <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
