Subject: [Add] Resolver-level attack on DDR CNAME upgrade from local forwarder proposal

From: Tommy Jensen <[email-masked]>
Date: Thu, 11 Mar 2021 15:38:09 +0000

I wrote this out on the GitHub PR, but am sharing with the list as well. See the PR here for context on the proposal: https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/11

I have concerns about the impact of an attack against the recursive resolver. We have focused on the attacker who has access to the local network hijacking the upgrade process. Let's say instead the attacker is interested in hijacking the traffic for all the clients of the upstream resolver instead.

DDR as currently written: the attacker places a malicious SVCB record in the upstream resolver (x.y.z.w) referring to doh.attacker.example. The attack must also be able to present a valid certificate claiming ownership of x.y.z.w or else the client will reject the upgrade.

DDR with this PR: the attacker places a malicious CNAME record in the  upstream resolver (x.y.z.w) referring to doh.attacker.example. The attacker needs to do nothing else in order to harvest all of the DNS traffic for all clients of the x.y.z.w resolver for as long as the malicious CNAME record goes unnoticed.

The difficulty of the attack is notable, but is far lower than it is without this PR, and has a far larger impact than simple one local network as the transient attacker scenario we have been discussing.

While it's true that this attack could be arguably the same as simply taking full control of the recursive resolver, the difference is that the client will think the connection is more secure than simply sending plain-text queries, which will not be true at a bar lower than "taking control of a TLS identity". That also requires a persistent attack (control of the resolver) versus a transient attack (add a single malicious CNAME entry).

In light of the threat model requests being made during the meeting: is this an attack we want to consider or acknowledge?

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 11 Mar 2021 11:18:49 -0500

On Thu, Mar 11, 2021 at 10:38 AM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> I wrote this out on the GitHub PR, but am sharing with the list as well.
> See the PR here for context on the proposal:
> https://github.com/ietf-wg-add/draft-ietf-add-ddr/pull/11
>
>
>
> I have concerns about the impact of an attack against the recursive
> resolver. We have focused on the attacker who has access to the local
> network hijacking the upgrade process. Let's say instead the attacker is
> interested in hijacking the traffic for all the clients of the upstream
> resolver instead.
>

So we're on the same page: "upstream" implies the use of a forwarder.

DDR as currently written: the attacker places a malicious SVCB record in
> the upstream resolver (x.y.z.w) referring to doh.attacker.example. The
> attack must also be able to present a valid certificate claiming ownership
> of x.y.z.w or else the client will reject the upgrade.
>

In the presence of a forwarder, with present DDR, the client will simply
never upgrade.  Neither this attacker nor the true upstream owner can
trigger an upgrade at all.

DDR with this PR: the attacker places a malicious CNAME record in the
> upstream resolver (x.y.z.w) referring to doh.attacker.example. The attacker
> needs to do nothing else in order to harvest all of the DNS traffic for all
> clients of the x.y.z.w resolver for as long as the malicious CNAME record
> goes unnoticed.
>

To be clear, this is only true when there is a forwarder in place.  The
clients are only indirectly clients of x.y.z.w; they're directly clients of
192.168.x.y.

The difficulty of the attack is notable, but is far lower than it is
> without this PR, and has a far larger impact than simple one local network
> as the transient attacker scenario we have been discussing.
>

I agree that, with this PR, an adversary who can spoof SVCB responses from
the upstream resolver can take control of the query stream, for clients who
are accessing it through a forwarder.  (Clients who access it directly are
not affected due to the TLS IP certificate check.)

> While it's true that this attack could be arguably the same as simply
> taking full control of the recursive resolver, the difference is that the
> client will think the connection is more secure than simply sending
> plain-text queries, which will not be true at a bar lower than "taking
> control of a TLS identity".
>

This section of the draft is called "opportunistic security".  I think it
would be a grave mistake for the client to assume that use of TLS in this
context results in a "more secure" connection.  In particular, a full
on-path attacker can always substitute themselves for the upstream server.

That also requires a persistent attack (control of the resolver) versus a
> transient attack (add a single malicious CNAME entry).
>
>
>
> In light of the threat model requests being made during the meeting: is
> this an attack we want to consider or acknowledge?
>

This is definitely worth considering.  I think the threat you are modeling
(the "spoofer") is an attacker who
* can spoof some DNS responses from the upstream resolver (by implanting
them or by executing a Kaminsky-type attack)
* cannot otherwise modify the resolver's behavior (e.g. to send them back
the query contents)
* is not on-path (cannot observe and modify forwarder-upstream
communication)

Personally, I'm more concerned about an off-path spoofer than the implant
threat.  The concept of an intruder who can modify the system in some ways
but not others seems like a very narrow threat model and uncommon in the
IETF.

The threat this PR defends against is essentially "passive on-path", an
observer who can simply watch the unencrypted stream.

The (insecure) DNS protocol has acquired considerable defenses against
off-path spoofers.  Given the choice between these threat models, I think
that defending against the passive on-path attacker is more valuable.