Thanks, I will have a look. Note you might also run into unbound startup issues as it tries to fetch the Icann pem bundle from icann.org which is also on rsasha1 - so ensure to check unbound’s PreStart items too.
https://stats.dnssec-tools.org/explore/?icann.org Sent using a virtual keyboard on a phone > On Apr 8, 2022, at 10:48, Petr Menšík <[email protected]> wrote: > > 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: [email protected] > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
