[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 - Having DS sent to the parent, rather than calculated locally by the parent, introduces a host of human and/or process risks/requirements - The DS only needs to be built when the DNSKEY changes (key rollover) - The parent is already trusted with DNSSEC tools, since the parent is signing the parent's zone (including the DS record!) - 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. - 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) 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? Brian _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
