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

[Brian Dickson <[e-mail]>]

> On Aug 23, 2019, at 8:25 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
>> 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.

There are two kinds of “blocked” answers that a resolver doing this kind of blocking would return. All non-blocked answers would pass such a check. 

The two kinds are:
1) A non-zero response code (indicating an error) with Jim’s suggested extended error code explaining why. This “lie” is meta-data only. The only time this response would fail to validate is if it was an NXDOMAIN response, which would require a signed proof of non-existence. Adding Jim’s suggested logic only blocks access, it never requires trusting data in the answer. (Adding a signed proof might be possible but would require adding DNSSEC trust anchors.)
2) A substitute response, typically directing the client (user) to a “walled garden” explaining the blocking and possibly doing other things (like offering the user the option of reporting a false positive). There may be ways to sign these substitute responses, but those would require additional DNSSEC trust anchors (on the client).

If the blocking is done using only the first type of response, the distinction is significant: the client only ever has to trust negative answers marked as “blocked by XXX”. All other answers would validate. The client would never have to trust a bogus positive answer.

If additional trust anchors are used, their use could be restricted to answers marked with extended response codes, and highlighted by the browser as such. In this case, all responses would be validated, either with the standard trust anchor, or with an extra trust anchor used only for blocking.

Brian