Subject: [dnsop] DOP #15: Parental DS correctness check.

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 13 Jun 2005 16:48:58 +0200

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