[dane] Proposal: AD bit handling in stub-resolvers (ACK/amend/NACK)

Petr Spacek <pspacek@redhat.com> Fri, 28 February 2014 12:12 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 5BCB31A026A for <dane@ietfa.amsl.com>; Fri, 28 Feb 2014 04:12:43 -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 L2tqUWl1SAXe for <dane@ietfa.amsl.com>; Fri, 28 Feb 2014 04:12:41 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D46E11A022F for <dane@ietf.org>; Fri, 28 Feb 2014 04:12:41 -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 s1SCCd0a001477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Fri, 28 Feb 2014 07:12:39 -0500
Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1SCCbiH003924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Feb 2014 07:12:38 -0500
Message-ID: <53107D34.1030409@redhat.com>
Date: Fri, 28 Feb 2014 13:12:36 +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: <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> <20140227212614.GY21390@mournblade.imrryr.org> <alpine.LFD.2.10.1402271729140.1209@bofh.nohats.ca> <20140227230922.GD21390@mournblade.imrryr.org>
In-Reply-To: <20140227230922.GD21390@mournblade.imrryr.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.22
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5EncyDxW8BwRQDG61KY0_-_XF8w
Subject: [dane] Proposal: AD bit handling in stub-resolvers (ACK/amend/NACK)
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, 28 Feb 2014 12:12:43 -0000

Hello,

please comment on the following proposal. Paul and Viktor are most active in 
this discussion but we would like to hear opinions from other experts!

Let's agree on the very basic principle, please do not recommend particular 
libraries etc.


The Goal
========
On 28.2.2014 00:09, Viktor Dukhovni wrote:
 >> On 27.2.2014 22:26, Viktor Dukhovni wrote:
>>> I want the AD bit to be more than blind faith.
(This means AD bit as seen by applications in responses from generic DNS API.)


Long-term solution
==================
Paul Wouters pushes hard for validating recursor on each host. Viktor and me 
agree with that:
> So *if* there is a local resolver and it is the only one used,
> great!  No need to disable the AD bit.  If there is not, perhaps
> "failing safe" is sensible.

However, we want to find some intermediate solution deployable today.
> It may be enough to design systems that default to local resolvers,
> and users who change that are free to shoot themselves in both feet.


Proposal for short-term solution - please comment
=================================================
All names are completely "random". Please propose better names and/or semantics.

1) Add a new boolean to /etc/resolv.conf:
options resolvers-trusted
- If present, this option states that "admin ensured that recursor is 
trustworthy and the communication link between recursor and stub-resolver is 
secure".
- If present, the AD bit will be passed from recursors to applications as-is.
- If not present, the AD bit sent to a applications will be always 0.
- E.g. the option will be present on a system with locally running Unbound.
- E.g. the option *will not* be present on thin client, compute node in data 
centre, a random laptop installed today with default configuration etc.

Objections:
- There is a chance that dhcp client copies "options" from old resolv.conf to 
new one. In that case simplest variant "options resolvers-trusted" is insecure 
if one configured e.g. local trusted recursor and DHCP client was started 
after that.
- Many applications mess with resolv.conf so the new boolean should be 
somewhere else. E.g. /etc/resolv.trusted.
- Because of the first objection, the file /etc/resolv.trusted should contain 
explicit whitelist with IP addresses of trusted recursors. That lowers the 
probability that admin sets option "resolvers-trusted" to /etc/resolv.trusted 
but some application (like DHCP client) will change name servers in 
/etc/resolv.conf.


2) Add a function call for run-time check (for library users):
boolean dns_resolvers_trusted(resolver);
- TRUE if admin declared resolvers as trusted. AD bit is unchanged.
- FALSE otherwise. AD bit is always set to 0. Applications can detect that AD 
bit masking is enabled.
- If the function is not defined then DNS library doesn't support AD bit 
masking as described here.

Naturally, this can be replaced by any other mechanism for run-time checks if 
a library in question has such mechanism already.


3) Usage from applications:
- Call run-time check:
/* WARNING! This call can't be skipped: It ensures that your DNS the library 
supports the new behavior. */
dns_trusted = dns_resolvers_trusted(resolver);
if (dns_trusted)
     Enable code depending on DNSSEC
else
     Fallback

- Decide if you want to use the data from DNS or not:
dns_query(resolver, query, answer);
if (answer->ad_bit)
     Use data from DNS (answer->data)
else
     Fallback


Please add what I have missed, what is wrong etc.

Thank you very much for your time!

-- 
Petr^2 Spacek