This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Petr Spacek <pspacek at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 13 Nov 2015 23:31:18 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563A6E40 dot 9040508 at redhat dot com> <20151105012328 dot GU8645 at brightrain dot aerifal dot cx> <563C760E dot 4060107 at redhat dot com> <20151106175956 dot GA3818 at brightrain dot aerifal dot cx> <563CED63 dot 1070201 at redhat dot com> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com> <20151109180310 dot GO3818 at brightrain dot aerifal dot cx> <5641C454 dot 3030309 at redhat dot com> <20151110174923 dot GS3818 at brightrain dot aerifal dot cx> <56433969 dot 10405 at redhat dot com>
On 11/11/2015 07:49 AM, Petr Spacek wrote:
> 4.
> - TLS: Failing open in this analogy means that on systems where the list of
> trusted CAs is not present the validation will always pass.
> - DNSSEC: In our case the application sees AD bit set by attacker, which is
> roughly equivalent to an attacker sending arbitrary cert which gets accepted.
That's a system configuration error.
If we are going to use DNSSEC by default by must ship an /etc/resolv.conf
with `options dns-strip-dnssec-ad-bit` and thus after the upgrade of glibc
no application will ever see the AD-bit until the local validating resolver
is installed.
c.