Re: [dane] An AD bit discussion (correction)

[Viktor Dukhovni <[e-mail]>]

On Thu, Feb 27, 2014 at 09:04:13PM +0100, Petr Spacek wrote:

> Of course, there are applications with special requirements but easy
> cases could be (we hope) handled in crypto library and special case
> over appropriate APIs.
> 
> The discussion ended with statement that we need to solve API for
> resolvers first and then we can open discussion about DANE in NSS
> again.
>
>    <<< --- We are here :-)

Almost, because some of the DANE requirements are not set in stone.
For example, interaction with CNAME records is not yet a done deal.
Likewise digest agility, support for multiple peer names, semantics
of CU=3, ...

Early implementations are raising issues that clarify or extend
the standard, and so even if the resolver API were a solved problem,
it would be a bit early to bake a complete DANE implementation,
including all the policy issues around TLSA records, into a TLS
toolkit.

It is a good time to be thinking about how to validate certificate
chains via a given set of TLSA records and get the basics right
(subtle enough in itself, that almost every implementation I've
seen has serious flaws).

So progress can be made by implementing code in such toolkits:

    - To validate a remote server's certificate chain against
      a set of TLSA records provided by the application

    - To integrate this with name checks (off for CU=3) that
      support multiple application-provided names.

    - To think about the semantics of "IN TLSA 2 1 0" and whether
      such bare keys in DNS are usable without a corresponding
      chain element in the server TLS "certificate message".

    - To think about how to support digest agility

    - To provide an API for applications that want to do their
      own DNS lookups, and pass them to the librarary, rather
      than asking the TLS library to perform DNS lookups.

> This is long-term goal and adding application-controlled policies
> for DANE goes in opposite direction. That is the reason why we are
> trying to move 'policy logic' to system level/library level and do
> not pollute applications with policy processing. (We have to at
> least *try* that.)

For the simplest applications that have a single secure hostname,
and want to use some shiny new simplified API, which promises DANE
as a default enabled connection security mechanism, sure we can
assume there's a role for that.

Complications arise quickly if needs of more complex applications
are not anticipated and one need to be careful of complex dependency
chains if the crypto library depends on DNSSEC libraries which in
turn depend on crypto libraries.

> That is exactly the point. We don't want to configure everything
> again and again per-application, we want system-wide configuration.

Yes.

> The intent is to avoid adding more and more application specific
> knobs because it will be hard to get rid of them in future. (There
> are exceptions - as always.)

I vote for a stub resolver whose configuration combines a list of
recursive resolvers with a trust predicate that specifies whether
the AD bit should be passed to stub resolver applications.

I further vote for a way to query this predicate and to set the
recursor list, all via an extended libresolv.

> >>Yes, that's why I am recommending adoption of BSD libresolv, which
> >>is a superset of the traditional libresolv, and offers more of what
> >>is required to support DANE.  In particular, just having res_setservers()
> >>and res_nsearch()/res_nquery would be major progress.
>
> Again, we are not interested in a single library but in a general
> approach. Please consider that vanilla Fedora distro contains > 40
> 000 packages. I can name 5 different DNS libraries I use daily *only
> from top of my head*.

Then add the requisite functionality to each of the relevant
libraries.  But for your simple application API you only need to
care about the DNS libraries used by:

	OpenSSL (if any)
	GnuTLS  (if any)
	NSS	(if any)

you can help direct those toolkits at the preferred DNS library,
at which point behaviour of other DNS libraries is less important.

> We want to open DNSSEC/DANE potential for all of them, not only
> some small subset.

I would recommend a bit of focus at the outset.

> Of course, this idea (nameserver whitelisting/AD bit masking) has to
> be widely adopted in rest of the ecosystem otherwise we can give it
> up right now. We don't want and can't go against the whole world.

I am still not sold on "whitelisting", as opposed to "blessing" a
configuration as a whole, but this is not critical.  Yes work with
library designers to come to agreement on the approach.

> I'm glad that we agree on that. Do you have some specific proposal
> in your mind?  You have proposed new option in /etc/resolv.conf,
> something like
>
> 	resolvers_trusted = no/yes, right?

Something like that, without suggesting any particular name.

> What behavior is 'the best' in your opinion? Would it be okay to
> always set AD bit to 0 if option "resolvers_trusted" is set to "no"?

That would be fine.  Fail closed.  If some DHCP client unaware of
the new predicate generates a resolv.conf file, it should I think
be considered insecure.

> Are you okay with default "no"? (If the new option is not present.)

Yes.  I am of course not the entirety of this group (even if lately
I am responsible for ~50% of the traffic).  So perhaps this view
is not widely held.

> I agree. What do you think about AD bit masking configured
> system-wide? Please keep in mind that this needs to be universal
> behavior implement-able even in old glibc resolver and any other DNS
> library.

Fine by me, I prefer it in fact, provided the administrator can
unmask it, and an application can find out whether the masking is
taking place.

> The problem is that our glibc maintainer explicitly refused to
> change default behavior (i.e. mask AD bit until admin white-lists
> given resolver in /etc/resolv.conf) because it could break some
> (potentially) existing applications. That is a reason why we
> invented "init_trusted()" concept.

I think he's wrong.  Precisely because applications might be using
the AD bit, it *should* be masked when unsafe.  Polluting the library
with useless initializers (and still no resolver context as with
res_ninit(), ...) would be lame.

> Could you give us some detailed thoughts about compatibility?

Go ahead, PLEASE, break Postfix DANE support on systems using
insecure upstead resolvers on which the administrator does not
arrange for the right predicate in /etc/resolv.conf.

I want the AD bit to be more than blind faith.

-- 
	Viktor.