Subject: [DNSOP] <draft-ietf-dnsop-dnssec-key-timing-02> Interaction with Configured Trust Anchors

From: Matthijs Mekking <[email-masked]>
Date: Thu, 28 Jul 2011 19:32:42 +0200 (CEST)

Hi,

I am questioning if the duration of 30 days with respect to adding a KSK 
is the absolute correct value. The 30 days is a validator parameter that 
says a trust anchor must stay in the AddPend state for that amount of time 
before it may actually be used as trust anchor. The new KSK must 
be pre-published two times the Active Refresh, as defined in RFC 5011. 
Roughly, this is indeed 30 days at most.

However, one does not know whether the validator failed to do an 
Active Refresh. If you take into account the retryTime (which is at most 
an hour), the Active Refresh can go up more than 15 days. Suppose a query 
fails just once, the maximum value of the Active Refresh is 15d 1h.

A more accurate value for the add hold-down time at the server side would
be 2 times Active Refresh:

 	Active Refresh = (queryInterval + x * retryTime)

where x is the the number of queries failed. Perhaps adding a Dta, the 
delay between the query and the trust anchor set is actually updated, for 
additional safety.

Also, the remove hold-down time is a validator parameter that can't be 
taken exactly as a value for the server side. Actually, the validator only 
has to see the revoked key once in order to remove it from the set of 
trust anchors. So the remove hold-down time at the server side would be 
only one time the Active Refresh.

By the way, why RFC 5011 says the server needs to keep the revoked key for 
remove hold-down time in the zone, I don't know.

Best regards,

Matthijs