
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Thanks, I will have a look.<div><br></div><div>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.</div><div><br></div><div><a href="https://stats.dnssec-tools.org/explore/?icann.org">https://stats.dnssec-tools.org/explore/?icann.org</a><br><br><div dir="ltr">Sent using a virtual keyboard on a phone</div><div dir="ltr"><br><blockquote type="cite">On Apr 8, 2022, at 10:48, Petr Menšík <pemensik@redhat.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>It seems I have successful prototype of unbound reacting to policy changes.</span><br><span></span><br><span>It seems it passes ietf.org or int as INSECURE if DEFAULT policy is</span><br><span>active. But still passes it as secure if DEFAULT:SHA1 is active.</span><br><span></span><br><span>Tested just with unbound-host -rdD ietf.org</span><br><span></span><br><span>Create PR #660 [1], any testing, comments or review would be very welcome.</span><br><span></span><br><span>Cheers,</span><br><span>Petr</span><br><span></span><br><span>1. https://github.com/NLnetLabs/unbound/pull/660</span><br><span></span><br><span>On 4/7/22 16:00, Paul Wouters wrote:</span><br><blockquote type="cite"><span>On Thu, 7 Apr 2022, Simo Sorce wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>It means RHEL9 cannot be used as a platform for DNS resolvers.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>It can, you just need to set crypto-policies to allow SHA1 signatures.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>It is just a matter of configuration like many others.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>but unbound has no seperate policies in the system-wide crypto</span><br></blockquote><blockquote type="cite"><span>backends. Bind does, but will it be modified to allow SHA1? As I</span><br></blockquote><blockquote type="cite"><span>understand it, it is the openssl backend that will refuse SHA1?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>The unbound package should not use crypto-policies if those cannot</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>facilitate the requirements of RFC 8624.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>This is applied at the openssl library level.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>So that is a problem then. You have to enable it in openssl to make</span><br></blockquote><blockquote type="cite"><span>it available to bind/unbound and now it is exposed to other parts too,</span><br></blockquote><blockquote type="cite"><span>eg tls and ssh.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>If Red Hat proceeds with this, users have two choices. Change the</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>system wide policy to LEGACY and degrading security for everything</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>running on the box (ssh, tls) or stick with rhel8 past its secure and</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>supported date.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>We think this is a legitimate choice.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>But it does not need to be this drastic. A custom openssl configuration</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>can be provided just to the application that needs to do DNSSEC</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>verification via OPENSSL_CONF variable.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>However we hope DNSSEC can move away from SHA1 quickly, there is no</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>reason to stick to weak digest for so long.</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Rubber meets the road somewhere and RFC 8624 has done these</span><br></blockquote><blockquote type="cite"><span>determinations. If you think Red Hat can go against the worldwide</span><br></blockquote><blockquote type="cite"><span>view/flow, then go ahead. You get to keep the pieces. The authors</span><br></blockquote><blockquote type="cite"><span>of RFC 8624 are closely monitoring worldwide statistics and will</span><br></blockquote><blockquote type="cite"><span>update the RFC when appropriate.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Note also that just breaking the crypto without proper support in the</span><br></blockquote><blockquote type="cite"><span>DNS software causes ServFail's and not just a change from DNS data</span><br></blockquote><blockquote type="cite"><span>being handles as "insecure" instead of "dnssec protected". This is</span><br></blockquote><blockquote type="cite"><span>the bigger problem. Please do ensure unbound, bind et all do not</span><br></blockquote><blockquote type="cite"><span>fail due to crypto library failing, but handle it properly as an</span><br></blockquote><blockquote type="cite"><span>"unsupported algorithm" or otherwise there will be user outages.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Paul</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span>-- </span><br><span>Petr Menšík</span><br><span>Software Engineer</span><br><span>Red Hat, http://www.redhat.com/</span><br><span>email: pemensik@redhat.com</span><br><span>PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</span><br></div></blockquote></div></body></html>