IETF Logo Mail Archive

Re: [DNSOP] Resolver behaviour with multiple trust anchors

Ólafur Guðmundsson <olafur@cloudflare.com> Tue, 31 October 2017 18:25 UTC

Return-Path: <olafur@cloudflare.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 C17CB13FA3C for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 11:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 JSe7W7WxrenJ for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 11:25:37 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9563713F85B for <dnsop@ietf.org>; Tue, 31 Oct 2017 11:25:37 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id g90so16796401wrd.6 for <dnsop@ietf.org>; Tue, 31 Oct 2017 11:25:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XzN6O8ZvnBmeo5G3vBZABMipBm5h/dKRPm6D0KQHXWQ=; b=TZtcW6kXAMuGuWMHzf7x54yLjjjyjv09CA0pepaZM/cgT+7N9f/PbkPhKH/VvjTykJ HkfJQrLq3j54cgc8HRXDw7hUGHMRGrhmpgUsNHuPpf90OcLnkCFw3g/PQVfbG7De9YIN rDYfp14dOVXlVKUXQ0EKI0DZGYWfRsBa/ORV4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XzN6O8ZvnBmeo5G3vBZABMipBm5h/dKRPm6D0KQHXWQ=; b=L82stE9moX0EjHb2EQEj/wJ+vHm4jXcCxLxw+J9BdxigAXrhLpPyZQCUZpJg/Px8pz b752KHWFr1yYVQidmjPDQRqxKBV9M91CiHYxFK/+/Cq/TNhIyBTbh0hykDoLI9mB4mwW /XmA1EIknwM7fYtTR3EHXH4svjFE/zLcQ7lU2iR4KRGMGeMDHbPlmPglM8DlZpnyBFlu XgpGBvPGq28Ddz2dYazrZpytAZqLohp2oj+A7aoGUC2eDsrjiIpLA6YYyaCYpCoM04RO LiYTauRf3ZGGxoFFPxR9+Ojm6Ynwd3yJL15eycZme9Yuoj2Z2KkVjVQ9tzOg1DPe3Doe sVOw==
X-Gm-Message-State: AMCzsaWEf6BRQUR0EJEi8n+7ni0FlrdYKOEI7fmtLOZjdfMywyseEj96 z/VCamDzp9z/O0+262HS2lQgtqANutUjd31TmOc8oQ==
X-Google-Smtp-Source: ABhQp+S81ECpvbaAPpSRX+5Xp4rWfdGKy81K1S4i08sX8TdPnOOVAWfg0/RqlwtqhicR3ZBnN0eALKYDujCQq1X6Wuw=
X-Received: by 10.223.135.90 with SMTP id 26mr2547258wrz.114.1509474335878; Tue, 31 Oct 2017 11:25:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.201.10 with HTTP; Tue, 31 Oct 2017 11:25:35 -0700 (PDT)
In-Reply-To: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>
References: <121CDBC2-D68C-48EE-A56E-46C61FC21538@sidn.nl>
From: Ólafur Guðmundsson <olafur@cloudflare.com>
Date: Tue, 31 Oct 2017 11:25:35 -0700
Message-ID: <CAN6NTqxy4SWxsUNZyBA=1TZxdhWtVxaTDYLoA1qO2nKf202g9w@mail.gmail.com>
To: Moritz Muller <moritz.muller@sidn.nl>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146a3ec9682d7055cdbe170"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iTicaoOgG8FsqO3xaIk2vm9jlDE>
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:25:40 -0000

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
>
>

v2.23.0 | Report a Bug | By Email