[ietf-provreg] My verision of MaxSigLife's history was Re: ... 03 AD Feedback

[Edward Lewis <Ed.Lewis@neustar.biz>]

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

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, Ray.Bellis@nominet.org.uk 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.