computer_security_key

.SE KSK Algorithm Rollover

At IIS we are very security concious. We were the first TLD in the world to sign their zone with DNSSEC. Being on the forefront of things is a nice feeling, but sometimes you get to feel the pain of it. Having signed so early means that at the time there was only one algorithm to use, RSA-SHA1. The security of SHA1 has been discussed in the community for some time now and even though there is no need for panic, there are more secure alternatives available today.

When you look at the IANA algorithm list the situation is somewhat diffrent from october 2005. There are a lot of algorithms to choose from. Some are clearly inappropriate, like RSAMD5, but how does one choose between all the others? The IETF has tried to agree on some guidance in the question, but no definite answer has been reached. (https://www.ietf.org/proceedings/98/slides/slides-98-dnsop-algorithm-update-wouters-00.pdf)

Sweden has one of the highest percentage of validating resolvers in the world, and we would like to keep it that way. Unfortunately we do not have information on all the validating resolvers in Sweden and their crypto capabilities. That requires us to make a conservative choice and eliminates all ECC algorithms.

There is no need to choose any of the NSEC3 algorithms, since we publish our zone file anyway. This leaves us with a short list of RSA-SHA256 and RSA-SHA512.

The added key and signature size of SHA512 didn’t really attract us and as the root is running on RSA-SHA256 we don’t believe RSA-SHA512 would be worth the effort.

We have decided to run with RSA-SHA256 for the time being.

That’s how we roll

Ripe NCC has some experience with algorithm rollovers and published a very informative blog post about it.

The short verion is that you must follow these steps

  1. Sign with new ZSK, insert RRSIG in zone
  2. Insert new KSK and ZSK in zone
  3. New and old KSK sign DNSKEY set
  4. Publish new DS in parent and remove old DS from parent
  5. Drop old KSK, ZSK and RRSIG from zone

Between all the steps wait at least two times the TTL of your zone.

We will use OpenDNSSECs automatic algorithm rollover. It uses a slightly different approach.

  1. Update KASP database
  2. Generate new keys
  3. OpenDNSSEC will start using the new keys, publishing KSK, ZSK and double signing all records
  4. Publish new DS in parent and remove old DS from parent
  5. Drop old KSK, ZSK and RRSIG from zone

Sidelines

To make the whole process easier on use we have upgraded our infrastructure to run OpenDNSSEC 2.1.3. Not only is this the shiny new version of OpenDNSSEC. This version comes with the capability to roll over algorithms.

We will use OpenDNSSECs automatic roll over capabilities.

What if?

If things go south? We actually do have two instances of OpenDNSSEC. We will perform the rollover on one of them, while the other instance will standby and sign the .SE zone with no changes. So we will be able to fall back in case of any failure.

Timeline

The time line is preliminary. We will start the rollover on the 28th of November. But the time line after that is dependend on many factors, not all of which are under our control.

 Update OpenDNSSEC to version 2.1 (support for automatic algorithm rollover)

 Update KASP database with new policy

 Create new KSK and ZSK in HSM

 Start Algorithm Rollover in OpenDNSSEC

 Start IANA process to update .SE DS records in the root

 Algorithm roll over is done

 Update second OpenDNSSEC instance to use new keys

This article has no tags

About the blogger

Ulrich Wisser Ulrich Wisser Developer at IIS Ulrich is working as a developer at IIS. He is mainly working on our production systems and EPP. Before he came to IIS he worked for ten years as an SEO developer.

Leave a comment

Reply to a comment

Required

Required

Optional

Comments

  • Arsen Stasic 1 december 2017, kl 09.01

    I highly appreciate your effort for the KSK Algorithm Rollover!

    Have you changed your timeline?

    As of today 1st Dec I can’t see a new DS RR for .se in the root zone. It is still the old DS RR for .se:
    dig +noall +answer @i.root-servers.net se ds
    se. 86400 IN DS 59747 5 2 44388B3DE9A22CAFA8A12883F60A0F984472D0DFEF0F63ED59A29BE0 18658B28

    And your nameserver still server the old DNSKEY and show no trace of a new DNSKEY:
    dig +noall +answer @x.ns.se. se dnskey +multi +dnssec
    se. 3600 IN DNSKEY 256 3 5 (
    AwEAAc7JzJQ5XCSxvJDOxY5zloEdFMbSbemhLD/s5PjD
    2MTP1VXJpQK6Dgdb3qAPym/OS2vM+DhOGtyClmoHIfIo
    GY1xwcdK1mTXGRI5j4P0D5T7dBVsnAwvQOZJpBve21Qa
    Keb5HNuaLYlU1jUtO/F32WkF5zpnlJJ3y9ozjXSqN9yP
    ) ; ZSK; alg = RSASHA1 ; key id = 39028
    se. 3600 IN DNSKEY 257 3 5 (
    AwEAAZYYG1hpk8XKHNHpdO/EEg+r4YmIEC4Fn3x2DEsy
    gxDuoT9d/QCiX1pz0omFGCaVfCWHvaScVvWd4xP4kNDn
    SDQxBzPwLEXE3l0cLseMJ2YMQeBPf3hGhLs6VSDnGFKA
    zNG4fhri9EBTLv9ubL8Kx8cWQKuu3A5HRVD3li7lZB+0
    kmUKqGiIQdERKt/Ec36BkK93lyGags5RrR2VDdrXCj9Y
    ay90KCKITk52AbwVoMPm0OYlPbD4ViBPMk5nmh/dPeCo
    ZoVJxgANZ/doVQxR5vDkMBYxuhrXuQk3CvZBB011NsXx
    k9yHtHvp/5gjUVJjvhdRvjRB6/xYR03c9owi/aM=
    ) ; KSK; alg = RSASHA1 ; key id = 59747
    se. 3600 IN RRSIG DNSKEY 5 1 3600 (
    20171213060613 20171130021053 59747 se.
    RZv4345PcBH5ahlGETdgQSDYumG3/YYMlI+CIPqignIY
    oN+SeyeD6vxBs511EZcZGTq+GGe1an2VsA4ZRlI4jfEu
    VxBcv9N52llOE7NPwf4pE3mJaGCAbQKX4NN+6SBW87zJ
    JTUBjmmXyuSni+/0or2/jUquDq23QufWy+AXOYMrerMC
    JE2fokE2ZJtU+9w40PcVvE8sDIU+8JeqvyxT/iC0nUtL
    hGr/zssqdjwJbnyPC1VE/xwr1SJVApZ4RsbcVSp5sPN6
    aSwn4tl2o+Vk2t4rprI4g/y/SduZ1b+AoJRfUjQ5LET6
    aRJ5voutISbqyBqnMxaDNDlGAzzm6crJAA== )

    Reply
  • Ulrich Wisser
    Ulrich Wisser 1 december 2017, kl 09.53

    We have started the rollover with a one day delay. In all our tests OpenDNSSEC started to insert signatures with the new key immideately. Unfortunately when we created the new keys in our production environment OpenDNSSEC did not insert any new signatures into the zone. Therefor we decided to still run with the old zone generation.
    Over night OpenDNSSEC had a change of mind and signed the full zone with the new and old keys. We have run additional tests and found everything to be ok.
    Most probably we will change over to the ”updated” zone on monday.

    Reply