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

[Olaf Kolkman <[e-mail]>]

Hi Miek, Ted, Dan and others.

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


Detail: Since this not only applies to TLDs, where the terminology may
be a little stronger, I think above line should read be 'SHOULD be
kept as'.


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

Except for key compromise I can't see a reason for very short
signature validity. If there is a reason other than key compromise
then the child can put a short validity period on the SIGs in its zone
and sign it's zone more often. 

The validity period of a parental SIG is bound to a minimum set by
operational parameters. That is SLA material, hence the suggested
SHOULD above.


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


This confusion got me to the following thought. Since the idea is more
relevant to dnsops. I will post it there starting a new thread with
subject "One Interaction KEY exchange", please continue the discussion
on this part of the mail there.


Using the ideas from draft-ietf-dnsext-parent-stores-zone-keys-00.txt
this is an alternative to the key exchange mechanism described in
section 4 of that draft (which is the same as in
draft-ietf-dnsop-parent-sig-00.txt)

I think one can restrict the parent-child interaction even more. I get
to only 1 child parent interaction and an optional parent child
interaction. During the rollover the parent only needs to sign keys
once instead of twice.

Consider the following

1. To initiate a key rollover the child replaces the KEYold by the
KEYnew, signs KEYnew and the rest of the zone using the old and new KEY.

Then the child signals the parent to initiate the rollover.

2. The parent fetches the new key with the double signature and verifies
the SIG made with the old KEY with the old child KEY that the parent
is authoritative for. If the SIG is correct the Parent publishes the
new KEY with parental signature.

Since all child zone data is already signed with the new key that
data is also validated against the now signed KEYnew.

3. Once the child notices (or receives the optional signal by the parent)
that KEYnew has been signed the child can remove the SIG made with
KEYold. This is not a resigning exercise. A simple 'grep -v' will do.


To put this in a hopefully readable table:     
__________________________________________________
KEYold is  the child's old key RR
KEYnew is  the child's new key RR
SIGparent(RR) is the parental signature over RR
SIGkeyold(RR) is the child  signature over RR using keyold
SIGkeyold(RR) is the child  signature over RR using keynew
(At all times the child has signed the complete zone with the same keys 
as it signed the KEY record with.)
_______________________________________________________________________________
Time               Parent state              Child state         Comment
_______________________________________________________________________________

0                  KEYold                 KEYold            Before key rollover
                   SIGparent(KEYold)      SIGkeyold(KEYold)
            
1                  KEYold                 KEYnew             Shortly before 
                   SIGparent(KEYold)      SIGkeyold(KEYnew)  rollover
                                          SIGkeynew(KEYnew)  This works 
                                                             because parent 
                                                             is authoritative.

2a   SIGNAL to parent parent fetches KEYnew with the two sigs. It can verify
     SIGkeyold(KEYnew) against the data it holds itself. then replaces KEYold 
     by KEYnew and signs
  
2b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeyold(KEYnew)
                                           SIGkeynew(KEYnew)

          
3a  SIGNAL from parent to child. Child checks signature over KEYnew and 
    knows it can dispose of SIGkeyold(KEYnew)

3b                 KEYnew                  KEYnew       
                   SIGparent(KEYnew)       SIGkeynew(KEYnew)

_______________________________________________________________________________




In the mentioned draft the child always publishes one KEY RR in its
KEY RRset that is signed by the parent. This is not the case in this
model still all arguments in paragraph 7 apply.

Paragraph 7:

"  There are two reasons to have of the child's zone KEY not only at the
   parent but also in the child's own zonefile: 
	1. to facilitate a key rollover  
	2. to prevent local lookups for local information to suffer 
           from possible loss of access to its outside parent

   To cope with 1, secure aware resolvers MUST be aware that during a
   key-rollover there may be a conflict, and that in that case the
   parent always holds the active KEY set.  To cope with 2, the local
   resolver/caching forwarder should be pre-configured with the zone-KEY
   and thus looks at its own zone as were it a secure entry-point.  For
   both things to work, the zone-KEY set must be selfsigned in the child
   zonefile.
"

As far as I can tell this scheme is still immune for fake signals
since the Parent will only update if it finds another key at the child
then the key in it's own zone. Besides, a spoofed new keyset will not
validate since it is not signed with the verifiable SIG made with the
old key.

To cope with point 2 from par 7 the zone administrator should configure
the local resolvers and forwarding caches with the KEYnew somewhere
between step 1. and step 2a. in the table



I welcome your merciless responses :-)


--Olaf


-----------------------------------------------------
  Olaf M. Kolkman      |  RIPE NCC 
     -----------       |      ---------------	   
  RIPE NCC             |  Phone:   [phone]
  Singel 258           |  Fax:     [phone]
  1016 AB Amsterdam    |  http://www.ripe.net
  The Netherlands      |  [e-mail]       
 



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