On Thu, Aug 28, 2008 at 12:56:09AM -0400, Brian Dickson wrote:
> [EMAIL PROTECTED] wrote:
> >On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
> >
> >>The DS may be provided by the operator of the subordinate zone, or built
> >>by the parent operator,
> >>most likely the latter.
> >>
> >
> >
> > thats an interesting premise.
> > why do you think this will be the case?
> >
> > (I would posit that the folks generating the DNSKEY will also
> > want to generate the DS hash on their known, trusted signing tools
> > instead of trusting the parent w/ the DNSKEY materials)
> >
>
> Well, here's why:
>
> - The DS is a deterministic function
no arguement there
> - Having DS sent to the parent, rather than calculated locally by the
> parent, introduces a host of human and/or process risks/requirements
as opposed to sending the DNSKEY?
> - The DS only needs to be built when the DNSKEY changes (key rollover)
yes - and the child rolls the DNSKEY, not the parent.
> - The parent is already trusted with DNSSEC tools, since the parent is
> signing the parent's zone (including the DS record!)
assuming facts not in evidence. there is active discussion
about having unsigned zones w/ DS records included.
> - Nothing in the DNSKEY, or in the building of the DS, involves private
> keys, only public keys - so there is no trust issue with the materials.
well... lets agree to disagree here.
> - The DNSKEY is already published, so the parent can trivially get it,
> in a way that is not subject to poisoning (the NS glue is hardcoded in
> the parent zone, after all)
and the NSset comes from the child.... like the DNSKEY and (in my case)
the DS rr. The rational for the child creating the DS is matching key
validity periods with the TTLs at the child.
>
> It isn't something that seemed obvious until I looked at the signing
> stuff. If the DS is deterministic, why create an avenue for expoiting?
see above. :)
>
> Brian
YMMV - my current policy is to create my DS rrs and send them to the
parents.
just like sending the paretn the right NSsset.
--bill
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
