Building consensus over DNSSEC enhancements to glibc.

[Simo Sorce]

On 09/11/15 05:57, Petr Spacek wrote:
> On 6.11.2015 21:10, Simo Sorce wrote:
>> 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.
>
> One of reasons why 'nameserver 127.0.0.1' only cannot work are systems which
> boot from network. Imagine that the system is booting so it does not
> necessarily have local resolver running (yet) but the system might need to
> mount NFS share with / from somewhere, probably from a NFS server which is
> identified by DNS name.
>
> That is exactly the case where you want to use remote DNS server for name->IP
> resolution but at the same time the DNS server should not be trusted for
> DNSSEC validation because as you said, only 127.0.0.1 can give you trustworthy
> answers. Sure, there should not be anything relying on DNSSEC during the boot
> process, but faith is not a good security principle.

This is not the only case, I have talked to people that have "trusted" 
networks (separate physical LAN, IPSEC based, etc) that want to 
outsource the DNS cache to one of the control nodes including DNSSEC 
resolution, and can trust it.
Sure it is a very special case of a very controlled network, but it 
should be supported IMHO (or they will do things like DNATting 
127.0.0.1:53 or similar anyway I guess...)

> To return back to the main discussion:
> What can we do to design and implement *something* which fails safe?

Whatever it is failing safe is fundamental because the current situation 
is that many (probably most of the non-server cases) use untrusted DNSs 
even when they listen locally (some DNS caching servers used to pass AD 
bits unmodified and unchecked) so the defaults must be failing safe.

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