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

"Wiley, Glen" <gwiley@verisign.com> Wed, 26 February 2014 16:02 UTC

Return-Path: <gwiley@verisign.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 C62A61A0454 for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2014 08:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hRiQzHcGu0za for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2014 08:02:47 -0800 (PST)
Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1732C1A0699 for <dnsop@ietf.org>; Wed, 26 Feb 2014 08:02:45 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUw4QI2oqf1lya/d23k2O1RAhTYMkYf1v@postini.com; Wed, 26 Feb 2014 08:02:46 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s1QG2gvb011937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 11:02:43 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 11:02:41 -0500
From: "Wiley, Glen" <gwiley@verisign.com>
To: Petr Spacek <pspacek@redhat.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] DNSSEC AD bit handling in stub-resolvers
Thread-Index: AQHPMwm90JqcSVg1Qkyoc2fHUuWuKprHskSA
Date: Wed, 26 Feb 2014 16:02:41 +0000
Message-ID: <CF337945.35ABA%gwiley@verisign.com>
References: <530E0BF1.4010008@redhat.com>
In-Reply-To: <530E0BF1.4010008@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <96AACE91EDC9074781DAF495475FFBCC@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/wBsuVZ1biCJ8FFom7tIUf3I5W6o
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:02:52 -0000

Petr,

Have you taken a look at the getdns API specification that Paul Hoffman
put together at http://www.vpnc.org/getdns-api/ ?

This addresses many of your points for both stub resolvers and a recursive
resolver that would run on a platform local to the applications.
-- 
Glen Wiley
KK4SFV

Sr. Engineer
The Hive, Verisign, Inc.




On 2/26/14 10:44 AM, "Petr Spacek" <pspacek@redhat.com>; 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.
>
>-- 
>Petr Spacek
>Software Engineer
>Red Hat
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop