Re: Agenda time!

[Miek Gieben <miekg@nlnetlabs.nl>]

Hello,

We would like to resolve this issue during 
the timeslot for reports of DNSSEC workshops
at the 49th IETF conference in San Diego.

regards,
Miek Gieben
NLnet Labs

-------

DNSSEC key rollover issues - Storing SIG by parent in parents zonefile only

1. Introduction
2. Resigning a TLD
3. Scheduled keyrollover
4. Unscheduled keyrollover
5. Possible problems
6. Conclusion

1. Introduction

RFC 2535 states that a zoneKEY must be present in the apex of a
zone. This can be at the delegation point in the parent's
zonefile (normally the case for nullKEYs), or in the child's
zonefile, or in both. On writing down operational procedures for
large zones (TLDs) on resigning child KEYs before normal expiration
or during a KEY-rollover, we found that storing the parent's SIG
over the child's zoneKEY in the child's zonefile:
- makes resigning a child's KEY difficult,
- makes a scheduled parent-keyrollover very complicated,
- makes an unscheduled keyrollover virtually impossible.

We propose for a best-current practice document to advice
that the parent's SIG over a child's zoneKEY is best stored
with a copy of the zoneKEY in the parents zonefile. In the
child's zonefile this zoneKEY is best selfsigned only.


2. Resigning a TLD

However, when SIG records are (also) included in child zonefiles,
special procedures are needed to take care of properly and timely
updating also these zonefiles to prevent these children from being
(temporarily) bad. A possible procedure is described in the key
rollover draft from Mark Andrews and Donald Eastlake. Although the
procedure seems implementable, we feel that it will not be
feasable for large TLD and their (millions of) children.

3. Scheduled keyrollover

A scheduled keyrollover is a rollover, that is planned and
announced well in advance before it actually takes place.

When the SIGs, produced by the KEY that is to be rolled over, are
all contained in one single zonefile, there are two parties
involved.

Let us look at an example where a TLD rolls over its zoneKEY. The
new KEY needs to be signed with the root's KEY before it can be
used to sign the TLD zone and the zoneKEYs of the TLD's children.
The steps that need to be taken by TLD and root are:

1] The TLD adds the new key to its keyset in its zonefile.
   This zone and keyset is signed with the old zonekey.
   Then the TLD signals the parent.
2] The root copies the new keyset, consisting of both new and
   old key, in its zonefile, resigns it, and signals the TLD.
3] The TLD removes the old key from its keyset, resigns its
   zone with the new key, and signals the the root.
4] The root copies the new keyset, now consisting of the
   new key only, and resigns it.

Note that this is a 4-step procedure, which can easily be
automated.  Also note that this same procedure can be used
anywhere else in the tree.

When the parent's SIGs, however, are (also) included in the
children's zonefiles, there are three generations (root, TLD,
delegated children) and thus many more parties and zonefiles
involved.
For a large TLD this means many millions of parties and zonefiles.
As now three generations are involved, the synchronisation requires
at least 7 steps.
One step involves waiting for all child-zones to update their
zonefiles. We think that the procedure, described in the draft from
Mark Andrews and Donald Eastlake, will be very difficult to be
carried out correctly by large TLDs since waiting for the (millions of)
child-zones to be updated may conflict with reasonable expirations
times for the intermediate KEYset sigs from the root.

4. Unscheduled keyrollover

Although nobody hopes that this will ever happen, we must be able to
cope with possible KEY compromises. When such an event occurs, an
immediate keyrollover is needed and must be completed in the
shortest possible time.

With two parties involved, it will still be awkward, but not
impossible to update two zonefiles overnight. "Out-of-band"
communication between the two parties will be necessary also,
since the compromised old KEY can not be trusted.
We think that between two parties this is doable.

With the update of millions of zonefiles, and overnight out-of-band
communication and synchronisation between three generations,
doom-scenarios as "reboot of the Internet" come to mind.
We feel that the procedure from Andrews and Eastlake is simply
impossible in such an event.

5. Possible problems

We have asked the dnsop mailing list for comments on this
scheme. There was one concern by Lewis: a child could
be victimized unknowingly by a parent's screw up. We have 
distinguished the following scenarios and adapted our
procedure scenarios where necessary:

1. An unsecured child.
   In this case, the child is always at the mercy of its
   parent.
2. The request is screwed up and the parent signs and
   includes a malformed KEY in its zone.
   With the key-rollover procedure we propose (and described
   above) the child could and should check for this before
   taking the new KEY into production.
3. A malicious person asks the parent to sign a false KEY
   with the intend to hijack the zone. When the child signs
   the new KEY with its old KEY as we propose, this should
   not be possible. Of course, the parent should check the
   old KEY's SIG as part of the procedure.

6. Conclusion
 
Storing the parent's SIG over the child's KEY in the parent's
zonefile simplifies the communication issues enormously.
For a simple resigning, no communication is needed, for a
key-rollover only two parties are involved. When this SIG is
(also) included in the child's zonefile, simple resigning
involves all children and a key-rollover involves three
generations.