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
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
