On 4/6/22 23:29, Paul Wouters wrote: > On Apr 6, 2022, at 14:38, Petr Menšík via Unbound-users > <[email protected]> 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: [email protected] PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
