<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>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.</p>
    <p>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.</p>
    <p> 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.<br>
    </p>
    <div class="moz-cite-prefix">On 4/14/22 07:02, Shreyas Zare wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:06702129-5967-5cbe-869b-706aacbeef8a@technitium.com">
      <p>Hi,</p>
      <p>Apart from DNSSEC validation, have you also tested DNS servers
        hosting DNSSEC signed zones with NSEC3? This is since NSEC3 only
        has <a
href="https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml"
          moz-do-not-send="true">SHA1 specified</a> 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.<br>
      </p>
    </blockquote>
    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.<br>
    <blockquote type="cite"
      cite="mid:06702129-5967-5cbe-869b-706aacbeef8a@technitium.com">
      <p> </p>
      <div class="moz-signature">
        <p> Regards,<br>
          <b>Shreyas Zare</b><br>
          <a href="https://technitium.com/" moz-do-not-send="true">Technitium</a>
        </p>
      </div>
      <br>
    </blockquote>
    Regards,<br>
    Petr<br>
    <pre class="moz-signature" cols="72">-- 
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
  </body>
</html>