Runtime detection of SHA-1 support in unbound

[Petr Menšík]

It seems I have successful prototype of unbound reacting to policy changes.

It seems it passes ietf.org or int as INSECURE if DEFAULT policy is
active. But still passes it as secure if DEFAULT:SHA1 is active.

Tested just with unbound-host -rdD ietf.org

Create PR #660 [1], any testing, comments or review would be very welcome.

Cheers,
Petr

1. https://github.com/NLnetLabs/unbound/pull/660

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?
>
>>> 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.
>
>>> 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
>
-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB