IETF Logo Mail Archive

Re: [Doh] panel discussion on DoH/DoC

Jim Reid <jim@rfc1035.com> Thu, 07 February 2019 13:52 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E469E126CC7 for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 05:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham 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 nhHYfF1MmYJl for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 05:51:58 -0800 (PST)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3495B124BE5 for <doh@ietf.org>; Thu, 7 Feb 2019 05:51:58 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 04E09242109D; Thu, 7 Feb 2019 13:51:55 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <FD7BFAFF-88B9-49BF-A652-3649ADCD53F9@fugue.com>
Date: Thu, 07 Feb 2019 13:51:54 +0000
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, doh@ietf.org, bert hubert <bert.hubert@powerdns.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com>
References: <20190207105106.GB1772@server.ds9a.nl> <C7C3BAF7-4BD4-4EE2-B3F2-1F8B49222980@fugue.com> <20190207130313.7g7hf4swaopnr75e@nic.fr> <FD7BFAFF-88B9-49BF-A652-3649ADCD53F9@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/3GDt2LREIIzNaaPIUD_i8DRgfFc>
Subject: Re: [Doh] panel discussion on DoH/DoC
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Feb 2019 13:52:01 -0000


> On 7 Feb 2019, at 13:08, Ted Lemon <mellon@fugue.com> wrote:
> 
> There isn’t a criticism in here from me—it seems clear that DoC is something that exists or doesn’t based on what browser vendors do, and if we really care about it, the knob we have to turn is not not having the specification, but rather being selective in what browsers we use, or in how they are configured.

Up to a point Ted. However we’d be missing *a lot* if the focus was just on those configuration and control hooks for web browsers. Suppose OS vendors use DoH/DoC instead of (the equivalent of) libresolv. Then there are all the web-based apps on our smartphones. Can I trust my bank to pick the right trusted DoH/DoC provider? Or will these just use whatever Apple and google decide are the trusted defaults for iOS and Android? For some definition of trust..,

These sorts of meta-issues need to be documented and I think this WG might be the best place to do that.

v2.23.0 | Report a Bug | By Email