Re: [Add] fixing coffee shop brokenness with DoH

[Eric Rescorla <[e-mail]>]

On Wed, Jul 24, 2019 at 10:32 AM Brian Dickson <
[e-mail]> wrote:

>
>
> On Wed, Jul 24, 2019 at 1:15 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Wed, Jul 24, 2019 at 8:58 AM Ted Lemon <[e-mail]> wrote:
>>
>>> 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.
>>>
>>
>> How?
>>
>
> Assumptions:
>
>    1. One resolver is controlled by the attacker
>    2. The path to the real endpoint is free from control by that same
>    attacker
>    3. Any other resolver, not controlled by that same attacker, is known
>
> This last possibility seems like a pretty narrow case. In the vast
majority of cases, clients have one path to the network.

It's a little surprising to be hearing resistance to local resolver
blocking being cited as a goal here, given that previously I've heard
complaints that DoH (which is effectively a separate path to another
resolver) is a mechanism for circumventing exactly this kind of blocking.

-Ekr



If the attacker's resolver supplies a fake NXDOMAIN, which the client
> detects via DNSSEC, then the client sees the resolver's answer as a
> SERVFAIL.
> The client then consults a different resolver, and gets a non-NXDOMAIN
> answer (validated by DNSSEC), and connects to the correct host.
> Since the attacker does not control the data path to the correct host, the
> client's connection succeeds.
>
> QED (useful).
>
> Brian
>
>