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

Ted Lemon <mellon@fugue.com> Mon, 20 August 2018 16:52 UTC

Return-Path: <mellon@fugue.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 47D25126BED for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 09:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 VNK3dMqBEX6P for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 09:52:23 -0700 (PDT)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B37B1286E3 for <dnsop@ietf.org>; Mon, 20 Aug 2018 09:52:23 -0700 (PDT)
Received: by mail-it0-x22f.google.com with SMTP id h23-v6so257852ita.5 for <dnsop@ietf.org>; Mon, 20 Aug 2018 09:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ajvKQv2vTqrDq5BuHAlSVid5/MKzJ7wuqWIf8w40odQ=; b=GEcFWhJpx0AsPdQcu8n9tStqxNUo9vv5yjPU6L0SUzcaTOydgl0lwBmKwYdnrm6AVo 7F6nbL22doBs6cJyLtNQviphq/8gz1Qymkhag/nX9vx6ojEw5QIUtGI8PICA1s8oOLLC v4AvPX824Cl7Ou/UTiAvwYUmd2XkZWxM45cVb1gxZX71vAeeUrxr3KOajDGNrm08KeoY JXzavU22I9BnVwmaKcI4oWpAHsQfjrw18q1XcAWvpAFnRy16/4IjW2wQA5DPomG7EUfW KX3RzNVwn/JkG3+Xl03ScOtLJhvPr8xOPfxfHUavSR8Ug0HT7tP1XcalapAKHpl76QE4 BntQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ajvKQv2vTqrDq5BuHAlSVid5/MKzJ7wuqWIf8w40odQ=; b=mUTyfSb5P1gTwHD5DxWR7E5hfMcnh3AlcCrPzo8kRJslYWKtjms6p4rSd6wg9XkSXR +at0ElvCP69AQLQ6bwkr706IAlX2oBdmLHmXKBFJ9w0ACbLz0aK2wOg2jsE2+JvDF4rz TBLFMwc6MT4wFjbkr0/Scm188R78/f0Pf58vqAqTTzrRyqAlwUFXkpZHlnfgcOQ1k0sg qxlaTnHfOOOUcg4vt5AR1VJk/MN+RHxGw6YbqLKTcojLoYjjhKRl7KfZutr0QoYxJCWZ UZq9MB6D3jkvR5adxFNIC4LOQeYfcv6t3PIBmMPNGnjoJ7n+P6+1ERYMT+bQTjRS6Dwe 5now==
X-Gm-Message-State: AOUpUlEVNUoKV4Ku26x7ds7DubYzIcrT7r+GlbcfnW7ds5Z81aX9gyW9 yLd0rTsYpHR+1rM8o83fghAjtO6gdyEzuf6cBhGrj6vm
X-Google-Smtp-Source: AA+uWPxSTPwTGdzkMytYq4MYTqo/lnhkaHXCq1ofoYk6r8uHl4zvYRpYX8irApY2OnJkoR5emZGdmcTI0ksmJHhoSL0=
X-Received: by 2002:a24:5f92:: with SMTP id r140-v6mr35059063itb.95.1534783942144; Mon, 20 Aug 2018 09:52:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Mon, 20 Aug 2018 09:51:41 -0700 (PDT)
In-Reply-To: <265867956.15518.1534783313366@appsuite.open-xchange.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>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 20 Aug 2018 12:51:41 -0400
Message-ID: <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
Cc: Paul Vixie <paul@redbarn.org>, Joe Abley <jabley@hopcount.ca>, dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000adcf760573e0bbf2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/OVnoWBQ8jgSzL5PXl798hvn-HDs>
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: Mon, 20 Aug 2018 16:52:28 -0000

On Mon, Aug 20, 2018 at 12:41 PM, Vittorio Bertola <
vittorio.bertola@open-xchange.com> wrote:

> Can you substantiate this statement with data / details? Because I only
> know cases in which:
> a) ISPs filter out content on behalf of the local government due to legal
> requirements/court orders;
>
Yes, although in many cases they are required by law to do it, but I am not
required by law to accept it—I can quite legally bypass this feature if I
want to.


> b) ISPs filter out content on request by the user, e.g. for parental
> control; in the UK, ISPs are actually required by law to provide this
> service to the user, that can then decide whether to activate it or not and
> even what to filter out;
>

Yes, and in that case wouldn't it be nice to be able to know that you're
actually talking to the right resolver?   You can't do that with DHCP.


> c) ISPs filter out threats such as botnets, compromised websites
> distributing malware, etc - this does not entail any freedom of speech
> consideration and contributes to everyone's security.
>

Same question.


> In many European countries network operators are selling b)+c) (see for
> example https://securenet.vodafone.com/ ) and people are actively buying
> the service, so they explicitly want this kind of filtering (and will not
> be able to continue getting it if their browser redirects their DNS queries
> somewhere else); and if you do not want it, you just don't buy it. As for
> a), possibly users do not want it, but it is still mandated by law.
>

Yup, absolutely.   I used to work for Nominum—we made a product that did
this, and a lot of people bought it, and I think they were wise to do so.


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


> Finally, note that *in your country* it may be your right to use DoH to
> tamper with what your network operator is doing, but this may not be true
> in other countries. In fact, deploying any technology that circumvents
> security measures that network operators are required to implement by law
> might be illegal in itself.
>

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.


> In the end, the DNS is a very complex policy subject (see the mess that
> ICANN is) with lots of stakeholders and conflicting views, and IMHO such a
> deep change in its architecture and "ecosystem" would require much more
> caution and a much broader discussion going well beyond the IETF.


I believe that I too have been arguing for caution.   Perhaps we disagree
on what the outcome of that cautious approach would be, but we both seem to
agree that it's worth thinking about carefully.