Re: [RFC] support for trusted validating resolver configuration

[Tomas Hozza <thozza at redhat dot com>]

On 12/01/2014 10:51 PM, Pavel Simerda wrote:
> ----- 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.

Hi Pavel.

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

I think applications can have only little trust in the information returned
by libc, if the library does not check if the data came from a trusted source,
while passing the AD bit to application.

I agree it is just one of the building blocks.

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

Yes, since the proposal is expecting a new file /etc/resolv-secure.conf
to be added. We can also restrict the modification of the file using mechanisms
like extended file attributes or SELinux policy.

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

I think you are right and the proposal conforms to AD bit description
and usage in existing RFCs.

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

The proposal role should be to ensure that if anyone modifies the /etc/resolv.conf
it will not affect the trust of AD bit if there is resolv-secure.conf. If someone
removes the resolv-secure.conf then there is no way the application can be fooled
by the AD bit set in the response.

I agree that the countermeasures have to be employed by the OS, not the library.

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

The goal of the proposal is to make sure the AD bit is not set at all if
trusted validating resolver was not used. Thus making the data not trusted.

The security level specified by zone may affect the trustworthiness of data
only from that zone, but will not affect the AD bit trustworthiness universally.

The proposal improves the situation compared to the current reality when
the AD bit is used blindly by the libc, which makes it hard to trust.

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

Right, the content of /etc/resolv-secure.conf should be configured by the
administrator.
The easiest way is to have a locally running validating resolver which ideally uses
nameservers obtained via DHCP to fetch all the information from authoritative
nameservers.
Since it does the validation itself, we can trust the AD bit value.

> 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

Is there any estimate when this could get into the libc?
I think we would really benefit from the support in the future,
considering we are hopefully going to have trusted validating
resolver in Fedora by default.

Thanks!

Tomas
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com