I thought this has been discussed to death. This is close to how DNSSEC was
originally proposed to work. It was through the insistence of people thinking
about how to handle large TLDs that this was changed.
First, let's just nuke the issue of unscheduled key rollover. If it's the
parent KEY that compromized, you're screwed. There is no ability to withdraw a
valid SIG until the time in the SIG expires. Anyone can replay that SIG at any
time until it expires and nothing can be done to prevent this. It's a design
decision fundamental to DNSSEC and it's ability to fit into DNS and scale.
Now let's look at the transaction to add a KEY in the child scenario and the
parent scenario.
In the child scenario, the child sends the key to the parent out of band, the
parent creates a SIG for the key and sends it back to the child out of band.
The child ckecks the SIG to make sure everything is clean then installs it in
it's zone. It's self checking with no opportunity for forgery.
In the parent scenario, the child sends the key to the parent to be signed.
The parent must certify the authority of the request very carefully, as this
is a one-way transaction. Once the ley is signed, it is installed in the
parent zone, making that zone larger and increasing the traffic requirements
for that zone's servers.
Now what happens if a child wants to delete a KEY advertisement. In the child
case it's a local operation. In the parent case, we have another one-way
transaction to secure. Given that some cases for this may want this to happen
as quickly as possible, the parent is not attached to a time critical path.
Not ot pick on Mark, but I think neither a registrar who will remain nameless
nor I want that loop. There could be serious legal ramifications to failing to
remove such an advertisement in a timely way.
Parent KEY rollover is the same amount of computational work in either case.
It's just that in the child case, the action needs to be initiated by the
child based on the SIG expiration information. There may want to be something
that can notify children about the desire to withdraw a KEY before SIGs
expire, but that should not be confused with security.
So for the improved security due to the removal on one-way parent
transactions, greated scalability and a possible lower risk to the parent, we
make it somewhat harder to do rollovers. A good trade IMO, and not something
to be fixed or unfixed depending on your historical view.
jerry
