Re: Keys and DS

[Daniel Massey <masseyd@isi.edu>]

Edward Lewis wrote:
<snip>

> First question.  Is there a requirement/need to have a child provide
> authentication during the sending of material key material to the 
> parent? (By "key material" I am not inferring a KEY set for this 
> question.)
>

I think this is a non issue.  A parent that blindly accepts a
random DS record or NS record allows child zones to be hijacked.

A different issue is the mechanism to authenticate the child's
change in DS/NS.  This may be an in person exchange, a PGP 
signed message, a message signed by a current zone key, etc., 
etc.  It greatly depends on the parent/child in question.
 
> Second question.  Should the child be responsible for sending the 
> generated DS records to the parent?  (This is perhaps a touchy 
> question.)  I won't  elaborate further, I would like to hear 
> opinions.
>

Do you prefer vi or emacs? :)   
 
> Third question.  With the use of DS, if each member of a zone's 
> apex keyset is represented by a (signed) DS record at the parent, 
> is/are SIG(KEY)s necessary?  E.g., If I see this:
>

<snip>

There are two reasons for the SIG.  

First is simplicity.
  Sign the authoritative records in your zone. 
  Period.  End of story.  Let's not append a comment about 
  "unless the record is a KEY and has a signed DS in the 
   parent and each KEY in the apex set has a DS...."

Second, SIGs on the key set are used in a variety of scenarios.
For example, we currently run a couple zones with a policy where
the SIG is absolutely essential for our style of key roll-over. 

Parent policy:
 - parent stores only 1 DS record for a child 
    (may need to be one DS per key algorithm used at child)
 - child uses secure mechanism to send DS to parent
     (experimenting with several options)
 - parent enters an authenticated DS within 1 week of submission
 - no notification is sent to child
    (push the limit of asynch behavior)
 - limit of one DS change per week 
    (exception for emergency such as key compromise)

Recommended child roll-over plan:
  - assume parent has "DS A", SIG by parent.
             child has "KEY A, SIG by A"
  **** child adds "KEY B" to its set so it now has
        {KEY A, KEY B}, SIG A, SIG B.
  - child sends DS B to parent using secure mechanism
  - within week, parent replaces "DS A" with "DS B".
  - child learns of parent action with dig
  - child waits until caches should have dropped DS A
     (3 times TTL) and then removes KEY A to get only
        KEY B, SIG B

The signing of the KEY set allows step **** to be possible and 
helps keep the parent/child exchange asynchronous.
   
Dan