Deprecating DNSSEC algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1)
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.
On Thu, 2020-01-09 at 20:19 -0500, Viktor Dukhovni wrote:
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.
Your zone is now bogus.
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.
You are missing:
C. Each algorithm for which a DNSKEY exists, must sign all the records in the zone.
Because of caching, step 1 potentially breaks this invariant.
https://tools.ietf.org/html/rfc6781#section-4.1.4 explains this at length (with better wording than I used), and appears to get it right.
Kind regards,
On Fri, Mar 06, 2020 at 05:33:42PM +0100, Peter van Dijk wrote:
On Thu, 2020-01-09 at 20:19 -0500, Viktor Dukhovni wrote:
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.Your zone is now bogus.
No it is not. The zone is signed with two ZSKs, one for each algorithm. The idea is sign the zone *at the same time* as the ZSK is introduced, not add the ZSK and sign later.
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.You are missing:
C. Each algorithm for which a DNSKEY exists, must sign all the records in the zone.
And the invariant holds, because it is signed with ZSKs for both algorithms.
Because of caching, step 1 potentially breaks this invariant.
https://tools.ietf.org/html/rfc6781#section-4.1.4 explains this at length (with better wording than I used), and appears to get it right.
Viktor Dukhovni ietf-dane@dukhovni.org writes:
On Fri, Mar 06, 2020 at 05:33:42PM +0100, Peter van Dijk wrote:
C. Each algorithm for which a DNSKEY exists, must sign all the records in the zone.
And the invariant holds, because it is signed with ZSKs for both algorithms.
Because of caching, step 1 potentially breaks this invariant.
https://tools.ietf.org/html/rfc6781#section-4.1.4 explains this at length (with better wording than I used), and appears to get it right.
You didn't really address Peter's concern. Any cached RRSIG with remaining TTL higher than a cached DNSKEY will be invalid after the cached DNSKEY expires if you add a new ZSK algorithm without first adding the signatures..
You need to add the signatures first, wait until old sigs are expired, and then add the new ZSK.
Looking at an example: My local resolver is going to keep the www.ietf.org RRSIG cached for 589 seconds after the ietf.org DNSKEY expires. If ietf.org were to add a ZSK with a new algorithm now, then www.ietf.org will be considered invalid for those 589 seconds until the cache picks up the new signature:
bjorn@miraculix:~$ dig dnskey ietf.org +dnssec +multiline; dig www.ietf.org +dnssec +multiline
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> dnskey ietf.org +dnssec +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25914 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 00d41f1eaa6c1e2b0d935c335e637697980f4266912fe3c1 (good) ;; QUESTION SECTION: ;ietf.org. IN DNSKEY
;; ANSWER SECTION: ietf.org. 589 IN DNSKEY 257 3 5 ( AwEAAavjQ1H6pE8FV8LGP0wQBFVL0EM9BRfqxz9p/sZ+ 8AByqyFHLdZcHoOGF7CgB5OKYMvGOgysuYQloPlwbq7W s5WywbutbXyG24lMWy4jijlJUsaFrS5EvUu4ydmuRc/T GnEXnN1XQkO+waIT4cLtrmcWjoY8Oqud6lDaJdj1cKr2 nX1NrmMRowIu3DIVtGbQJmzpukpDVZaYMMAm8M5vz4U2 vRCVETLgDoQ7rhsiD127J8gVExjO8B0113jCajbFRcMt UtFTjH4z7jXP2ZzDcXsgpe4LYFuenFQAcRBRlE6oaykH R7rlPqqmw58nIELJUFoMcb/BdRLgbyTeurFlnxs= ) ; KSK; alg = RSASHA1 ; key id = 45586 ietf.org. 589 IN DNSKEY 256 3 5 ( AwEAAdDECajHaTjfSoNTY58WcBah1BxPKVIHBz4IfLjf qMvium4lgKtKZLe97DgJ5/NQrNEGGQmr6fKvUj67cfrZ UojZ2cGRizVhgkOqZ9scaTVXNuXLM5Tw7VWOVIceeXAu uH2mPIiEV6MhJYUsW6dvmNsJ4XwCgNgroAmXhoMEiWEj BB+wjYZQ5GtZHBFKVXACSWTiCtddHcueOeSVPi5WH94V lubhHfiytNPZLrObhUCHT6k0tNE6phLoHnXWU+6vpsYp z6GhMw/R9BFxW5PdPFIWBgoWk2/XFVRSKG9Lr61b2z1R 126xeUwvw46RVy3hanV3vNO7LM5HniqaYclBbhk= ) ; ZSK; alg = RSASHA1 ; key id = 40452 ietf.org. 589 IN RRSIG DNSKEY 5 2 1800 ( 20210127000407 20200127230611 40452 ietf.org. wiauz1dcDs1GctjHvWCw5Xxt61nTZhG7fjx5/+mC/uaL 3GKYwjS7cyBYl/YcXuufSAWFQLBy7BXFIkIxbXyKkCCo uKogFWhoEilYZhUu/GxEppCK1Y7hvokM0i9enBlu7UDQ GvJ9m9buJaKGtcKkiOAOTJB2djeyEexlgOpsQFst1TtM DX6C7pdCjeaqTbFQrzq0LIBjthLJEzMWO4jNTr7bNcpi 8+nFDWV1MogDDP9cm8H89vMf4bUfqSvkskq2ouLNGwJ+ 6gyDqUWu3KR8FvOhOWpq040/6ZWXMAduq5JDbt80oNdD 1xjwkhCQDI28fVj0v96MaQTWwR4Brj6p4Q== ) ietf.org. 589 IN RRSIG DNSKEY 5 2 1800 ( 20210127000433 20200127230611 45586 ietf.org. NRattAGqWXC55uwxwK+iCZhIj81/ljephfA+Hx57jEES N2tCI4ZCldvOOtCojtkKnFchSsNoEfkuYpJtoAENlKat jxBFYmAJJESqoV/X+jh5Y0j45787hF9TMc51//a6qjSl PA3QJLZ2kReVgBRsBDQ9MroWaAWYKnsZOGKIKyg6Rxha ADS/ATg/3kq2XZJuKRXHKx2sdCvqhMpuejgdqr/+SU2K LUdPWrtvLmWRAP73MRIsBy52/rqR4iKkXhRLa6hPkovn hikLibD6wijh53T0Oyqsj0mlpUEQSI6uV5b/9hp0TXpl QhYCiDSuH1cu5fe/pgLvRpxkIEzof58vow== )
;; Query time: 28 msec ;; SERVER: 148.122.16.253#53(148.122.16.253) ;; WHEN: Sat Mar 07 11:25:27 CET 2020 ;; MSG SIZE rcvd: 1209
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> www.ietf.org +dnssec +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11102 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 4ff4c9a2b04e7362cc9958945e6376979d3ae21152d8ec4d (good) ;; QUESTION SECTION: ;www.ietf.org. IN A
;; ANSWER SECTION: www.ietf.org. 1175 IN CNAME www.ietf.org.cdn.cloudflare.net. www.ietf.org. 1175 IN RRSIG CNAME 5 3 1800 ( 20210127000323 20200127230611 40452 ietf.org. fX/FCVGya8pIk/2cMDWu3+iNKyWd0GLK4g6wtwp8v7rj p+nynpRm1jOanP20p36Dod4qj0IdoMGu3PN2756QZW7L zQ6nS+x7Re37Q52BP89ADXZ5J5tLlcaRl0MEyoj6/Cyv 6cW+GH8sK0PwYmE11mVzezI3ZrADWvTCmgNxEpxHxoF0 jlpJ0+JVt9gP2bbHWg0uF2yspTwspaoCSRcaO6KFKnkk QXI2PFhgk0w/Od4NXe86V64U1WtMGcqNyGOe0zcq4HPm iiW+lvZab6QuZJ8kq/A5HrDw66MzuRK5S2PJFjoF7lna 9OIru9JXT+FcHmozUpI9lwLJIwI5IRt11g== ) www.ietf.org.cdn.cloudflare.net. 300 IN A 104.20.0.85 www.ietf.org.cdn.cloudflare.net. 300 IN A 104.20.1.85 www.ietf.org.cdn.cloudflare.net. 300 IN RRSIG A 13 6 300 ( 20200308112527 20200306092527 34505 cloudflare.net. gEbu+OUEYzpr2m4Tsvukhpxyyy0ypEW1esxKg/q3qVQW nfeGk7PTcH2oqcplMI+d/9cMQPJW7v0m+/dHXq97FA== )
;; Query time: 31 msec ;; SERVER: 148.122.16.253#53(148.122.16.253) ;; WHEN: Sat Mar 07 11:25:27 CET 2020 ;; MSG SIZE rcvd: 552
Bjørn
Le 10/01/2020 à 02:19, Viktor Dukhovni a écrit :
If/when you do decide to switch algorithms, please perform the migration with care. Algorithm rollovers can be tricky.
Hello,
Anyone using rollerd? I'd like to upgrade my algorithms and let rollerd do the whole rollover job for me, just by specifying that I'd like a specific alg to be used on the next shift, but I'm not sure how to do this.
Thanks!
On Sun, Apr 05, 2020 at 03:34:16PM +0200, Hoggins! wrote:
Le 10/01/2020 à 02:19, Viktor Dukhovni a écrit :
If/when you do decide to switch algorithms, please perform the migration with care. Algorithm rollovers can be tricky.
Anyone using rollerd? I'd like to upgrade my algorithms and let rollerd do the whole rollover job for me, just by specifying that I'd like a specific alg to be used on the next shift, but I'm not sure how to do this.
I have never heard of rollerd, but you might do better on a DNS list, rather than the dane-users list. Perhaps someone on the dns-operations list can help.
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Viktor Dukhovni writes:
On Sun, Apr 05, 2020 at 03:34:16PM +0200, Hoggins! wrote:
Le 10/01/2020 à 02:19, Viktor Dukhovni a écrit :
If/when you do decide to switch algorithms, please perform the migration with care. Algorithm rollovers can be tricky.
Anyone using rollerd? I'd like to upgrade my algorithms and let rollerd do the whole rollover job for me, just by specifying that I'd like a specific alg to be used on the next shift, but I'm not sure how to do this.
I have never heard of rollerd, but you might do better on a DNS list, rather than the dane-users list. Perhaps someone on the dns-operations list can help.
It is ancient and from the time before bind had key maintenance buikd in. And I don't think it will do an alogorithm rollover. See the man page (as in https://linux.die.net/man/1/rollerd).
jaap
Le 05/04/2020 à 21:03, Viktor Dukhovni a écrit :
I have never heard of rollerd, but you might do better on a DNS list, rather than the dane-users list. Perhaps someone on the dns-operations list can help.
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Thanks Viktor!
Agreed this ML is probably not made for that. I'll look on that side of course, but even if it's off-topic, I'm open for suggestions on what tools you folks use for automated keys rollover.
Hoggins!
On Apr 6, 2020, at 4:45 AM, Hoggins! fuckspam@wheres5.com wrote:
Agreed this ML is probably not made for that. I'll look on that side of course, but even if it's off-topic, I'm open for suggestions on what tools you folks use for automated keys rollover.
I've not looked too closely yet, but BIND 9.16 automates many aspects of DNS key management, beyond the automatic zone signing available in earlier versions.
Take a close look at BIND 9.16 documentation, try it out, and share your impressions...
participants (5)
-
Bjørn Mork -
Hoggins! -
Jaap Akkerhuis -
Peter van Dijk -
Viktor Dukhovni