Peter et al -
It might be useful to review RFC 4986 -
https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to
DNS Security Trust Anchor Rollover - to understand what the problem
requirements were/are before resurrecting this discussion again. If
the requirements have changed, then perhaps we need a new solution, but
we should probably update 4986 before tossing 5011.
Peter -
WRT to your analogy to the CA system, I will note that browser clients
(where the trust anchors are embedded for the CA) are not even close to
being updated in the same manner as recursive resolvers (not simply "DNS
clients") and many resolvers are used to provide services within various
small and large organizations rather than being owned and updated by a
single person. For one thing, there are orders of magnitude more
browers than there are resolvers. For another, resolvers are rarely
updated automatically. What would be interesting is to get some idea
of the set of resolvers with no active management being performed on
them - including software updates.
Mike
On 6/30/2021 2:59 PM, Peter van Dijk wrote:
Hello DNSOP,
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 see this ruffled some feathers. Here's a more nuanced version.
I feel that 5011, for the purpose of root key rollovers, is the wrong tool,
-especially- combined with the trust anchor signaling that various resolver
stacks sent to the root. Lack of clarity about where various signals came from,
combined with some interesting bugs in implementations, has led to a lot of
wild goose chases, and it would not surprise me (but I cannot prove) that bad
data is what delayed the first roll for so long. Not actual problems predicted
by the data; just bad data. (I have mentioned before that I think the trust
anchor signalling was a mistake too, and any calls for 'more of this' are
'calls for more bad data' and we do not need more bad data.)
I feel that the right mechanism for root key distribution is software
distributors. This is working fine for the CA system, and with keys announced
far enough in advance, should work fine for DNSSEC. Software distributors have
solved this problem; they are very good at distributing things; I suggest we
let them solve this for us.
rfc5011-security-considerations is a good document, and I apologise for
targeting it unfairly - my problem with 5011 is as above. Given my next two
point, it probably makes sense to publish rfc5011-security-considerations.
With heaps of 5011 'client' implementations out there, I am in no way proposing
that root rolls happen in a way that that software could not follow along. I am
only proposing that we write down that 5011 is not the best fit for the
problem, and recommend against more client implementations of it *for the
purpose of root key rolls*.
I think (can't find it right now) that somebody mentioned that 5011 has its
place outside of the root key system, inside enterprises. I'm inclined to
disagree, but do not feel entirely capable of judging that. If (again, when
there's WG bandwidth) we draft a document about why 5011 is a bad fit for the
root, perhaps somebody can contribute text about the level-of-fit for other use
cases.
Kind regards,
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
