On Sun, Aug 19, 2018 at 3:29 PM Paul Wouters <p...@nohats.ca> wrote: > On Mon, 13 Aug 2018, Brian Dickson wrote: > > > Subject: Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02 > > > IF (big if, with the how/when/where etc kept as a separate discussion) > an attacker manages to modify glue (for example, poisoning a > > resolver's cache for glue info), the attacker has the opportunity to > selectively return unmodified glue, or to replace further glue data (and > > continue to be a DNS-MITM) and thus both view queries, and if/when the > queries cross to insecure delegations, modify non-glue data. For > > example, if there is a TLD "foo", and the attacker manages to poison the > A record for one (or more) names of NS for "foo", the attacker can > > act as a forwarder for most *.foo names, but then selectively modify the > A records for the NS for "bar.foo", and then for "blech.bar.foo", > > until there is an insecure delegation, at which point the attacker can > spoof any RR type for any name below that zone cut. The attacker also > > has control over TTLs of any/all spoofed records, modulo recursive > resolver's TTL ceiling/floor. The attacker can gain further information > > about the ongoing success of attacks by TTL-based meta-monitoring (high > TTL on delegation glue, low TTL on sub-delegation glue, observe > > sub-delegation re-queries at the spoofed delegation point.) > > I don't think this document should make any decisions based on helping > non-DNSSEC domains be more secure by providing transport security that > depends on some different PKI system than DNSSEC. > > The solution against spoofing is DNSSEC, not some kind of out-of-band > zone transfer. > > > Even in the case of an all-DNSSEC sub-tree, some attackers may see value > in observing ALL the queries (and answers);being a DNS-MITM (via > > modified glue) achieves this, even for an off-path attacker who normally > would not have any visibility to the UDP/53 packets. > > When using DNSSEC, the resolver should follow the glue and then perform > a query at the child zone to confirm the glue data. In unbound.conf > terms this is called harden-glue: yes >
I had not thought of this, thanks for mentioning it. So if I transfer a copy of the root (or other zone), I can verify the signed parts with DNSSEC, and the glue by resolving them and verifying from the child zone. Does that leave any unverified records (are glue the only unsigned records)? Note that the child might have different records than the parent glue, so my copy of the zone might end up different in that regard - is that ok? -- Bob Harold > > The above scenario works even on networks you trust, and even with > resolvers you know and trust, as long as there is the ability to attack > > the glue. A single successful attack on a single resolver's glue has the > potential to result in a persistent long-lived DNS exploit, the > > scope of which is largely limited by the attackers resources and/or > intent and/or desire to evade detection. Application of such an exploit > > is an exercise in Kaminsky, i.e. the danger is obvious. > > This is a DNS spoofing attack by a attacker that's not on path. I think > compared to on-path MITM's (and unjustly trusted resolvers) being able > to rewrite glue, this issue is a tony fraction of the problem. And again > in my view this document shouldn't attempt to address it. > > > The theoretical existence of this sort of attack, should be motivation > enough to advocate for greater DNSSEC deployment efforts. It should > > motivate any and all methods of preventing undetected (and undetectable) > modification of glue records when copies of zone data are retrieved. > > This is where we really disagree. the protection against any DNS spoofing > is DNSSEC, not some bandaid applied later in the transport layer. > > > A centralized distribution point without data integrity protection of > some kind > > We have intergrity protection, see the harden-glue: comment above. > > > P.S. Documenting aspects of the more-than-theoretical poisoning attacks > are long overdue; when time permits, I will work on this, possibly > > with interested parties. Any/all are welcome to work on this with me, > FYI. > > I'm not sure I see value in a long document of various DNS spoofing that > as solution has "deploy DNSSEC and confirm glue in the signed child zone". > > Paul > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
