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
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
