Re: DNSSec mess with SHA1

2023-12-15 Thread Mark Andrews 
They haven’t removed sha1 they have removed certain uses of sha1.  If they ever 
remove sha1 we will just add an implementation for sha1. 
-- 
Mark Andrews

> On 16 Dec 2023, at 01:09, Scott Morizot  wrote:
> 
> 
>> On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček  wrote:
>> We do runtime detection at startup because it's configurable, build time 
>> would not work properly.
> 
> Okay, that makes sense. However, if I understood the scenario correctly, it 
> seems like that configuration should then generate a runtime error or at 
> least report that DNSSEC validation has been disabled. The description 
> involved removing support for SHA1 entirely from the underlying system 
> configuration. If that's the case then I don't see how DNSSEC validation can 
> be reliably performed at all. It's not like introducing a new DNSSEC 
> algorithm or removing support for an older DNSSEC algorithm. SHA1 is used to 
> generate the hash label in NSEC3. I know that's been discussed on dnsops, but 
> it hasn't changed. And from algorithm 8 on, there haven't been separate 
> algorithms with and without NSEC3. Rather it's an option that can be 
> configured for signing on a zone by zone basis. So if SHA1 isn't available, I 
> don't see how any of the DNSSEC algorithms could truly be considered 
> supported on the system.
> 
> That's making me curious enough that I might see if I can set up a system 
> where I could reproduce that scenario and see what happens. Unless it's 
> already part of your test suite and you know the answer, of course.
> 
> Scott
> -- 
> 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
-- 
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

Re: DNSSec mess with SHA1

2023-12-15 Thread Scott Morizot 
On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček  wrote:

> We do runtime detection at startup because it's configurable, build time
> would not work properly.
>

Okay, that makes sense. However, if I understood the scenario correctly, it
seems like that configuration should then generate a runtime error or at
least report that DNSSEC validation has been disabled. The description
involved removing support for SHA1 entirely from the underlying system
configuration. If that's the case then I don't see how DNSSEC validation
can be reliably performed at all. It's not like introducing a new DNSSEC
algorithm or removing support for an older DNSSEC algorithm. SHA1 is used
to generate the hash label in NSEC3. I know that's been discussed on
dnsops, but it hasn't changed. And from algorithm 8 on, there haven't been
separate algorithms with and without NSEC3. Rather it's an option that can
be configured for signing on a zone by zone basis. So if SHA1 isn't
available, I don't see how any of the DNSSEC algorithms could truly be
considered supported on the system.

That's making me curious enough that I might see if I can set up a system
where I could reproduce that scenario and see what happens. Unless it's
already part of your test suite and you know the answer, of course.

Scott
-- 
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

Re: DNSSec mess with SHA1

2023-12-15 Thread Petr Špaček 

On 15. 12. 23 14:28, Scott Morizot wrote:
On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček > wrote:


Hello.

It smells like a packaging issue to me. Stock BIND (not an obsolete Red
Hat-Frankenstein version) should detect this condition and threat
domains as insecure.


And I think that answers the one question I had. I was curious what BIND 
would do at build time on a system like that and it sounds like it would 
pick it up during build. I didn't have a system available with the 
described issue on which I could do a full build and see what happened.


We do runtime detection at startup because it's configurable, build time 
would not work properly.


--
Petr Špaček
Internet Systems Consortium
--
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

Re: DNSSec mess with SHA1

2023-12-15 Thread Scott Morizot 
On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček  wrote:

> Hello.
>
> It smells like a packaging issue to me. Stock BIND (not an obsolete Red
> Hat-Frankenstein version) should detect this condition and threat
> domains as insecure.
>

And I think that answers the one question I had. I was curious what BIND
would do at build time on a system like that and it sounds like it would
pick it up during build. I didn't have a system available with the
described issue on which I could do a full build and see what happened.

Thanks,

Scott
-- 
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

Re: DNSSec mess with SHA1

2023-12-15 Thread Petr Špaček 

Hello.

It smells like a packaging issue to me. Stock BIND (not an obsolete Red 
Hat-Frankenstein version) should detect this condition and threat 
domains as insecure.


If it does not work with stock BIND please report it to us. If it does 
not work in Red Hat's packages only, well, report it to Red Hat.


HTH
Petr Špaček
Internet Systems Consortium




On 15. 12. 23 13:21, Wolfgang Riedel wrote:

Hello,

To answer my own question, the following will work:

shadowman-200.png
Chapter 4. Using system-wide cryptographic policies Red Hat Enterprise 
Linux 8 | Red Hat Customer Portal 

access.redhat.com 






With:dnssec-validation auto;


_Not working:_
sudo update-crypto-policies —show
DEFAULT

_working:_
update-crypto-policies --set LEGACY

sudo update-crypto-policies --show
LEGACY

—
Cheers,
Wolfgang
__
Wolfgang Riedel | DistinguishedEngineer | CCIE #13804 | VCP #42559


On 15. Dec 2023, at 12:46, Wolfgang Riedel via bind-users 
 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 
dnsviz.net 
 



My question is more how you all deal with the fact on current and 
updates systems???



Attached the requested information.


_1) Error Messages:_

15-Dec-2023 12:36:38.772 lame-servers: info: insecurity proof failed 
resolving 'nist.gov/DNSKEY/IN': 2600:1480:800::43#53
15-Dec-2023 12:36:39.302 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1401:1::42#53
15-Dec-2023 12:36:40.151 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2610:20:6b01:3::10#53
15-Dec-2023 12:36:40.681 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1401:2::d8#53
15-Dec-2023 12:36:40.779 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1480:9000::40#53
15-Dec-2023 12:36:41.304 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1406:32::43#53
15-Dec-2023 12:36:41.321 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1480:f000::41#53
15-Dec-2023 12:36:41.784 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2610:20:6005:92::10#53
15-Dec-2023 12:36:41.828 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2.22.230.67#53
15-Dec-2023 12:36:43.094 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 132.163.3.10#53
15-Dec-2023 12:36:43.148 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 193.108.91.216#53
15-Dec-2023 12:36:43.237 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 72.246.46.64#53
15-Dec-2023 12:36:43.288 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 23.61.199.67#53
15-Dec-2023 12:36:43.305 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 184.26.160.65#53
15-Dec-2023 12:36:43.771 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 129.6.92.10#53
15-Dec-2023 12:36:43.823 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 23.211.133.66#53
15-Dec-2023 12:36:43.824 lame-servers: info: broken trust chain 
resolving 'www.nist.gov/A/IN': 2610:20:6005:92::10#53
15-Dec-2023 12:36:45.905 lame-servers: info: broken trust chain 
resolving 'www.nist.gov/A/IN': 2600:1480:f000::41#53
15-Dec-2023 12:36:47.403 lame-servers: info: broken trust chain 
resolving 'csrc.nist.gov/A/IN': 2600:1480:f000::41#53


15-Dec-2023 12:38:26.064 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3a::1#53
15-Dec-2023 12:38:26.880 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3d::1#53
15-Dec-2023 12:38:27.148 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.62.1#53
15-Dec-2023 12:38:27.415 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.60.1#53
15-Dec-2023 12:38:27.753 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.61.1#53
15-Dec-2023 12:38:27.770 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.63.1#53
15-Dec-2023 12:38:28.037 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3c::1#53
15-Dec-2023 12:41:23.114 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN':

Re: DNSSec mess with SHA1

2023-12-15 Thread 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@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 
> dnsviz.net 
> [image: logo_16x16.png] 
> 
>
> My question is more how you all deal with the fact on current and updates
> systems???
>
-- 
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

Re: DNSSec mess with SHA1

2023-12-15 Thread Wolfgang Riedel via bind-users 
Hello,

To answer my own question, the following will work:


[shadowman-200.png]
Chapter 4. Using system-wide cryptographic policies Red Hat Enterprise Linux 8 
| Red Hat Customer 
Portal
access.redhat.com




With:dnssec-validation auto;


Not working:
sudo update-crypto-policies —show
DEFAULT

working:
update-crypto-policies --set LEGACY

sudo update-crypto-policies --show
LEGACY

—
Cheers,
Wolfgang
__
Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559


On 15. Dec 2023, at 12:46, Wolfgang Riedel via bind-users 
 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
dnsviz.net



My question is more how you all deal with the fact on current and updates 
systems???


Attached the requested information.


1) Error Messages:

15-Dec-2023 12:36:38.772 lame-servers: info: insecurity proof failed resolving 
'nist.gov/DNSKEY/IN': 2600:1480:800::43#53
15-Dec-2023 12:36:39.302 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1401:1::42#53
15-Dec-2023 12:36:40.151 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2610:20:6b01:3::10#53
15-Dec-2023 12:36:40.681 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1401:2::d8#53
15-Dec-2023 12:36:40.779 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1480:9000::40#53
15-Dec-2023 12:36:41.304 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1406:32::43#53
15-Dec-2023 12:36:41.321 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2600:1480:f000::41#53
15-Dec-2023 12:36:41.784 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2610:20:6005:92::10#53
15-Dec-2023 12:36:41.828 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 2.22.230.67#53
15-Dec-2023 12:36:43.094 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 132.163.3.10#53
15-Dec-2023 12:36:43.148 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 193.108.91.216#53
15-Dec-2023 12:36:43.237 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 72.246.46.64#53
15-Dec-2023 12:36:43.288 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 23.61.199.67#53
15-Dec-2023 12:36:43.305 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 184.26.160.65#53
15-Dec-2023 12:36:43.771 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 129.6.92.10#53
15-Dec-2023 12:36:43.823 lame-servers: info: no valid RRSIG resolving 
'nist.gov/DNSKEY/IN': 23.211.133.66#53
15-Dec-2023 12:36:43.824 lame-servers: info: broken trust chain resolving 
'www.nist.gov/A/IN': 2610:20:6005:92::10#53
15-Dec-2023 12:36:45.905 lame-servers: info: broken trust chain resolving 
'www.nist.gov/A/IN': 2600:1480:f000::41#53
15-Dec-2023 12:36:47.403 lame-servers: info: broken trust chain resolving 
'csrc.nist.gov/A/IN': 2600:1480:f000::41#53

15-Dec-2023 12:38:26.064 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3a::1#53
15-Dec-2023 12:38:26.880 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3d::1#53
15-Dec-2023 12:38:27.148 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.62.1#53
15-Dec-2023 12:38:27.415 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.60.1#53
15-Dec-2023 12:38:27.753 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.61.1#53
15-Dec-2023 12:38:27.770 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.63.1#53
15-Dec-2023 12:38:28.037 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3c::1#53
15-Dec-2023 12:41:23.114 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3d::1#53
15-Dec-2023 12:41:23.380 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 2a01:8840:3a::1#53
15-Dec-2023 12:41:23.648 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.62.1#53
15-Dec-2023 12:41:23.986 lame-servers: info: no valid RRSIG resolving 
'apple/DNSKEY/IN': 65.22.61.1#53
15-Dec-2023 12:41:24.003 lame-servers: info: no valid RRSIG resolving