This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building consensus over DNSSEC enhancements to glibc.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]