On Thu, Jul 26, 2018 at 10:16 PM Davey Song <songlinj...@gmail.com> wrote:
> > - It was not really clear exactly what kind of problem this digest >> tries to solve, especially given that the primarily intended usage >> is for the root zone, which is DNSSEC-signed with NSEC. >> > > It puzzled me as well. > > It is said in the document that diffferent from DNSSEC (and NSEC), the > zone digest is for the intergirty of unsigned NS and Glue of the zone. As I > asked in IETF102: why unsigned NS and glue is worth of protecting by > introducing a new RRtype, addtional complexity of degesting and validation. > Is it really necessary for local resolver(or local-root) aware the integity > of NS and glue? any technical problems if the NS RR and glue are > modified locally? > The ZONEMD digest is over the entire zone, not just the delegation NS and glue records. Normally, in order to ensure that secondary servers accurately got a copy of a zone from the master server, we would use a channel protection mechanism like TSIG. This is typically needed even if they were no unsigned data in the zone because authoritative servers do not typically validate signatures of the data in zones they themselves serve - in theory they could, but in fact I don't know any implementations that validate RRSIGs received over zone transfers - they just trust the source and serve the data. Resolvers validate signatures. Authoritative servers that serve signed zones trust that they have already have an authentic copy of the zone. The problem for wide scale distribution of the root zone, is that traditional TSIG (without adding a complex key management infrastructure) doesn't scale. Earlier in this thread, I had proposed that SIG(0) could be a scalable solution to this problem, but it has some limitations, and Duane has argued that the full zone signature is a better solution. I'm not opposed to this, but I think Mark Andrew's XHASH proposal is worth thinking through also. Even if the local-root-zone resolvers were modified to validate signatures of signed RRsets in the zone, if a MITM attacker fed them bogus glue, to recover from this, they would need operator intervention to manually retransfer the zone. This doesn't strike me as a robust operational configuration. --Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
