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
- 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