Re: [DNSOP] IETF meeting prep and what

[Joe Abley <[e-mail]>]

On 23 Jun 2021, at 12:28, Vladimír Čunát <[e-mail]> 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.


Joe