Re: [Add] fixing coffee shop brokenness with DoH

[Ted Lemon <[e-mail]>]

There are a variety of attack scenarios to account for. DNSSEC is not useful for countering a fake NXDOMAIN attack when the attacker also controls the path and can prevent connection establishment.

However, if the attacker is the resolver, and the resolver isn’t under the control of the path, then detecting a fake NXDOMAIN is useful. 

Sent from my iPhone

> On Jul 24, 2019, at 11:20 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
>> 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
>