Subject: Re: [dnsop] epp-secdns

From: Samuel Weiler <[email-masked]>
Date: Tue, 15 Mar 2005 01:52:23 -0500 (EST)

Ed writes:

> Currently there are four timing parameters:
>
> 1) TTL suggestion
> 2) vInterval (signing frequency parameter
> 3) startDate
> 4) endDate
>
> If these dates are not honored, the current situation treats this as a
> warning.
>
> Here is what we think it ought to become...
>
> 1) TTL limit
> 2) Validity span limit
>
> Treating failure of the server to accommodate these as hard failures.

In general, I think Ed and I are now on the same page.  I concur
that a validity spam limit (which I called maxRRSIG lifetime) is
needed, and I like the idea of a hard failure, for the reasons Ed
described.  I'm not sure the hard failure is needed for TTL, but
it doesn't sound harmful.  Furthermore, I expect that a resigning
interval (which will be shorter than the validity span) can be
calculated by the parent, as I discussed in:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03337.html

However...the current draft does include those sDate/eDate parameters
for telling a parent when to to first (and last) publish a DS.  From a
security standpoint, they probably aren't strictly needed (it may
depend on what you want the failure mode to be if the child doesn't
contact its parent regularly: do you want the DS to keep getting
resigned forever and always or just timeout?).  I assume there was
some reason for them to be in the draft, so it's probably worth
explicitly asking if that functionality desired by anyone.

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

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 15 Mar 2005 10:18:57 -0500 (EST)

> explicitly asking if that functionality desired by anyone.

Asking this in a different way:  what failure modes do we want to
enable for cases when a child does not regularly contact its parent?
Do we want to enable allowing the DS to timeout (be removed from the
zone), in which case sDate/eDate are probably needed?

-- Sam
.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Tue, 15 Mar 2005 10:02:10 -0500

> explicitly asking if that functionality desired by anyone.

It's been proposed that the sDate/eDate parameters be removed.  The person
that first proposed their inclusion (Mark Kosters) has agreed that they're
probably not needed.

-Scott-

.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Mar 2005 11:11:02 -0500

>that first proposed their inclusion (Mark Kosters) has agreed that they're

Post DNSOP meeting...

Besides the necessary parameters for the DS RR and the ancillary 
DNSKEY RR, there are three issues.

1) Limiting the time-of-vulnerability of a child to a key exposure.

The suggestion is to send a numeric parameter (seconds, relative 
time) along with an update adding a DS RR.

2) Aligning TTLs of the authoritative DNSKEY (in child) and the 
authoritative DS (in parent).

This is probably not necessary.  DNSSECbis (-protocols) contains this 
in section 2.4:

    The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
    (that is, the NS RRset from the same zone containing the DS RRset).

Apparently, we shouldn't be concerned about the TTL.

3) What happens when the server won't honor the request of the 
client, specifically regarding #1?

A hard failure seems prudent, otherwise the server might publish an 
unacceptable (to the child's policy) RRSIG.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Mar 2005 13:45:38 -0500

At 12:15 -0500 3/15/05, Eric Brunner-Williams in Portland Maine wrote:
>This is inconsistent with the (wrong) "choice" forced on PROVREG by some

I love being inconsistent with wrong choices. :)

>process adverse person, for an optional (thank Dog) client policy bit to
>force a client policy on a server, independent of the server's manditory
>policy announcement, or the ability of the server to negotiate (albeit
>clunkily via session tear down and setup with one or more alternatives).
>
>Consistency is the hobgobblin of little minds, and I'm happier with the
>hard failure semantics than the child (or client) binds on the parent (or
>server) semantics we get (optionally) stuck with on data collection.

Cool.

><p3p_hat="on>
>We looked at the problem of putting a temporal guarantee on policies too,
>more to prevent the overhead of re-evaluation and to prevent silent
>revocation than any other reason. If I remember anything I think was
>useful, I'll post it.
>
>Eric

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 15 Mar 2005 22:19:20 +0100 (CET)

> zone), in which case sDate/eDate are probably needed?

Do you want to enable allowing the NS to timeout (be removed from the 
zone), in case the child doesn't regulary contact its parent? If not, why 
would you want this with DS?

 	jakob
.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Mar 2005 16:55:31 -0500

In a master server, nothing "times out."

In a slave server, a zone can expire.

In a verifier, an RRSIG may no longer be valid.  (Or may yet to be valid.)

The absolute times in the start and end date should remain the domain 
of the parent and the parent alone.  The duration between the dates 
can be subject to the child's wishes, but the absolute times will be 
a function of the institutionalized time table for signature 
generation.

At 22:19 +0100 3/15/05, Jakob Schlyter wrote:
>Do you want to enable allowing the NS to timeout (be removed from the zone),
>in case the child doesn't regulary contact its parent? If not, why would you
>want this with DS?

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 15 Mar 2005 12:15:53 -0500

<p3p_hat="on>

Eric
.