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

Reply via email to