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

[Edward Lewis <[e-mail]>]

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."

>...  But I'm not convinced that operation experience has shown that the
>decision was wrong.  The argument now is that it's somehow easier to store
>keys in the parent.  This is not true.  In both cases, the key must be
>sent from the child to the parent.  In both cases, something must be sent
>from the parent back to the child, whether this something may either be a
>signed keyset or a confirmation doesn't change the fact that it's still a
>message.

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

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.

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.)

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).

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

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

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: [phone]                      Email: [e-mail]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.




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