Re: [dane] An AD bit discussion

Viktor Dukhovni <viktor1dane@dukhovni.org> Thu, 27 February 2014 16:40 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742D81A0348 for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 08:40:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QDxMjfGzwlr for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 08:40:18 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id C36491A03B4 for <dane@ietf.org>; Thu, 27 Feb 2014 08:40:17 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BADD72AAC73; Thu, 27 Feb 2014 16:40:14 +0000 (UTC)
Date: Thu, 27 Feb 2014 16:40:14 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140227164014.GT21390@mournblade.imrryr.org>
References: <m3txbly9ui.fsf@carbon.jhcloos.org> <alpine.LFD.2.10.1402261930400.3528@bofh.nohats.ca> <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <530F3A64.2000001@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2Xq1AJusBvCWP_9RhzXWlZro4Nw
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 16:40:20 -0000

On Thu, Feb 27, 2014 at 02:15:16PM +0100, Petr Spacek wrote:

> Please let's concentrate on following situation:
> - Crypto libraries like GnuTLS/OpenSSL/NSS have DANE support
> compiled and enabled by default out-of-the-box.

The enabled by default part would be most likely.  It is not up to
the libraries to enable DANE support.  They don't know which
application protocol they're riding on top of, and how/whether DANE
applies to that application protocol.

For example, DANE for SMTP will be rather different from DANE for
various other app-layer protocols.  For example SMTP adds the MX
domains to the list of valid peer names to be found in an MX host
certificate.  SMTP does not support usages 0/1, ...

At this time 2 of the above libraries have no DANE support, and
GnuTLS DANE support is substantially incomplete (TLSA trust anchors
must be immediate issuers of the leaf certificate, and possibly
other limitations).

> - GnuTLS/OpenSSL/NSS libraries use AD bit as received from stub-resolver.

Which stub resolver API would you suggest they use?  Given the
multiplicity of interfaces, and the fact that applications may want
an asynchronous DNS interface, but none is as yet as entrenched as
libresolv, I would expect these toolkits to punt on TLSA record
resolution and leave this up to the application.  Especially because
policy about DNSSEC validation (AD bit vs. in-app trust anchors,
which nameservers, ...) don't belong in the underlying SSL library.

> - A random application (e.g. Firefox/Thunderbird/offlineimap) use
> DANE-enabled crypto library and have no clue about DNSSEC. (That is
> what we want, right? Just use it without modifying all
> crypto-enabled applications in the world!)

It is not so simple.  The application sets trust policy, including
whether DANE applies, which root CAs to trust, ...  Completely
transparent DANE assumes no application-specific DANE-related policy,
this seems unlikely.

For example, with SMTP, the SSL library won't be doing MX resolution,
but the security of the MX RRset determines whether DANE applies to
any of the MX hosts.

> - The whole set is running on machine with plain stub-resolver
> without validator.

> Result => It is completely insecure because attacker can use DANE
> for effective man-in-the-middle attack: The crypto library will
> trust to fake TLSA records because attacker send fake TLSA record
> with AD=1.

Your model is too naive.  Crypto libraries should not and won't
set application protocol policy.  MTAs and so on, have lots of
knobs to enable DANE (in Postfix it is NOT on by default), and the
administrator is responsible for making sure the platform is suitably
configured before relying on DANE.

> One opinion is 'use a new shiny API for DNS and do not hack existing
> resolver APIs' and the other option is to 'do validation yourself'.
> I'm afraid that this do not belong to category 'temporary solution'.

Postfix does neither.  The administrator sets up a trusted recursor
and then enables DANE.  DANE support in interactive applications
operated on multi-user machines by non-administrators may need to
know whether the stub resolver is trustworthy.  This requires
a new predicate in resolv.conf (or whatever).

> It can take too long to design API, then to develop libraries and
> then *to convince application developers to use this new API*.

Yep, 5-10 year deployment horizons for brand new stuff.

> I definitely agree that old resolver from BIND8 is "not the best"
> but we have to count with existing applications. It is easier to
> push small patches like
> - res_init()
> + res_init_trusted()
> It is *much much* harder to push patches rewriting code related to
> DNS to some completely new library. We want to add DANE support to
> existing applications not only to new ones.

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.

Beyond that, an application interface to ask whether the system
list of recursors is deemed secure would be helpful.  Work with
the various upstream library maintainers to make that happen.

> The proposed approach with a new initialization call (*for example*
> res_init_trusted()) have two (desired) side-effects:

This is I think a mistake.  Without resolver contexts as with
res_ninit(), this applies to all resolver clients in the same
address space, not just the caller.  Applications are usually not
in a good position to define trusted recursors.  Instead of saying
which resolvers are trusted, they want to ask whether the default
resolvers *are* trustworthy.

> - It prevents an application relying on AD bit from running on old
> system which does not guarantee trustworthiness of the AD bit.

There are no such legacy applications.  If you get ahead of DANE
adoption with suitable libraries, the applications can start directly
with the new plumbing.

> Otherwise we would have to invent some way how to check at run-time
> that special handling for AD bit is supported. (Think about cases
> where application was compiled on newer system and somebody tries to
> run it on older system etc.)

Run-time checks are required, and support for these will be missing
from older systems, so the code won't run there for lack of required
dependencies.

> For example current software like Postfix or OpenSSH client will
> 'just work' without any change. AD bit will be handled in special
> way only if the resolver library is initialized with the new call.

As the developer of the Postfix DANE interface, I'd rather Postfix
AD bit handling were subject to default system policy, and would
ask the administrator to set system policy accordingly.  Once APIs
for querying the stub-resolver behaviour (AD suppressed or trusted)
become widely available, Postfix will start using them to sanity
check its TLS policy settings (can't use DANE when stub resolver
suppresses AD support).

> It doesn't surprise me that very few applications use AD bit because
> nowadays it requires adding a new configuration option "resolver is
> un/trusted" to the application. It is not easy neither for
> programmer nor for administrator.

It is the administrator's job, but the platform can make that as
easy as possible.  I don't know which applications you have in mind
that are the ones doing DNSSEC and avoid using the AD bit.  Very
few applications use DANE, period.

The Exim folks are planning to implement DANE (as soon as one or
two of them are less cycle starved), and to trust the AD bit (that
code is partly there already per Tony's post).

Which DANE libraries are these apps using?  There is no DANE support
in OpenSSL or NSS yet, and GnuTLS is sufficiently incomplete, that
it is not ready for production use.

> I'm sorry, this also sounds like a long-term plan. We are looking
> for something workable today. The plan is to push DANE support as
> much as possible and as soon as possible - not to wait (potentially
> long time) for standardization and adoption of new APIs etc.

Today, DANE is essentially unusable.  Postfix DANE support took a
year of development and resulting in a new IETF draft plus proposed
changes that I hope will lead to DANEbis.  We're not there *today*.

> >As to the question of whether always trusting AD when the recursive
> >resolvers are not "secure" is OK?  I don't know.  Depends what
> >applications do with that trust.
>
> Please see the example with DANE-enabled crypto library above.

The example is largely naive.  It is not going to work that way
for quite some time.  DANE will be enabled by the code that performs
the application protocol (which may sit a few layers below the
business logic), but it will not any time soon be automatically
enabled by the transport security library due to insufficient
context.  For example, the application has to confirm that the
transport endpoint name is secure (e.g. after MX or SRV lookups)
and configure fallback behaviour when all TLSA records are unusable
(e.g. mandatory unauthenticated TLS, ...).

-- 
	Viktor.