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

[Jim Reid <[e-mail]>]

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.