Also see thread starting at:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03465.html
Ed was the last to respond
>
> >>
> >> #4.4.3 Security Lameness
> >> #
> >> # Security Lameness is defined as what happens when a parent has a DS
> >> # RR pointing to a non-existing DNSKEY RR. During key exchange a
> >> # parent should make sure that the child's key is actually configured
> >> # in the DNS before publishing a DS RR in its zone. Failure to do so
> >> # could cause the child's zone being marked as Bogus.
> >>
> >> I think it is dangerous to suggest that the parent check the health of the
> >> child. During key rollover, I think the child ought to be looking to see
> >> when the parent has changed the DS record before changing the
> >>child's DNSKEYs.
> >
> >Now I am confused. I can imagine you would not like to see the
> >suggestion that the parent checks the health of the child but you not
> >having a DNSKEY before the parent publishes a DS would really break
> >things. It would at least put the "double signature rollover" to the
> >dustbin and registries would then have to deal with multiple DSs in
> >their zone.
>
> A child can list two KSK's in their zone, ask the parent to DS the
> new one. When the new DS is signed, the old KSK is yanked. There is
> no need for the parent to see if the requested DS corresponds to any
> published KSK, the child ought to be indicating that the new KSK is
> in place by making the request.
>
> I don't see any reason that the parent has to have multiple DS
> records (per algorithm). True, if the child requests a new DS and
> hasn't put the KSK in the zone, none of the child's data will
> validate. In this case, the child feels the pain and the child is
> the one that can fix this.
>
> If the parent has to find it - it's like looking for the bent needle
> in a haystack. And the parent really can't fix the situation -
> putting back in the old DS might prolong a vulnerability that
> prompted the botched rollover.
>
> >> If you have the child looking up and the parent looking down, you run the
> >> risk of a control "loop." I think the burden ought to be on the child to
> >> always make sure it is well represented in the parent, to keep the
> >> attention
> >> focused in one direction. Also, a large delegating parent might waste
> >> time
> >> on the well-run children instead of helping out the needy kids.
> >>
> >> Consider too that a child knows better what it's outage (connectivity)
> >> situation is (than does the parent), which could account for any "missing"
> >> keys.
> >
> >
> >Does changing the "should" into "could" in the above paragraph address
> >your uneasiness.
> >
> > "During key exchange a parent could make sure that the child's key is
> > actually configured"
>
> Could, yes, but I would add "as part of a comprehensive delegation
> check." I don't think we want to say that DNSSEC also incurs higher
> maintenance just because it can - which is what I read here.
I propose the following text as a result:
4.4.3 Security Lameness
Security Lameness is defined as what happens when a parent has a DS
RR pointing to a non-existing DNSKEY RR. When this happens the child's
zone may be marked as "Bogus" by validating DNS clients.
As part of a comprehensive delegation check the parent could, at
key exchange time, verify that the child's key is actually
configured in the DNS.
--Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
