On May 1, 2024, at 07:32, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote:
>> Their zone is already made insecure by a number of OS/DNS implementation >> combos. Perhaps someone with RIPE Atlas credits can run a check like the >> equivalent of "dig dnskey nic.kpn +dnssec" to see how many endusers >> already get insecure answers for this? > > This reads as Redhat strong-arming the IETF into adopting a draft that has > no technical merit. The number of OS/DNS comboes that you refer to are all > from or related to Redhat. This seems a bit exaggerated. I don't see Red Hat here promoting changes in the DNSSEC standards. I think it's uncontentious to say that maintaining DNSSEC software on affected platforms has become more complex. Complexity is not an obvious friend of operational security. The platforms concerned are in widespread use. Regardless of whose business decision triggered the situation, it's certainly possible to agree that the situation exists and that it is more likely to get worse over time than better, e.g. as other OS vendors follow suit and SHA-1 support disappears from crypto libraries. There are other reasons to deprecate SHA-1 in DNSSEC than mathematical concern about the use of that particular digest algorithm in the protocol. Problems with SHA-1 definitively exist in other places, in protocols that are in much more widespread use than DNSSEC. For example, a message that says "stop using SHA-1" might be more effective at fixing TLS implementations than a message that says "stop using SHA-1 unless you are using it in one of the following ways, in which case it's totally fine". From the perspective of DNSSEC, "stop using SHA-1" might be a much more effective message to communicate at the same time that everybody else is saying it than ten years later. On the other hand, I have not seen any particularly compelling argument that MUST NOTting SHA-1 will cause the sky to fall. A handful of responses signed by people who are not paying attention will stop being validated. Security and not paying attention are usually related, and not in a good way. I don't think talk about "Red Hat strong-arming the IETF" is very sensible. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
