Re: [DNSOP] Resolver behaviour with multiple trust anchors

Philip Homburg <pch-dnsop-2@u-1.phicoh.com> Tue, 31 October 2017 18:24 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
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 D00B013F5AE for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 11:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 qsqO7F5uEpS4 for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 11:24:19 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 C558313F502 for <dnsop@ietf.org>; Tue, 31 Oct 2017 11:24:18 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1e9bCx-0000EpC; Tue, 31 Oct 2017 19:24:15 +0100
Message-Id: <m1e9bCx-0000EpC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Paul Hoffman <paul.hoffman@vpnc.org>
From: Philip Homburg <pch-dnsop-2@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <897E0B21-1A78-45F5-95CF-B87FD36524FC@vpnc.org>
In-reply-to: Your message of "Tue, 31 Oct 2017 07:42:32 -0700 ." <897E0B21-1A78-45F5-95CF-B87FD36524FC@vpnc.org>
Date: Tue, 31 Oct 2017 19:24:14 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2y-zlUJ0-vBjBvM19Rx2s5Sj7V8>
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: Tue, 31 Oct 2017 18:24:21 -0000

>It sounds like clarification is needed if even one (much less three) 
>systems treat such a signature as Bogus. My reading of RFC 4035 is that 
>any chain that successfully leads to a trust anchor should return 
>Secure, even if a different chain returns Bogus.

If extra trust anchors are configured for security reasons (as opposed to
availability) then I would expect some sort of longest match on the
trust anchor that is to be used.

For example, if I configure a trust anchor for example.com for security
reasons, then that is probably because I don't fully trust the .com zone
or even the root zone.

If then a record fails to validate using the trust anchor that is configured
for example.com, then it would be very bad if the resolver turns around and
suddenly trusts the information from the .com zone.