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

[Miek Gieben <[e-mail]>]

On Tue, Apr 03, 2001 at 12:54:14PM -0400, Dan Massey wrote:
> Section 2.1 describes the TTL at the parent but it does not specify 
> anything about the lifetime of the SIG at the parent.  Note that an
> attacker can continue replaying an expired or compromised key until the
> parent's SIG expires. You want to avoid scenarios where the child plans 
> to change keys once a month, but the parent creates SIGs with a lifetime 
> of one year.  Perhaps you need something like the following: 
> 
> The parent and child should agree upon an expiration date for the child's 
> key.  Any SIGs generated by the parent must not exceed this expiration date. 
> 
> In CAIRN, our current plan is that the child will send a self-signed key 
> and the expiration date on that (self-signed) SIG is taken as the key's 
> expiration date.  
we've added:

2.2. SIG expiration considerations
   The expiration lifetime of the parental SIG over the 
child's zone KEY MUST be kept as short as possible. A good
value is one day. If there is a child KEY compromise, the 
SIGs for that zone are only valid for as long as the
parental SIG is valid. The selfsigned zone KEY stored in the
child's zone can have a much longer expiration lifetime.
The SIG at the child does not serve any purpose, a lifetime
measured in years is not uncommon.

-----------
I don't (yet) know if it matters if a child has a shorter
lifetime on the sig than the parent.

> Section 4 describes a scheduled key rollover.  Should there be a transition
> period where both keys are valid?  The old cairn.net plan had a short 
> transition period where both the old and new key were active. After the 
> transition, the zone moved to only the new key.  The current draft seems
> to disallow this.  
We are not sure how or why you come to this conclusion from section
4. The idea was, and still is, to have a short  transition period
where both the old and new key are active.
The actions are:
   Child               Parent              Comments
   add new key                             Old key is still valid.
                       get, check, and
                         sign new set.     Both old and new key are valid.
   use new key and
     remove old key.
                       get, check, and
                         sign new set.     Only the new key is valid.

Perhaps confusing is that from the parent point of view, both
actions look (and are) identical. This is done on purpose to help
automating the parent's actions.

> Section 8 seems to push a lot of complexity into the resolver.  To lookup
> the non-zone (ipsec/ssh/whatever) key for host bar.foo.com, the resolver
> just requests the keyset for bar.foo.com, verifies the set signed by the 
> foo.com zone key, and returns the result.  But to lookup a non-zone key 

Not sure whether this is really true.

In this example, if I were to look (without any knowledge) for an
ipsec/ssh/whatever key for the host "bar.foo.com" I'd look for a
key-set with the name "bar.foo.com" and not for the key-set
"foo.com" (which contains the zone-key for the domain where
"bar.foo.com" resides).

With proper knowledge about what I want from "bar.foo.com"
(ipsec/ssh/whatever) I would very likely also know the name
of the key.

For host with an A RR that points to the zone-name (instead of
a hostname under the zone-name) and without any knowledge, this
clash could happen, but then two unlikely things are happening
(a system administrator putting his "ipsec/ssh" host at the
top of his zone and a user whois aware of ipsec/ssh but unaware
of where to look for the ipsec/ssh key-RR).

So, we don't think this is a resolver problem, its a user problem,
and should not by adding complexity to the resolver.

Regards,
Ted & Miek


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