Re: [dane] AD bit handling in stub-resolvers: conclusions and compromises

[Viktor Dukhovni <[e-mail]>]

On Tue, Apr 08, 2014 at 10:19:33AM -0700, Wes Hardaker wrote:

> Petr Spacek <[e-mail]> writes:
> 
> > It seems that almost everyone agree that local validating resolver is the
> > best option.
> 
> I failed to pipe up before, unfortunately.
> 
> But, no I don't agree that's the best solution.  The reality is that in
> some cases we're making *security decisions* based on the results of a
> flag that we're not 100% sure of the source.  Without doing something
> like replacing the system library's notion of even looking at
> resolv.conf and only looking for 127.0.0.1, then you can't be 100% sure
> that the bit you get back is actually trustable.  If the default install
> of the OS does the right thing, who's to say it'll stay that way.

This is where Wes and I part ways somewhat, but fortunately, this
issue is not an impediment to the SMTP DANE draft.

> As an application author who might want absolute assurance that DNSSEC
> was done (because I'm bootstrapping TLS or SSH or ... off of it), then
> my ideal situation is to have a local resolver for caching purposes, but
> to actually do validation in-application.

For me doing it in application, means costly integration of complex
code into the application that will add considerable latency because
the application will have a cold DNSSEC cache (and will now need
a cache where one was not needed before...  The Plan-9 approach of
moving security features into system services is I think far
preferable.

The intersection of the position Wes takes and mine is some sort
of 'assured' AD bit, which I am not opposed to in principle, provided
this is in fact a reasonable plan of action.

So for example, extending libresolv to match long-established BSD
semantics to improve thread safety and provide more application
control would suffice, res_ninit(), res_setservers(), ...  plus
ideally the ability to set the "AD" bit in the request (rather than
"DO", reducing the quantity of unnecessary bloat in the reply).

That way applications that want a local resolver can be configured
to use one, and can make appropriate fallback decisions if one is
not available.

As for *censoring* the AD bit, that approach is likely more
problematic and I think is where Paul Wouters and Petr part ways...

So please make it possible in all the various DNS APIs (that don't
already do this) for the stub resolver to override the default
nameserver list (static or insecurely obtained from DHCP).  Give
the stub resolver more control over the "AD" and "DO" bits, and
think long and hard about whether censoring is a viable approach
it may well be a bad idea.

-- 
	Viktor.