Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt

Vittorio Bertola <vittorio.bertola@open-xchange.com> Wed, 04 September 2019 12:31 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC731200F7 for <dnsop@ietfa.amsl.com>; Wed, 4 Sep 2019 05:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etWay8UTGvoY for <dnsop@ietfa.amsl.com>; Wed, 4 Sep 2019 05:31:13 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBFB120091 for <dnsop@ietf.org>; Wed, 4 Sep 2019 05:31:13 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 2077B6A277; Wed, 4 Sep 2019 14:31:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1567600270; bh=joAMZuM1TyUWGlMPKkGxkxNp7Jp8o3qvOVMTYy2lRys=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=p2lGBpEeXGBJtz5KmpznXNBN3KJBGEaJF6ci9Uj3s7jTAIuXlegV/y/UVLxsmVJSt 4m2js9PyNTYNo/pV3ADoquuM8Fi2AsjvpOpfOws+PeaKA0484NYufpRiJwUJ660PgC DB+xsgjleKJiPMg1CItz//7IMJ+ROyIeXQXnhqEuS5k8ESYybyRHNyjZNxOONTmfnE PEw+g1y0DLPoA4bCP8Ms/wB0Lr/cNpcg06lK+mJ0N0bX6T3Tmr8sJbpuRuPv41vh61 9ALwb6Kk/juQK0XBzXu8J7NgEr3DJXY62TiLhm0Vs+HriB4XMOMMQ/CMuX5rLuoZmq IhQND8w5yJHWQ==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 146123C02B5; Wed, 4 Sep 2019 14:31:10 +0200 (CEST)
Date: Wed, 4 Sep 2019 14:31:09 +0200 (CEST)
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Reply-To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: dnsop@ietf.org
Message-ID: <319120265.868.1567600269990@appsuite-gw1.open-xchange.com>
In-Reply-To: <yblblwwhmq3.fsf@w7.hardakers.net>
References: <156541541443.1807.17639675157921847600@ietfa.amsl.com> <yblblwwhmq3.fsf@w7.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.2-Rev11
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KQJM4zQFvNgRfSvNxdD_6UW4eXA>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-08.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 12:31:15 -0000


> Il 10 agosto 2019 20:57 Wes Hardaker <wjhns1@hardakers.net> ha scritto:
> 
> 4) Now that this has had multiple implementations (though they'll need
> to change after the packet format and code changes [that they
> requested]), this is likely ready for last call after passing through
> the document for nits and addressing any last comments raised. 

Given some recent discussions on the ADD list, I think that it could make sense to add a third error code for DNS filtering. Currently, the draft has these two:


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


There is however a third case, which is "blocked by user request". The three cases differ on who made the decision to filter, i.e.:
- code 15 is for when the recursor blocks stuff that its own operator dislikes;
- code 16 is for when the recursor blocks stuff that public authorities dislike;
- the third code would be for when the recursor blocks stuff that the user (the entity that acquired the service) dislikes, e.g. for parental control, destinations not suitable for work, etc.

There was also some discussion on whether these error codes could be accompanied by a URL that the client device can use to display a human-readable explanation to the user, which would be a cleaner solution than the current practice of giving to the client a positive response, but with the IP address of a local web server instead of the original one (a practice that doesn't work well with HTTPS anyway). 

This has many security caveats, and could only work with an authenticated, trusted resolver (which is anyway true of the above error codes in themselves, since an adversarial recursor could just lie on the reason for blocking or even on the fact that it is actually blocking something). It is really too early to say whether this could work or whether it would actually be implemented, and also, on transports other than DoH, I'm not sure if applications could ever access this information. Still, perhaps a note on whether EXTRA-TEXT could bear structured information for certain error codes, and how this mechanism could be later defined, could be useful. 

(Happy to propose text if this makes sense.)

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy