Re: [DNSOP] Resolver behaviour with multiple trust anchors

"Paul Hoffman" <paul.hoffman@vpnc.org> Tue, 31 October 2017 20:51 UTC

Return-Path: <paul.hoffman@vpnc.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 5A57B139A2F for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 13:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Z86CC7NRGJl5 for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 13:51:45 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 55C8913F574 for <dnsop@ietf.org>; Tue, 31 Oct 2017 13:51:45 -0700 (PDT)
Received: from [169.254.101.35] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v9VKoK4u060765 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <dnsop@ietf.org>; Tue, 31 Oct 2017 13:50:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.101.35]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: dnsop@ietf.org
Date: Tue, 31 Oct 2017 13:51:42 -0700
Message-ID: <148C88F0-FEED-4759-8026-F3FB95B44252@vpnc.org>
In-Reply-To: <d85db292-47fa-f146-a908-add09a8f6bdc@nthpermutation.com>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <d85db292-47fa-f146-a908-add09a8f6bdc@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.7r5425)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5f2Tf4P1l3V19Ryz8hfXnZpDcqg>
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 20:51:46 -0000

On 31 Oct 2017, at 12:23, Michael StJohns wrote:

> But sadly - the language in RFC6840 section 5.10 is controlling... 
> basically, any implementation can do whatever it wants.
>
>> A DNSSEC validator may be configured such that, for a given response,
>> more than one trust anchor could be used to validate the chain of
>> trust to the response zone. For example, imagine a validator
>> configured with trust anchors for "example." and "zone.example."
>> When the validator is asked to validate a response to
>> "www.sub.zone.example.", either trust anchor could apply.
>
>> When presented with this situation, DNSSEC validators have a choice
>> of which trust anchor(s) to use. Which to use is a matter of
>> implementation choice. Appendix C discusses several possible
>> algorithms.

And the two paragraphs that follow those give more guidance:

    It is possible and advisable to expose the choice of policy as a
    configuration option.  As a default, it is suggested that validators
    implement the "Accept Any Success" policy described in Appendix C.2
    while exposing other policies as configuration options.

    The "Accept Any Success" policy is to try all applicable trust
    anchors until one gives a validation result of Secure, in which case
    the final validation result is Secure.  If and only if all 
applicable
    trust anchors give a result of Insecure, the final validation result
    is Insecure.  If one or more trust anchors lead to a Bogus result 
and
    there is no Secure result, then the final validation result is 
Bogus.

> And once again we see the folly of the words "implementation choice" 
> when trying to come up with a coherent DNS.

The full quote makes the situation murkier: it is a combination of 
implementation choice plus configuration options. Some folks on this 
list strongly prefer that, others strongly don't.

--Paul Hoffman