Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Vittorio Bertola <vittorio.bertola@open-xchange.com> Tue, 21 August 2018 10:34 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 A8A5D130DEB for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 03:34:00 -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 F3sv1pD03KCT for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 03:33:58 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB2E130DC4 for <dnsop@ietf.org>; Tue, 21 Aug 2018 03:33:58 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 7591D6A369; Tue, 21 Aug 2018 12:33:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1534847636; bh=KrRr4UT80vjM+4+9OW8ko8EGIdAmx7dCP2d/LPEguU0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=5uAeV1kIeQIM3/FzbXQLFsVrWBifLpzxxeWLfymK7ATiWZ1n9MAXCOi5EccULe/aC tCBSqFYi+4O/csEFJ60IGldwVhwD+FI30E4VLAfgO5sBdQOOfhZvMLKyyWwCWFxtXe iHyX4/w21vCFcRBAfIgUQOO0nY++H2IA+DGwMo9MQ55SqA+Z3VKbH4KuAP28f2HGvE EbDV5sncQbCY/mLDu/ph/Fc1XrYHZKX4eG9v+jBW+xx7KS+qclxm/wH6z9N6aFPxlO mP7ctC8kXinKvM5cNokw/Il9r44ePqLM32ISpHf7WcPF9RX8Qotld0NNWSo4283Te3 avI1ijbHsJELg==
Received: from null (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 6869B3C06EA; Tue, 21 Aug 2018 12:33:56 +0200 (CEST)
Date: Tue, 21 Aug 2018 12:33:56 +0200 (CEST)
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Ted Lemon <mellon@fugue.com>
Cc: dnsop WG <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, Joe Abley <jabley@hopcount.ca>
Message-ID: <471139805.18285.1534847636363@appsuite.open-xchange.com>
In-Reply-To: <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.0-Rev11
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TCll7xqGukLCn6PJ4TlY67STKMA>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 21 Aug 2018 10:34:01 -0000


> Il 20 agosto 2018 alle 18.51 Ted Lemon <mellon@fugue.com> ha scritto: 
> 
> 
> > So I cannot immediately recall cases in which a network operator in Europe is filtering out things that a user wants and can lawfully access. But you mention that your network operator is spoofing the DNS and stifling your freedom of expression, so I guess it is censoring legitimate websites - this is bad, of course, but can you tell me which operator, and which websites? It would help my understanding of your use case.
>  
> No, it's not bad.   It's the service they offer, and it's fine that they offer it.   I think it's the right default.   It's also fine that I choose to bypass it.

If I got it well, what you are trying to bypass is your ISP's security filter that prevents you from connecting to malware or to illegal content (e.g. intellectual property violations and the likes). I also imagine that your ISP is doing some transparent proxying/scanning so that you cannot simply bypass this filter by configuring a different resolver in your OS, right? (which, by the way, is the simple solution to your problem that is already available and widely used across the world - see the famous picture of people painting 8.8.8.8 on walls in Turkey)
 
If so, I can accept your use case: a smart user, knowing what he is doing, does not want anyone else to sanitize his queries for him. But I don't see why the best solution to your use case - which is quite a minority case, though easily overrepresented in a technical environment - is to build a sort of "nuclear bomb" protocol that, if widely adopted, will destroy most of the existing practices in the DNS "ecosystem" (I'm using the word that was being used at ICANN's DNS Symposium in Montreal), including the basic security measures that protect the 99.9% of the users who are not technically smart. Perhaps it would have been enough for you to have a discussion with your ISP and get them to give you an opt-out, which is entirely possible with today's DNS filtering techniques - or to just change to another ISP.
 
Anyway, this looks to me a lot like a policy issue, rather than a technical one; and the more I get into this discussion, the more DoH looks like "the IETF against the world's governments and ISPs" - not a good thing, IMHO.

> Yes, and if we come up with a solution that allows both situations to be securely communicated to the end user device, and allows the end user to make an informed decision about whether or not to use the service with these restrictions in place, I'm okay with that, and I think it's appropriate for the IETF to do it.   What I am arguing is that we should actually describe how to do that, and not just hack together a solution without thinking about that.

I would be fine with this approach and happy to work on it, as long as there is an agreement by the DoH/browsers community that DoH will not be deployed to the general public until this missing piece is completed and implemented. Otherwise it would just be a waste of time.

Regards, 
-- 

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