Subject: Re: [ietf-provreg] rfc4310bis 03 AD Feedback

From: [email-masked]
Date: Mon, 1 Feb 2010 13:45:15 +0000

> The idea is that the child might want to have some maximum above which
> it doesn't go, so that the child can roll keys in a predictable way.
> This unfortunately ignores the effects of the RR TTL on the whole
> issue, and IMO is a foot-gun loaded for bear, because it makes it
> trivially easy to set the RRSIG short enough that an RRSIG expires
> while in cache.  Without a knob to control TTLs, I don't know why
> you'd allow this to be adjusted.

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 5 Feb 2010 09:44:34 -0500

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-masked] 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.