Re: Building consensus over DNSSEC enhancements to glibc.

["Carlos O'Donell" <carlos at redhat dot com>]

On 11/16/2015 08:04 PM, Zack Weinberg wrote:
> On 11/13/2015 11:38 PM, Carlos O'Donell wrote:
>> On 11/10/2015 08:47 PM, Zack Weinberg wrote:
>>> On 11/04/2015 03:44 PM, Carlos O'Donell wrote:
>>>> Community,
>>>>
>>>> I have written up a summary of the mailing list discussions
>>>> surrounding DNSSEC and the enhancements required to better
>>>> support it in glibc.
>>>>
>>>> https://sourceware.org/glibc/wiki/DNSSEC
>>>>
>>>> Any thoughts or comments would be much appreciated.
>>>
>>> (I am not a DNS nerd, but I *am* a security nerd.)
>>>
>>> The conversation so far has convinced me of something I've suspected for
>>> a while: The nameservers configured in /etc/resolv.conf *cannot* be
>>> trusted - not even 127.0.0.1.  The only approach that seems viable to me
>>> is to scrap the idea of outsourcing DNSSEC validation to a local DNS server.
>>
>> Could you expand on this a bit?
>>
>> How is outsourcing to a local validating resolver different from outsourcing
>> to nscd?
> 
> So first off, I hope you agree with me that outsourcing DNSSEC to a
> local DNS server is not an option.  If the rest of this thread hasn't
> convinced you of that, I don't know what to say.

Updated: https://sourceware.org/glibc/wiki/DNSSEC

I'm sorry, but I have yet to be convinced, and a hand waving argument of
this sort is even less convincing. I appreciate that your time may be
limited and you may not wish to summarize your position. I'm asking
because I want to understand your position and need help.

I would like to see some more solid and in-depth arguments against
outsourcing DNSSEC to a local validating resolver via an /etc/resolv.conf
that has one entry for 127.0.0.1. I'm not a fundamentalist, and I can be
convinced otherwise.

I want to note the two somewhat orthogonal issues:

(a) How do we configure a DNSSEC based system?

- I have sustained opposition to changes to /etc/resolv.conf other than
  an options entry to control the stripping of DNSSEC AD-bit.

- My opinion is that we need a more complex policy framework than
  just a list of trusted servers and that users will want more control
  than this based on interfaces, dhcp responses etc.

(b) How does one trust the results of the API calls?

- I am not opposed to looking at best practice in say the getdns API
  and using similar API strategies to add DNSSEC support if possible
  (ABI and API restriction apply) to the APIs in glibc. This can include
  things like "always suppress untrusted results" or "ask for all results
  but include trust information in the results."

Outsourcing DNSSEC validation is (a), and not (b),
 
> The most straightforward alternative, the option with the fewest moving
> parts and the fewest ways it could fail insecure, would be to do
> validation in-process - imagine replacing libresolv with libunbound, or
> something like that.  I would actually prefer that to an nscd-based
> approach.

I agree fully that this is the very simplest implementation that would
solve *some* of our DNSSEC related issues. Though you are still left
with (a) and (b) from above.

The counter argument to that is that it increases the attack surface for
the application by including a lot of new crypto code into the process.

Is your opinion that the added complexity and maintenance burden of all
of this new code as "core" libraries worth the benefit compared to other
deployment models? Say a local validating resolver?

My own personal judgement is that in-process validation is not worth
the increase security risk and the local validating resolver is a single
process we can harden and audit more easily than all the possible
interactions of the new crypto code and all processes that use it.

> However, I can see a case for some sort of local, DNSSEC-aware cache.
> We *can* trust nscd to do that job, even though we can't trust a local
> DNS server, because we provide the code on both sides of the
> communications channel, and we *don't* look at resolv.conf to find out
> where to talk to nscd.  It's /var/run/nscd/socket or nothing.  And
> nobody is mucking with nscd.conf the way they muck with resolv.conf; we
> can stick validation options in there and rely on them *staying* there.

That is indeed a compelling argument for using nscd.

Enabling nscd gives you more than just DNSSEC, it will cache everything
else by default. You would have to use SELinux to disable access to the
other caches (possible because we control cache access via AVC bits).

I'm worried that this "cache everything" by default approach may hinder
adoption for those that just want DNSSEC.

I am not opposed to nscd becoming DNSSEC aware.

> Unrelatedly, I hope you also agree with me that exposing the AD bit to
> applications is a Bad Idea unless they explicitly demonstrate that they
> know what they are doing by using a low-level API. If getaddrinfo() does
> not fail hard in the condition DNSSEC calls "bogus", there will be
> exploitable application bugs.

Exposing the AD-bit to applications is wrong. It is on-the-wire DNS
protocol information that has nothing to do with applications. The authors
of DNS consider the on-the-wire protocol to terminate at the host and that
host APIs will transform that into something sensible.

Therefore applications that want that on-the-wire data will have to use
libresolv directly to inspect that low-level data. They know what they are
doing at that point. Any other higher level API should not talk about the
AD-bit.

The behaviour of getaddrinfo() in the case of "bogus" is complicated.
There are three issues here:

* Backwards compatibility.

  * Returning the expected responses by default.

* Policy by API

  * The API call requests that "bogus" data be dropped.

  * The API call requests no data be dropped but that results contain
    trust data for the application to inspect. Allows enumeration of
    all results and the trust information.

* Policy by interface/domain/zone etc.

  * A more complex configuration where the system administrator
    has some control over how DNSSEC related error handling is
    carried out. Consider a signature error and a workaround
    required until the zone is in compliance again and not returning
    "bogus" for validation.

I expect you might consider this a "side stepping" of your question.
I think my answer for "bogus" results is "it depends."

In a securely configured system with DNSSEC enabled and enforced 
I agree completely that "bogus" results in an error, "insecure"
results in dropped responses, and "secure/indeterminate" are
returned to the caller for a default API usage without
any additional trust related flags.

My apologies for the long reply.

Cheers,
Carlos.