Re: [DNSOP] Resolver behaviour with multiple trust anchors

Patrik Wallstrom <pawal@blipp.com> Wed, 01 November 2017 12:17 UTC

Return-Path: <pawal@blipp.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 D534313F63A for <dnsop@ietfa.amsl.com>; Wed, 1 Nov 2017 05:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, 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 3WR0So-Gii1a for <dnsop@ietfa.amsl.com>; Wed, 1 Nov 2017 05:17:35 -0700 (PDT)
Received: from vic20.blipp.com (vic20.blipp.com [192.195.142.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB8E13F45D for <dnsop@ietf.org>; Wed, 1 Nov 2017 05:17:35 -0700 (PDT)
Received: by vic20.blipp.com (Postfix, from userid 1000) id 161A93821C; Wed, 1 Nov 2017 13:17:31 +0100 (CET)
Date: Wed, 1 Nov 2017 13:17:31 +0100
From: Patrik Wallstrom <pawal@blipp.com>
To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= <olafur@cloudflare.com>
Cc: Moritz Muller <moritz.muller@sidn.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20171101121730.esajuad5cefebtgg@vic20.blipp.com>
Mail-Followup-To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= <olafur@cloudflare.com>, Moritz Muller <moritz.muller@sidn.nl>, "dnsop@ietf.org" <dnsop@ietf.org>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl> <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/H0Q0yExLhKp4drzUhQ5GIUwb2LA>
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 12:17:38 -0000

If I remember the discussions correctly, there was a sense that the
resolver decides the local policy. And that yes, those are the three
options. Perhaps the options should be made more clear in a text somewhere.

On Tue, 31 Oct 2017, Ólafur Guðmundsson wrote:

>There are three ways to treat this case:
>Any-TruestedKey-works
>ConfiguredKey-trumps-DS
>DS-trumps-configuredKey
>
>I think the Last one is the "most" correct from an operational expectation,
>but the first one is least likely to run into errors,
>But I suspect the middle one is implemented
>
>Olafur
>
>
>On Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller <moritz.muller@sidn.nl>;
>wrote:
>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>

>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop