Re: DNSSec mess with SHA1

I would like to add decision to not allow SHA1 signatures verification were done on openssl component in RHEL9. It was not proposed by bind maintainer and because the crypto library prevents that operation, there is a little bind package made by any vendor can do. Unless they want to support th

Re: DNSSec mess with SHA1

Hello Wolfgang, I would suggest using policy DEFAULT:SHA1 instead. It does not enable all outdated algorithms, but enables only SHA1 in addition. Good choice for dedicated DNS servers. $ update-crypto-policies --set DEFAULT:SHA1 With my bind maintainer hat on, I need to clarify that it was e

Re: DNSSec mess with SHA1

Hi Folks, Many thanks for you feedback and insights. I didn’t wanted to say that this is an ISC issue or something I expected someone to fix. I just wanted to get your opinions and maybe provide a solution as I am not the only one facing that challenge ;-) Yes, it may be a distribution packing

Re: DNSSec mess with SHA1

They haven’t removed sha1 they have removed certain uses of sha1. If they ever remove sha1 we will just add an implementation for sha1. -- Mark Andrews > On 16 Dec 2023, at 01:09, Scott Morizot wrote: > >  >> On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: >> We do runtime detection at

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 7:40 AM Petr Špaček wrote: > We do runtime detection at startup because it's configurable, build time > would not work properly. > Okay, that makes sense. However, if I understood the scenario correctly, it seems like that configuration should then generate a runtime erro

Re: DNSSec mess with SHA1

On 15. 12. 23 14:28, Scott Morizot wrote: On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček > wrote: Hello. It smells like a packaging issue to me. Stock BIND (not an obsolete Red Hat-Frankenstein version) should detect this condition and threat domains as inse

Re: DNSSec mess with SHA1

On Fri, Dec 15, 2023 at 6:58 AM Petr Špaček wrote: > Hello. > > It smells like a packaging issue to me. Stock BIND (not an obsolete Red > Hat-Frankenstein version) should detect this condition and threat > domains as insecure. > And I think that answers the one question I had. I was curious what

Re: DNSSec mess with SHA1

Hello. It smells like a packaging issue to me. Stock BIND (not an obsolete Red Hat-Frankenstein version) should detect this condition and threat domains as insecure. If it does not work with stock BIND please report it to us. If it does not work in Red Hat's packages only, well, report it to

Re: DNSSec mess with SHA1

The question I have is why you're posting the issue to this list and what you expect the ISC to do? It could be submitted as a bug to the distribution you're using. Or if you want to change the way algorithms are treated, the dnsops list at the IETF would be an appropriate place to start. (There ha

Re: DNSSec mess with SHA1

Hello, To answer my own question, the following will work: [shadowman-200.png] Chapter 4. Using system-wide cryptographic policies Red

Re: DNSSec mess with SHA1

On 14. 12. 23 8:58, Wolfgang Riedel via bind-users wrote: Hi Folks, I just wonder what's your take is on the current DNSSec mess with SHA1? There are still a lot of top level domains being signed with SHA1 and look like nobody really cares? Current OS releases like RHEL9 and others simply remo