[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 []) 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 []) 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
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


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:

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:

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.

*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