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: Rich Felker <dalias at libc dot org>
- To: Petr Spacek <pspacek at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 11 Nov 2015 12:07:06 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <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> <20151111154525 dot GW3818 at brightrain dot aerifal dot cx> <56436FB2 dot 2010302 at redhat dot com>
On Wed, Nov 11, 2015 at 05:41:22PM +0100, Petr Spacek wrote:
> Ah, I see. This example might be confusing because with TLS you have only two
> states: Fully validated (secure?) or not-validated (insecure?). On the other
> hand, in DNS we have four security states, not only two (see RFC 4033 section
> 5 and RFC 4035 section 4.3).
>
> When reading this, consider glibc to be "Non-Validating Security-Aware Stub
> Resolver" (RFC 4033 section 2).
>
>
> Now back to the DNSSEC security states:
> "servfail" should be returned for security state "bogus", but "bogus" state
> can be returned by validator which detects this state. This is not our case
> because we do not have any validator yet (because the system is configured yet).
>
> In fact, because the system was not configured to do validation yet, we are
> talking about handling of "Indeterminate" state which according RFC 4033
> section 5 is handled in the same way as state "Insecure", i.e. the AD bit
> should be 0.
>
> I'm not making this up :-)
I accept that you're not making this up. What I question is whether
the people who did make it up are repeating the same mistakes that
browsers made with TLS (making it easy to accept forged certs).
My view is that there are two types of system setups:
1. Using DNSSEC: only localhost should be used for queries, and when
not available, all queries should fail with the equivalent of
ServFail.
2. Not using DNSSEC: same situation as now.
I believe your position, and the position of the people who designed
this stuff, is that there should be a third option:
3. Might have DNSSEC: query result needs to report to the application
whether the result has a valid signature or not. Known forgeries
should probably be dropped as ServFail still, but unsigned answers
could be reported.
IMO this third setup creates a lot more room for misconfiguration and
essentially replicates the problems you always have with opportunistic
encryption.
> Search in RFC 4033 for "Indeterminate" and you will get two hits
> - ... "This is the default operation mode."
> - "The current signaling mechanism does not distinguish between indeterminate
> and insecure states."
>
> Does it explain why AD bit should be cleared instead of returning servfail in
> cases where validator is not available?
Yes, but I think it's bad security policy and should not be
implemented. It's also not a situation you can get into if you have a
local validator. The validator is always available, and can always
determine whether an answer is valid or forged.
Rich