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: Mon, 16 Nov 2015 11:23:28 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <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> <20151111170706 dot GY3818 at brightrain dot aerifal dot cx> <5649BB13 dot 6040907 at redhat dot com>
On Mon, Nov 16, 2015 at 12:16:35PM +0100, Petr Spacek wrote:
> On 11.11.2015 18:07, Rich Felker wrote:
> > 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.
>
> 'Not using DNSSEC: same situation as now' goes directly against the gold DNS
> standard. Please see original (i.e. pre-DNSSEC) RFC 1035:
> http://tools.ietf.org/html/rfc1035#page-26 section 4.1.1 Header section format.
>
> It clearly states what to do with bits 9, 10 (AD), and 11 in message header:
> "Reserved for future use. Must be zero in all queries and responses." So, if
> you decide not to use/ignore DNSSEC please do it in a standard-compilant and
> at the same time secure way: Zero out these bits unconditionally.
In such a setup, no DNS packets are being generated at all. You're
using someone else's nameserver that could forge whatever it wants (or
whose payload could be forged by MITM on the network).
> > 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.
>
> This is probably a misunderstanding. It has nothing to do with opportunistic
> encryption, it is about incremental deployment.
But it has exactly the same inherent risks as opportunistic crypto.
> This third option is a 'must have' for incremental deployment. There are no
> flag days on the big Internet. Nobody can 'turn on DNSSEC' on all DNSSEC
> domains in the global DNS tree.
As I understand it, all domains in the global DNS tree either require
signatures or have a way to obtain a signed chain of records saying
that they do not use DNSSEC. Either of these is sufficient to treat a
result as valid (i.e. not ServFail it).
If this is incorrect, could you explain how/why?
Rich