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

[Neil Cook <[e-mail]>]

> 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] <mailto:[e-mail]>> wrote:
> 
> 
> > On 22 Aug 2019, at 08:00, Eric Rescorla <[e-mail] <mailto: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”.


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 
-------------------------------------------------------------------------------------