On 18. 11. 24 15:37, Paul Wouters wrote:
If the whole talk were about complaining of actually worsening overall security, then using LEGACY should not be proposed to improve that. If you can, use DEFAULT:SHA1. The method with custom OPENSSL_CONF is the most secure way I know, because it still won't allow SHA1 in TLS, but allow it only for generic signature verification, like in DNSSEC.On Sun, 17 Nov 2024, Philip Homburg wrote:[indeed a bit offtopic] Correct, it is now compiled using --disable-sha1. I think it would be better to enable this again, assuming unbound now has proper code to detect if sha1 is failing or not during runtime. Then the crypto-policies can be used to enable this again. If this was a dedicated container/host, it could simply use: update-crypto-policies --set LEGACY
It seems "sha1_in_dnssec" has been obsoleted. I do not know what this was done, I think it was a perfectly fine method to create a crypto policy submodule only enabling sha1 for DNSSEC. Paul
There is no way an user can signal into OpenSSL library that he wants it used for DNSSEC verification (or signing) only. Therefore you cannot demand DNSSEC submodule itself. But I think crypto team could have made submodule allowing just generic SHA1 signature verification, where not other uses of SHA-1. You know those people more than I do. They are not DNSSEC supporters and have kind of hard stance to SHA-1. They say nobody should use it anymore and do not want to invest more resources to make it better.
Regards, Petr -- Petr Menšík Senior Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
