Re: child sig at parent

[ted@tednet.nl (Ted Lindgreen)]

[Quoting Jerry Scharf, on Jan 17,  3:23, in "Re: child sig at par ..."]

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

Although this has been discussed, there is no consensus yet on how
to do it. I've read and heard different (strong) opinions about it,
and also with sig@child the anomaly with nullKEY@parent remains.
Therefore, I don't think the issue dead already.

Especially for the large TLDs, for which we are working, it is
very important that this issue is resolved.

> First, let's just nuke the issue of unscheduled key rollover. If it's the 
> parent KEY that compromized, you're screwed.  ...

Ignoring the problem does not make it go away. There is a chance
that such an event happens. And when it does, we (the TLDs) MUST
have an idea how to handle it. Leaning backwards and accepting that
either verifyably secure domains are not secure anymore or that
these domains just drop off the Internet is not acceptable. We must
have a scheme with workable procedures to handle this in an
acceptable manner. We have been able to write up a workable scheme
for the sig@parent case, but for the sig@child case it just looks
plain impossible.

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

I'm affraid this is incorrect. The whole idea of the parent signing
the childs KEY, is that the parent tells the world it has signed
the right KEY and only the right KEY for this child.
This is not self checking, on the contrairy, it is wide open for
forgery for anyone who want to hijack a zone. (Please replace
all but the first "child" by "hijacker" above to see how easy
this works).

The only way to get this working, is to establish two-way secure
out-of-band communication between parent and child. However, in the
case of (large) TLDs, this is not only complicated because of the
number of children but also because four parties are involved
(registry, registrar, registrant, and domain-administrator) and
there is no direct, let alone two-way secure, communication
between parent and child.

> Now what happens if a child wants to delete a KEY advertisement. In the child 
> case it's a local operation.

This incorrect: when the child deletes its KEY, it drops from the Internet.
The parent must first sign a null-KEY for the child to prevent this. So
its not a local operation, the parent MUST be involved. (If not, the
zone is hijackable).

> Parent KEY rollover is the same amount of computational work in either case. 

I'm affraid you misunderstood the proposal.
- In case of sig@parent:
  - SIG refreshment is a one-step and local issue.
  - KEY rollover is a 5 step and 2-party issue: zone+parent
- In case of sig@child:
  - SIG refreshment 3 step issue and involves zone + all children,
    so millions of parties for the large TLDs.
  - KEY rollover is an 11 step and 3-generation issue:
    zone+parent+children, so also millions of parties for large TLDs.
The amount of computational work is not only the generation of
sigs, but also the distribution and control of the SIGs, and there
is a huge difference.

However, we do not think that the computational work is the main
issue, we think that the organisational work, complicated by the
varying response we learned to expect from the large numbers of
domain-holders, is the problem that the large TLDs fear the most.

Therefore it seems crucial to get this response out of the loop as
much as possible and certainly out of monthly repeating procedures
like a SIG refreshment. We think this can be done, but we need
feedback to understand and hopefully fix all the possible
side-effects.

Regards,
-- Ted.