Re: [DNSOP] IETF meeting prep and what

Joe Abley <> Wed, 23 June 2021 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC3553A3E86 for <>; Wed, 23 Jun 2021 10:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s8aNsS21mtTP for <>; Wed, 23 Jun 2021 10:27:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33B133A3E87 for <>; Wed, 23 Jun 2021 10:27:55 -0700 (PDT)
Received: by with SMTP id h10so1844627qvz.2 for <>; Wed, 23 Jun 2021 10:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3DOPr2WELyU0+Ai1Lfx8pOTlICIsK9HxvSS0YkH/fpY=; b=f8/at5a0gl7wefxHnnA+q38LvH/TriidHOm7YvrmFZRZjl4E7hBBZHsXTCi8I8Xakf 3XkaKxS0UpdHP+OCvI4QOs/zj/l/LhF+WlHPnAsC4YwzYPigBEXzx0B8/vrVAKhq5KO/ IDuegsEk4XNhqMpJQstLVwpuBvwM8XsER+n58=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3DOPr2WELyU0+Ai1Lfx8pOTlICIsK9HxvSS0YkH/fpY=; b=JpyPviSXaEwXg5RvcHmbeIbOlnw/zW/qDNOb50pcJheFsVjDluQ50gRK5cbE9N4UAT Y7pe8S9oCXqe3OM9xq2wit49d/V4PQTIefQygmZLk3xWt0St+zLA5pqJ3c5LIsCHPLh7 xRdBLw4dViH6smaMSuJ9qP4muHFZ8q57oGZdm2yxnZIVyH1pVHJIprBJDAIJU+lzOyKr Q9vvZwUVi9aSU4uqgsyb4I7B6pFHYAcjclOR44Mq3tWnrIfPTKfjfIWCL+BAr1IeqzvP SLBFWi1vvJtCXRfIUZMTk+RTd3Kha+K4Xu8a25acT0NTAAJYiCcAQQ50obvy/huDwLSt jhiQ==
X-Gm-Message-State: AOAM531iHRm6Zf9wdurlM12E0C0nf5i1i/hXfT5zKSGWDjnyy0zO/wkt pV0yEnaeYVtiUXRXMV2I0ygu2WaeETxIbnb+Uaw=
X-Google-Smtp-Source: ABdhPJwNCGYOMDbscIXmyZd5ylG0ml00/7p7z7MPwOjnAKFg5jr6AjiupixYKbwJ9q4s7NMkRt9u3Q==
X-Received: by 2002:ad4:4d02:: with SMTP id l2mr892586qvl.59.1624469273494; Wed, 23 Jun 2021 10:27:53 -0700 (PDT)
Received: from ([2607:f2c0:e784:c7:654f:d347:52c9:4d69]) by with ESMTPSA id 6sm366256qtp.47.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jun 2021 10:27:52 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Joe Abley <>
In-Reply-To: <>
Date: Wed, 23 Jun 2021 13:27:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Vladimír Čunát <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [DNSOP] IETF meeting prep and what
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Jun 2021 17:28:00 -0000

On 23 Jun 2021, at 12:28, Vladimír Čunát <> wrote:

> On 18/06/2021 19.40, Peter van Dijk wrote:
>> I propose replacing rfc5011-security-considerations with a short document deprecating 5011 in its entirety. I am happy to write text for that, if there is an appetite - when the WG queue is small enough!
> I agree that 5011 doesn't seem really useful (anymore).
> We have it in Knot Resolver but recommend not to use it, because it's just more trouble than worth in practice.  Notably, (all) resolver software needs much more frequent updates than the rate of root KSK rollovers, so it's easier to distribute root DS within the updates; some Linux distros even package these separately and share them among different resolver packages.  Even if you're conservative and use BIND ESV or similar, I believe it's a better approach than 5011.  For non-root keys there doesn't seem much point nowadays, as getting a chain from root is better.
> (By the way, an "interesting" example: router with DNSSEC validation and factory reset / rollback, commonly shelved for a year, unreliable clock, etc.)

There are a variety of mechanisms available to identify and configure a trust anchor to use in a validator, some automatic and some manual; some rely upon having an existing, functional trust anchor to introduce a new one, some use other trusted paths such as vendor update processes and the web PKI. There are almost certainly mechanisms we don't know about, as well as the variety with which we are familiar.

There are also a variety of scenarios in which trust anchor maintenance is important. Some scenarios involve informed administrators; some involve uninformed users; some involve isolated devices that have no immediate human administrator or user. Some (as you point out) feature long air-gapped periods between configuration and use. We do not have a complete understanding of the breadth of the set of scenarios.

Given that there is such a variety of existing mechanisms and possible use-cases, and considering the profound lack of measurement which could inform us about which mechanisms are being used (or work) and which are not (or don't), I think it's premature to start talking about retiring particular mechanisms either as operational practice or in the sense of deprecation.

As one of the people who spent painful amounts of time trying to contact people by phone and e-mail to find out whether the dirty signals we were worried about during the last (and only!) root zone KSK roll, I can attest that RFC 5011 certainly works well for some people. I think it's fair to say we don't have a good way of quantifying that data point into a more general statement that is stronger than anecdotal. This is not a firm foundation on which to build a plan.