[FR] Smart deprecation of SHA-1 signatures

[pemensik]

Current behavior

Is there a current behavior that the feature relates to?

Yes, DNSSEC verifies names signed by algorithm 5 or 7 by default. It is possible to disable validation on build-time for all names. Our engineers prepared system-wide policy, which attempts to enforce RFC 9155 and refuse SHA-1 as valid signature algorithm. Sure, it clashes with RFC 8624, which in turn requires RSASHA-1 to be enabled. Our crypto team made change to OpenSSL policy, which refuses RSASHA-1 signatures verification by default. That would break any RSASHA-1 domains resolution.

Current possible mode is to always disable SHA-1 at build time or leave it enabled. But this behaviour depends on runtime changes to the system.

If yes, would you wish the current behavior to change?

It seems current way is to check algorithm support before validation starts. In our case, it would be better to leave algorithm support check on OpenSSL library. Problem is there does not seems to be any public API, where it may indicate before validation that RSASHA-1 is not available in runtime.

Describe the desired feature
I would like unbound to be able to fall back from secure handling of signature in verify_canonrrset function to insecure record, if EVP_VerifyFinal() returns code indicating used digest function is not acceptable. I would like possiblity to make the record insecure, without ad flag. But avoid SERVFAIL status code and provide result just like the record were not signed at all. It seems some EVP error codes might indicate there is nothing wrong with signature itself, but it is not available due to policy. There seems no alternative

Potential use-case
RHEL9 and CentOS Stream 9 will make EVP_VerifyFinal() fail in crypto-policy DEFAULT mode. But if its mode is changed runtime by administrator to DEFAULT:SHA1, it makes EVP_VerifyFinal() pass even on RSASHA-1 signatures. I would like single binary build to handle both modes.

• if SHA1 is disabled, produce INSECURE results without ad bit
• if SHA1 is enabled, produce SECURE results with ad bit set
• avoid SERVFAIL status if verification failure is related to system-wide policy, not wrong hash or bad key

[pemensik]

It will fail EVP_DigestVerifyInit() on unbound, when used key is SHA-1 algorithm.