[dane] AD bit handling in stub-resolvers: conclusions and compromises
Petr Spacek <pspacek@redhat.com> Fri, 04 April 2014 13:31 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 9CA221A0190 for <dane@ietfa.amsl.com>; Fri, 4 Apr 2014 06:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5bLRpF38upgn for <dane@ietfa.amsl.com>; Fri, 4 Apr 2014 06:31:38 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD2F1A017C for <dane@ietf.org>; Fri, 4 Apr 2014 06:31:38 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s34DVXHC002068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Fri, 4 Apr 2014 09:31:33 -0400
Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s34DVVMR003133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Fri, 4 Apr 2014 09:31:33 -0400
Message-ID: <533EB433.5060204@redhat.com>
Date: Fri, 04 Apr 2014 15:31:31 +0200
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.4.0
MIME-Version: 1.0
To: dane@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Gg4BQlvO_P5JOsG0RJBajkOXKFg
Subject: [dane] AD bit handling in stub-resolvers: conclusions and compromises
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: Fri, 04 Apr 2014 13:31:42 -0000
Hello, Let me sum up the discussion and document the compromise for archaeologists: It seems that almost everyone agree that local validating resolver is the best option. People start to disagree when it comes to questions like "Is it feasible to rely on a local validating resolver in the near future? How can applications detect that a validating resolver is not configured and that DNS responses can't be trusted?" Aim of the proposal below is to enable applications to stay safe on systems without a validating resolver. Approach A ========== One approach is to do nothing in stub resolvers and rely on validating resolvers or application logic. This approach was mentioned by Paul Wouters <pwouters@redhat.com>, Prasad Pandit <ppandit@redhat.com>, Carlos O'Donell <carlos@redhat.com>, Olafur Gudmundsson <ogud@ogud.com>. It seems that the main concern about AD bit stripping in stub resolvers is compatibility with existing applications which rely on AD bit: http://www.ietf.org/mail-archive/web/dane/current/msg06521.html http://www.ietf.org/mail-archive/web/dane/current/msg06497.html After further discussion, it seems that pwouters is okay with AD bit stripping in stub resolver if it is explicitly requested by a calling application. (E.g. by special resolver initialization.) Approach B ========== The other approach is to do AD bit stripping in stub resolvers by default. It was proposed to add system-wide setting for this (e.g. to resolv.conf) and default to "strip AD bit unless admin configured something else". This approach was mentioned by Petr Spacek <pspacek@redhat.com>, Simo Sorce <ssorce@redhat.com>, Viktor Dukhovni <viktor1dane@dukhovni.org>, Tony Finch <dot@dotat.at>, James Cloos <cloos@jhcloos.com>. viktor1dane thinks that compatibility concerns are not well-founded: http://www.ietf.org/mail-archive/web/dane/current/msg06523.html Naturally, application has to be able to do run-time check that it is using a library with this new behavior to avoid running in unsafe environment. Compromise ========== *Local validating resolver is strongly recommended.* - Introduce a new system-wide setting for AD bit stripping. - Add a new flag or initialization function to stub resolver API. Resolver behavior will depend on this new flag: -- Old applications (not using the new flag or new initialization call): Never strip AD bits. 100 % compatibility is guaranteed. -- New applications (actively using the flag): Stub resolver will strip all AD bits by default until admin configures some trusted name servers. Applications using the new resolver flags will fail safe on systems with no configured trusted resolver i.e. an application will request AD bit stripping from the stub resolver and the AD bit will be stripped until the admin configured a trusted resolver. Next Steps ========== Define what is yet not defined: - System-wide configuration format (e.g. modify resolv.conf vs. add a new file) - Propose specific API changes for major DNS libraries (glibc, maybe ldns and co.) - Prepare recommendation for application developers how and when to use a new API Further discussion about implementation details will happen on mailing lists related to the particular DNS libraries. Please speak up *now* if you have strong technical objections against the high-level idea described above. -- Petr Spacek @ Red Hat
- [dane] AD bit handling in stub-resolvers: conclus… Petr Spacek
- Re: [dane] AD bit handling in stub-resolvers: con… Wes Hardaker
- Re: [dane] AD bit handling in stub-resolvers: con… Viktor Dukhovni
- Re: [dane] AD bit handling in stub-resolvers: con… Mark Andrews
- Re: [dane] AD bit handling in stub-resolvers: con… Nico Williams
- Re: [dane] AD bit handling in stub-resolvers: con… Nico Williams
- Re: [dane] AD bit handling in stub-resolvers: con… Paul Wouters
- Re: [dane] AD bit handling in stub-resolvers: con… Paul Wouters