2020-02-14 - News - Tony Finch
This is a follow-up to my article last month about SHA-1 chosen-prefix collisions and DNSSEC.
Summary
DNSSEC validators should continue to treat SHA-1 signatures as secure until DNSSEC signers have had enough time to perform algorithm rollovers and eliminate SHA-1 from the vast majority of signed zones.
- Deprecating SHA-1 in DNSSEC
- What breaks without DNSSEC
- Risks of relying on SHA-1 in DNSSEC
- SHA-1 and DNSSEC validation
Deprecating SHA-1 in DNSSEC
At the time of writing, the root zone has 1517 TLDs, of which 1376 are signed (91%). 141 (9%) are insecure and 274 (18%) use SHA-1. Two out of the five regional Internet registries use SHA-1 for their reverse DNS zones.
In an ideal world, everyone should have paid attention to the reasons that the root zone chose SHA-256 rather than SHA-1 when it was signed 10 years ago. In the second-best world, everyone should have paid attention to the first real demonstration of a collision attack on SHA-1 five years ago.
Despite many very clear recommendations (from NIST, from 5 years of practical SHA-1 attacks), we have been slow to eliminate SHA-1 from DNSSEC. I hope these articles will help to get rid of it faster.
What breaks without DNSSEC
Some applications that use DNSSEC will stop working if DNSSEC validation is disabled; some will quiely become insecure.
In my movie-plot attack scenario I said the attacker's target was using CAA records to protect against unauthorised X.509 certificates. The CA/Browser forum baseline requirements say that CAs must do DNSSEC validation for CAA lookups, so our victim's defence should have been solid. This CAA + DNSSEC defence was supposed to restrict what CAs and ACME accounts can request certificates. Without that restriction, ACME is vulnerable to interception attacks.
There is a similarly quiet fall-back to insecure behaviour for DANE TLSA authentication of mail servers if DNSSEC validation is disabled.
The breakage is more obvious for ssh. If a site is relying on SSHFP records in the DNS for authenticating servers, common ssh implementations will not cache server key fingerprints in the way they do for traditional trust-on-first-use ssh connections. If DNSSEC stops validating SSHFP records then ssh connections will stop working, and instead prompt a human to authenticate server key fingerprints (for interactive uses) or generate cronspam.
Risks of relying on SHA-1 in DNSSEC
At the moment, the cost and difficulty of a SHA-1 collision attack is large, even in a lab setup with expert cryptographers. The practicalities of applying an attack in the real world make it even more challenging: predicting the RRSIG timing parameters, scheduling a DNS update to sub-second accuracy, having a spare supercomputer available at the right time, ...
Although this is much less than cryptographic levels of security, it is still hard to find a payoff that would make an attack worthwhile: there is a lot of lower-hanging fruit. For instance, in my movie-plot scenario I set things up so that it made more sense to attack DNSSEC than plaintext HTTP by assuming that CAA validationmethods and accounturi records are published and checked. But that draft spec has not yet been deployed, so ACME is a softer target than DNSSEC.
SHA-1 and DNSSEC validation
There are still a lot of sites that depend on DNSSEC SHA-1 algorithms. Things will break if SHA-1 validation is abruptly disabled. SHA-1 is not yet so easily cracked that it is useful to attackers.
My recommendation is that DNSSEC validators should continue to treat SHA-1 as secure from the protocol point of view. They should continue to reject responses that fail to validate as expected, and they should set the "AD" authenticated data bit in responses that do validate.
DNSSEC signers need to stop using SHA-1 as soon as they can. At the moment signers (those 18% of TLDs, those 40% of RIRs, those however-many subdomains) are responsible for the deprecation schedule. They should be encouraged by friendly help and advocacy to plan and implement their algorithm rollovers.
Disabling SHA-1 validation at this point in time is not friendly or helpful. We should plan to deprecate it after the number of zones signed with SHA-1 has fallen to a small enough level.