Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1)

[Viktor Dukhovni]

Given the recent advances in SHA-1 collision attacks,

    https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html
    https://sha-mbles.github.io/

it is time to deprecate the remaining DNSSEC SHA-1 based DNSKEY
algorithms.

If you've deployed inbound DANE by publishing signed TLSA records for
your MX hosts, but your underlying DNSSEC deployment uses DNSKEY
algorithms other than 13 (recommended), 8 (popular) or 10 (fine, though
not widely used), then you should migrate your domains to algorithm 13
(preferred) or 8.

This should be done while the attacks are still costly, and have somewhat
limited applicability.  Algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1)
may not be quite dead, but they are significantly wounded.

If/when you do decide to switch algorithms, please perform the migration
with care.  Algorithm rollovers can be tricky.  The basic process is:

    1.  Publish and activate a ZSK for the new algorithm.  Your zone
        should now be double-signed, which each record having two
        RRSIGs.  Don't forget to bump the SOA.

    2.  Wait for at least 2 maximum TTLs after the primary and all
        secondary nameservers have started serving the updated zone.

    3.  Publish and activate a KSK for the new algorithm.  This KSK
        adds a second signature to your zone apex DNSKEY RRset.
        Don't forget to bump the SOA.

    4.  Wait for at least 2 maximum TTLs after the primary and all
        secondary nameservers have started serving the updated zone.

    5.  Arrange for the parent zone to publish DS records matching
        the new KSK in addition to DS RRs matching the KSKs for the
        previous algorithm.

    6.  Wait for at least 2 parent zone TTLs after all nameservers
        for the parent zone have started serving the new DS RRset.

    7.  Request deletion of the DS RRs for the old algorithm.

    8.  Wait for at least 2 parent zone TTLs after all nameservers
        for the parent zone have starting serving the new DS RRset.

    9.  Remove the old KSKs from your DNSKEY RRset after checking
        that the DS RRset with just the new algorithm matches your
        new KSK.

    10. Wait for at least 2 maximum TTLs after the primary and all
        secondary nameservers have started serving the updated zone.

    11. Deactivate the old ZSKs leaving the zone signed only under
        the new ZSKs.

    12. Wait for at least 2 maximum TTLs after the primary and all
        secondary nameservers have started serving the updated zone.

    13. Remove the old ZSKs from your DNSKEY RRset.

The reason for all this is to maintain the followin invariants:

    A. Each algorithm mentioned in the parent zone DS RRset must
       have a matching KSK in the zone's DNSKEY RRset.

    B. Each KSK algorithm appearing in the zone's DNSKEY RRset
       must have a corresponding ZSK signature for each record
       in the zone. 

Therefore, new algorithms are introduced from the ZSK up, while old
algorithms are removed from the DS RRset down.  The various "wait"
steps are needed to ensure that resolvers using cached data are
able to validate your changing zone at all times.

Presently, the DANE survey database shows ~230 thousand domains using
algorithms 5 and 7.  It would be great to see this number substantially
reduced over the coming months.

-- 
    Viktor.