Re: child sig at parent

[Miek Gieben <miekg@nlnetlabs.nl>]

> 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.
this is not what want with our proposal. Indeed if a private key is compromised you are
screwed. But the fact remains that if the private key of .com is compromised
it must recreated 20 million new signatures for all its childeren. To do this
.com must contact all its childeren, get their key, make the sig en return it
to the child. Also not all the secure childeren will respond in time, so .com
will have to say something like, if 50% of my childeren has responded we will
go forward with the new KEY.

> 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. 
this out of band communication is what you want to minimize. All that out of 
band communication is not scalable for ccTLD/TLD's.

> 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.
and then the parent installs a NULL KEY for the child....

> 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 
true, this is crucial, but this is also the case if the sig is stored at the
child.

> is a one-way transaction. Once the key is signed, it is installed in the 
> parent zone, making that zone larger and increasing the traffic requirements 
> for that zone's servers.
true, but zones are growing with DNS also, and we at NLnet Labs have shown
that big zone files are not a problem at all. (http://www.nlnetlabs.nl/dnssec/bigzones.html)
Further, in the beginning the parent stores a lot of NULL keys (for all the zones
that are considered not secure) and the corresponding SIG's.

<snip>

grtz Miek