Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

Vittorio Bertola <vittorio.bertola@open-xchange.com> Fri, 22 March 2019 07:53 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 D84C4130EC0; Fri, 22 Mar 2019 00:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_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 yXDGpJ8lv2Fg; Fri, 22 Mar 2019 00:53:24 -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 AB9DE130EBF; Fri, 22 Mar 2019 00:53:23 -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 507A56A31A; Fri, 22 Mar 2019 08:53:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1553241201; bh=BdbWdzpFsSxLv0hag4+1eqFybJyNuT/B12tdDJimlys=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=f+OD/v2HO9CHRE9LtpR9VwvkCPLHufhQZWDz9oiWyrHAwzoKMHz4Y/3jVoRq4vMMm QuhOgFzT4oUgonhVtupY+kxnfnY8KiACPtqoA1EYklGFcwSrmmnLXxFP7KYd10uiHY 2qEJAnx8x2Z8l0Qb+Ga+LGzzFOpXx2dXm45ykB5sypkR1jU9g7XI0o8b5i8KyVImXK k/Din/Ivlb6/vBhr6uow6uVm1MWTLQMJbSER0y3fKuvGFGP7Vbj6/aQ+J8QS68oZe3 73yB2lq7AzJJvt5UTvm1bqCLv1e9Wvn0EW0OnzvOIMvIjhemhNDSstgmX4KjDJFxkz 5e+pTpQoChWmw==
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 43DA73C0019; Fri, 22 Mar 2019 08:53:21 +0100 (CET)
Date: Fri, 22 Mar 2019 08:53:20 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Christian Huitema <huitema@huitema.net>, Wes Hardaker <wjhns1@hardakers.net>
Cc: DoH WG <doh@ietf.org>, dnsop <dnsop@ietf.org>
Message-ID: <1878722055.8877.1553241201213@appsuite.open-xchange.com>
In-Reply-To: <04C556AF-D3B3-41A5-B119-8FE5F81FB9A7@huitema.net>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <a38cf205-b10e-e8e2-62cf-8e0377dfc1ef@brokendns.net> <4599B066-BA82-4EA8-92C1-F1BE1464A790@puck.nether.net> <b8c58757-3945-ea19-b018-8e59292abf30@cs.tcd.ie> <CAH1iCirBm0NKA2-zw--ZKd3gN1ZCmwZ7_ZOSyaTk+2SMmrtxKg@mail.gmail.com> <EA89EA1A-A1EA-4887-9294-4F68AB5C3211@puck.nether.net> <91A0BBD0-CB73-498E-B4E0-57C7E5ABE0B4@hopcount.ca> <2145465817.5147.1553119548565@appsuite.open-xchange.com> <yblh8bv95l0.fsf@w7.hardakers.net> <04C556AF-D3B3-41A5-B119-8FE5F81FB9A7@huitema.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.1-Rev9
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Z5wghORd-ryYtmcYJPVqeOFmd_c>
Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
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: Fri, 22 Mar 2019 07:53:26 -0000


> Il 22 marzo 2019 alle 4.40 Christian Huitema <huitema@huitema.net> ha scritto:
> 
> Much of the debate is on the second point. One position is that users should be forced to trust the DNS resolver provided by the local infrastructure. Another position is that users have the right to apply their own policy and decide which server they will trust, based on some configuration.

I think this is a mischaracterization of the debate, which actually started because of a third position that you don't mention: Mozilla's public statement that in the future they will force (or, at least, make as a default - clarification requests haven't solved the doubt yet) Firefox users to use a remote resolver chosen within a shortlist that they will manage.

There are some people advocating that in some cases people should have to use the local resolver so that the local network can monitor them and apply policies, but that's always been limited to private / corporate / high security networks. I don't think anyone has ever proposed that all users be always required to use a local resolver, full stop; though, if DoH deployment continues this way, I do see some governments - even in Europe - trying to go in that direction, either by mandating the use of in-country resolvers or by passing GDPR-style legislation that requires any global operator to apply national DNS policies when serving their citizen, or be fined for 4% of their revenues.

In the end, I think that everyone should agree on the principle of user choice (which is actually the first recommendation in my draft). There will then be some discussion on whether the local resolver should continue being the silent default or not; though I note that the opposite policy, i.e. letting each application pick its own default resolver, creates a fragmented mess of a network and makes it much harder for the user to implement any practical choice. But anything different than "users are fully in charge as far as they want" is IMHO dangerous and unmanageable.

Regards,
-- 

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