<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I would like to add decision to not allow SHA1 signatures
verification were done on openssl component in RHEL9. It was not
proposed by bind maintainer and because the crypto library
prevents that operation, there is a little bind package made by
any vendor can do. Unless they want to support their own SHA1
implementation.<br>
</p>
<p>Of course you can configure DEFAULT:SHA1 crypto policy manually,
which I believe is the safest option. Sadly, that will also enable
SHA1 acceptance in TLS connections, which were primary target
anyway. Unfortunately I do not know a way to enable SHA1 for
named.service, but disallow it in other programs.<br>
</p>
<div class="moz-cite-prefix">On 12/15/23 13:38, Scott Morizot wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFy81rk5qnR_KvXzwxVfAMCQbZj1TBaCjoKiQ7oCYzAj-O9PBg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>The question I have is why you're posting the issue to this
list and what you expect the ISC to do? It could be submitted
as a bug to the distribution you're using. Or if you want to
change the way algorithms are treated, the dnsops list at the
IETF would be an appropriate place to start. (There has been a
fair amount of discussion there on algorithms, but I admit I
haven't been following it closely and it has mostly been
focused on the signing side.)</div>
<div><br>
</div>
<div>As far as I know, RFC 8624 from 2019 remains the last
published standards track instruction to validators. Here's
the table from it.</div>
<div><br>
</div>
<div> The following table lists the implementation
recommendations for DNSKEY algorithms [DNSKEY-IANA].<br>
<br>
<font face="monospace">
+--------+--------------------+-----------------+-------------------+<br>
| Number | Mnemonics | DNSSEC Signing | DNSSEC
Validation |<br>
+--------+--------------------+-----------------+-------------------+<br>
| 1 | RSAMD5 | MUST NOT | MUST
NOT |<br>
| 3 | DSA | MUST NOT | MUST
NOT |<br>
| 5 | RSASHA1 | NOT RECOMMENDED | MUST
|<br>
| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST
NOT |<br>
| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST
|<br>
| 8 | RSASHA256 | MUST | MUST
|<br>
| 10 | RSASHA512 | NOT RECOMMENDED | MUST
|<br>
| 12 | ECC-GOST | MUST NOT | MAY
|<br>
| 13 | ECDSAP256SHA256 | MUST | MUST
|<br>
| 14 | ECDSAP384SHA384 | MAY |
RECOMMENDED |<br>
| 15 | ED25519 | RECOMMENDED |
RECOMMENDED |<br>
| 16 | ED448 | MAY |
RECOMMENDED |<br>
+--------+--------------------+-----------------+-------------------+</font><br>
</div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">Algorithms 5 and 7 are not
recommended for signing but remain valid options until they
are moved to MUST NOT. And as long as they are valid
options, DNSSEC validation has to remain MUST. ISC BIND
functions in part as the reference implementation for the
DNS standards as published through the IETF. If your
distribution removed the libraries for an algorithm (and
openssl is a separate project) on which BIND depends for
validating those algorithms and it's the only algorithm
available I'm not sure what other result BIND can
legitimately return.</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">Yes, there's a statement in the
validation portion of RFC 4035 that if the resolver doesn't
support any of the algorithms in the delegation, it should
treat the zone as unsigned. But that doesn't apply here from
what I can tell. The DNSSEC algorithm itself (algorithm 7 in
this instance) is supported in the resolver and must be
supported for validation to be standards conformant. Support
for the hash algorithm used by the supported algorithm has
been removed from the operating system. <br>
</font></div>
</div>
</blockquote>
<p>There is a little we can do. Used crypto backend does not allow
SHA1 validation and there is no configuration named can use to
request it. Choices any DNSSEC validation service has is:</p>
<p>1) Ignore the problem. Causes SERVFAILs on any SHA1 signed zones
unfortunately on RHEL9 and derivatives in default configuration.<br>
2) Do not use system provided crypto libraries. I think named
maintainers lack expertise and manpower to properly maintain own
set of crypto libraries. I would not recommend that either.<br>
3) Disable SHA1 algorithm to make it equivalent to unsigned. Yes,
it violates RFC 8624 this way. But does not cause SERVFAILs, still
protects all other zones signed with stronger algorithms. Just
small subset becomes unprotected. Either by runtime autodetection
or manual configuration.<br>
4) Completely disable DNSSEC validation. I would not recommend
this option, this is the worst choice.<br>
</p>
<p>I have chosen the choice 3) for RHEL bind package and ISC has
taken it as well. I don't think there were any better choice
anyway.</p>
<p>I think the future solution might be having separate openssl SHA1
provider, which would be explicitly requested by API in named, but
not used for common applications doing TLS connections.<br>
</p>
<blockquote type="cite"
cite="mid:CAFy81rk5qnR_KvXzwxVfAMCQbZj1TBaCjoKiQ7oCYzAj-O9PBg@mail.gmail.com">
<div dir="ltr">
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">I don't see anywhere that BIND is
returning the wrong result. In that situation, it looks like
the only option. The ISC has no control over those building
distributions nor does it have any control over what NIST,
Apple, and others choose to use within the standards to sign
their zones.</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">Yes, it's a problem and the ISC can
and likely will weigh in on it in the appropriate places.
Since one of their objectives with BIND has always been to
be a reference implementation for the standards, they can't
really arbitrarily decide not to follow them.</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">Anyway, those are the main thoughts
I had while reading the discussion. I don't speak for anyone
but myself so the ISC might have an entirely different take
on the issue.</font></div>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">Scott</font></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Dec 15, 2023 at
5:47 AM Wolfgang Riedel via bind-users <<a
href="mailto:bind-users@lists.isc.org"
moz-do-not-send="true" class="moz-txt-link-freetext">bind-users@lists.isc.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
Hello Petr,
<div><br>
</div>
<div>The issue is not just BIND local, as you can see on <a
href="http://dnsviz.net" target="_blank"
moz-do-not-send="true">
dnsviz.net</a>.</div>
<div>The whole chain of trust is broken.</div>
<div><br>
</div>
<div>
<div style="display:block">
<div style="display:inline-block" role="link">
<a
style="border-radius:10px;font-family:-apple-system,Helvetica,Arial,sans-serif;display:block;width:300px;overflow:hidden;text-decoration:none"
rel="nofollow"
href="https://dnsviz.net/d/nist.gov/dnssec/"
dir="ltr" role="button" width="300"
target="_blank" moz-do-not-send="true">
<table
style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:rgb(229,230,233);font-family:-apple-system,Helvetica,Arial,sans-serif"
width="300" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
<td>
<table
style="font-family:-apple-system,Helvetica,Arial,sans-serif;table-layout:fixed;background-color:rgb(229,230,233)"
width="300" cellspacing="0"
cellpadding="0" bgcolor="#E5E6E9">
<tbody>
<tr>
<td style="padding:8px 0px">
<div
style="max-width:100%;margin:0px 16px;overflow:hidden">
<div
style="font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left">
<a rel="nofollow"
href="https://dnsviz.net/d/nist.gov/dnssec/"
style="text-decoration:none"
target="_blank"
moz-do-not-send="true"><font
style="color:rgba(0,0,0,0.847)" color="#272727">nist.gov</font></a></div>
<div
style="font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left">
<a rel="nofollow"
href="https://dnsviz.net/d/nist.gov/dnssec/"
style="text-decoration:none"
target="_blank"
moz-do-not-send="true"><font
style="color:rgba(0,0,0,0.498)" color="#808080">dnsviz.net</font></a></div>
</div>
</td>
<td style="padding:6px 12px 6px 0px"
width="36">
<a rel="nofollow"
href="https://dnsviz.net/d/nist.gov/dnssec/" target="_blank"
moz-do-not-send="true"><img
style="display: inline-block; width: 36px; height: 36px; border-radius: 3px;"
alt="logo_16x16.png"
src="cid:part1.NjTPfVOf.h6sF3dEQ@redhat.com" class="" width="36"
height="36"></a></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</a></div>
</div>
<br>
</div>
<div>
<div><span style="color:rgb(0,0,0)">My question is more
how you all deal with the fact on current and
updates systems???</span></div>
</div>
</div>
</blockquote>
<div> </div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>