Runtime detection of SHA-1 support in unbound

[Petr Menšík]

On 4/6/22 23:29, Paul Wouters wrote:
> On Apr 6, 2022, at 14:38, Petr Menšík via Unbound-users
> <unbound-users at lists.nlnetlabs.nl> wrote:
>>
>> 
>>
>> Hello,
>>
>> I am maintainer of unbound in RHEL. We are preparing RHEL9 (and
>> CentOS Stream 9). Because preparations for various security
>> certifications SHA-1 signature validation is disabled now in upcoming
>> RHEL9.
>>
>
> This is broken and violates RFC 8624.
It is, but the change have been already made and cannot revert.
>
> It means RHEL9 cannot be used as a platform for DNS resolvers.
That is not correct. Policy DEFAULT:SHA1 enables also SHA-1 signatures
verification and it would work suitable. I admit the change got
implemented quite late, so we could make our unbound with completely
disabled SHA-1 at build time.
>
> The unbound package should not use crypto-policies if those cannot
> facilitate the requirements of RFC 8624.

Unbound package does not use crypto-policies. It has no way to do that.
But openssl does and it causes problems. Sure, the original intention
was to support RFC 9155 [1]. Quote from it: "This document updates
[RFC5246 <https://www.rfc-editor.org/rfc/rfc9155.html#RFC5246>] in such
a way that MD5 and SHA-1 MUST NOT be used for digital signatures." Sure,
it is in conflict with RFC 8624, when applied also to DNS. It is not
only problem of unbound, bind9 has the same problem. But it is able to
disable the algorithm runtime according to policy via configuration
snippet in crypto policy. Then it does not fail when SHA-1 is disabled,
but can validation if it isn't.

Unbound it specific, because it contains both TLS channel support and
DNSSEC. It would break RFC 9155 if it would not follow the system
policy. BIND 9.16 present in CentOS 9 does not yet contain TLS support,
unbound is the only provider of encrypted channel DNS on it.

>
> This would be particularly sad since one of the authors of this RFC
> (me) wrote it while working at Red Hat.
I know you are the author of RFC we now violate.
>
> 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.
>
> Paul

It is already in CentOS Stream 9, there is not "if" anymore. Openssl
part is finished and all I can do is handle it in a good way. I
understood quite late how it would work and what it would cause. I think
it would affect any dnssec software using supported crypto libraries. It
would cause issues also to knot or pdns I would expect.

I want to "fix" it on RHEL 9.0 by turning off SHA-1 support
completely(bug #2070495 [2]). It would make queries to SHA-1 signed
domains insecure, but avoids SERVFAIL replies. I would like to find a
way to keep replies insecure in DEFAULT mode, but to enable them as soon
as crypto library (policy) allows it (DEFAULT:SHA1 mode). I cannot be
fixed in 9.0, but could be fixed in 9.1+ in a better way. I would like
find the best way here. There is some fake_sha1 support, which does not
seem to be usable.

1. https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction
2. https://bugzilla.redhat.com/show_bug.cgi?id=2070495

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20220407/7f77e818/attachment.htm>