Subject: child sig at parent

From: Miek Gieben <[email-masked]>
Date: Tue, 16 Jan 2001 18:19:38 +0100

hi,

This is the idea we announced at the IETF, comments
are appriciated.

grtz Miek
NLnet Labs

---

From: Miek Gieben <[email-masked]>
Date: Tue, 16 Jan 2001 19:53:48 +0100

> This is the idea we announced at the IETF, comments
posting it again, now with the correct numbering.

grtz Miek

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 16 Jan 2001 17:57:39 -0800

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

---

From: Miek Gieben <[email-masked]>
Date: Thu, 18 Jan 2001 22:30:53 +0100

> 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.

> 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.

> it's zone. It's self checking with no opportunity for forgery.
and then the parent installs a NULL KEY for the child....

> 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 
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