Runtime detection of SHA-1 support in unbound

[Petr Menšík]

On 4/7/22 16:00, Paul Wouters wrote:
> On Thu, 7 Apr 2022, Simo Sorce wrote:
>
>>> It means RHEL9 cannot be used as a platform for DNS resolvers.
>>
>> It can, you just need to set crypto-policies to allow SHA1 signatures.
>> It is just a matter of configuration like many others.
>
> but unbound has no seperate policies in the system-wide crypto
> backends. Bind does, but will it be modified to allow SHA1? As I
> understand it, it is the openssl backend that will refuse SHA1?

No, because it is not possible in a self-contained way. It would be the
other way around.
It would disable SHA-1 in DEFAULT and FUTURE policy to avoid SERVFAIL on
those names.
Because openssl does not provide a way to verify SHA-1 based signature,
any configuration of bind cannot revert that. It might be possible with
custom openssl configuration,
but that might introduce more issues than it solves. Simo shared such
example.

>
>>> The unbound package should not use crypto-policies if those cannot
>>> facilitate the requirements of RFC 8624.
>>
>> This is applied at the openssl library level.
>
> So that is a problem then. You have to enable it in openssl to make
> it available to bind/unbound and now it is exposed to other parts too,
> eg tls and ssh.
Yes, that is correct.
>
>>> If Red Hat proceeds with this, users have two choices. Change the
>>> system wide policy to LEGACY and degrading security for everything
>>> running on the box (ssh, tls) or stick with rhel8 past its secure and
>>> supported date.
>>
>> We think this is a legitimate choice.
>> But it does not need to be this drastic. A custom openssl configuration
>> can be provided just to the application that needs to do DNSSEC
>> verification via OPENSSL_CONF variable.
>>
>> However we hope DNSSEC can move away from SHA1 quickly, there is no
>> reason to stick to weak digest for so long.
>
> Rubber meets the road somewhere and RFC 8624 has done these
> determinations. If you think Red Hat can go against the worldwide
> view/flow, then go ahead. You get to keep the pieces. The authors
> of RFC 8624 are closely monitoring worldwide statistics and will
> update the RFC when appropriate.
>
> Note also that just breaking the crypto without proper support in the
> DNS software causes ServFail's and not just a change from DNS data
> being handles as "insecure" instead of "dnssec protected". This is
> the bigger problem. Please do ensure unbound, bind et all do not
> fail due to crypto library failing, but handle it properly as an
> "unsupported algorithm" or otherwise there will be user outages.
>
> Paul
>
I am aware that is the result and that is the reason I started that post
here. I would like more solving this in Fedora first and then landing it
later to RHEL, but unfortunately it did not happen this way. I would
like to find a good way for any similar configuration of crypto backend
to make as smooth user-experience as possible. It may influence even
different algorithms, not only SHA-1 based.

Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB