Use OPENSSL_CONF environment to point to conf file containing:
.include = /etc/ssl/openssl.cnf [evp_properties] rh-allow-sha1-signatures = yesThat is all needed to get SHA1 verification in DNSSEC back, without accepting SHA1 in TLS connections at the same time. Cool, eh?
I think it is quite okay to have SHA1 recognized on similar level as DNS cookies. It helps against cache poisoning, but is not reliable against attacker with significant resources (government agencies?). That is why I think setting AD for it should not be done, but it should be used as relative good source indication.
I don't know about any implementation we support, which would be able to report this. It is just full trust or nothing.
I am missing a good call indicating from the crypto library, that given key type and digest algorithm for signature is not considered strong enough. Our crypto team is not very supportive with this, not a priority for them. They are not DNSSEC fans anyway. Until we have a good way to get DS record trust level from crypto library, we can use just make strange hacks around.
If you can influence openssl upstream, please try. It is a common problem for (almost?) all open source implementations.
They have made openssl issue #17662 [1] for adding a separate definitions for signing and verification. Which is needed for the lifecycle mentioned, but not yet merged. I would add we need also interface to get that state back from the library, once configured.
More below... 1. https://github.com/openssl/openssl/issues/17662 On 13/11/2024 17:03, Philip Homburg wrote:
No, zone stays where author has it. What might get different is what clients see.Tony Finch has correctly identified in SHA-1 chosen prefix collisions and DNSSEC [3] article that when a single record is usually safe, multiple records might allow creating fake signature even in DNSSEC.There are two types of attacks on hash functions: collisions and second pre-image attacks. There is no practical 2nd pre-image attack for SHA-1, so we can concentrate on collision attacks. A collision attack requires that the victim to accepts malcious data from an attacker There are many, proably even the majority of DNSSEC signed domains, where this is not an issue. Attackers cannot influence the contents of a zone. In those cases, using SHA-1 is secure.
I think that is correct and needed. Consider them similar to DNS cookie verified. Better than nothing yes, strong authentication no. If something expects strong proof, SHA1 should not be trusted for that.DANE expect strong proofs IMO. But first someone needs to implement that.Obviously we need to move away from SHA-1 as fast as possible. But we do those domains a disservice if we treat them as insecure. In particular, DANE will stop working if a domain is considered insecure.
We have it included in RHEL 9.0 Release notes [2] in clear words. It is not our fault documentation is not read, then someone is surprised.We already see the operational impact. People with RedHat systems notice that DANE suddenly stops working. They have no clue where is coming from, they just see that unbound doesn't set the AD bit.
The solution should be that RedHat provides a way to link with a different crypto library that does support RSASHA1.
We should have provided helping configuration. If we had that at hand, we would have.
Hope that helps, Petr[2] https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.0_release_notes/known-issues#known-issue_infrastructure-services
-- Petr Menšík Software Engineer, RHEL Red Hat,https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
