Re: [Add] fixing coffee shop brokenness with DoH

[Eric Rescorla <[e-mail]>]

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

> On Jul 24, 2019, at 11:10 AM, Eric Rescorla <[e-mail]> wrote:
>
> 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.
>
>
> Ah, I see where the disconnect is.   Yes, if the resolver and the network
> are controlled by the same entity, then DNSSEC doesn’t help you to get a
> connection.
>
> However, if you are able to tunnel to a resolver that is not controlled by
> the network operator, then this equivalence no longer exists.   In this
> case, DNSSEC is useful for validating the NXDOMAIN, because the network
> operator is not cooperating with the resolver operator.
>

I'm sorry, I think I'm confused. Where do you think the attacker is
positioned?

-Ekr