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

[Dan Massey <[e-mail]>]

On Friday, March 30, 2001 at 12:35PM, Ted Lindgreen wrote:
| 
| But, perhaps you refer to registry testbeds?  I know of two
| implementations: one at CAIRN and one over here at NLnet Labs.
| 
| The former uses the KEY+parentalSIG @child scheme. From private
| communication during the last IETF (50th) with the
| authors/zoneadministrators I know that most, of not all, of their
| test child zones are currently BAD.  They told me that they consider
| their setup as very difficult, if not impossible, to maintain, and
| that they are considering to adopt the parental-SIG@parent scheme.
| 

First, I'd like to follow up on the above comment.  In CAIRN, we have 
found that the SIG at child approach makes changing parent keys 
operationally difficult and we are testing the NLnet Labs approach.  
Currently we have some people working out the operation guidelines
and revising our key registration and rollover procedures appropriately.  
The switch should be complete soon.  

With respect to the latest sig@parent draft, I think this a good idea
but I have some questions/comments.

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.  

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.  

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 
for foo.com, the resolver requests the keyset for foo.com and gets only the
zone keys.  At this point, the resolver must be smart enough to know that
the requestor wants something besides zone keys and the resovler must be 
smart enough to send a query for the keyset of f.i.keys.foo.com.  

Shouldn't the query just say keyset for foo.com, not this particular type of 
KEY record?  Will this work for recursive queries?  If the foo.com zone 
chooses a name other f.i.keys.foo.com, how will the resolver know what to
ask for?  

Dan


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