Subject: RE: [dnsop] EPP-DNSSEC Document Updates (fwd)

From: Samuel Weiler <[email-masked]>
Date: Fri, 4 Mar 2005 02:34:26 -0500 (EST)

> I'm not sure [RRSIG lifetime] is needed as it seems a bit redundant
> to me. Sam please correctly if I'm wrong.

Here's a note on the topic that I sent to Scott back in January that
may explain better.  In short, there is some redundancy is including
BOTH a resigning interval and a maximum RRISG lifetime, but those
numbers will be different.  It may be possible to derive one from the
other, but I'm not exactly sure what calculation should be done for
that.

To be very clear, I do think maximum RRSIG lifetime is a
security-critical parameter and that an EPP client should be able to
request it explicitly.  In the below note, I suggesting calculating a
maxRRSIGlifetime based on the resigning interval (vInternal) -- I
think it would be better to calculate that the other way around,
deriving the resigning interval from the RRSIG lifetime, assuming that
any calculation is done at all.

One could also use the sDate/eDate to specify the maximum RRSIG
lifetime, but that would mean far more frequent EPP updates
(essentially saying "yes, it's okay for you to keep publishing this DS
record for me", and saying it on a very regular basis).  I think Scott
said this was not the meaning he intended.

-- Sam

---------- Forwarded message ----------
Date: Tue, 25 Jan 2005 19:43:31 -0500 (EST)
From: Samuel Weiler <[email-masked]>
To: Scott Hollenbeck <[email-masked]>
Subject: RE: [dnsop] EPP-DNSSEC Document Updates

[dropped the list, because I'm not being coherent today.  Hopefully
you can make more sense out of this than I can.]

> > Section 2.1.2: It's still not clear exactly how the <secDNS:infData>
> > element's sDate, eDate and vInterval should be used: in particular,
> > none of these seem to specify a desired RRSIG lifetime.  Perhaps sDate
> > and eDate are intended to do that, though it's likely that a DNSKEY
> > will be in use for far longer than the requested signing interval --
> > perhaps another field <maxRRSIGlifetime> is needed?  This way a client
> > could say: don't publish this DS until time X, use an RRSIG lifetime
> > no more than 3 days, resigning the DSset every day, and quit
> > publishing this DS after 30 days.
>
> I don't have a strong feeling wither way about the maxRRSIGlifetime thought
> above, but you have the intent correct.  s/eDate describe the client's
> preference for the start and end dates of DS and RRSIG publication in the
> parent zone; vInterval is the client's preference for the parent to
> regenerate the RRSIG every "X" units.  What text would make that purpose
> more clear to you?

We may be confusing each other here.  I see three time periods of
interest:

-- How long a DS is _expected_ to be published.
-- The start and end times on any RRSIG covering it (noting that
   there's a single RRSIG lifetime on the whole DSset).
-- How often the DSset is resigned.

One interpretation of the existing three data elements is that the
parent only resigns the DS when the RRSIG (is about to) expire -- that
could lead to lots of load all at once, as caches suddenly have to
refetch the DS when the RRSIG expires.

Maybe the guidance should be: resign at interval vInterval with
lifetime = current time + vInterval + TTL.  But I'm not sure of that.
I should go reread Olaf's doc...

I can also imagine a case where a zone wants the RRSIG(DS) to have a
maximum lifetime of (for example) 3 days, so that a compromise of the
corresponding private key can be recovered from, without fail, in that
time, but also have the RRSIG regenerated every day, with a renewed
3-day lifetime.

-- Sam

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html