[dns-operations] Stale NTA for "peek.ru" at Cloudflare?

[Viktor Dukhovni]

On Fri, Mar 13, 2020 at 06:01:52PM -0400, Viktor Dukhovni wrote:

> That said the "MUST NOT" validate algorithms from that table have the
> following frequencies in the wild based on my (unavoidably incomplete)
> survey of ~10.8 million signed domains:
> 
>     dane=> select count(distinct qname), alg from ds where alg in (1,3,6) group by 2 order by 1 desc;
>      count | alg
>     -------+-----
>        288 |   1
>        234 |   3
>         40 |   6
> 
> So the scope of the problem is admittedly rather modest, affecting fewer
> than 600 of the ~10.8 million domains.

After upgrading my system to unbound 1.10.0, I see the same response
from the local unbound server as from Cloudflare:

    $ hsdig -CD -t tlsa _25._tcp.beta.peek.ru
    _25._tcp.beta.peek.ru. IN CNAME _tlsa.peek.ru. ; NoError AD=0
    _tlsa.peek.ru. IN TLSA 3 0 1 ef3d63aa7b10d1f060d43d30b356f19a38fddb36542ab188da787524be265a24 ; NoError AD=0
    _tlsa.peek.ru. IN TLSA 3 0 1 925758b9aed10aa43ad72b5cd170eee4744d56cda9e3d970df2769e3085b083d ; NoError AD=0

So perhaps this is to be expected given that DSA-NSEC3-SHA1 went from
"optional" in:

    https://tools.ietf.org/html/rfc6944#section-2.3

to "MUST NOT" for both signing and validation in 

    https://tools.ietf.org/html/rfc8624#section-3.1

In future RFCs deprecating algorithms (e.g. soon I hope RSASHA1 5 and
RSASHA1-NSEC3-SHA1 7) we should perhaps aim to first specify "MUST NOT"
for signing, and only some time (years) later "MUST NOT" for validation.

Which I think ideally means updating "8624" *this year* with a "MUST NOT"
for signing for 5 and 7, with a view to "MUST NOT" also for validation
no earlier than 2022.

-- 
    Viktor.