Re: Building consensus over DNSSEC enhancements to glibc.

[Petr Spacek <pspacek at redhat dot com>]

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.

There can be plenty of reasons why local validating resolver is not available:
The system is booting/shutting down/it is an embedded system without power to
do validation/DNSSEC validation is intentionally not configured because it is
not needed ...

So, the application or preferably DNS API need to have one bit somewhere to
detect if system is running local validating resolver or not - this is a
*necessary* condition to make DNSSEC consumable by applications.

This method is currently missing so applications wanting to use DNSSEC are
doing weird things: E.g. Postfix is examining /etc/resolv.conf to verify that
only 127.0.0.1 is listed there.

Hopefully this explains the role of Glibc: It is *the* provider of canonical
DNS API, so it is a natural place where the signal 'AD bit can be trusted'
could be exposed to applications.


The proposed AD bit stripping was an easy and cheap way to do this at one
place in the system, with central configuration, which would allow us to
eliminate all kinds of weird re-implementations in applications.

Other proposals which fail safe are more than welcome, but anything which does
not fail safe will do more harm than good.

-- 
Petr Spacek  @  Red Hat