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.

This entry was posted on Tuesday, January 17th, 2012 at 17:29 and is filed under Deployment. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.