Re: DNSSEC Best Practices

[Peter van Dijk]

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.xhtml
[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/

Re: DNSSEC Best Practices

[Robert Story]

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 
USC Information Sciences Institute 

Re: DNSSEC Best Practices

[Mark Tinka]

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.

Re: DNSSEC Best Practices

[Tony Finch]

Arne Jensen  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.finchhttps://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.

Re: DNSSEC Best Practices

[Mark Tinka]

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.

Re: DNSSEC Best Practices

[Mark Tinka]

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.

Re: DNSSEC Best Practices

[Ca By]

On Tue, Apr 27, 2021 at 12:34 PM Eric Germann via NANOG 
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
>
>
>
>
>
>

Re: DNSSEC Best Practices

[Arne Jensen]

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

DNSSEC Best Practices

[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?

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