Cryptographic sanity: Key sizes

Written by Rick van Rein in category: Crypto, Timing

WikiMedia commons

In our architecture, we consider three levels of users:

  • End users who understand DNS at a conceptual level
  • Operators who understand DNS at an operational level
  • Security officers who are mindful about the cryptographic intricacies of DNSSEC

After initial setup has been done, a security officer only needs to oversee the secure operation of the system, and keep up to date with cryptanalytic advances by monitoring the security landscape. Any organisation which is security-aware has a few people running around who can fulfill that role.

The main responsibility of the security officer is to balance key sizes against validity periods of such keys. DNSSEC operational practices include two keys to help straighten that balance:

  • Zone Signing Key (or ZSK) for signing individual records in a zone
  • Key Signing Key (or KSK) for signing the ZSKs

The idea behind this separation is that there are only a few signatures to validate that were made with a KSK, so it can have a higher security qualification than the ZSK. Having a longer KSK means less rollover of these keys, and thus less of the complicated interactions with the parent zone. The result of a lower-grade ZSK is that it can help to quickly resolve quite a few DNS records, but the disadvantage is that it cannot be safely used for long periods. This means that the ZSK must be replaced every month or so. Software like OpenDNSSEC or ZKT is designed to automate such processes, and because it all happens internally to the zone it need not cause anxiety. The KSK is a different matter altogether; its validity is stated by the parent zone, which signs and publishes secure hashes of the KSK(s) that it has been told to trust through a secondary channel like EPP. The mere fact that other parties are involved in setting up or tearing down a KSK, thus making it more complicated to change, means that it is better to design that key for a higher level of security.

The first security choice to make about the keys used is their algorithm. The options are roughly DSA, RSA and Elliptic Curve algorithms. There is no established DNSSEC algorithm for Elliptic Curve signatures, although it is foreseen to be added at some point. Of the remaining options, DSA signatures take longer to verify than RSA, and the security cannot be upgraded as easily as RSA, where you can pick any key size which is a multiple of 8. So RSA is our public key algorithm of choice.

Now, how long are the ZSK and KSK? Generally advised lengths are 1024 bit for a one-month ZSK and “longer” for the KSK. Note that “longer” need not mean the double length: The search space doubles with every few bits added to a key, and in general the cracking effort grows exponentially with key size. Longer keys however, also waste resources on resolvers, which we prefer to keep as fast as possible. For a one-year period we would currently consider 1280 to be a good KSK key size. Alternatively, we could go for 2048 bit and simply state that it is intended for “several years to come” and document a key rolling procedure in so much detail that we needn’t re-invent it when the time comes to roll the KSK. General guidelines for this class of decisions was initiated by Lenstra and Verheul, with an online resource on key size estimates: This work gives a clear indication of the key sizes and how many years they ought to be reliable from a given start year. These estimates are generally considered conservative and excellent.

Before signing resource records with RSA, the data to be signed is first securely hashed. Since this could break the signature in spite of the strength of RSA, it is advisable to pick wisely. MD5 is known not to be good enough. SHA1 is also making cryptographers feel a little edgy, because advances are being made in cracking it. The job has not been completed, but it eventually will. The currently advised algorithm to use for DNSSEC signatures is RSA/SHA-256. This uses the SHA-256 algorithm, which produces a 256-bit hash so that even the easiest attack (a so-called birthday attack) would take an an incredible amount of computing power — beyond the limits of what is believed to be practical for many years to come.

The last point where cryptography comes in play, is with NSEC3. We will discuss that topic separately.