Let me play Candide and stumble into this naively. If we’re imagining very wide spread distribution of the root zone, say 100,000 or 1,000,000 local copies distributed twice a day, I would expect the evolution of a set of trusted sources and the use of some existing secure transport protocol to protect the transmission. No new protocol or data types, just a way of finding the address of one more trusted sources. And the existing set of root servers seems like a perfectly good set of trusted sources.
Steve On Thu, Jul 26, 2018 at 7:45 PM Shumon Huque <shu...@gmail.com> wrote: > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
