Re: [Add] data integrity and DNSSEC or DoH/DoT

[Eric Rescorla <[e-mail]>]

On Fri, Aug 23, 2019 at 9:04 AM Jim Reid <[e-mail]> wrote:

> On 23 Aug 2019, at 05:39, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > On Thu, Aug 22, 2019 at 1:41 PM Jim Reid <[e-mail]> wrote:
> >
> >> > On 22 Aug 2019, at 08:00, Eric Rescorla <[e-mail]> wrote:
> >> >
> >> > Suppose that I receive a bogus response to my A record query, how am
> I to usefully distinguish "this is malware blocking" from "this resolver is
> malicious"?
> >>
> >> I suppose draft-ietf-dnsop-extended-error could add another error code
> for the specific case of a malicious resolver. Whatever that might mean.
> Though I doubt the operators of such servers will choose to set that evil
> bit on their responses.
> >>
> >> PS A potential problem with this I-D is these extended error codes
> won’t be signed. So they can be spoofed by bad actors.
> >>
> > Yes, and for this reason I don't see how this solves the problem. It's
> just "resolver blocked it and claims reason X".
>
> Which I thought answered your original question. Though maybe those
> responses should be signed somehow. Handwave, handwave. If you have
> suggestions on how to improve the security considerations of that I-D,
> please supply text to dnsop.
>
> But now I’m confused. Could you please clarify what you mean by malicious
> resolver? We seem to be using different (unwritten) definitions.
>
> I also don’t understand why it matters to distinguish between responses
> that say "this is malware blocking" from "this resolver is malicious”. The
> end result’s the same - the resolver’s not returning the expected DNS data
> for the query. What difference does it make if the resolver’s giving a
> genuine or a bogus reason for doing that? After all, the client will almost
> always believe what the resolver told them. It entered into an implicit or
> explicit trust relationship with that resolver when the client sent its DNS
> queries there.


Let's go back to your original message, which made the distinction between
actual truth and whatever the resolver told you "DNSSEC validation means
you get the truth, the whole truth and nothing but the truth regardless of
your choice of resolver or the transport path between you and that
resolver. DoH and DoT offer no protection at all from a lying resolver -
you’re just guaranteed to receive precisely whatever lies or truth that
resolver sends" This distinction is only relevant if you actually aren't
going to just trust whatever the resolver tells you.

-Ekr