Subject: DNSSEC and child sigs

From: Miek Gieben <[email-masked]>
Date: Tue, 10 Oct 2000 15:59:08 +0200

Hello,

Should the parent keep the child's key in its zone file or
should the child keep it in its zone file or both? 

The same can be asked about the parent's sig over the child's key.

We can identify the following situations:

                            A         B       C          D
  parent has ..         |key+sig  |key+sig|   -      |key+sig  |
  child has             |key+sig  |key    |key+sig   |   -     |
  ----------------------+---------+-------+----------+---------|
1 init. parent signing  |notify?  | ok    | oob      | ok      |
                        |         |       |          |         |
2 init. child signing   | ok      | ok    | ok       | ok      |
                        |         |       |          |         |
3 parent resign         |notify?  | ok    | oob      | ok      |
                        |         |       |          |         |
4 child resign          | ok      | ok    | ok       | ok      |
                        |         |       |          |         |
5 new parent key        |notify?  | ok    | oob      | ok      |
                        |         |       |          |         |
6 new child key         |oob      | oob   | oob      | oob     |

Explanation

A)
        1) parent signs its zone and notifies the child. But what if the
           child does not react on this notify? We then have a sig clash.
        2) child sign its zone, no problem.
        3) parent signature expires and resigns. The child must be
           informed of this update. This can be done by a DNS notify,
B
           but see 1.
        4) child sig expires. No problem. Child resigns zone.
        5) new parent key. Child must be updated with the new SIG.
           See 1&3.
        6) new child key. Out of band communication is needed here.

B)      
        3) child doesn't have the sig, no communication needed
        5) child doesn't have the sig, no communication needed
        1+2+4+6) see A.

C)
        1) The problem here is that the sig does not exist and will not
                be put in the parent's zone, so an out of band notification
                is needed to update the child
        3) the sig has expired. How does the parent know and out-of-band
           notification is needed to update the child?
        5) see 3.
        2+4+6) see A.

D)
        see B.
        With an added advantage that there is no duplicate information
        DNS. The child will have the key for configuration purposes
        anyway.

It seems that D is the most optimum and B also ranks high, but we see
that bind9 uses either A or C. Why?

Miek Gieben
NLnet Labs

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 10 Oct 2000 14:01:38 -0400

My knee-jerk reaction is that this is a DNSOP issue, as far as determing
the best practice.

>that bind9 uses either A or C. Why?

RFC2535 says that if the child is signed, the child must advertise its
public key and signature that validates the key.  (At least one sig,
whether the sig is allowed to validate is an issue, see the Signing Auth
proto-RFC.)  The RFC also says that the parent MAY also publish the child's
key and the sig.  This is why BIND 9 does A or C.

One problem with D is that the KEY set belongs in the child zone, not the
parent.

IMHO, many of us who have spent time developing DNSSEC have assumed A and C
were the best/only ways to do this.  I don't think B or C had been
considered because we just hadn't thought of those possibilities.  So,
perhaps you have added a new wrinkle to this.  But this wrinkle should be
asked to DNSOP.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.