DNSSec mess with SHA1

Wed Jan 3 11:30:23 UTC 2024

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240103/9a0168fa/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_16x16.png
Type: image/png
Size: 4387 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240103/9a0168fa/attachment-0001.png>