Dear Björn,
On Sun, Jun 9, 2024 at 12:39 AM Björn Persson <Bjorn@rombobjörn.se> wrote:
== 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.
I don't think that 140000 of something world-wide (22 mln of DNSSec signed domains) should be considered a large amount.
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.
I agree that the maintainers of the DNSSec software have to consider the behavior of their software. But it doesn't mean that SHA1 for crypto purposes is of any security.
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 an attacker can manipulate DNSSec so easily, it means it's completely broken.
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.
Looks reasonable to me.