Re: [dane] An AD bit discussion
Petr Spacek <pspacek@redhat.com> Wed, 26 February 2014 16:28 UTC
Return-Path: <pspacek@redhat.com>
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 58DF31A06D5 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 08:28:00 -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 jtxBJmCpOBqh for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 08:27:54 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 10CB51A0139 for <dane@ietf.org>; Wed, 26 Feb 2014 08:27:48 -0800 (PST)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1QGRkgJ022346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Wed, 26 Feb 2014 11:27:46 -0500
Received: from pspacek.brq.redhat.com (vpn1-4-54.ams2.redhat.com [10.36.4.54]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1QGRioM027720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Wed, 26 Feb 2014 11:27:45 -0500
Message-ID: <530E15FF.2020107@redhat.com>
Date: Wed, 26 Feb 2014 17:27:43 +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: dane@ietf.org
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <20140226155752.GT21390@mournblade.imrryr.org> <alpine.LFD.2.10.1402261114460.3528@bofh.nohats.ca> <20140226162221.GV21390@mournblade.imrryr.org>
In-Reply-To: <20140226162221.GV21390@mournblade.imrryr.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qgtW583Neg1gjUXNWsjeanKML4g
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Wed, 26 Feb 2014 16:28:00 -0000
Greetings, On 26.2.2014 17:22, Viktor Dukhovni wrote: > On Wed, Feb 26, 2014 at 11:16:36AM -0500, Paul Wouters wrote: > >>>> Now for my question. Until we reach 4), what should we do with the AD >>>> bit in getaddrinfo() ? >>> >>> I was not aware of any mechanism in getaddrinfo() to communicate >>> the AD bit? Is this a new getaddrinfo() implementation with features >>> I've not looked at yet? >> >> Sorry, I mistook the flags in the struct to be the DNS flags. Let me >> rephrase it as "a DNS API call that returns the presence or lack of AD bit" > > I, for one, no longer know what you're asking. Not enough context. > If your question is not about getaddrinfo(), can you ask it again > with a bit of context? Are you asking what applications should > (in general?) do with the AD bit from stub resolvers? Or how > libraries should report the AD bit from DNS to applications when > the library has a mechanism to do so unambiguously? Or ...? Paul and me have accidentally open threads about the same topic on this list and also on dnsop-list. I guess that this discussion fits better here so I will post our reasoning. Please note that we would like to discuss the right implementation approach with you and not to push described proposal. I work in Red Hat's Identity Management group and my opinions can differ from Paul's, don't be surprised. (I.e. "we" in following text doesn't necessarily include Paul 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. A n 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(). - 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 widelly 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 @ Red Hat
- Re: [dane] An AD bit discussion Paul Wouters
- [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Ondřej Surý
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Olafur Gudmundsson
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Wiley, Glen
- Re: [dane] An AD bit discussion James Cloos
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andreas Schulze
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion (correction) Petr Spacek
- Re: [dane] An AD bit discussion (+concerns from g… Petr Spacek
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion (+concerns from g… Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- [dane] Proposal: AD bit handling in stub-resolver… Petr Spacek
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] Proposal: AD bit handling in stub-reso… Viktor Dukhovni
- Re: [dane] An AD bit discussion Florian Weimer
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek