Re: Building consensus over DNSSEC enhancements to glibc.

[Zack Weinberg <zackw at panix dot com>]

On 11/16/2015 10:44 PM, Carlos O'Donell wrote:
> On 11/16/2015 08:04 PM, Zack Weinberg wrote:
>> On 11/13/2015 11:38 PM, Carlos O'Donell wrote:
>>> 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

For future reference, I prefer that my first name be spelled with a 'k',
not an 'h'.  I don't seem to have privileges to edit the glibc wiki.

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

OK, I'll try.

First, I will note that at least one person in this discussion (Paul
Wouters) wants to be able to outsource DNSSEC to a validating resolver
that is *not* on 127.0.0.1.  This is obviously a terrible idea when
there is a physical network in between the client and the validating
resolver, and I *think* he conceded that point to Rich, but he brought
up the possibility of containers or VMs outsourcing to a validating
resolver in another container or on the host, via a VLAN.  It seems to
me that even in that case we cannot be *certain* that response forgery
is impossible (does the kernel actually contract to prevent address
spoofing? are you *sure* there are no bugs?).  Also, how are we to
determine whether "nameserver w.x.y.z" refers to a peer on a VLAN?  Do
we have to check the routing table before and after every DNS lookup?
So I'd prefer to rule out the possibility of ever outsourcing over IP to
anything other than 127.0.0.1.

Now, I happen to think that outsourcing to 127.0.0.1:53, using the
existing DNS-over-IP protocol, is *also* a bad idea, but I'll admit that
it's not as clear-cut.  I see three interlocking problems:

First, I think trying to prevent tampering with /etc/resolv.conf is a
lost cause.  There are too many existing programs that expect to be able
to do that, and expect to have their modifications honored.  In this
very discussion, _everyone_ other than you, me, Rich, and Roland has
been insisting that nameservers in particular must remain configurable
via resolv.conf.  Even if you think changing all those programs is
doable as a long-term goal, you must admit that the transition period
will be measured in years.  It would be silly to delay actually making
use of DNSSEC until the transition is over, if there's an alternative.

Second, I think that _even if_ you are on a system where you know
nothing will modify resolv.conf, and it reads "nameserver 127.0.0.1",
that does not tell you whether the local caching resolver is
_trustworthy_.  There are hundreds, maybe thousands of systems out there
right now with that configuration, where the local caching resolver
doesn't support DNSSEC at all, and will cheerfully pass through
responses with AD set.  If glibc starts paying attention to AD based on
whether resolv.conf says "nameserver 127.0.0.1" all those systems are hosed.

I *think* this second point is what you mean to address with the
"options entry to control the stripping of the AD bit."  But, on the
assumption that programs will continue to tamper with resolv.conf, you
can't rely on resolv.conf to tell you whether to do that!  I'd feel a
lot better about that plan if the knob were in nsswitch.conf.  Yes, in
most cases, a program that can edit resolv.conf *can* also edit
nsswitch.conf, but there is no (or not nearly as large) installed base
of programs that *expect* to be able to edit nsswitch.conf, so locking
that down (with SELinux or chattr +i or whatever) is not an exercise in
boiling the ocean.  Similarly for nscd.conf.

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

It seems to me that there is no consensus for either your position or
the opposition's position re /etc/resolv.conf.

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

Complex policy frameworks make me nervous: more ways to set things up
wrong.  However, I have not thought about all the use cases in detail here.

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

Here, though, I have an informed opinion: "Include trust information in
the results" is a Bad Idea.  Look at the track record with applications
screwing up TLS authentication - most often by assuming that the library
does everything for them.

In the DNSSEC context I believe the following lines should be drawn and
they should not be configurable:

* "Bogus" responses must always be discarded.
* "Insecure" (zone is known not to be signed) responses must be
discarded, except for a fixed list of records where backward
compatibility forces us to permit their use in unsigned zones.

This applies both to getaddrinfo/getnameinfo and a hypothetical
intermediate-level API that lets you do arbitrary queries but doesn't
make you parse the reply packet yourself (so, a little higher level than
ub_resolve).  Applications that want to parse the reply packet
themselves probably *can* be trusted to process security annotations
correctly.

I'm not 100% sure about this, but now that the public root has been
signed, I think "indeterminate" should no longer be possible as long as
the trust anchor is available.

There probably *does* need to be a toggle for what happens if no trust
anchor is available: either fail all lookups, or fall back to
DNSSEC-oblivious operation (but only for the same fixed set of records
that are grandfathered in for unsigned zones).  In the future one might
also want a toggle to suppress *all* results from unsigned zones, but
the world is not ready for that one.

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

That is a strong counterargument, and that is why ultimately I come down
in favor of doing the job in nscd.

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

Perhaps it would make sense to change the default nscd configuration to
one that *only* did DNS.

zw