4

During penetration testing I have seen DNSSEC keys with lengths of 1024 and 512 bits. NIST recommends a key length of at least 2048 bits. So is it correct to assume that these DNSKEY's are unsafe to use? Because 512 bit keys can be decrypted in 30 hours.

Additionally, if a DNSKEY record has a (very) high time to live (TTL) for example a year, how would a high TTL impact DNSSEC security?

Lastly, two questions regarding the same subject:
- If ECDSA is used, how long (compared to RSA) do the keys have to be in order to be secure for DNS record signing (a lower key length)?
- What is the practical risk of a DNSKEY getting compromised?

Eelke
  • 506
  • 1
  • 5
  • 18

1 Answers1

3

So is it correct to assume that these DNSKEY's are unsafe to use?

The 512-bit ones definitely, because they can be factored within such a short time frame.

The 1024-bit ones should be safe because they are most likely Zone-Signing Keys (ZSKs) that are rotated once a month or so and getting brute-force cracking time of 1024-bit RSA keys down to less than a month is still very expensive.

Additionally, if a DNSKEY record has a (very) high time to live (TTL) for example a year, how would a high TTL impact DNSSEC security?

When rotating DNSKEY records you first introduce the new key into the zone, wait until every client has fetched the new key and no client has still the old one cached and then you can start using the new key. So if you have a year as your TTL for your ZSK you effectively can only rotate your ZSK once a year at most which is clearly undesirable.

Now if it is your key signing key (KSK) that has this long TTL you should be better off because these tend to use much longer keylengths (long-term secure ones) anyways. But as soon as you want to / have to rotate the ZSK you really want a "short" TTL.

If ECDSA is used, how long (compared to RSA) do the keys have to be in order to be secure for DNS record signing (a lower key length)?

2048-bit RSA keys offer roughly 112-bit security, thus a 224-bit curve (eg secp224r1) has roughly the same security. 1024-bit RSA keys offer roughly 80-bit security and thus a 160-bit curve (eg secp160r1) and for 512-bit keys we have about 40-bit security which would equal to an 80-bit curve size (of which I couldn't find any examples just now). For more details on these conversions, see keylength.com and this Crypto.SE answer. In practice only 256-bit and 384-bit curves are standardized for DNSSEC.

The length of the ECDSA signature is always aboout two times the size of the curve here (encoding the x coordinates of two points). The size of an ECDSA public key is also roughly twice the curve size (unless compression is used).

What is the practical risk of a DNSKEY getting compromised?

Basically the same as with using no DNSSEC at all, because an attacker can forge records on their way from the authoritative server to potential recursive resolvers or the end user. The only caveat here is that said systems will still think that DNSSEC protects them and thus it will pass eventual "only-DNSSEC validated records) filter.

Community
  • 1
SEJPM
  • 9,500
  • 5
  • 35
  • 66
  • Only P-256 and P-384 are standardized for DNS. ECDSA signature consists of two integers less than the order of the basepoint, which for the NIST Fp curves is equal to the curve order which is the same size as (but not equal to) the p defining the underlying Zp field. And DNS (rfc 6605) encodes just the integers with no overhead. In EdDSA (Bernstein) the signature is indeed a pair of points but they are compressed and thus only a bit larger than the size of the underlying field. – dave_thompson_085 Jun 06 '17 at 06:10
  • @dave_thompson_085 thank you. I updated my answer. My confusion about the lengths came from the miss-remembering of "ECDSA has a factor of 4" where this actually is the relation between security-level and signature size and not between curve-size and signature size (which would yield a factor of 8). – SEJPM Jun 07 '17 at 09:31