DNSSec mess with SHA1

[Scott Morizot]

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.

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.
> 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/>
> [image: 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???
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231215/9d63fb34/attachment.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/20231215/9d63fb34/attachment.png>