Re: [dane] An AD bit discussion

Petr Spacek <pspacek@redhat.com> Thu, 27 February 2014 18:40 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 7AB5D1A0410 for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 10:40:28 -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 4e4STRF2NvhY for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 10:40:26 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id CF23D1A0176 for <dane@ietf.org>; Thu, 27 Feb 2014 10:40:26 -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 s1RIKJdt000835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Feb 2014 13:20:19 -0500
Received: from pspacek.brq.redhat.com (vpn1-7-193.ams2.redhat.com [10.36.7.193]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1RIKGhx031540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 13:20:18 -0500
Message-ID: <530F81DF.6010401@redhat.com>
Date: Thu, 27 Feb 2014 19:20:15 +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: Paul Wouters <paul@nohats.ca>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <m3txbly9ui.fsf@carbon.jhcloos.org> <alpine.LFD.2.10.1402261930400.3528@bofh.nohats.ca> <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org> <20140227034723.GA73861@mx1.yitter.info> <20140227041753.3509810773A8@rock.dv.isc.org> <20140227044213.GO21390@mournblade.imrryr.org> <alpine.LFD.2.10.1402270015320.6180@bofh.nohats.ca> <20140227054617.GP21390@mournblade.imrryr.org> <530F3A64.2000001@redhat.com> <alpine.LFD.2.10.1402271144500.24957@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1402271144500.24957@bofh.nohats.ca>
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/dane/k_p9C6oByXXIzMQ27cWryQhK_Ls
Cc: dane@ietf.org
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: Thu, 27 Feb 2014 18:40:28 -0000

On 27.2.2014 18:01, Paul Wouters wrote:
> On Thu, 27 Feb 2014, Petr Spacek wrote:
>> Now we need to discuss 'a temporary solution' for the case where a
>> validating resolver is not available for whatever reason.
>
> I don't agree with this premise, but those applications can be changed
> to use (most error handling removed for clarity):
>
>      /* one time setup */
>      dnsctx = ub_ctx_create(); /* create unbound resolver context */

Please correct me if I'm wrong but I'm afraid that this snippet effectively 
bakes a security policy to applications:
>      ub_ctx_hosts(dnsctx, "/etc/hosts") /* emulate POSIX */
>      ub_ctx_resolvconf(dnsctx, "/etc/resolv.conf") /* use nameservers from
> resolv.conf */
>      ub_ctx_add_ta(dnsctx, rootanchor); /* root key auto-updates via
> /var/lib/unbound/root.anchor */
>      ub_ctx_set_option(dnsctx, "dlv-anchor:", dlvanchor); /* activate DLV */
How can I install my own trust anchors? (E.g. I have internal zones and I want 
to use DNSSEC for them...) How can I disable DLV on system-wide level? All 
this should be system-wide configuration otherwise it will create problems for 
tightly controlled environments.

> This has the same effect as stripping out forged AD bits, except real AD
> bits survive. It uses whatever nameservers the system has in
> /etc/resolv.conf. It supports overrides in /etc/hosts. It does not
> require glibc modification. It does not require various applications
> read new keywords in resolv.conf or new config files. It has no race
> conditions. It's a great band-aid until "tomorrow".
>
> And possibly, the getdns API has an even simpler way of doing this.
I agree that new DNS API is a great idea, I have said that many times already.

> Is this really too hard to do today for those old applications that need
> to be fixed and for the new applications you will write tomorrow?
Will you patch every application doing TLS to link with libunbound? (Upstream 
developers are always happy to accept patches introducing new dependencies.)

Are you going to convince OpenStack people (accepting only pure Python code 
and nothing else) to use this?

Please see the other branch of this thread, I will reply there about crypto 
libraries.

-- 
Petr^2 Spacek