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 — Eric Germann ekgermann (at) semperen.com LinkedIn: https://www.linkedin.com/in/ericgermann GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1
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
On 4/27/21 22:56, Arne Jensen wrote:
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.
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.
Arne Jensen <darkdevil@darkdevil.dk> wrote:
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.
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. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Lough Foyle to Carlingford Lough: Northerly or northeasterly 4 or 5, occasionally 6 at first in far southeast, becoming variable 2 or 3 later. Slight, occasionally moderate at first. Fair at first, then showers. Good.
On 4/28/21 11:51, Tony Finch wrote:
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.
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.
On Wed 2021-04-28 12:02:18+0200 Mark wrote:
On 4/28/21 11:51, Tony Finch wrote:
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.
Both 13 and 14 are already smaller than 8 (which is the most widely deployed algorithm today).
For those interested, actual numbers for algorithm deployment can be found in the DNSSEC parameter frequency analysis section of https://stats.dnssec-tools.org/. -- Robert Story <http://www.isi.edu/~rstory> USC Information Sciences Institute <http://www.isi.edu/>
On Tue, 2021-04-27 at 22:56 +0200, Arne Jensen wrote:
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.
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] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xht... [2] https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/
On Tue, Apr 27, 2021 at 12:34 PM Eric Germann via NANOG <nanog@nanog.org> wrote:
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.
— Eric Germann ekgermann (at) semperen.com LinkedIn: https://www.linkedin.com/in/ericgermann
GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1
On 4/27/21 21:31, Eric Germann via NANOG wrote:
What algorithms do you typically sign with (RSASHA256, ECDSAP256SHA256, both, something other)?
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.
participants (7)
-
Arne Jensen -
Ca By -
Eric Germann -
Mark Tinka -
Peter van Dijk -
Robert Story -
Tony Finch