Does anyone have a pointer to a good resource for current best practices for deployment of DNSSEC, preferably newer than RFC6781?
What algorithms do you typically sign with (RSASHA256, ECDSAP256SHA256, both, something other)?
Feel free to little r me off list if you wish
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"
-> RFC 8624 - Algorithm Implementation Requirements and Usage Guidance for DNSSEC
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.
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:
-> Catalin was quoting me in the article, so it's only fair that I elaborate here. ... | Hacker News
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.
Does anyone have a pointer to a good resource for current best practices for deployment of DNSSEC, preferably newer than RFC6781?
What algorithms do you typically sign with (RSASHA256, ECDSAP256SHA256, both, something other)?
Feel free to little r me off list if you wish
Probably best not to deploy it since it does not solve any practical problems, yet makes huge ddos possible via dns reflection attacks.
I've been using ECDSAP384SHA384 (14) for a few months now, with no problems of note.
I know that ECDSAP256SHA256 (13) is "firmer", but hey :-)...
Mark.
I've been happy with ECDSAP384SHA384 for a few months now. No issues to report. All works. My registrar supports it. End of.
The only other thing I can say to the OP is the whether the registrar supports the uploading of DS records, or derives the DS record from the DNSKEY you submit to them. From another list discussion a while back, the world appears to be split 50/50 on this.
Mark.
RFC8624 "Algorithm Implementation Requirements and Usage Guidance for
DNSSEC"-> RFC 8624 - Algorithm Implementation Requirements and Usage Guidance for DNSSEC
> 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.
Yes. I recommend p256 because the security advantages of p384 are not
significant enough to justify the increased costs in space (packet size)
and time.
If for some terrible reason you need to use RSASHA256, use 2048 bit keys,
same as the root zone.
In the future when support is widespread enough, ed25519 will be the best
choice.
SHA256 and SHA512 have been discussed about vulnerable to length
extension attacks, where SHA384 hasn't:
Length extension attacks aren't a problem in this context.
Tony.
Both 13 and 14 are already smaller than 8 (which is the most widely deployed algorithm today).
512 bits vs 768 bits is not going to break the Internet.
Mark.
For those interested, actual numbers for algorithm deployment can be
found in the DNSSEC parameter frequency analysis section of
https://stats.dnssec-tools.org/.
This appears to be a frequent source of confusion.
In '14 4', '14' is the DNSSEC signing algorithm ECDSAP384SHA384 [1]. '4' is the DS digest algorithm SHA384 [2].
Then, '14 2', is still the DNSSEC signing algorithm ECDSAP384SHA384, and '2' is the DS digest algorithm SHA256.
The DNSSEC signing algorithm is used to sign the zone's content. The DS digest algorithm is what the parent zone uses to digest (hash) the child's DNSKEY (and this digest is then signed by whatever DNSSEC signing algorithm the parent chose).
So, '14 2' is not ECDSAP384SHA256, it's still ECDSAP384SHA384.
[1] Domain Name System Security (DNSSEC) Algorithm Numbers
[2] Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
Kind regards,