-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Won't Fix
-
Affects Version/s: OpenDNSSEC 1.3.14, OpenDNSSEC 1.4.3
-
Fix Version/s: None
-
Component/s: Enforcer
-
Labels:None
-
Environment:
Irrelevant
This bug report is reporting an invalid end of retirement date calculation found in enforcer/ksm/ksm_update.c
The incorrect formula is probably used in all OpenDNSSEC versions, but have been spotted at least in OpenDNSSEC 1.4.3 and 1.3.14.
The formula is deemed incorrect according to :
- draft-ietf-dnsop-dnssec-key-timing-03 ยง3.2.1, event 8,
- my own calculations,
- the following comment that can be found in enforcer/ksm/ksm_update.c :
/* - A key in the "retire" state moves into the "dead" state after a period
- of:
* - TTLsig + Dp + St
* - ... where
* - TTLsig = Signature lifetime (how long a signature is valid for)
- Dp = Propagation delay
- St = Retire safety margin
*/
In the case of a ZSK retirement, the calculation for the end of retirement date is done with the following formula, which uses "zsksiglife" :
deltat = collection->zsksiglife + collection->propdelay + collection->ret_safety;
According to the previous references, the formula should be
deltat = collection->zskttl + collection->propdelay + collection->ret_safety;
The impact of this incorrect duration calculation is that DNSKEY are published longer than necessary and causes larger than necessary DNSKEY RRset (eventually including multiple concurrent retired keys if multiple ZSK rollover occurs within a single siglifetime of DNSKEY rrsets).
This might have various impact, including TCP fallback when the Max UDP Size parameter has been carefully set to the theoretical maximum size of a DNSKEY answer + RRSIGs (which is actually the case in my DNSSEC deployment as the signed DNSKEY RRset is the largest RRSet in my zone).