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

[Eric Rescorla <[e-mail]>]

On Tue, Sep 3, 2019 at 6:15 AM Neil Cook <[e-mail]> wrote:

>
>
> On 23 Aug 2019, at 06: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] <ekr@rtfm..com>>
>> 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”?
>>
>
> ...
>
> To be slightly less glib, the dnsop WG has an I-D on extended error codes.
>> [And FWIW lack of a discrete error code(s) for validation failure is one of
>> the things I think DNSSEC got wrong.] draft-ietf-dnsop-extended-error
>> already goes some way to answering your question:
>>
>> 4.16.  Extended DNS Error Code 15 - Blocked
>>
>>    The resolver attempted to perfom a DNS query but the domain is
>>    blacklisted due to a security policy implemented on the server being
>>    directly talked to.
>>
>> 4.17.  Extended DNS Error Code 16 - Censored
>>
>>    The resolver attempted to perfom a DNS query but the domain was
>>    blacklisted by a security policy imposed upon the server being talked
>>    to.  Note that how the imposed policy is applied is irrelevant (in-
>>    band DNS somehow, court order, etc).
>>
>> 4.18.  Extended DNS Error Code 17 - Prohibited
>>
>>    An authoritative or recursive resolver that receives a query from an
>>    "unauthorized" client can annotate its REFUSED message with this
>>    code.  Examples of "unauthorized" clients are recursive queries from
>>    IP addresses outside the network, blacklisted IP addresses, local
>>    policy, etc.
>>
>> 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.
>
>
>
> I don’t see why malicious resolvers would tell clients they are returning
> bogus results.
>
> Yes, and for this reason I don't see how this solves the problem. It's
> just "resolver blocked it and claims reason X".
>
>
> 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.

-Ekr


>
> Neil Cook
> [e-mail]
>
>
> -------------------------------------------------------------------------------------
> Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court
> Nuremberg HRB 24738
> Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael
> Knapstein, Stephan Martin
> Chairman of the Board: Richard Seibt
>
> European Office:
> Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District
> Court Siegen, HRB 8718
> Managing Director: Frank Hoberg
>
> US Office:
> Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
>
> -------------------------------------------------------------------------------------
>
>