Of course no-one were ever considering making sha-1 signatures fail hard with SERVFAIL. More below.
On 3/23/22 15:50, Paul Wouters wrote: > This has come up before and has been relayed before. I will see about > getting this unstuck. > > Btw what do you mean with “disabling”? Letting it be treated as > insecure or throwing a sha1 crypto library error and causing a bogus > result leading to failure to access the sites ? Insecure only. Yes, that would lead to valid resolution of dnssec-failed.org for example, because it is also signed only by RSASHA-1. Might surprise someone, it did surprise me. Disabled algorithms are tested to pass as insecure. Only dnsmasq with GOST digest needs fixing on Fedora and RHEL, at least according to test on rootcanary.org. Because NSEC3 algorithm still does not have any alternative to SHA-1, hard crypto failure would be blocker for any our DNS products. I haven't heard about it even being considered this way. I know it might not be best time for it yet, but it has to come someday. > > Paul > > Sent using a virtual keyboard on a phone > >> On Mar 23, 2022, at 15:31, Petr Menšík <pemen...@redhat.com> wrote: >> >> Is this workgroup more appropriate to drive possible change? Has it >> any means to modify ietf.org infrastructure? >> >> -------- Forwarded Message -------- >> Subject: DNSSEC algorithm used on ietf.org >> Date: Wed, 23 Mar 2022 12:28:39 +0100 >> From: Petr Menšík <pemen...@redhat.com> >> Organization: Red Hat >> To: tools-disc...@ietf.org >> >> >> >> Hello, >> >> I work in Red Hat on DNS related products. We were analysing impact on >> disabling algorithm RSASHA1. It is in a strange sitation, because IETF >> itself deprecated this algorithm [1], but is using it for all documents >> it publishes. For some reason site stats.dnssec-tools.org gives it as an >> example [2]. It seems update of Key signing key (ksk) and algorithm >> should be upgraded to more recent algorithm. There is also informational >> RFC 7583 [3], which should help with it. >> >> Is there already plan to upgrade DNSSEC algorithm? Is there any specific >> reason why it stayed unchanged? >> >> I were directed here by the support of ietf. Might be also interesting >> topic for dnsop WG. >> >> Were upgrade already considered? >> >> Best Regards, >> Petr Menšík >> >> 1. https://datatracker.ietf.org/doc/html/rfc8624#section-3 >> 2. https://stats.dnssec-tools.org/explore/ >> 3. https://datatracker.ietf.org/doc/html/rfc7583 >> >> -- >> Petr Menšík >> Software Engineer >> Red Hat, http://www.redhat.com/ >> email: pemen...@redhat.com >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
