My verision of MaxSigLife's history was Re: ... 03 AD Feedback

The MaxSigLife was intended to limit the span of time an attacker 
could replay the DS record after acquiring (through stealing or 
cryptanalysis) the private key.

If (for example) this sequence of events happens:

on the 1st day of the month you put a key pair into service (meaning 
the parent publishes a DS record and signs from the 1st to the 31st)
on the 3rd day someone hacks in and copies the key pair out
on the 4th day you detect this and place a new keypair into service 
(meaning the parent deletes the old DS and puts in a new one, and 
generates a new signature)

The attacker can replay the parent's RRSIG of the DS set with your 
broken key until the 31st and verifiers will still consider the the 
key good.  This is because there was no revocation in DNSSEC (prior 
to RFC 5011).

When 4310 was written, some in the DNSOP WG felt that the child 
should be able to curtail the window of abuse opportunity by letting 
the child request a shorter (or longer) signature duration than the 
parent's default.

That's the motivation.

But, of the folks with the most experience with this at the time of 
4310's development, no one wanted to add this.  It was added at the 
insistence of folks in the DNSOP WG.  So it was added and made 
optional.

I would recommend against using it.  A signature's duration ought to 
be a function of the strength and reliability of the key generating 
it, making it a parent's internal matter.  I really haven't thought 
much about this wrinkle, but with RFC 5011, it's probably no longer 
needed for any reason.

At 13:45 +0000 2/1/10, [email protected] wrote:

I also can't see how it relates to rollovers - as later messages 
point out, the signature lifetime in the DS RRSIG applies to _every_ 
DS record, and is not on a per-DS basis.  Hence you can't have a 
different life time on different keys as they're introduced - all you 
_might_ do is reduce the lifetime on _all_ keys.

Our initial assessment is that we can see no need to expose this 
parameter to child zones.  The signature on the DS RRset in the 
parent zone is created by the parent, and is the way that the parent 
guarantees to anyone who retrieves the DS RRs that the information is 
from the parent and has not been altered in transit.  All the child 
should be concerned about is data in the DS record; proving the 
authenticity of that data is the parent's responsibility.

Ray


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.