> == 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.