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

From: [email-masked] (Ted Lindgreen)
Date: Thu, 29 Mar 2001 11:48:49 +0200

[Quoting Edward Lewis, on Mar 28, 19:41, in "Re: Signature at par ..."]

> Some folks have A records at the zone apex (cnn.com comes to mind), which
> leads me to believe that in the future some folks may have non-zone keys at
> the apex.  This implies that the parent will be signing a mix of zone and
> non-zone keys for such a delegation.
> 
> The idea of having the parent (.com) being authoritative for cnn.com's
> IPSEC key seems somewhat "hard to sell."  I see the point of having the SIG
> be at .com, and therefore the KEYs be from .com, but when we look at the
> non-zone keys, having the parent be authoritative is a hard sell.

Hmm, interesting complication, haven't thought of that before!

After spending a sleepless night on it (not really :-), I came to
the following conclusions:

1. If (when?) zone administrators are putting local-keys (keys to
   be used locally for things like ipsec and whatever else) into
   the zone-key-set, both this administrator and his/her parents
   administrator will not be amused later on.
2. The problem is not really a "draft-ietf-dnsop-parent-sig-00"problem,
   but merely an RFC2535 problem: even if we ignore the formal authority,
   having local keys signed, and thus maintained, by outside
   organisations is a bad idea.
3. The only thing we plead guilty for, is highlighting the
   problem by throwing words as "authoritative" at it, and then
   you are guilty of noticing it :-)
   Of course, it's much better recognizing it now
   then to find out and be sorry later.

So, we better find ways to discourage zone administrators to put
local keys into the externally signed zone-key-set.

The alternative is easy:  put these under a label (keys.child.parent
or ipsec.child.parent), so that this RRset is signed by their own
zone-KEY instead of their parents.

Next question is: how to discourage it. I see three possibilities, but
I have no strong opinion about it yet:

1. Have it forbidden by the protocol. In that case, we must hope
   that implementations really enforce it, to prevent discussions
   like the current "CNAME at the apex" later.
2. Let the market take care of it, i.e. watch TLDs and/or external
   signing authoraties charge obseen amounts of money to sign and
   resign key-sets full of non-zone-keys.
3. Let's hope for the best and feel pity for zone administrators
   children and their parents that are stupid enough to fall into
   this trap afterall.

Hmm, perhaps, 1 is the best afterall :-)

> There is a few reasons to have the data in the parent.  Cement trucks,
> backhoes, and (for those in certain areas) shotguns are reasons. (;))  We
> just had a cable cut severing us from the Internet, so we couldn't get to
> the parent zone.  The upshot of this is that I may want to have self-signed
> keys configured locally to continue secure lookups.  ('Course, who am I
> protecting myself against - if the Internet "is down.")

Yes, agree. We think the local secure aware forwarder/resolver
could (should?) have the local zone-key preconfigured.  By the way,
this will be automatically the case when the local nameservers are
used both for internally use as caching forwarder and externally
as authorative server for the local zone, a configuration we often
see in networks of medium and large organisations. For small
organisations, not running there own nameserver, we need to think
of something else, I'm affraid.

Regards,
-- Ted.

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: Thu, 29 Mar 2001 15:03:07 -0800 (PST)

>    like the current "CNAME at the apex" later.

That seems like overkill.

>    resign key-sets full of non-zone-keys.

Again, overkill.  Having larger keysets doesn't really hurt anything.

>    children and their parents that are stupid enough to fall into

That wouldn't be very productive.

> Hmm, perhaps, 1 is the best afterall :-)

A simple SHOULD in the spec would work.

Brian