Re: [DNSOP] [Ext] DNSSEC Strict Mode

[Paul Wouters <[e-mail]>]

On Wed, 24 Feb 2021, Ben Schwartz wrote:

> On Tue, Feb 23, 2021 at 11:05 PM Brian Dickson <[e-mail]> 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