Re: Building consensus over DNSSEC enhancements to glibc.
From: | Petr Spacek <pspacek-AT-redhat.com> | |
To: | libc-alpha-AT-sourceware.org | |
Subject: | Re: Building consensus over DNSSEC enhancements to glibc. | |
Date: | Fri, 6 Nov 2015 10:42:38 +0100 | |
Message-ID: | <563C760E.4060107@redhat.com> | |
Cc: | Simo Sorce <simo-AT-redhat.com>, Paul Wouters <pwouters-AT-redhat.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
(Log in to post comments)