Re: [Add] point of deploying DoH in access network (Re: meeting hum: should the IETF take up this work?)

Joe Abley <jabley@hopcount.ca> Thu, 01 August 2019 18:46 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D56120165 for <add@ietfa.amsl.com>; Thu, 1 Aug 2019 11:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 lBnxbTrmiuW6 for <add@ietfa.amsl.com>; Thu, 1 Aug 2019 11:45:58 -0700 (PDT)
Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (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 4B0C6120059 for <add@ietf.org>; Thu, 1 Aug 2019 11:45:58 -0700 (PDT)
Received: by mail-io1-xd41.google.com with SMTP id j5so142506775ioj.8 for <add@ietf.org>; Thu, 01 Aug 2019 11:45:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QZkccvEC7alTjNJjHoTsa7IhSiGzHTpmTwxltpHZ29M=; b=mTFi4M0YxlXjmS1JhzdxRrynRBNimdg4RSTpCcmzlynHfNKNRVTJlzNeIxvcDAQ3Pv mfep/xVaQRlLvXvjjqzZMSVRMu+tqJjH6Pkm4HvvaCWdvbUMGBVlVP+dfYGLBYEqXplM ywPCnMLlY6jrJEy1XYLADQQOqji62vMcD/CzY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QZkccvEC7alTjNJjHoTsa7IhSiGzHTpmTwxltpHZ29M=; b=CiOKrZXUdLTtu0WCh6w9cKDqIiRAR/HOPiBjrqDysGueLKs46b2mVKDnV4m6ZUyO4y 41DVALPYjcuH9iYnlqK2d1xyfIxd33/zaDavKcOi8hyDL32RCVXGfmKkwI/nkrx+j4xs Ngn/z51Wo4//X+yZIzL0GCKNsVSQU5XxIZ4RzNaAZYbml5s3/nPS3g+lpkGmtXzWnLo7 MoYo9/Pl2yGZ56s89OZRxuWkr43UwBjmIRibltlfjo1E/iFHDOI28wlJTqa4tiIqRoP5 twBP7RA+fOwVaqOOQamiF0nj79JJkjanMBpTpmOkXYY5yk7opGtcRn+OJ4ob6cOpwpiK EROw==
X-Gm-Message-State: APjAAAU83viYeVIND3yGOWmVrn43hTR+8pJcKhfC+OjjQFeE9ycSqghs tbyiC7N/CuglCyqzfA8vdPM=
X-Google-Smtp-Source: APXvYqxhrVgKqSDNywAbXdfesY44JOMpP8srmnbUStAqYnnOCndhLBn2OVyJ+0bnSLbuFuJdsfNCmQ==
X-Received: by 2002:a05:6638:52:: with SMTP id a18mr10574055jap.75.1564685157246; Thu, 01 Aug 2019 11:45:57 -0700 (PDT)
Received: from [192.168.1.50] (24-246-23-138.cable.teksavvy.com. [24.246.23.138]) by smtp.gmail.com with ESMTPSA id h19sm49444016iol.65.2019.08.01.11.45.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Aug 2019 11:45:56 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <A4AC000B-6A46-4642-B3E8-EFCBFC345880@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_4FC5DF76-8922-4C40-A096-A0A81365A38E"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 01 Aug 2019 14:45:54 -0400
In-Reply-To: <CAJE_bqf=9r5yvCMY+CGuXMQBCNY+a-RFQTzjJ83wOtawhUHR0g@mail.gmail.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "add@ietf.org" <add@ietf.org>, Barry Leiba <barryleiba.mailing.lists@gmail.com>, "STARK, BARBARA H" <bs7652@att.com>, Rob Sayre <sayrer@gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E23910C@GAALPA1MSGUSRBF.ITServices.sbc.com> <20190724171549.GD29051@laperouse.bortzmeyer.org> <CAJE_bqf=9r5yvCMY+CGuXMQBCNY+a-RFQTzjJ83wOtawhUHR0g@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/lmlk9YWj1WmGupfQ_SUoYdTS8xw>
Subject: Re: [Add] point of deploying DoH in access network (Re: meeting hum: should the IETF take up this work?)
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 18:46:00 -0000

On 1 Aug 2019, at 14:38, 神明達哉 <jinmei@wide.ad.jp> wrote:

> At Wed, 24 Jul 2019 13:15:49 -0400,
> Stephane Bortzmeyer <bortzmeyer@nic.fr <mailto:bortzmeyer@nic.fr>> wrote:
> 
> > > I’m also trying to understand why there seems to be resistance to
> > > providing ISPs with advice on deploying DoH.
> >
> > I'm tempted to say that I don't see the point for an access network to
> > deploy DoH. If the network is safe, DoH is not really necessary
> > (paranoid may use DoT, since the access network can ensure that port
> > 853 is clear). If it is not, for instance because the resolver
> > modifies the answers, then users will want to bypass it, anyway.
> >
> > My guess is that DoH operators will be different from access network
> > operators.
> 
> I've been wondering about this, too.

Lots of access network providers don't control all of the infrastructure between their network and their end-users. Examples are ISPs that use wholesale DSL and CATV access networks operated by incumbents who are required to allow third-party access by regulators.

I have heard concerns before that such access wholesalers might interfere (e.g. block, rate-limit) traffic that was in competition with their own services, or for other reasons. I've also heard concerns that such wholesalers routinely target retail customers of other ISPs when trying to sell their own retail services, and that visibility of the traffic of the end-users allows them to be tempted with targeted promotions.

I'm not saying any of this has happened, anywhere; I'm just saying I have heard concerns about these kinds of things.

To the extent that any of this kind of thing can be enabled by surveillance of DNS traffic between an end-user and a resolver, this to me is a plausible reason to want privacy protection. DoH is arguably a better mechanism than DoT for anybody whose primary focus is privacy (as has been discussed from many angles, many times) because the existence of the channel is obfuscated along with its content.


Joe