On Tue, 30 Apr 2024, Philip Homburg wrote:
So what happens instead is that software is patched to return insecure if SHA1 is not avaiable for signing and that is of course very risky.
has been patched, yes. The problem arguably is that DNS moved WAY slower that the industry as a whole to get rid of SHA1. You can blame the industry, but honestly, DNS(SEC) is the outlier here.
So it seems that one company is trying set policy.
Entities stating to not use SHA1 for cryptographic purposes: - FIPS - PCI-DSS - BSI - OWASP - SOC2 - PKI-industry & CAB/Forum - TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF. - All the cryptographers including CFRG
Given that for a large number of zones, SHA1 does not pose a security risk, there is no 'too slow'.
"too slow" is literally what caused this, as the cryptographic libraries and OSes prepared for more centralized OS control and disabling of SHA1 for cryptographic purposes throughout the entire OS.
There is a general move to EC for signatures and that solves the SHA1 issue as well. For zones that are currently secure, just let them be secure.
They are not guaranteed secure. For some these are insecure already. And endusers or zoneowners might not even be aware of this.
And let Redhat ship broken products if they want.
I was still at Red Hat when this originally happened, and the DNS software was not prepaered for this. I tried to talk to everyone involved to contain the damage. DNS software got updated. But that was FIVE YEARS ago. I can't believe we are still having a discussion to keep allowing SHA1 five years after the damage started to show. That is a DNS problem, and this draft is the proper way for IETF to signal to people to move away from SHA1. It's the most the IETF can do and it is already damn little. Your proposed alternative seems to be to do nothing, which is clearly ignoring the market and blaming the frontrunner within that market. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
