Re: [Add] fixing coffee shop brokenness with DoH

[Eric Rescorla <[e-mail]>]

On Wed, Jul 24, 2019 at 7:39 AM Ted Lemon <[e-mail]> wrote:

> On Jul 24, 2019, at 10:37 AM, Eric Rescorla <[e-mail]> wrote:
>
> Yes. But that need not be cryptographically verifiable because the client
> really has no option but to abandon the connection at this point, even if
> it is suspicious of the DNSSEC status.
>
>
> I think you reasoned a few steps faster than I am able to here, Eric.
> Can you walk us through this step by step?
>

Sure. The case of interest here is that you have a client which wants to
connect to domain A and the resolver (or a network attacker) wants to stop
them.

In the case where A is not DNSSEC signed, the attacker just sends NXDOMAIN,
which the client accepts and refuses to connect.

In the case where A *is* DNSSEC signed, the attacker can also inject an
NXDOMAIN. DNSSEC of course won't validate, but the client still doesn't
have an IP address to connect to, so it's only recourse is to error out.
Now, it can show the user a different error than it did for NXDOMAIN, but
these errors tend to be fairly generic anyway (Firefox, for instance, shows
"Hmm. We’re having trouble finding that site."), so from the user
perspective these aren't really very different.

That's actually the best case scenario. As a practical matter, endpoint
DNSSEC error rates are high enough that failure to validate DNSSEC records
isn't a reliable indicator of attack, so as a practical matter, you would
very likely just end up treating this as a simple resolution failure and
show the same error

-Ekr