[Opendnssec-develop] Re: [Opendnssec-otr] Off-by-one error and new year

[Rickard Bellgrim]

>> Remove the affected signatures:
>> If there are signatures in the zone with extra long validity periods,
>> then it is recommended to drop all of the signatures and re-sign the
>> zone. This can be done with the following commands:
>> > ods-signer clear <zone>
>> > ods-signer sign <zone>
>
> This temporarily breaks the domain's validity, right?  This
> should be avoided if possible -- which I think it is.

"ods-signer clear" will clear the internal signatures. New ones will
be created and distributed during the next scheduled re-sign. The sign
command will force this to happen now.

The keys are still there, just that we get a new set of signatures.
Nothing will break here.

> There is no immediate need to do flush signatures --the signatures
> are valid, but they shouldn't last so long-- and the following step
> of key rollover stops future problems from happening.  I would
> not want to remove these signatures in a way that breaks validation.
> and would hope to see support of that in an email of this kind.

I think I need to clarify that the two commands will remove and add
new signatures in one "atomic operation".

>> Mitigate replay attacks:
>> If your 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:
>> > ods-ksmutil key rollover --zone <zone>

> You also mentioned potential future domain invalidity, is that
> also a reason to be choosing to do this?

The reason was that you want to invalidate any signatures that an
attacker can replay. The signatures is valid far longer than the TTL.

> I suppose it comes down to a choice, right?  clear+resign or do a
> KSK rollover (including parent actions).

You should at least do clear+resign and on top of this also do key rollover.

>> Solution:
>> The issue has been fixed in ldns 1.6.12. Upgrade to this version in
>> order to not get affected the next time.
>
> "next time" meaning "you should upgrade to the new LDNS before the
> end of the current year" right?

Yes, will fix that text.

Thanks
// Rickard