On Tue, 30 Apr 2024, Philip Homburg wrote:
- FIPS
- PCI-DSS
- BSI
- OWASP
- SOC2
- PKI-industry & CAB/Forum
- TLS, IPsec/IKE, OpenPGP, SMIME, et all at IETF.
- All the cryptographers including CFRG
The problem is that none if them did an impact analysis for this draft.
I phrase it the other way around:
The DNS community failed to track industry wide commitments and
requirements for many years.
Yes of course, in isolation it is good to move away from SHA1. Nobody
says SHA1 is great, we should promote it. RFC 8624 already says that
algorithms 5 and 7 are not recommended for signing.
That's from 2019. It could use an update from SHOULD NOT to MUST NOT.
That's exactly what this document does. If not now, when would you want
to change it? I was reluctant too until I saw the numbers from Viktor
about to low amount of SHA1 zones left a few months ago.
However, going ahead and breaking things is something different. And that
is exactly what is proposed here. And that is something that doesn't give
security benefits. Just a reduction of security in the name of crypto purity.
As explained, it will cause less breakage not more. It will also cause
more insecure zones, but that is not "breakage" and these zones are far
behind current practices. I found my old viktor messages, so I refound:
https://stats.dnssec-tools.org/#/?top=parameters&dnssec_param_tab=0
19750 out of 22,713,302 aka 0.08% is using RSASHA1
119678 out of 22,713,302 aka 0.52% is using NEC3-RSASHA1
at 0.6%, I think it is long time to say MUST NOT. Yes that half percent
will see their DNSSEC status reduced to insecure, but on the plus side,
it won't cause sha1 bogus servfail errors anywhere.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
