On Mar 23, 2022, at 10:04 AM, Petr Menšík <pemen...@redhat.com> 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. > 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. > We are preparing RHEL 9 and we still have SHA-1 for DNS(SEC) as > exception. What does "as exception" mean here? > 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. > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
