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.
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.
On 12/15/23 13:38, Scott Morizot wrote:
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.)
As far as I know, RFC 8624 from 2019 remains the last published
standards track instruction to validators. Here's the table from it.
The following table lists the implementation recommendations for
DNSKEY algorithms [DNSKEY-IANA].
+--------+--------------------+-----------------+-------------------+
| Number | Mnemonics | DNSSEC Signing | DNSSEC Validation |
+--------+--------------------+-----------------+-------------------+
| 1 | RSAMD5 | MUST NOT | MUST NOT |
| 3 | DSA | MUST NOT | MUST NOT |
| 5 | RSASHA1 | NOT RECOMMENDED | MUST |
| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST |
| 8 | RSASHA256 | MUST | MUST |
| 10 | RSASHA512 | NOT RECOMMENDED | MUST |
| 12 | ECC-GOST | MUST NOT | MAY |
| 13 | ECDSAP256SHA256 | MUST | MUST |
| 14 | ECDSAP384SHA384 | MAY | RECOMMENDED |
| 15 | ED25519 | RECOMMENDED | RECOMMENDED |
| 16 | ED448 | MAY | RECOMMENDED |
+--------+--------------------+-----------------+-------------------+
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.
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.
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:
1) Ignore the problem. Causes SERVFAILs on any SHA1 signed zones
unfortunately on RHEL9 and derivatives in default configuration.
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.
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.
4) Completely disable DNSSEC validation. I would not recommend this
option, this is the worst choice.
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.
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.
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.
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.
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.
Scott
On Fri, Dec 15, 2023 at 5:47 AM Wolfgang Riedel via bind-users
<bind-users@lists.isc.org> wrote:
Hello Petr,
The issue is not just BIND local, as you can see on dnsviz.net
<http://dnsviz.net>.
The whole chain of trust is broken.
nist.gov <https://dnsviz.net/d/nist.gov/dnssec/>
dnsviz.net <https://dnsviz.net/d/nist.gov/dnssec/>
logo_16x16.png <https://dnsviz.net/d/nist.gov/dnssec/>
<https://dnsviz.net/d/nist.gov/dnssec/>
My question is more how you all deal with the fact on current and
updates systems???
--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
