Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

[Brian Wellington <[e-mail]>]

On Sun, 1 Apr 2001, Edward Lewis wrote:

> At 4:28 PM -0400 3/30/01, Brian Wellington wrote:
> >Because that's what you said.  "There is [sic] a few reasons to have the
> >data in the parent.", followed by said reasons.
>
> Oh.
>
> I meant that "there is [sic ;)] a few reasons to have the data in the child."

That does make your argument clearer :)

> >From what I've garnered from discussions, the issue is this:
>
> When the parent needs to change its keys, it will need to resign all of the
> children's keys and make the new signatures available.  (More on this in a
> minute.)  The issue of passing information back and forth at the delegation
> point is equal whether the existing signature-at-the-child is used or the
> new proposal.  I consider that issue somewhat of a red herring in this
> discussion.

OK.

> Now, about the re-signing of the parent.  In Sweden last fall the workshop
> changed the parent's key in the afternoon one of the days.  Stepping
> backwards, the children had submitted keys via an HTTP interface and
> retrieved the signatures via another page.  I forget if the parent
> explicitly retained the keys, but I do know that if a child submitted
> multiple keys sets (ie one for Monday, another for Tuesday), the later key
> set overwrote the first in the parent's system.

Right.  But this shouldn't really be relevant, since no matter where the
signatures are store, the parent needs to be notified when the child's key
set is changed.

> What happened when the parent went to resign its zone, it turned out that
> one of two things happened.  A child's key could either not be resigned
> (the parent no longer had it) or the child neglected to take the action to
> get the new key.  Eventually, the parent marked unresponsive children as
> unsecured.  (A few children did notice and were kept secured.  Those
> children happened to be those sitting closest to the parent.  Draw from
> that what you will.)

Given the lack of a defined parent-child communication mechanism, this is
a problem.  At the workshop, that mechanism was voice, if I recall.  It
could also be something like NOTIFY, though, which would allow the child
to take an action and fetch the signed key from the parent.

> The upshot is that there is a requirement that the parent keep a copy of
> all the children keys in order to make the resigning of the parent work -
> at least in my view.  Now, this requirement could be met in two ways - the
> parent places the children keys in a database off-line where the signer can
> get to them or the parent keeps the keys in DNS.  Personally, I don't care
> which is which (...this is an issue I'd like to get input from TLDs on -
> and NLnet is providing this input).

Or the parent could fetch the key from the child and resign it.  This is
DNS after all; we might as well take advantage of it.  Even assuming an
offline signing process, the parent could obtain (by DNS) all of its
childrens' keys before the resigning process.

> Now, the issue is where the signature goes.  This is a related question -
> recall that there were children who didn't grab the new signatures (because
> they weren't aware of them).  So, does the delegator just cut the middleman
> and publish the signatures that it generated, or does the child need to be
> notified  by (push) or need to poll the (pull) parent.  NLnet is proposing
> cutting out the middleman...

Polling is definitely not the right solution.  Notifying should work.
The client shouldn't necessarily needs to have a dynamic zone - the
response to a notification could be a simple as sending an email to the
zone administrator indicating that a new signed key set should be obtained
from the parent.

> Yet another question...this proposal helps keep the parent-child
> relationship going, but is it secure?

Does it need to be?  When the parent sends key sets to the child, they are
signed.  The parent's key can be verified through the DNS.

Brian



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.