DNSSEC Best Practices

Tue Apr 27 20:56:50 UTC 2021

Den 27-04-2021 kl. 21:31 skrev Eric Germann via NANOG:
> Does anyone have a pointer to a good resource for current best
> practices for deployment of DNSSEC, preferably newer than RFC6781?

RFC8624 "Algorithm Implementation Requirements and Usage Guidance for
DNSSEC"

-> https://tools.ietf.org/html/rfc8624

>
> What algorithms do you typically sign with
> (RSASHA256, ECDSAP256SHA256, both, something other)?

Those two mentioned are the ones that the vast majority seems to sign with.

As to quote the above mentioned RFC:

>    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.

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.

-> https://www.dns.pl/formularze/ecc_support_in_dns_resolvers.pdf

While looking at Page 4, section 3 (Conclusions), saying:

> A similarobservation was made for DS digest algorithms. SHA-384was,
> unlike GOST R 34.11-94, almost as frequently sup-ported as SHA-256

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.

On the other hand, allowing signing with e.g. SHA1 is definitely a
NO-GO. But as the RFC says:

DNSKEY 8, 13, 14, 15 and 16
DS/CDS 2 and 4

is the only ones i would *eventually* look at, where I would personally
put my priority on 14 4, a.k.a. ECDSAP384SHA384.

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".

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, ...?

SHA256 and SHA512 have been discussed about vulnerable to length
extension attacks, where SHA384 hasn't:

-> https://news.ycombinator.com/item?id=19916440

> 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.)
>
> [...]
>
> SHA-224, SHA-384, SHA-512/224, and SHA-512/256 are not vulnerable to
> length extension attacks.

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.

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".

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.

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.

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.

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.

Just my two cents.

-- 
Med venlig hilsen / Kind regards,
Arne Jensen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210427/9b1bfd7f/attachment.html>