On 3/23/22 18:41, Paul Hoffman wrote: > On Mar 23, 2022, at 10:04 AM, Petr Menšík <[email protected]> wrote: >>>> I work in Red Hat on DNS related products. We were analysing impact on >>>> disabling algorithm RSASHA1. >>> The impact is clear: you will cause many validly-signed zones to be >>> considered unsigned. >> I am aware this would be the result. It were done in very similar manner >> with RSAMD5. > RSAMD5 has a very different status in RFC 8624 than RSASHA1 does. RSAMD5 must not be implemented since RFC 6944, year . So many domains do not use any kind of DNSSEC signatures, would SHA-1 break everything so bad? >> It is questionable anyway how secure it is, when its >> operator does not follow up-to-date recommendation. > If Red Hat believes that it can make that kind of judgement for its > customers, that's fine, but you should make your customers aware of the > implications of that decision: validly-signed zones will be treated as > unsigned by Red Hat software. Your customers can then decide if they want to > keep using that software from you, or switch to another vendor. Red Hat creates stable Linux distribution, which our customers usually start using 2-3 years after we release it. We have to make reasonable guess what might be best practice at that time. It is hard. I know it is not considered as broken as RSAMD5 is. That might change, we are trying to prepare for that time ahead. >> We are preparing RHEL 9 and we still have SHA-1 for DNS(SEC) as >> exception. > What does "as exception" mean here? We try to prepare strong algorithms only for TLS negotiated channels. For example HTTPS connection would not accept RSASHA1 certificate. Anywhere SHA-2 can be used, it has to be used instead. DNS is not so simple, because no such on-demand negotiation is done. And RSASHA1 is still considered strong enough for DNSSEC. It would not be allowed for a web service. Therefore DNS has exception to keep using SHA-1 for security purposes from our crypto people. >> But we think it would happen when it would be under support. >> Thank you for exact reference, it may be used in our internal discussion. > Certainly. Anyone making such decisions should be reading the relevant RFCs > carefully. > >> While it might not be required yet, it should be ready when that >> happens. Is there expected timeline for that yet? > No. Everything that is known about the state of the recommendations is in the > RFC itself. > >> Any required changes, >> which may change validation to SHOULD or MAY? > Those are possibilities, as is leaving it a MUST. > >> Is it just about DNSSEC >> algorithms used on top level domains? > No. RFC 8624 does not differentiate between levels in the DNS hierarchy. > >> Server configuration already makes >> it possible to disable any algorithm, including RSASHA1. It must >> implement it and it would. Question here is only whether it would be >> disabled in default configuration or not. > Given that RFC 8624 says that validation is "MUST", I think that answers it > for you.
Yes, it says so. It also says SHA-1 is not recommended for new signatures and ietf.org signature was made at 20220318000627. Is there reason why DNS is so better protected than TLS certificates? Is its shorter message length a good protection? I don't understand the difference between There were thread two years ago: https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/ I were not watching well enough, does that mean DNS(SEC) is not affected? Is it required to wait for a new RFC? >> We are not considering disabling its support at build time, it would be >> always possible to enable later. > That sounds fine, as long as your customers understand when you are making > choices to deviate from the Internet standards they expect you to be > following. > > --Paul Hoffman It seems you take our consideration even personal. I am sorry for that. I were not looking for a flame, but for a guidance. I did not know we have to humbly wait for RFC approval for our configuration. We understood still not a tiny amount of people is using RSASHA-1 in DNS. But I am unsure how would people here conclude it is the right time to make SHA-1 non-mandatory. Our product undergoes security certification. That mandates strong cryptography is used whenever it can be. I think if someone needs to have secure domain then SHA-1 is not ideal way there. Even when RFC 8624 says it has to be supported. Okay, not yet ready. I just hope it would not come too late. Best Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: [email protected] PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
