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

[Ben Schwartz <[e-mail]>]

On Wed, Jun 16, 2021 at 8:36 PM Tommy Jensen <Jensen.Thomas=
[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.

>