The validators where not returning BOGUS. They where returning unknown error. Both errors resulted in servfail.
Once we knew what RH had done one could go from compile time testing of support to runtime testing of support. The DNSSEC RFC’s already told developers how to handle this. RSASHA1 is just treated as any other unsupported algorithm if there is not runtime support. Unfortunately there isn’t an easy test. You have to attempt to verify a known good signature. -- Mark Andrews > On 1 May 2024, at 00:41, Mark Andrews <ma...@isc.org> wrote: > > One got servfail because validators where not aware that support was ripped > away underneath it. Validators started to get errors that where totally > unexpected. Performing runtime testing of algorithm support addressed that by > allowing the validator to skip the unsupported algorithm. > -- > Mark Andrews > >> On 1 May 2024, at 00:04, Paul Wouters <p...@nohats.ca> wrote: >> On Tue, 30 Apr 2024, Philip Homburg wrote: >> >>>> The advise is split between producing SHA1 signatures and consuming SHA1 >>>> signatures, and those timings do not have to be identical. >>>> That said, a number of OSes have already forced the issue by failing >>>> SHA1 as cryptographic operation (RHEL, CentOS, Fedora, maybe more). So >>>> right now, if you run DNSSEC with SHA1 (which includes NSEC3 using >>>> SHA1), your validator might already return it as an insecure zone. >>>> I think a MUST NOT for signing with SHA1 is a no-brainer. The timing for >>>> MAY on validation should be relatively short (eg 0-2 years?) >>> >>> What worries me about the draft is the security section. I can understand >>> the desire to get rid of old crypto, but as far as I can tell >>> this draft will mostly decrease security. >> >> It will also prevent ServFails when the system crypto SHA1 for >> authentication and signature purposes is blocked, and the DNS software >> sees this as a failure and returns BOGUS. I am not sure how many DNS >> implementations are now probing SHA1 and on failure put it in the >> "unsupported algorithm" class, to serve it as insecure instead of bogus. >> >> This issue did hit RHEL,CentOS, Fedora. >> >>> We can accept as given that it is easy to find collisions for SHA1. However, >>> a second pre-image attack is way off in the future. >> >> I'm not too concerned about that. >> >>> Looking at the signer part, this is not great either. Moving away from SHA1 >>> requires an algorithm roll-over. DNSSEC is already quite fragile and >>> algorithm >>> rolls are worse. So there is a failure risk that is too big ignore. >> >> Yes, this fragility is why there are still zones using SHA1 at all. But >> I think software and DNS services have no matured to the point where it >> is save to do. Eg bind, opendnssec, knot. >> >>> This draft requires zones that do not have a collision risk to move to a >>> different algorithm, at a significant risk, but there is no increase in >>> security. So that part is also a net negative for security. >> >> Staying at SHA1 incurs the above risk of SHA1 leading to Bogus/ServFail. >> >>> So it seems that we are asked to adopt a draft that will mostly reduce >>> security, not increase it. >> >> It prevents zone outages. >> >>> There might be other arguments for adopting the draft, such a Redhat not >>> validating signatures with SHA1 anymore. But those arguments are not >>> mentioned in the draft. >> >> I guess these considerations can be added to the draft if the WG wants? >> >>> And if some companies from one country want to shoot themselves in the foot, >>> does the rest of the world have to follow? >> >> The IETF and its cryptographic policies are a careful interworking >> between market forces, reality and desire. Moving to fast leads to RFCs >> being ignored. Moving too slow means RFCs do not encourage >> modernization. Every other protocol has left SHA1 behind. It's time for >> DNS to follow suit. It's had its "exemption" for a few years already. >> >> Paul >> >> _______________________________________________ >> 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
