Re: [Add] [EXTERNAL] I-D Action: draft-ietf-add-ddr-01.txt

[Tommy Jensen <[e-mail]>]

> When there is an on-path attacker and the unencrypted resolver is identified by a private IP, DDR-01 results in an encrypted connection to an unintended party.

It results in an encrypted connection to the exact same IP address the client would have otherwise sent unencrypted traffic to anyway. The attacker must be present for all traffic it wants to see/manipulate in both cases. PR#11 adds the ability for this to occur but to a different, possibly off-network, IP address and will continue reaping the benefits for some amount of time after leaving the local path. I argue that is a significantly worse security posture.

> For example, in DDR-01, an on-path attacker can point all requested domains to attacker-controlled IPs with long TTLs, allowing them to stay on-path for application traffic long after the DNS attack is over.

Assuming you mean an attacker on the encrypted path, this requires that either the client establishes and uses a connection to an attacker’s encrypted resolver or that an attacker compromises the encrypted resolver itself, becoming the endpoint (ignoring an attacker who can break TLS, as that attack renders all mechanisms we have moot). The former is prevented by the IP address validation (and scope limiting DDR to those identities a TLS cert can cover); the latter is unrelated to the discovery mechanism used to connect to the encrypted resolver. No discovery mechanism will protect a client against an attacker taking over their recursive resolver.

> I think a similar dynamic applies here.

DV versus OV is resource-cost prohibitive: one is harder than the other. DNR versus PR#11 is time-cost prohibitive: one would be possible right away and the other will be possible eventually. Meaning as time goes on and CE/CPE are sold supporting DNR, networks will be able to advertise whatever encrypted resolver config they want over DHCP/RA without any additional bootstrapping needed by (or attack vectors exposed to) clients. As the same time goes on, the costs of DV versus OV remain the same in ratio (manual verification is always going to be much harder/expensive than automatic).

You’re correct that both PR#11 and DV certs are examples of weaker security postures in the hopes of increasing encryption adoption. However, one is to bring encryption that would otherwise never occur (as the OV bar is too high for many “mom and pop” size domain owners); the other is to bring encryption that could otherwise eventually occur (the 85% problem is rooted entirely in the inability to modify CE/CPE right away faster than hardware turnover in the wild).

In fact, I think this is a great example of why DDR and PR#11 should remain separate. The strength of the ownership guarantee provided by each ownership verification method are significantly different; the same is true for DNS encrypted resolver discovery. One could say the end user will only see “green padlock” or “secure DNS” but under the hood they are very different mechanisms. Why define them together in a single bucket?

Thanks,
Tommy

From: Ben Schwartz <bemasc=[e-mail]>
Sent: Wednesday, June 16, 2021 6:50 PM
To: Tommy Jensen <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Add] [EXTERNAL] I-D Action: draft-ietf-add-ddr-01.txt

On Wed, Jun 16, 2021 at 8:36 PM Tommy Jensen <Jensen.Thomas=[e-mail]<mailto:[e-mail]>> wrote:
...
> In PR #11, private IP upgrade is additionally vulnerable for a short time window after an on-path attacker ceases to be on-path.

This is the difference in security bar I am objecting to. DDR as it stands will never result in an encrypted connection to an unintended party (assuming certificate ownership is secure, the same bar set for general HTTPS usage).

When there is an on-path attacker and the unencrypted resolver is identified by a private IP, DDR-01 results in an encrypted connection to an unintended party.

Your PR undoes that promise in a way that can only be limited, not eliminated.

I don't think it's nearly so clear-cut.  For example, in DDR-01, an on-path attacker can point all requested domains to attacker-controlled IPs with long TTLs, allowing them to stay on-path for application traffic long after the DNS attack is over.  If the client uses any insecure protocols (e.g. HTTP), of course much worse attacks are possible.

> If PR #11 enables significantly broader use of encrypted DNS, as seems likely, I think it would represent an improvement to overall security.

I whole-heartedly disagree with this mentality. Encryption alone is not equal to security.

The modern web is powered almost entirely by Domain Validated certificates.  Unlike the classic Organization Validated certificates, these are highly vulnerable to a transient on-path attacker, who can instantly acquire certificates and persist their attack for months.  Nonetheless, the modern web, where a majority of traffic uses HTTPS with DV certs, is much more secure than the old web where 10% of sites used HTTPS with OV certs, and 90% were unencrypted.

I think a similar dynamic applies here.