Re: child sig at parent

[Jerry Scharf <scharf@vix.com>]

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