Changing signature algorithms in DNSSEC is a different process than normal key rollovers. OpenDNSSEC currently does not support performing rolls to another algorithm. The only safe way to do it would be to retract your DS record and go insecure for a short while. However, we now worked out a way to do an algorithm rollover with OpenDNSSEC 1.3 while keeping the zone properly signed and without the need to take the signer daemon offline. Service downtime should not be needed.

During the end of last year, a bug was uncovered in the library ldns. The bug had an off-by-one error which caused some signatures to have the expiration date set to December 31 2012. 64-bit versions are unaffected.

Affected versions: ldns < 1.6.12 (32-bit)
Fixed versions: ldns >= 1.6.12 (32-bit)

Description:
The 32-bit version of ldns has code for converting days since epoch to the day of year. That code had a bug which handled the end of the year in the wrong way. The result of the bug was that some signatures got the intended validity period extended by a year. The signature will be reused by the Signer Engine until the key is rolled. However, the Enforcer is not aware that there exist signatures with such a long validity period. Any affected signature will thus have no post-publication of its corresponding DNSKEY, possibly resulting in validation failure. There is also the risk that the affected signature will be used in a replay attack.

Test for affected signatures:
The affected signatures can be spotted by reviewing your signed zone. E.g. by using the following command:
> grep “20121231[0-9]\{6\} 2011″ signed.zone.file

Remove the affected signatures:
If there are signatures in the zone with extra long validity periods, then it is recommended to recreate all of the signatures. This is done by clearing the internal storage of the Signer Engine. You then wait for the next scheduled re-sign, but you can also force an immediate re-sign (the second command below) to speed up the process:
> ods-signer clear <zone>
> ods-signer sign <zone>

Mitigate replay attacks:
Once the affected signatures are removed from the zone, it may also be advisable to roll your keys. If you have a non-static zone and are changing your zone data, then there is a chance for an attacker to replay old data since the signature is still valid. You need to assess the risk and possible cost of such an attack. If you need to mitigate such an attack, then you need to roll your keys. Rolling keys will invalidate any signatures that an attacker may have stored for later use. If the signature of the DNSKEY RRset was affected, then you also need to roll the KSK:
> ods-ksmutil key rollover –zone <zone> –keytype ZSK
> ods-ksmutil key rollover –zone <zone> –keytype KSK

Solution:
The issue has been fixed in ldns 1.6.12. You should upgrade ldns before the end of this year.

We are now working with the v1.3 release, which will add support for multithreaded signing. The current version of OpenDNSSEC only uses one thread when signing a single zone, which means that you will most likely not get the maximum performance out of your HSM. As our review of HSMs showed us, you’ll need to have multiple connections (threads) to your HSM in order to get 100% performance.

OpenDNSSEC has “workers” which will handle the tasks of each zone. Each worker is single threaded, but using multiple workers will give the effect of multi threading. This requires you to have multiple zones. However, an environment with large amount of signatures and frequent updates typically fits the profile of a single large zone (TLD).

We have now changed the design so that each worker will add RRsets to a signing queue, where a pool of signer threads (called “drudgers”) can grab a signing task and perform it. The number of workers and drudgers can be configured in the configuration (conf.xml). The default value is to have 4 WorkerThreads and 4 SignerThreads. If the SignerThreads tag is not present, it will have the same value as the WorkerThreads. This is so that old configuration files will get the benefit of multithreaded signing.

Below you can find how long time it takes to sign the .se-zone (serial 2010121504) using NSEC, plain NSEC3, and NSEC3 Opt-Out. We are using the SCA6000 with 80 SignerThreads. RSA/SHA-1 with 2048-bit KSK and 1024-bit ZSK. NSEC3 with 5 iterations and salt length 8.

All we have to do now is some more testing before doing a release.

OpenDNSSEC v1.3.0-trunk

NSEC
[STATS] se RR[count=2322389 time=46(sec)] NSEC[count=998562 time=20(sec)] RRSIG[new=1002849 reused=0 time=74(sec) avg=13552(sig/sec)] TOTAL[time=170(sec)]

Plain NSEC3
[STATS] se RR[count=2322389 time=46(sec)] NSEC3[count=998603 time=27(sec)] RRSIG[new=1002891 reused=0 time=74(sec) avg=13552(sig/sec)] TOTAL[time=182(sec)]

NSEC3 Opt-Out
[STATS] se RR[count=2322389 time=46(sec)] NSEC3[count=4265 time=4(sec)] RRSIG[new=8553 reused=0 time=1(sec) avg=8553(sig/sec)] TOTAL[time=63(sec)]

OpenDNSSEC v1.2-branch

NSEC
[STATS] se RR[count=2322389 time=56(sec)] NSEC[count=998562 time=40(sec)] RRSIG[new=1002849 reused=0 time=470(sec) avg=2133(sig/sec)] TOTAL[time=604(sec)]

Plain NSEC3
[STATS] se RR[count=2322389 time=56(sec)] NSEC3[count=998603 time=60(sec)] RRSIG[new=1002891 reused=0 time=478(sec) avg=2098(sig/sec)] TOTAL[time=637(sec)]

NSEC3 Opt-Out
[STATS] se RR[count=2322389 time=56(sec)] NSEC3[count=4265 time=12(sec)] RRSIG[new=8553 reused=0 time=4(sec) avg=2138(sig/sec)] TOTAL[time=95(sec)]

Getting OpenDNSSEC to run as a signer for a very large amount of zones is today not a trivial task. Running the software with a thousand zones is not a big deal. In this blog post I will outline how you can reach an even larger amount of zones – 50000 – using version 1.2.0 of OpenDNSSEC and SoftHSM. Each zone contains about 20 resource records.

(more…)

We would like to present the report “A Review of Hardware Security Modules” that was published today.

This report describes a technical review of four leading network based Hardware Security Modules performed during the fall of 2010. When deriving the review point set the focus was primarily on security features and functionality used for DNSSEC applications. However the more interesting findings were in different areas such as usability and management procedures.

Generally all the modules work as expected and offer the necessary functionality one needs from a secure crypto processor. Which HSM to choose depends on budget, the deployment scenario, performance requirements and other application specific facts. From an application perspective the PKCS#11 interface worked exemplary on all modules. Once set up we hardly experienced any problems with the interface. The only issue worth mentioning is the fact that we needed to execute several concurrent threads (for all modules) in order to achieve a decent HSM CPU load.

There was high level of diversity in how features such as role structure, authorization models and key backup were implemented. A more standardized security and authorization model and nomenclature would have been favourable. Instead each vendor has chosen to integrate with the PKCS#11model in different fashions. An evolvement of the PKCS#11 standard to incorporate more complex than smartcards would probably be advisable.

When performing this review it would have been very helpful to have had access to best practise recommendations for setting up and configuring HSMs. Such a text could also document certain application areas and general deployment scenarios. At the moment the user is referred primarily to vendor specific whitepapers and presentations.

You can read the full report here.