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

[Christian Huitema <[e-mail]>]

On 9/3/2019 9:35 AM, Neil Cook wrote:
>
>
>> On 3 Sep 2019, at 18:16, Christian Huitema <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>  
>>
>> On Sep 3, 2019, at 7:34 AM, Neil Cook
>> <neil.cook=[e-mail]
>> <mailto:neil.cook=[e-mail]>> wrote:
>>
>>>
>>>
>>>> On 3 Sep 2019, at 15:46, Eric Rescorla <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>
>>>>     It’s not entirely  useless. The problem it does solve is giving
>>>>     the user a better experience when a site is blocked for
>>>>     resolvers that support this extended Error Code. Currently for
>>>>     HTTPS the user will end up with a TLS connection error of some
>>>>     kind (or a blank page in some browsers). If a resolver returns
>>>>     a “blocked/censored/prohibited” response, then the browser can
>>>>     tell the user that the web page was blocked with an informative
>>>>     message. Assuming this becomes the default behaviour for
>>>>     non-malicious resolvers then I think it will a good signal for
>>>>     distinguishing  "this is malware blocking" from "this resolver
>>>>     is malicious”.
>>>>
>>>>
>>>> I'm not following. Suppose that we add an error code that says
>>>> "this site has malware". Now, I operate a resolver which is
>>>> malicious in the sense that it wishes to block a certain form of
>>>> content (say, access to the IETF) but don't want the people whose
>>>> content I am blocking is being blocked for that reason. So, instead
>>>> I return "this site has malware".
>>>>
>>>> My point here is that a code of this type only tells you what the
>>>> resolver *asserts* the reason it blocked it is, it doesn't
>>>> necessarily tell you what the actual reason that the content was
>>>> blocked.
>>>>
>>>
>>> Ok yes I understand. The blocking reason wouldn’t be that useful in
>>> the general case of not knowing whether a resolver was malicious.
>>> However I think the fact that the resolver is telling you that the
>>> content is blocked is still useful, no matter what the reason for
>>> the blocking is, for the reason described above. For example in your
>>> use-case, the user would see “this site is blocked by the DNS
>>> resolver” (or whatever) rather than “TLS connection error” which
>>> would be the case today.
>>
>> Is there a way to explain how the message is blocked? Such as, "this
>> domain is listed as malware in RBZ malware.example.net
>> <http://malware.example.net/>." Information like that would allow the
>> client to make an informed decision.
>>
>
> The proposal as it’s currently specified doesn’t allow further
> granularity. Also Eric’s point is that you can’t trust the reason the
> resolver gives you, so this wouldn’t be useful. Assuming the client
> did trust the resolver however it may be useful;  although I’m not
> sure how the client would make an “informed decision” - I mean, what
> can the client do except try a different resolver perhaps?

If the client knows why the query was rejected, then it can look a bit
further. Take my example, in which the server would announce that the
domain is marked as blocked in a specific RBZ, "malware.example.net".
The client may decides whether it trusts that specific RBZ. Does it have
a good reputation, or is it known for a trigger-happy behavior leading
to all kinds of false positive? And then, the client may want to check
whether the domain is in fact listed in that specific RBZ, or whether
the resolver is making that up. It can indeed do that by contacting
another resolver. It may or may not do that all the time, it may or may
not expose that as some kind of option. My point is that more
transparency always helps.

-- Christian Huitema