Paul, you seem suspicious that there is some underhand camel attack being planned, here, and that the forces of good must assemble to reveal the ugly truth and save the caravan.
I think being able to verify the integrity of a zone as a complete data structure is useful. I think interop is useful. I think this specification is pretty good. I think stable specifications promote interop and make things like this more useful. Your objections seem to boil down to: I don't like this; I'd achieve the kinds of things you want to achieve in other ways. That seems like useful input to a document that discusses the relative merits of doing things in many ways; that's not what this document is about, though. So I must be missing something because I don't understand what you're objecting to. > On Aug 10, 2018, at 16:41, Paul Wouters <[email protected]> wrote: > > On Fri, 10 Aug 2018, Wessels, Duane wrote: > >>> But there are already mechanisms for this at the data set level. (This is >>> a "belts and suspenders" style argument.) What if -err- when, in a zone's >>> distribution, the glue records are either forged or simply fat-fingered? >>> That's covered, in a way that is more efficient - in a lazy evaluation way. >>> Mangled glue never referenced needs not be checked, when it is needed >>> there's backup in the authoritative version. If all else fails, DNSSEC >>> will flag whatever response as suspect. >> >> Yes, certainly DNSSEC protects from modification of answers. It generally >> protects recursives who validate. But it doesn't protect consumers of zone >> files. > > By design.... > >> Another limitation I've mentioned before, where DNSSEC doesn't protect you, >> is that a delegation could be falsified such that traffic goes to an >> eavesdropper that just records but doesn't modify messages. > > but on most networks you connect to that you don't trust, they could > just be monitoring all your port 53 traffic anyway? I don't see this > much as a use case. An attacker that cannot see your traffic, but could > get to see your DNS root queries but only briefly if you cache or > actually use the root zone you just transfered from them. Also query > minimalization makes that use case very uninteresting. > >> I'd also argue that maybe applications shouldn't necessarily trust a file >> just because its "on disk." The application doesn't know how it got there, >> or what may have been done to it. > > Sure but applications should either validate or trust the local > validator loading the zone. So that limits the discussion to > glue/NS only. > >> I'm not sure this is what you mean by "speed of execution" but as an >> example, my implementation (which uses ldns) can calculate and verify a >> SHA256 signed root zone digest in under 100 msec. >> >> $ sort --random-sort root.zone.signed | ldns-zone-digest -t -p 2 -c -v . >> Loading Zone...22539 records >> Remove existing ZONEMD... >> Add placeholder ZONEMD... >> Calculating Digest...Done >> Calculating Digest...Done >> Found and calculated digests do MATCH. >> TIMINGS: load 142.18 calculate 82.72 verify 52.24 update 0.00 > > I don't see it validating the ZONEMD RRSIG here ? :P > > Paul > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
