<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thanks for the clarification.</p>
    <div class="moz-cite-prefix">On 4/14/2022 2:53 PM, Petr Menšík
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:af79b308-891e-ba53-9c63-59b072ad0148@redhat.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <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>
    <div class="moz-signature">
      <p>
        Regards,<br>
        <b>Shreyas Zare</b><br>
        <a href="https://technitium.com/">Technitium</a>
      </p>
    </div>
  </body>
</html>