Re: [RFC] support for trusted validating resolver configuration

[Pavel Simerda <psimerda at redhat dot com>]

----- Original Message -----
> From: "Florian Weimer" <fweimer@redhat.com>
> To: "Pavel Simerda" <psimerda@redhat.com>, "libc-alpha" <libc-alpha@sourceware.org>
> Cc: "Tomas Hozza" <thozza@redhat.com>, "Petr Spacek" <pspacek@redhat.com>, "Alexandre Oliva" <aoliva@redhat.com>,
> siddhesh@redhat.com, schwab@suse.de, neleai@seznam.cz
> Sent: Monday, December 1, 2014 4:06:34 PM
> Subject: Re: [RFC] support for trusted validating resolver configuration
> 
> On 11/18/2014 01:40 PM, Pavel Simerda wrote:
> > Goals:
> >
> >   * Applications can rely on the AD flag coming from the library.
> >      - It's either cleared out or it comes from a trusted validating
> >      resolver.
> 
> Hi Pavel,
> 
> I have looked at the situation, I think there are actually two goals here.

Thanks a lot!

For the record, we're talking about the following proposal:

https://sourceware.org/ml/libc-alpha/2014-11/msg00426.html

Basically the proposal shouldn't be read as a cure for all DNSSEC related
issues but rather as an important building block. Technical notes follow.

> (1) Prevent updating the nss_dns configuration from untrusted sources
> (such as DHCP).

The proposal doesn't talk about nss_dns because nsswitch modules don't
currently provide any security information for the results. Instead it
is about the resolver providing API functions like res_query that return
a complete DNS answer including the AD flag that actually carries such
information.

The proposal also recognizes the need to use dynamically obtained data (like
those from DHCP) in the resolver configuration in order to access local
resources and to use the network infrastructure effectively. 

Therefore the proposal doesn't assume a restricted environment that would
avoid using resolvers not trusted for validation. As a result, it is useful
in all sorts of setups and when its basic assumptions (see later) are met,
it provides universal guarantees for libraries and applications.

> (2) The AD flag matter.
>
> I think (1) is a separate issue because there are so many things that
> can unexpectedly edit /etc/resolv.conf,

The proposal provides the same guarantees whether /etc/resolv.conf is guarded
from being replaced/rewritten or not.

> essentially taking a trust,
> local validating resolver (whether recursive or not) out of the picture.

One of the main features of the proposal is that /etc/resolv.conf contents
don't define the trusted validating resolver.

> It's better to consider (2) because that part is really complex.  (I
> firmly believe we should in no way encourage applications to alter
> behavior on the AD bit

As far as I understand, the AD flag is the standard way[1][2] the trusted
validator signals that the returned data is authenticated (using DNSSEC).

[1] http://tools.ietf.org/html/rfc4035#section-3.2.3
[2] http://tools.ietf.org/html/rfc6840#section-5.6

An application that relies on the security level of the data[1][2][3] has
therefore no other choice than directly or indirectly:

1) Derive the authenticity from the *AD flag* when the trusted validator
is contacted using DNS (e.g. via the stub resolver in libc). The proposal
ensures that it is safe to use the AD flag from the stub resolver.

2) Derive the authenticity from *an equivalent of the AD flag* when the
trusted validator is contacted via other means or the application performs
validation itself. The proposal avoids the need to perform the validation
in the application itself (e.g. using libunbound[4]).

Correct me if I'm wrong.

[1] https://tools.ietf.org/html/rfc6698
[2] https://tools.ietf.org/html/rfc4025
[3] https://tools.ietf.org/html/rfc4255
[4] https://unbound.net/documentation/libunbound.html

> But the nice thing is that if there is a foolproof way to lock a system
> to a trusted resolver,

The proposal ensures that for retrieving data from insecure zones, there
is no difference between a trusted validator and any other resolver. For
retrieving data from secure zones, it ensures that an untrusted resolver
cannot spoof the validation data.

In addition to the proposal, the operating system should employ techniques
to maximize the availability of the trusted validator in order to provide
security aware applications with validation data whenever possible as well
as to provide opportunistic(*) security to all applications. We are working
on this in the dnssec-trigger and unbound projects[1] and we appreciate
any feedback.

[1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver

(*) Where the opportunity depends on whether the zone is evaluated as signed
using a chain of trust. Please correct me if there's a better term for it.

> then the correctness of the AD bit matters less (in the sense that you can be
> sure that you receive DNS data at the security level specified by
> relevant zone operators).

This is useful for the opportunistic security (as specified above). Security
aware applications still need the AD flag (or an equivalent) to learn the
actual security level. Some data like TLSA[1], IPsec keying material[2] and
SSH key fingerprints[3] can only be used authenticated.

[1] https://tools.ietf.org/html/rfc6698
[2] https://tools.ietf.org/html/rfc4025
[3] https://tools.ietf.org/html/rfc4255

> For goal (1), there is also the question where the contents of
> /etc/resolv-secure.conf will come from. Obviously, DHCP is out.

Looks like I omitted this information in the original posting. Untrusted
sources like DHCP may still be needed to configure the trusted validating
resolver *whose* address ends up in /etc/resolv-secure.conf.

Please treat the following list of situations as an amendment to the proposal:

 * /etc/resolv-secure.conf contains just 127.0.0.1 and we have a locally
   running validating name server. This is part of what dnssec-trigger with
   unbound achieves, but can be done manually as well.

 * In a managed environment /etc/resolv-secure.conf includes the address of
   a validating name server that is securely reachable. This may apply to a
   host with containers or virtual machines, as well as a secure network
   managed by an automated tool.

 * The administrator really knows what he's doing, secures the network on his own,
   and drops the address of a name server in /etc/resolv-secure.conf that will
   be trusted to express the validation result using the AD flag.

Thank you again for finding time to review the proposal. As you see on the mailing
list, it's not easy to get feedback in this area.

Cheers,

Pavel