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

神明達哉 <jinmei@wide.ad.jp> Wed, 20 March 2019 18:40 UTC

Return-Path: <jinmei.tatuya@gmail.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 0A32F130F25; Wed, 20 Mar 2019 11:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Level:
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 cwhP6RjKhrlw; Wed, 20 Mar 2019 11:40:11 -0700 (PDT)
Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 EB6EB1200B3; Wed, 20 Mar 2019 11:40:10 -0700 (PDT)
Received: by mail-wm1-f54.google.com with SMTP id a184so274153wma.2; Wed, 20 Mar 2019 11:40:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rQ3kdgZuenk4U0DtAD9p8rEVK9qsyMgYZ/0Ux2nfnxw=; b=a6wSIlC8YridIDdpGNLPUCE4IaIHSjhrCLhk63H9bt+sKt/sorvgIUMfTQGWIv+5T7 SPN/sUYfXVZpu7qoojRrejpo794KKWqbRuXlyePeHjAP1lXqpaIRhi/Top68moVBJLnf /F7bVNZ+n+e6RlEKLHT3EtaIipG8bic7yz4hmpuvvY3B8WOdZOkNnSre4C4wfgfFDB/Q ud/ab1SL5vmxjXnoBhrxMTEjgZkOP7A/N38O8+PmpP+e9TUxl7uoMetOrnIVIrF1ztqX Oq0G4kXSWLMqnO3TgktKgtJJWDoHa9JsLC41+D1lk3XbM3m8yMSV+aXbQfsjJE1YrfZS QB8g==
X-Gm-Message-State: APjAAAUGUgWbqwNfTCAqv89aq/GE/Klgk0RrpjIU2fzR6Jbc7R7530+7 Asg7X6qjuukxsu8zZPIrQP8inYTdRFe3oOtxCKk=
X-Google-Smtp-Source: APXvYqzLoP6avYU7dtXPqxn0I7GBz+AmBmjnH/leoaEzJj++2hHAGa+0wsPjCPlqpGsPUq7RUIPiAXCeLgMhc7TYK7o=
X-Received: by 2002:a1c:4641:: with SMTP id t62mr9767076wma.53.1553107209255; Wed, 20 Mar 2019 11:40:09 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <91A0BBD0-CB73-498E-B4E0-57C7E5ABE0B4@hopcount.ca>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Wed, 20 Mar 2019 11:39:57 -0700
Message-ID: <CAJE_bqfEoy4Lbei27XNTbRSF9XHoAQ1gYPNerTXg9y6swp1a0w@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: Jared Mauch <jared@puck.nether.net>, Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>, dnsop <dnsop@ietf.org>, paul vixie <paul@redbarn.org>, Michael Sinatra <michael@brokendns.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="00000000000081802a05848af30c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-8iVn5NX0kTfXHp-GGHMhhuV6Qc>
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: Wed, 20 Mar 2019 18:40:13 -0000

At Wed, 20 Mar 2019 12:38:05 +0100,
Joe Abley <jabley@hopcount.ca>; wrote:

> > Often as an industry we may discuss various solutions that are great
for oneself but don’t scale when looking at the big picture.
>
> I think what we are seeing is the fundamental tension between privacy and
control. You need to give up some privacy in order to make the control
possible; you need to give up some control in order to afford privacy.

> Some in this thread want certainty that they are able to exercise
control, e.g. for devices in their network.

> Some in this thread want certainty that they can obtain privacy, e.g. for
for their device in any network.

[...]

Thank you for the nice, concise summary.  I think it's well-balanced
observation of where we are.  (I'm so glad I can finally see a
constructive post after seeing a common pattern of boring IETF
discussion, where people with different opinions just keep stating
their views without making any real progress:).

> Seems to me that there's a middle ground within sight here.
>
> Standardise this privacy mechanism, and specify (with reasoning) that it
should be implemented such that the existence of the channel (but not the
content) can be identified as distinct from other traffic by third parties.
Maybe specify use of a different port number, as was done with DoT.

I see that those who want to exercise control can live with this (or
at least using a different set of IP addresses for DoH servers than
those for other ordinary web services).  But I'm not so sure if that's
acceptable for the other group.  In that sense I'm curious whether
some big possible DoH providers are now willing to accept this middle
ground.  If my memory is correct the longer term plan at Google (and
maybe also Clouldflare?) is to provide DoH service on the same IP
addresses as those for other ordinary and popular web services (and on
port 443, of course), so that an intermediate operator cannot easily
block access to their DoH services.

> Those who choose to ignore that direction and create a covert channel
using port 443 instead will do so. Nothing much we can do to stop that
today (I guarantee it is already happening). The future is not really
different.

True.  But I think giant providers tend to respect a community
consensus.  Niche or really malicious players may/will still ignore
it, but it would be very difficult for them to collocate their DoH
services with other important web services that can hardly be blocked,
so it shouldn't be a big problem for "those who want certainty of
control".  So if we can really agree on the above "middle ground" and
publish a BCP or something that describes the consensus, I guess we
can now really work on technical issues.  But I'm not sure if we can
reach that consensus.

--
JINMEI, Tatuya