<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/6/22 23:29, Paul Wouters wrote:<br>
</div>
<blockquote type="cite"
cite="mid:3FAD3A0A-7CF4-4CAE-B6AE-16F13A3D5383@nohats.ca">
<div dir="ltr">On Apr 6, 2022, at 14:38, Petr Menšík via
Unbound-users <a class="moz-txt-link-rfc2396E" href="mailto:unbound-users@lists.nlnetlabs.nl"><unbound-users@lists.nlnetlabs.nl></a> wrote:<br>
<div dir="ltr">
<blockquote type="cite"><br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<p>Hello,</p>
<p>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.</p>
</div>
</blockquote>
<br>
<div>This is broken and violates RFC 8624.</div>
</div>
</blockquote>
It is, but the change have been already made and cannot revert.<br>
<blockquote type="cite"
cite="mid:3FAD3A0A-7CF4-4CAE-B6AE-16F13A3D5383@nohats.ca">
<div dir="ltr">
<div><br>
</div>
<div>It means RHEL9 cannot be used as a platform for DNS
resolvers.</div>
</div>
</blockquote>
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.<br>
<blockquote type="cite"
cite="mid:3FAD3A0A-7CF4-4CAE-B6AE-16F13A3D5383@nohats.ca">
<div dir="ltr">
<div><br>
</div>
<div>The unbound package should not use crypto-policies if those
cannot facilitate the requirements of RFC 8624.</div>
</div>
</blockquote>
<p>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 <span>[<a
href="https://www.rfc-editor.org/rfc/rfc9155.html#RFC5246"
class="xref">RFC5246</a>]</span> in such a way that MD5 and
SHA-1 <span class="bcp14">MUST NOT</span> 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.</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:3FAD3A0A-7CF4-4CAE-B6AE-16F13A3D5383@nohats.ca">
<div dir="ltr">
<div><br>
</div>
<div>This would be particularly sad since one of the authors of
this RFC (me) wrote it while working at Red Hat.</div>
</div>
</blockquote>
I know you are the author of RFC we now violate.<br>
<blockquote type="cite"
cite="mid:3FAD3A0A-7CF4-4CAE-B6AE-16F13A3D5383@nohats.ca">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:3FAD3A0A-7CF4-4CAE-B6AE-16F13A3D5383@nohats.ca">
<div dir="ltr">
<div><br>
</div>
<div>Paul</div>
</div>
</blockquote>
<p>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.</p>
<p>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.<br>
</p>
1. <a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction">https://www.rfc-editor.org/rfc/rfc9155.html#name-introduction</a><br>
2. <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=2070495">https://bugzilla.redhat.com/show_bug.cgi?id=2070495</a><br>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>