Re: Building consensus over DNSSEC enhancements to glibc.

[Simo Sorce <simo at redhat dot com>]

On 06/11/15 13:28, Rich Felker wrote:
> On Fri, Nov 06, 2015 at 01:11:47PM -0500, Simo Sorce wrote:
> > On 06/11/15 12:59, Rich Felker wrote:
> > > On Fri, Nov 06, 2015 at 10:42:38AM +0100, Petr Spacek wrote:
> > > > On 5.11.2015 02:23, Rich Felker wrote:
> > > > > On Wed, Nov 04, 2015 at 03:44:48PM -0500, 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.
> > > > >
> > > > > While I'm not opposed to clean ways to expose DNSSEC trust to
> > > > > applications, I don't see a bit libc role in the ideal client setup:
> > > > > you just run a local nameserver that verifies DNSSEC and replies with
> > > > > ServFail upon receiving forged reslts/results that are supposed to be
> > > > > signed but aren't.
> > > >
> > > > This scheme is okay in principle and we want to deliver it in Fedora, however,
> > > > it is missing one important aspect: It has to fail safe.
> > > >
> > > > If the local validating resolver is not available for whatever reason the
> > > > application cannot rely on AD bit - doing so would be a security nightmare
> > > > because an attacker could easily spoof SSL/SSH key fingerprints etc.
> > >
> > > In such a configuration, if the local validating resolver is not
> > > available, all lookups fail with an inconclusive error.
> > >
> > > Presumably you're assuming having a non-local backup nameserver
> > > configured. Such a configuration is inherently broken and insecure.
> > > resolv.conf should contain nothing but "nameserver 127.0.0.1" on a
> > > DNSSEC enabled system.
> >
> > The problem is what happen if you configure the system to have
> > 127.0.0.1 in the normal case, then you attach a new network
> > interface and suddenly resolv.conf is changed to point to something
> > else (whatever DNS is passed to a dhcp client or vpn client or ...).
>
> On a system configured with DNSSEC you do not allow resolv.conf to be
> changed by dhcp clients. Doing so is a bug.

It is not whether you want it, it is what do you do when (not if) it 
happens.

Look, we all want DNSSEC, and we all want a local resolver and avoid bad 
resolv.conf configuration, but we all also know that desires and reality 
are two different thing.

Our end goal with Fedora (and eventually RHEL) is to end up with a 
default local resolver and NetworkManager (or other appropriate daemon) 
controlling resolv.conf (probably setting it with the immutable 
filesystem flag and what not).

However we are not there, and there are ton of Linux distributions that 
we have no say over and will continue to allow dhclient, vpn clients, 
and whatnot to change resolv.conf

In order for *any* application to be able to trust glibc's AD bit, glibc 
must give guarantees that it will not serve data from untrusted servers 
(or exposes indication about trustability).

To do that glibc needs to know that a server *is* indeed trusted. and 
looking at the nameserver field is obviously not sufficient, because no 
matter how ardently we desire so, common/existing configuration managers 
slap in random servers with no regard.

So how do we indicate to glibc that a server is trusted in a way that 
applications can trust it and other commonly used resolver libraries 
(like c-ares for example) can learn to use ?

We need a (positive) way to tell glibc, unequivocally, that the system 
is handled by a configuration manager (whether that is software or an 
admin manually setting configuration options doesn't matter) that is 
aware and know how to properly set the system for DNSSEC.

The easiest mostr compatible way to tell glibc is by adding/changing an 
option in resolv.conf, an option not used by current existing 
configuration managers.

Then glibc has two options to deal with applications:
 - always strip AD bits unless trusted resolver is enabled
or
 - add a new public function that applications can call to query if 
glibc is currently configured with a trusted resolver or not.


A situation in which glibc does not use an explicit configuration option 
to signal applications that it is using a trusted resolver is not useful 
... no scratch that, it is actively harmful, because applications 
developers will quickly realize they cannot trust any information coming 
from glibc and will simply not use it for DNSSEC related information.

Simo.

--
Simo Sorce * Red Hat, Inc * New York