Re: [DNSOP] DNSSEC AD bit handling in stub-resolvers

Petr Spacek <pspacek@redhat.com> Wed, 26 February 2014 16:03 UTC

Return-Path: <pspacek@redhat.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353E41A06A3 for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2014 08:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level:
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 xMhlay23aaDC for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2014 08:03:11 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E6DDF1A0683 for <dnsop@ietf.org>; Wed, 26 Feb 2014 08:03:10 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1QG38mB009330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dnsop@ietf.org>; Wed, 26 Feb 2014 11:03:08 -0500
Received: from pspacek.brq.redhat.com (vpn1-4-54.ams2.redhat.com [10.36.4.54]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1QG2uuG004497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dnsop@ietf.org>; Wed, 26 Feb 2014 11:03:02 -0500
Message-ID: <530E1030.6060300@redhat.com>
Date: Wed, 26 Feb 2014 17:02:56 +0100
From: Petr Spacek <pspacek@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dnsop@ietf.org
References: <530E0BF1.4010008@redhat.com>
In-Reply-To: <530E0BF1.4010008@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/oc-hJh_EvWgmc1gHgc3Il590O6Y
Subject: Re: [DNSOP] DNSSEC AD bit handling in stub-resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 16:03:15 -0000

Greetings,

Paul Wouters and me have accidentally open threads about the same topic on 
this list and also on dane-list. I guess that this discussion fits better to 
dane-list so please discuss there.

I'm sorry for the noise.

Petr Spacek

On 26.2.2014 16:44, Petr Spacek wrote:
> Greetings,
>
> I'm Petr Spacek from Red Hat's Identity Management group. We plan to extend
> support for DNSSEC (including DANE and others) in open-source software and we
> would like to discuss the right implementation approach with you.
>
> We can see two very basic approaches:
> A) Do DNSSEC response validation in each application.
> B) Let recursive resolver do the validation and use AD bit in the application.
>
> We consider the first approach (i.e. each application doing response
> validation) too heavy-weight and hard to administer for various reasons:
> - Response validation is sensitive operation and application programmers
> should not do it themselves.
> - A variant where every application calls validation library is still not
> optimal. Experience with crypto libraries shows that there are many
> opportunities to use a library incorrectly (in a way which works but is not
> secure).
> - This approach has potential to create administrative nightmare if each
> application decides to maintain own set of trust anchors etc. We can see
> results of such approach in PKI world ...
>
>
> We believe that better approach is to centralize validation in local
> system-wide recursive resolver and use AD bit for signaling that data are
> trustworthy to applications. An application should use stub-resolver to talk
> to local recursive resolver and use received AD bit to decide e.g. if it is
> possible to trust TLSA records or not.
>
> Unfortunately, there are use cases where neither a locally running validating
> resolver nor a trusted path to a remote resolver are available and deployment
> of such is unacceptable.
>
> It seems that existing stub-resolvers unconditionally trust recursive
> resolvers and just forward the AD bit back and forth. This behavior is okay
> only if no application relays on the AD bit. In other words, supporting DANE
> with current stub-resolvers practically requires to add a configuration option
> 'recursive resolver is un/trusted' to each and every DANE-enabled application
> and library. (This is exactly what OpenSSH client does. An additional problem
> is that this value has to be maintained as network configuration changes over
> time.)
>
>
> We would like to make DNSSEC implementation in applications as simple and
> secure as possible. That is a reason why we are looking for a solution for a
> case where AD bit can't be trusted because validating resolver is not
> available for whatever reason. It would allow applications to use AD bit
> without explicit configuration per-application if we solve this case somehow.
>
> Is there any 'standard' way to handle described situation?
>
>
> We have the following proposal (some people say it is controversial):
> - Extend stub-resolvers with a new call for resolver initialization: In case
> of ldns it would be something like: ldns_resolver_new_frm_file_trusted() or
> for glibc res_init_trusted().
> - The new call will initialize library as usual + read some system-wide
> configuration (it can be whatever, imagine for example a new file
> /etc/resolv.trusted).
> - Client applications will use the same API (except the initialization) to do
> DNS queries.
> - When a DNS answer is received from network the stub-resolver will consult
> configuration read from /etc/resolv.trusted:
> -- If the particular recursive resolver is listed as trusted - pass AD bit to
> the application.
> -- *Otherwise: Clear AD bit and pass the answer with AD=0 to the application.*
>
> This allows an administrator to configure system-wide policy. In case with
> locally running validating resolver or e.g. IPSec tunnel to trusted resolver
> admin can declare it as trusted and nothing changes. However, this mechanism
> allows the system to be safe even in configurations *without* validating
> resolver. No explicit configuration in application is need, just one
> system-wide setting.
>
> It could seem like a minor improvement or a hack, but it allows applications
> to trust the AD bit unconditionally and as a result it significantly
> simplifies DNSSEC implementation and configuration on client machines. We hope
> that this simple approach will allow us to implement and deploy DANE and
> similar technologies widely.
>
> This proposal can be seen as temporary solution before secure transport
> mechanisms like IPSec or CGA-TSIG are widely available and used. The main
> advantage is that it is easy to implement and it doesn't require any new
> technology so we can use it in applications today.
>
> We would like to hear your opinions and recommendations for this area.
>
> Thank you for your time.