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

That’s why you move the censored Answer Section: data to the Authoritative Section.

Paul

Sent from mobile device

> On Sep 3, 2019, at 09:15, Neil Cook <neil.cook=40open-xchange.com@dmarc.ietf.org> wrote:
> 
> 
> 
>> On 23 Aug 2019, at 06:39, Eric Rescorla <ekr@rtfm.com> wrote:
>> 
>> 
>> 
>> On Thu, Aug 22, 2019 at 1:41 PM Jim Reid <jim@rfc1035.com> wrote:
>>> 
>>> 
>>> > On 22 Aug 2019, at 08:00, Eric Rescorla <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
> neil.cook@open-xchange.com
> 
> -------------------------------------------------------------------------------------
> 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 
> -------------------------------------------------------------------------------------
> 
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add