Re: [dane] An AD bit discussion (+concerns from glibc camp)

Petr Spacek <pspacek@redhat.com> Thu, 27 February 2014 20:44 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 11EFD1A0649 for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 12:44:08 -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 nAMJEpncLTxa for <dane@ietfa.amsl.com>; Thu, 27 Feb 2014 12:44:06 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA01A0141 for <dane@ietf.org>; Thu, 27 Feb 2014 12:44:06 -0800 (PST)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1RKi3bl027164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Thu, 27 Feb 2014 15:44:03 -0500
Received: from pspacek.brq.redhat.com (vpn1-7-193.ams2.redhat.com [10.36.7.193]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1RKi1TY018679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Thu, 27 Feb 2014 15:44:03 -0500
Message-ID: <530FA391.1070604@redhat.com>
Date: Thu, 27 Feb 2014 21:44:01 +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.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> <20140227164014.GT21390@mournblade.imrryr.org> <20140227164201.GU21390@mournblade.imrryr.org> <530F9A3D.3070008@redhat.com>
In-Reply-To: <530F9A3D.3070008@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.25
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8pF_6G1j-lqB0ktzeWe7PeP51as
Subject: Re: [dane] An AD bit discussion (+concerns from glibc camp)
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 20:44:08 -0000

On 27.2.2014 21:04, Petr Spacek wrote:
>>>> 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.

I'm adding quote from our glibc maintainer:

 >>>> Carlos O'Donell <carlos@redhat.com>; wrote:
>>>>> Consider a RHEL7 or RHEL6 system using the present meaning of
>>>>> `nameserver' in /etc/resolv.conf, on a secure network with a trusted
>>>>> recursive resolver using DNSSEC for some given domains. In this
>>>>> configuration any application using the AD bit works as expected.
>>>>> The system administrators ensured there was trust between the recursive
>>>>> resolver and the client stub resolver. This is how a user might configure
>>>>> their corporate network, and even better they might also use 802.1x
>>>>> with no rogue or untrusted systems on their network.
>>>>>
>>>>> If we release a z-stream or y-stream glibc that inverts the definition
>>>>> of `nameserver' from trusted to untrusted (doesn't use EDNS0+DO for
>>>>> a query, and clears the AD bit) then applications in such a configuration
>>>>> as described above that rely on the AD bit forwarding may cease to
>>>>> function correctly.
>>>>>
>>>>> That is why I do not want to change the existing meaning of `nameserver'
>>>>> and why we should not change any of the existing meanings of entries in
>>>>> /etc/resolv.conf. Thus for compatibility I suggest adding a new option
>>>>> `untrusted' for use by such applications as NetworkManager to put
>>>>> untrusted DNS server (acquired from untrusted DHCP results) into.
>>>>>
>>>>> Let me be clear though, if I didn't care about breaking customer
>>>>> configurations, I'd make this change, but I think we would be doing
>>>>> a disservice to our users by breaking valid existing DNSSEC uses.

-- 
Petr^2 Spacek