<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Den 27-04-2021 kl. 21:31 skrev Eric
      Germann via NANOG:<br>
    </div>
    <blockquote type="cite"
cite="mid:sig.775198015c.BDC105F9-D002-4BD4-A0CF-09523E35CF7D@semperen.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class=""><font class="" face="InputMono-Regular"><span
            style="font-size: 14px; font-style: normal;" class="">Does
            anyone have a pointer to a good resource for current best
            practices for deployment of DNSSEC, preferably newer than
            RFC6781?</span></font></div>
    </blockquote>
    <p><font face="InputMono-Regular">RFC8624 "Algorithm Implementation
        Requirements and Usage Guidance for DNSSEC"<br>
      </font></p>
    <p><font face="InputMono-Regular">->
        <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc8624">https://tools.ietf.org/html/rfc8624</a><br>
      </font></p>
    <blockquote type="cite"
cite="mid:sig.775198015c.BDC105F9-D002-4BD4-A0CF-09523E35CF7D@semperen.com">
      <div class=""><font class="" face="InputMono-Regular"><span
            style="font-size: 14px; font-style: normal;" class=""><br
              class="">
          </span></font></div>
      <div class=""><font class="" face="InputMono-Regular"><span
            style="font-size: 14px; font-style: normal;" class="">What
            algorithms do you typically sign with (RSASHA256, <span
              style="orphans: 2; widows: 2;" class="">ECDSAP256SHA256,
              both, something other)?</span></span></font></div>
    </blockquote>
    <p><font face="InputMono-Regular">Those two mentioned are the ones
        that the vast majority seems to sign with.</font></p>
    <p><font face="InputMono-Regular">As to quote the above mentioned
        RFC:</font></p>
    <p><font face="InputMono-Regular">
        <blockquote type="cite">
          <pre class="newpage">   ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256 but
   offers a modest security advantage over ECDSAP256SHA256 (192 bits of
   strength versus 128 bits).  For most DNSSEC applications,
   ECDSAP256SHA256 should be satisfactory and robust for the foreseeable
   future and is therefore recommended for signing.  While it is
   unlikely for a DNSSEC use case requiring 192-bit security strength to
   arise, ECDSA384SHA384 is provided for such applications, and it MAY
   be used for signing in these cases.</pre>
        </blockquote>
        <br>
      </font></p>
    <p><font face="InputMono-Regular">I would also allow this one to be
        used, even if you personally may not agree with it, or may like
        that particular algorithm / hash, or whatever.</font></p>
    <p><font face="InputMono-Regular">->
        <a class="moz-txt-link-freetext" href="https://www.dns.pl/formularze/ecc_support_in_dns_resolvers.pdf">https://www.dns.pl/formularze/ecc_support_in_dns_resolvers.pdf</a></font></p>
    <p><font face="InputMono-Regular">While looking at Page 4, section 3
        (Conclusions), saying:</font></p>
    <p><font face="InputMono-Regular">
        <blockquote type="cite"><span style="left: 518.563px; top:
            760.342px; font-size: 16.6043px; font-family: sans-serif;
            transform: scaleX(1.04015);" dir="ltr">A similar</span><span
            style="left: 518.563px; top: 780.267px; font-size:
            16.6043px; font-family: sans-serif; transform:
            scaleX(0.961496);" dir="ltr" class=""> observation was made
            for DS digest algorithms. SHA-<span class="highlight
              selected">384</span></span><span style="left: 517.965px;
            top: 800.192px; font-size: 16.6043px; font-family:
            sans-serif; transform: scaleX(0.992524);" dir="ltr"> was,
            unlike GOST R 34.11-94, almost as frequently sup-</span><span
            style="left: 518.563px; top: 820.119px; font-size:
            16.6043px; font-family: sans-serif; transform:
            scaleX(1.03778);" dir="ltr">ported as SHA-256</span></blockquote>
        <br>
      </font></p>
    <p><font face="InputMono-Regular">I would personally say that there
        is no reasons for you not to allow your customers/clients to
        take advantage of the "security advantage", if they want it.</font></p>
    <p><font face="InputMono-Regular">On the other hand, allowing
        signing with e.g. SHA1 is definitely a NO-GO. But as the RFC
        says:<br>
      </font></p>
    <p><font face="InputMono-Regular">DNSKEY 8, 13, 14, 15 and 16<br>
        DS/CDS 2 and 4</font></p>
    <p><font face="InputMono-Regular">is the only ones i would
        *eventually* look at, where I would personally put my priority
        on 14 4, a.k.a. ECDSAP384SHA384.<br>
      </font></p>
    <p><font face="InputMono-Regular">A lot of people on the Internet
        might, like the RFC says, indicate that 13 2 (ECDSAP256SHA256)
        is more than enough, but I personally see no reasons not to take
        the "strongest possible one, while ensuring broad
        compatibility".</font></p>
    <p><font face="InputMono-Regular"><br>
      </font></p>
    <p><font face="InputMono-Regular">True or false? Also applicable to
        the ECDSA @ DNSSEC? Uhm.... Always a good question, when you
        read something "online", but when seeing multiple independent
        sources saying the same, ...?<br>
      </font></p>
    <p><font face="InputMono-Regular">SHA256 and SHA512 have been
        discussed about vulnerable to length extension attacks, where
        SHA384 hasn't:<br>
      </font></p>
    <p><font face="InputMono-Regular">->
        <a class="moz-txt-link-freetext" href="https://news.ycombinator.com/item?id=19916440">https://news.ycombinator.com/item?id=19916440</a></font></p>
    <p><font face="InputMono-Regular">
        <blockquote type="cite">SHA-256 and SHA-512 (not the truncated
          varieties) are known to be vulnerable to length extension
          attacks. This is only a problem if you're using these hash
          functions in a vulnerable way. (Which isn't as uncommon as
          you'd think in homebrew crypto.)<br>
          <br>
          [...]<br>
          <br>
          SHA-224, SHA-384, SHA-512/224, and SHA-512/256 are not
          vulnerable to length extension attacks.</blockquote>
        <br>
      </font></p>
    <p><font face="InputMono-Regular">Other URL's (that I've lost, or
        which vanished) have likewise been shouting out things about
        SHA-224 and SHA-384 not being affected, but that SHA-256 and
        SHA-512 was.</font></p>
    <p><font face="InputMono-Regular">That one could probably also yell
        more and more for 14 4, a.k.a. ECDSAP384SHA384, ... if you would
        really care about DNSSEC "done right".</font></p>
    <p><font face="InputMono-Regular">Although, I wouldn't tend to
        believe that the implementers, according to above, aren't
        implementing the DNSSEC "in a vulnerable way", as quoted from
        the link above.</font></p>
    <p><font face="InputMono-Regular"><br>
        In the end, I would simply set up everything with 14 4, a.k.a.
        ECDSAP384SHA384, unless any customers/clients could provide
        valid justification (including evidence) why it "cannot" be
        used, such as e.g. a TLD not supporting it, could be valid
        justification to make an exception for that particular TLD. But
        in order to make that exception, there would need to be evidence
        (from the customer/client) documenting the claim, so they cannot
        just go with "I don't like this algorithm", or other useless
        crap to go down to for example SHA1.</font></p>
    <p><font face="InputMono-Regular">It would likewise be mandatory, if
        I had anything to say, for public sector/government and
        financial institutions (banks, card issuers, and so on), to run
        DNSSEC and to always secure that they had the strongest possible
        algorithms on it.</font></p>
    <p><font face="InputMono-Regular"><br>
        NB: The reason I'm writing 14 4, a.k.a. ECDSAP384SHA384 all
        along is that I've seen DNSSEC signatures with 14 2
        (ECDSAP384SHA256), which I would find quite weird.<br>
      </font></p>
    <p><font face="InputMono-Regular">Just my two cents.<br>
      </font></p>
    <pre class="moz-signature" cols="72">-- 
Med venlig hilsen / Kind regards,
Arne Jensen</pre>
  </body>
</html>