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

[Petr Spacek <[e-mail]>]

On 27.2.2014 17:42, Viktor Dukhovni wrote:
> On 27.2.2014 17:40, Viktor Dukhovni wrote:
> 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
 > Oops, s/most likely/most UNLIKELY/.
>> the libraries to enable DANE support.  They don't know which
[...]

Feel free to skip handwaving about crypto libraries and jump straight to the 
matter - DNS stub-resolvers.

/Disclaimer: Please read following text about crypto libraries as a long-term 
vision. I'm adding it here just to add some context information. I'm aware 
that it will take long and that is not *that* simple./

>> 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.
I have talked with NSS developers at Red Hat's Developer Conference this year 
(devconf.cz) and their (personal and not-that-thorough) opinion was that it 
seems feasible to do DANE for pure TLS directly in crypto library.

If everything you need is to open a TLS connection to a server with given name 
then *in theory* the crypto library can do all the work for you.

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 :-)

>>> - 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.

Yes, that is a problem (in a little bit different area). Generally, we want to 
move crypto/security policies from applications to system level. Current 
situation is an administrative nightmare.

The 'Vision' (highly naive, *please* do not comment on API itself but on the 
idea) is to convert (as much as possible) applications to APIs like:

open_tls_connection('hostname', port, &conn);
send_enc_data(conn &buff, len);
recv_enc_data(conn, &buff, len);
close_tls_connection(&conn);

... and separate applications from DNS/connection handling/crypto stuff. Think 
about DNSSEC + happy eyeballs + TLS. That is a lot for an application to do 
for mere connection establishment!

That will allow us to control security policy on system-wide level where it 
belongs. We already do work in this field and direction.

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.)

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

Of course, it can't work today and there always be some special cases. MTAs 
can be one of them. You are expert in this area and I trust you.

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.)

>>> 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).
I 100 % agree.

>>> 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.
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*.

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


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.

>> 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.
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?

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"?

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


>>> 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.
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.

>>> - 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.
I personally agree but please read concerns expressed by glibc maintainer below.

>>> 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.
I'm personally okay with that.

>>> 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).
I 100 % agree with your point of view.

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.

Could you give us some detailed thoughts about compatibility?

I guess that we will have the same discussion about compatibility again and 
again with many upstream developers from many DNS libraries so any detailed 
analysis will be handy.

>> 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*.
Okay, let's find a way how we can move things forward on client side! :-)

Thank you very much for your time.

-- 
Petr^2 Spacek