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