On Wed, 24 Feb 2021, Ben Schwartz wrote:
On Tue, Feb 23, 2021 at 11:05 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote: ... My perspective is that most zone operators will only want to deploy a single algorithm, and improving the rate at which new algorithms are feasible to be adopted should be an explicit goal.I don't think this is realistic. Consider, for example, the deprecation of TLS 1.0 [1] 15 years after it was superseded by TLS 1.1. I see no reason to expect that DNSSEC validator update cycles will be faster.
I think there are two things confused here. Obsoleting an algorithm from a single zone using migration to a newer algorithm, and exorcising an old algorithm from the planet. The first is clearly defined on how it is done. It is also known that if the losing Registrar is uncooperative, things will be a bit wonky during the transfer. That can only be fixed by contractual obligations, not technology.
Given the experience with TLS, I don't think we can reasonably assume that "clients" are on a much faster update cycle.
I don't see the relevance of this at all. The "strict mode" seems to be originating from a believe that having two algorithms in the zone, either briefly during migration, or permanently to satisfy multiple government requirements, is a problem. I have not been convinced there is a problem that this draft would remedy.
I think, at core, there's a philosophical question here. Do we intend for DNSSEC to actually be used for critical security in open systems? If so, it will have to work like TLS: a 1% failure rate will be utterly intolerable, so servers will have to retain support for the 99th percentile of awful ancient clients.
No, because the failure mode of no longer trusting obsoleted DNSSEC algorithms is to treat them as "unsigned". So there is no failure rate of any percentage (other than implementation errors, such as returning ServFail when the system doesn't allow SHA1, instead of marking SHA1 as untrusted and returning data without the AD bit, which has happened recently in fedora with knot for example) Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
