Re: [DNSOP] Resolver behaviour with multiple trust anchors

Mark Andrews <marka@isc.org> Wed, 01 November 2017 00:50 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9175113F42E for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 17:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 7Io6ZyZxM3vD for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 17:50:19 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC67D13F42D for <dnsop@ietf.org>; Tue, 31 Oct 2017 17:50:19 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 995603BC050; Wed, 1 Nov 2017 00:50:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6B0CD160087; Wed, 1 Nov 2017 00:50:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4C9BF160086; Wed, 1 Nov 2017 00:50:17 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J1lH2fMeWElv; Wed, 1 Nov 2017 00:50:17 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 02343160064; Wed, 1 Nov 2017 00:50:17 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0A2E38DCF888; Wed, 1 Nov 2017 11:50:14 +1100 (AEDT)
To: Moritz Muller <moritz.muller@sidn.nl>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>
In-reply-to: Your message of "Tue, 31 Oct 2017 09:39:23 -0000." <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>
Date: Wed, 01 Nov 2017 11:50:13 +1100
Message-Id: <20171101005014.0A2E38DCF888@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ur-Lh4OH3UlYpzWTd9SlBM1gTok>
Subject: Re: [DNSOP] Resolver behaviour with multiple trust anchors
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Nov 2017 00:50:21 -0000

In message <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>;, Moritz Muller writes
:
>
> Hi,
>
> Together with my colleagues I have been stumbling upon a, for me, unclear
> case when validating trust anchors.
>
> Assuming that a resolver has enabled DNSSEC validation and has the root
> keys configured.
> Additionally, it has configured manually a trust anchor for a TLD (that
> has also published its DS in the root zone).
> Now, for example due to a key rollover at the TLD, the manually
> configured trust anchor of the TLD does not match the DS in the root
> anymore.
>
> How should a resolver treat the signatures of this TLD?
> The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures
> of the TLD as bogus, but we didn't find any specifics in RFC 4034 and
> 4035 that describe how resolvers should behave in this case.
> Knot resolver treats them as NOERROR (according to the developers).
> If we interpret section 4.3 of RFC 4035 then we would have assumed that
> the signature must be treated as secure.
>
> Did we miss something, or is there indeed clarification needed?
>
> — Moritz

Firstly the TLD has mismanged the key rollover if this is the case
assuming that it was expecting TA to be installed for it.  It not
the operator of the validator is in error.

Secondly doing deepest match on trust anchors is the only secure
way to prevent a parent overriding the child zone's security policy.

Thirdly if you are doing split DNS and you want to enforce that you
only get answers from a particular view you can use DNSSEC to reject
leaked answers.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org