Subject: Re: [DNSOP] Comments on draft-wessels-dns-zone-digest-02

From: Brian Dickson <[email-masked]>
Date: Mon, 13 Aug 2018 13:42:54 -0700

>
>
> 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.
>
>
While it is easy to misunderstand what Duane is referencing, or perhaps
there was some minimization on his part as well, there is a weakness caused
by the unsigned nature of delegations, whereby not protecting (e.g. via
zonemd) a publication point against a host of vulnerabilities, by
protecting the data itself, creates a very attractive target that lets an
adversary scale their attack very effectively.

Here's the gist of the problem, inherent in unsigned glue:
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.)

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.

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.

IMHO, this is the antithesis of "uninteresting".

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. A
centralized distribution point without data integrity protection of some
kind, becomes a very scalable place for an attacker to do bulk attacks
against large numbers of resolvers. A centralized distribution point WITH
data integrity protection that scales, provide protection against both
centralized AND decentralized (direct cache poisoning) attacks, thus
justifying the effort on doing this exact thing.

Brian Dickson

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.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Aug 2018 13:28:51 +0000

My reason for replying to this thead is to say that “we have other solutions in place for this, why one more?”

On 8/13/18, 16:43, "DNSOP on behalf of Brian Dickson" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wro

>While it is easy to misunderstand what Duane is referencing, or perhaps there was some minimization on his part as well, there is a weakness caused by the unsigned nature of delegations, whereby not protecting (e.g. via zonemd) a publication point against a host of vulnerabilities, by protecting the data itself, creates a very attractive target that lets an adversary scale their attack very effectively.

I think the fears are greatly exaggerated.  We have much experience with bad glue, usually as a result of fat-fingering and poor decommissioning practices.  So there’s some real-world information to work on.

When glue is fat-fingered, traffic is either reduced or not received at the authoritative server.  As fat fingering is the culprit, the zone administrator (usually well connected to the authoritative servers) will know to make an edit somewhere.

I’ve handled one very interesting case of malicious cache poisoning that proved to be due to poor decommissioning. A zone administrator noted that their mailhost address was “poisoned” repeatedly at an open recursive service.  This service permitted remote purging of entries, so even I could go to the service, purge the record, execute a query, see the correct value appear and then replaced by the poisoned value.

The result of this “went to litigation” so I never got a documented final report.  (I’m omitting some details so as not to expose the case, despite this being about 6 years ago.)  But what I did uncover, via calls to the victim and other traces was this.  A sysadmin was fired from the store (from the phone call).  He then (because the cell number traced him in WhoIs to the next employer) went to a competitor and set up their DNS (WhoIs records).  He apparently knew that the victim had transitioned their DNS services from hoster A to hoster B but neglected to purge all of the glue records at the registrar (otherwise, the needle in the haystack would be seen).  This left the glue record still in the database of the TLD and he was able to have an NS record refer to the owner, thus getting the TLD to respond with the should-be-cruft glue.

Due to the failure of the recursive server algorithm (it was home grown) to follow at least the trustworthiness rules in “Clarifications to the DNS”, and without DNSSEC in place, the recursive service believed the stale glue over the authoritative answer for the glue.  After a query for the victim was seen, all that needed to happen was a query for the attacker’s new zone to swap out the glue value, the latter query could have been delivered via a cron entry.

The danger in this case was that mail traffic was misdirected from the victim to the attacker as a denial of service (impact on business operations).  The victim’s MX record’s RDATA domain name was the same as the malicious NS record mentioned before.

In that case, DNSSEC would have helped, a solution we already have but not in place.  Additionally, and this was a conversation I never got to have, the open recursive service’s implementation choice permitted the attack to happen, (I do know it wasn’t a bug, I did get to speak to the lead engineer but never had the chance to educate them) once again, a solution is already there (better software!).

So, I can attest to glue being a weakness.  That’s not in question.

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

Once the tree falls to “insecure” land, all bets are off.   (And this is hard to determine, as trust anchors define the root of secure subtrees, not necessarily what’s in authoritative servers.)

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

If one is overly concerned about someone seeing traffic flows, there are a number of steps to take.  Sending a potentially telling query along an unsecured reference is not one of them.  For one, getting the authoritative version of the glue can be done (this is done in parallel, not before, when traffic inspection fear is less than the desire to get a page loaded).  And then there’s all the privacy widgets being invented.

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

Glue is just a hint.  Over time it has been confused as something more significant, such as when the old COM/NET/ORG servers would put it into the answer section of referrals (a practiced ended before DNSSEC was operationalized).  The solution to this has been better software.

>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. A centralized distribution point without data integrity protection of some kind, becomes a very scalable place for an attacker to do bulk attacks against large numbers of resolvers. A centralized distribution point WITH data integrity protection that scales, provide protection against both centralized AND decentralized (direct cache poisoning) attacks, thus justifying the effort on doing this exact thing.
>
>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.

A somewhat flippant reply – treating theoretical attacks contributes to software bloat without benefit (cue a camel joke).  I mean this seriously – I’d like to see a risk assessment of what’s involved to judge whether as solution is needed or not.  With the way the DNS is defined and operated today, if it was possible to seal up all the holes and cracks, it would have been done by now.  I’d concentrate on demonstrated problems without solutions.

Outside of the lone cache poisoning case I’ve dealt with, I am eager to see any published descriptions of real (more-than-theoretical) attacks.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Aug 2018 15:29:25 -0400 (EDT)

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

---

From: Bob Harold <[email-masked]>
Date: Mon, 20 Aug 2018 09:52:52 -0400

On Sun, Aug 19, 2018 at 3:29 PM Paul Wouters <[email-masked]> wrote:

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

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

> 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
> modification of glue records when copies of zone data are retrieved.
>
> > P.S. Documenting aspects of the more-than-theoretical poisoning attacks
> are long overdue; when time permits, I will work on this, possibly

---

From: Shumon Huque <[email-masked]>
Date: Mon, 20 Aug 2018 10:18:37 -0400

> my copy of the zone might end up different in that regard - is that ok?

This scheme won't work because in the general case glue records for signed
zones may live in unsigned zones and thus may not be validatable at all.
See glue for .COM, .NET, .ORG etc for prominent examples.

-- 
Shumon Huque

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Aug 2018 10:57:36 -0400 (EDT)

On Mon, 20 Aug 2018, Shumon Huque wrote:

> 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?
> 
> This scheme won't work because in the general case glue records for signed zones may live in unsigned zones and thus may not be validatable at all. See glue
> for .COM, .NET, .ORG etc for prominent examples.

Those zones would have a signed ZONEMD but no DS record leading to a
validated path anyway, so those are lost without an external (from
DNSSEC) PKI which falls very far outside the scope of ZONEMD.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Mon, 20 Aug 2018 11:19:01 -0400

Sent from my iPhone

> On Aug 20, 2018, at 10:57 AM, Paul Wouters <[email-masked]> wrote:
> 

What Shumon was referring to is the actual TLD zones themselves.

For example, the NS sets for COM have nameserver names under gtld-servers.net, which is an unsigned zone. 

The A/AAAA records, needed for finding the COM servers aren’t signed, even if attempting to find the AA answer. 

What ZONEMD would provide is a method of validation of the non-authoritative A/AAAA (glue) for the TLD itself.

While not as strong as using NS names in a signed zone, it is still a method of preventing poisoning of those glue records (A/AAAA specifically).

NB: root-servers.net is unsigned.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Aug 2018 11:40:03 -0400 (EDT)

> What ZONEMD would provide is a method of validation of the non-authoritative A/AAAA (glue) for the TLD itself.

It wouldn't add anything. To trust the ZONEMD record, you would need to
have traveled the DS chain from root to .com anyway and gotten valid
answers. At that point you are at the child and you can (and have to)
confirm the DNSKEY there, and then you might as well also confirm the
parental glue you followed in the child you found, since you've reached
that child zone anyway (which secure validating resolves already do
anyway)

> While not as strong as using NS names in a signed zone, it is still a method of preventing poisoning of those glue records (A/AAAA specifically).

You can never prevent poisoning. You have to blindly follow any glue and
verify at the alleged child zone that you reached the real thing, since
IP redirections or MITM are always possible.

> NB: root-servers.net is unsigned.

The number of insecure hops doesn't matter. What matters is finding a
signed zone with a DNSKEY that matches the DS record.

And also as I said before, the attackers that can change glue on you
dwarve in comparison with upstream hops that can just redirect IP
traffic which accomplishes the exact same thing. Fixing the 1% isn't
helpful when any hotel/coffeeshop can redirect your IP streams to
say 192.5.6.30 anyway.

Paul

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2018 12:29:18 -0400

>What ZONEMD would provide is a method of validation of the non-authoritative A/AAAA (glue) for the TLD itself.

No, assuming that the ZONEMD is signed, it just tells you that your
copy of the zone has the same glue as the one the zone's publisher
signed.  As others have noted it may or may not be possible to verify
the glue separately depending on what other zones are signed.

How about if we pare down the draft to say that a signed ZONEMD
attests that the zone has been copied unmodified from the signer, and
leave it at that.  It's not a substitute for DNSSEC.  It's a way to
reliably transfer signed zones over channels other than AXFR.

R's,
John