[dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream

[Shreyas Zare]

Thanks for the clarification.

On 4/14/2022 2:53 PM, Petr Menšík wrote:
>
> No, SHA-1 is not going to be disabled the same way MD5 were disabled 
> in RHEL 7. Normal message digests using SHA-1 will still work. I know 
> NSEC3 has no other alternative and therefore we cannot afford breaking 
> it altogether. It would break almost all resolution in the most common 
> top level domains. Any attempt to do that would be clear blocker for a 
> release and no, nothing such is planned or implemented.
>
> What will start failing are attempts to verify digests made using 
> SHA-1 and RSA keys used in the same openssl API call. I have included 
> examples of openssl calls which would now return error. sha1sum and 
> similar tools should still work unmodified. That means also NSEC3 
> would still work. I haven't seen complete API call list affected by 
> this change. I cannot share it therefore.
>
> Power DNS developer said their implementation still works. It seems 
> using lower-level API calls can avoid this change of policy. That is 
> discouraged by our internal guidelines, but could be used as a 
> workaround. I haven't tested those ways.
>
> On 4/14/22 07:02, Shreyas Zare wrote:
>>
>> Hi,
>>
>> Apart from DNSSEC validation, have you also tested DNS servers 
>> hosting DNSSEC signed zones with NSEC3? This is since NSEC3 only has 
>> SHA1 specified 
>> <https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml> 
>> and this may cause the DNS server unable to update the zone to create 
>> new NSEC3 records. This will mean that even if the zone is signed 
>> with ECDSA algorithms but use NSEC3 then they are going to fail.
>>
> Yes, I am aware there is no other hash algorithm standardized. I have 
> tested NSEC3 stays working and validates in DEFAULT policy. If you can 
> find a case where it stopped working on centos stream9 container, 
> please share steps to reproduce with me. I don't think that can 
> happen, but you can prove me wrong.

Regards,
*Shreyas Zare*
Technitium <https://technitium.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20220414/6aae8266/attachment.html>