== Summary == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41.
Validating DNS resolvers are still required to be able to validate signatures made with SHA-1. RFC 8624 is still current as far as I can tell:
https://www.rfc-editor.org/rfc/rfc8624#section-3.1 https://www.rfc-editor.org/rfc/rfc8624#section-3.3
There have been reports of SHA-1 disablement causing name resolution problems. Here's one example:
https://lists.isc.org/pipermail/bind-users/2023-December/108182.html
Here's a crappy program that can show some statistics but won't let me link directly to the relevant table:
https://stats.dnssec-tools.org/
It shows about 140000 SHA-1-signed domains. That's only 6‰ of the signed domains, but still a rather large absolute number.
Before voting on this proposal, Fesco should be informed of what will happen in Bind, Unbound and SystemD-ResolveD when users try to look up a domain that is signed with SHA-1.
Will SHA-1 signatures be treated as invalid signatures, causing the resolver to return SERVFAIL? That will violate RFC 8624 and make users scramble for quick workarounds. Many will apply far too big hammers, such as disabling DNSsec validation entirely or switching their whole system to the LEGACY policy just to be able to resolve a domain name signed with SHA-1. In this case it should be announced far and wide how users can unbreak DNS without weakening the security of the rest of their system. Otherwise this change could easily do more harm than good.
Will DNSsec validation be skipped whenever an algorithm number for SHA-1 is encountered? That will make the resolver vulnerable to downgrade attacks. An attacker can then disable DNSsec by sending manipulated responses indicating for example RSA/SHA-1 for records that are actually signed with RSA/SHA-256.
If that were implemented relatively well, it might only introduce a vulnerability when a domain is signed both with SHA-1 and a stronger algorithm. If implemented badly, it could allow DNS cache poisoning to succeed even for domains signed only with strong algorithms. Here's a paper that discusses such vulnerabilities found in popular resolvers:
https://arxiv.org/pdf/2205.10608v1.pdf
It seems to me that the following would be the best way to distrust SHA-1 in DNSsec:
1: If a valid chain of trust can be established where strong algorithms are used throughout, then return the records to the client with the AD bit set, per the standard, indicating that the data are authentic.
2: If there should be signatures, but no valid chain of trust can be established because records are missing or signatures fail to verify, then assume it's an attack and return SERVFAIL per the standard.
3: If one or more valid chains of trust are found, but they all involve SHA-1 somewhere, then return the records to the client with the AD bit zeroed, indicating that no attack was detected but the data should not be trusted any more than an unsigned domain.
To be able to distinguish between cases 2 and 3, the resolver must remain able to verify SHA-1 signatures.
Björn Persson