On Thu, May 29, 2025 at 3:03 PM Wes Hardaker <[email protected]> wrote:
> Paul Wouters via Datatracker <[email protected]> writes: > > Hi Paul, > > > In the Operational Considerations, one could add a sentence about the > > difference of not supporting SHA-1 versus having a system that does not > support > > SHA-1. The first results in an insecure validation, which is okay. The > second > > can result in ServFail, which is not okay. Something along the lines of: > > > > When not supporting or disabling SHA-1, care should be given by > > implementers that the DNS software itself is made aware not to > consume > > SHA-1. For example, disabling SHA-1 at the Operating System level > could > > result in SHA-1 cryptographic failures within the DNS system, > which would > > result in those zones failing, instead of the zones being treated > as > > unsigned/insecure > > We'd prefer something a bit more generic. How about: > > Operators should take care when deploying software packages and > operating systems that may have already removed support for the SHA-1 > algorithm. In these situations software may need to be manually built > and deployed by an operator to continue supporting the required levels > indicated by the "Use for DNSSEC Validation" and "Implement for DNSSEC > Validation" columns, which this document is not changing. > > Sound ok? > Can you change "manually built and deployed" to "manually build to disable the algorithms within the DNS software or may need to have the OS or DNS software settings modified to treat disabled algorithms as unsupported instead of causing cryptographic failures". Paul > > -- > Wes Hardaker > USC/ISI >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
