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

From: Edward Lewis <[email-masked]>
Date: Sun, 1 Apr 2001 07:42:39 -0400

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: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

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

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

---

From: Brian Wellington <[email-masked]>
Date: Mon, 2 Apr 2001 14:47:59 -0700 (PDT)

> I meant that "there is [sic ;)] a few reasons to have the data in the child."

That does make your argument clearer :)

> new proposal.  I consider that issue somewhat of a red herring in this

OK.

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

> children happened to be those sitting closest to the parent.  Draw from

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.

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

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

> 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