Test of supported DNSSEC algorithms

General discussion
1

Interesting page https://rootcanary.org with test of supported encryption algorithms.

image
image1013Ă—686 54.9 KB

and

Statistics for common and ather algorihms

https://portal.rootcanary.org/rcmstats.html

1 Like
2

Yes, we’ve used this one at Knot Resolver team.

3

Wrong link published.

4

Is DSA not supported by kresd due to its inherent security flaws?

But then RSA-SHA1 is neither secure, is it not, and should not be leveraged by a Delegation Signer?

What about GOST - considered insecure as well?

ED448 - coming to kresd soon? Unbound appears to be supporting it.

5

The three unsupported columns to the left are intentional indeed. I’m not aware of (RSA-)SHA1 being that bad yet, though it’s advisable to migrate away from SHA1; it still feels better to keep validating them instead of forcing them to insecure status (like the other three ones). ED448 waits for gnutls, as that’s where we take all of these from.

I actually had a prototype for GOST support, but the thing is that noone seems to want it (anymore) and even an RFC now dissuades from using it, so we didn’t add it in the end. If I understand it right, even GOST are migrating to a new version of algorithm and that one isn’t standardized for DNSSEC.

2 Likes
6

GOST is old and unsecure Soviet cipher.

7

It is known as broken since 2005 [1] and even now new attack vectors are being discovered [2]. Any conscious Delegation Signer will probably not touch it with a barge pole and even wearing gloves :smirk:

That is probably a matter of convenience as not to raise too many errors that could potentially taint DNSSEC for the uninitiated.

[1] SHA-1 Broken - Schneier on Security
[2] New SHA-1 Attack - Schneier on Security

8

In practice SHA1 algos are still used in DNSSEC relatively a lot. For example, .cz: https://stats.nic.cz/stats/dnssec_by_algorithms/ If I understand it correctly, so far the efficient attacks need long inputs, limiting their use in DNS. When mentioning this… here’s a recent DNS+SHA1 analysis: https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html (I haven’t studied SHA1 attack details myself.)

2 Likes
9

Oh dear. That does not help advocating DNSSEC. But then the number (that is not globally but just for .CZ TLD?) seems to hover around:

  • 5 K - for RSASHA1
  • 240 K - for RSASHA1-NSEC3-SHA1

True, it indeed depends on the context of the potential attack vector.

10

SHA1 is dead.

11

One would reckon but the statistics linked by @vcunat imply that it has not reached every Delegation Signer and/or domain admin…

Also the article cited by @vcunat mentions

SHA-1 is deprecated but still used in DNSSEC, and this collision attack means that some attacks against DNSSEC are now merely logistically challenging rather than being cryptographically infeasible.

Which in the end might give DNSSEC a bad name though not being at fault.

12

For reference, the discussion continued on GitLab (mainly about Unbound on Turris): https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/540

13

Whilst DNSSEC helps domain owners in preventing their domains getting hijacked through DNS there is no benefit to the end user since:

  • no web browser has implemented DNSSEC validation
  • no email client has implemented DNSSEC validation
  • likely other applications that utilise DNS less transparent in the background connectivity to the internet have implemented DNSSEC validation

Despite a Foris script producing a :white_check_mark: when testing DNSSEC validation there is no actual advantage for the user having DNSSEC validation enabled in the recursor, one could even argue that it unnecessarily:

  • consumes bandwidth
  • consumes probably CPU cycles (cryptography)
  • slows DNS resolution and subsequent adds lag in connectivity

without the slightest benefit for the end user.

14

Forged DNS records won’t get to those clients. (If behind a validating resolver and it’s not a name that’s provably insecure.) But I agree that benefit to regular end user still seems negligible, as security of their (web/mail/…) clients is built on other things (mainly TLS).

1 Like
15
16

To my understanding the design principle of kresd and unbound is three-fold:

  1. caching stub resolver that:
    a) forwards DNS queries for public domains from downstream clients to upstream resolvers
    b) caches the DNS responses from upstream and feeds downstream from its cache
  2. validating DNSSEC recursor for public domains
  3. rudimentary authoritative name server for private ip space / domains

With 3) being unrelated to the subject of DNSSEC it would seems to me that (perhaps kresd and unbound differ in the outcome):

  • even if the DNSSEC validation by the recursor part fails the downstream client is being fed by the stub resolver part the DNS resolution rnonetheless and thus the downstream client connects to a domain regardless of the DNSSEC validation
17

I don’t understand reasoning of your last paragraph and I haven’t observed similar behavior, at least not commonly. You can test on intentionally broken domains like http://www.rhybar.cz

BTW, I wouldn’t call kresd or unbound a “stub resolver”, but exact terminology doesn’t seem really important here.

1 Like
18

Pardon if I mixed up terminology…

Thank for the pointer. Indeed DNS resolution fails and thus the protection is there :+1: but the user is left clueless that actually DNSSEC validation is the cause for it and with something like

ERR_NAME_RESOLUTION_FAILED

being exhibited by the browser.

19

Yes, unfortunately SERVFAIL doesn’t nicely indicate the source of error, and that leads even to practical problems like https://bugzilla.mozilla.org/show_bug.cgi?id=1525854

20

OpenSSH team says: SHA-1 is not secure.

https://www.openssh.com/txt/release-8.2

Prevent SSH-1 support!