Re: [Doh] [Ext] panel discussion on DoH/DoC

Eliot Lear <lear@cisco.com> Thu, 07 February 2019 16:04 UTC

Return-Path: <lear@cisco.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 EDDCD1228B7 for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 08:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.6
X-Spam-Level:
X-Spam-Status: No, score=-12.6 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4yv7Qh6_OnCc for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 08:04:30 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507B912008F for <doh@ietf.org>; Thu, 7 Feb 2019 08:04:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12029; q=dns/txt; s=iport; t=1549555470; x=1550765070; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Tod1oRaiZN3U2csLVM9LOsbTOMQaG4Pc1cOLtNuaNA4=; b=DpmyvHQsmiDrWeCOuZKi1EbFE8jYOVLaekNX3i8YWvWU5WaWk6c5sfP8 SjLNactPUaxyub9kZqGzI9iH/uCWPJ+8nzGuoMit5QXLu17vkoBLOwdnJ DGW/c7YszENq+blvI2XrwJyYDlVDmD/e5SXYckozdcrJR4ftA0ogsy0ZM U=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAACDVVxc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgmpRMieEA4h5jR2SIoVvFIFnCAMBAYR?= =?us-ascii?q?sAoNKNgcNAQMBAQIBAQJtKIVKAQEBAwEjVgULCxgqAgJXBhODJAGBeQisCIE?= =?us-ascii?q?mXVKFRIRXD4IuP4ltgX+BOB+CTIREJ4MfMYIEIgKKMIQKgkaSEAmERo1/GYp?= =?us-ascii?q?KiAuZEoJqAgQGBQIUgU0IKTWBITMaCBsVZQGCQT6BbxKOHQI+AzCML4JLAQE?=
X-IronPort-AV: E=Sophos;i="5.58,344,1544486400"; d="asc'?scan'208,217";a="9878902"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2019 16:04:27 +0000
Received: from [10.61.203.34] ([10.61.203.34]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x17G4QSF021672 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Feb 2019 16:04:27 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <A0823A81-BE76-45F4-B5FF-0ADD82352922@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5ED6B7C2-51D4-4D73-98A4-0E6F240A0891"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 7 Feb 2019 17:04:25 +0100
In-Reply-To: <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org>
Cc: Ted Lemon <mellon@fugue.com>, DoH WG <doh@ietf.org>, Joseph Lorenzo Hall <joe@cdt.org>
To: Paul Hoffman <paul.hoffman@icann.org>
References: <20190207105106.GB1772@server.ds9a.nl> <C7C3BAF7-4BD4-4EE2-B3F2-1F8B49222980@fugue.com> <20190207130313.7g7hf4swaopnr75e@nic.fr> <FD7BFAFF-88B9-49BF-A652-3649ADCD53F9@fugue.com> <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org>
X-Mailer: Apple Mail (2.3445.102.3)
X-Outbound-SMTP-Client: 10.61.203.34, [10.61.203.34]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/vSeg58yaeOfKlb5CIGic_ybCP5A>
Subject: Re: [Doh] [Ext] 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 16:04:33 -0000

Hi Paul,

I agree with those who say that we are really in the realm of a policy and research discussion.  I want to focus on the latter below, just a bit.

> On 7 Feb 2019, at 16:36, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> On Feb 7, 2019, at 5:08 AM, Ted Lemon <mellon@fugue.com> wrote:
>> 
>> On Feb 7, 2019, at 8:03 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
>>> The protocols are not innocent (they enable, they encourage, they
>>> discourage) but they are not everything either. The dominance of Gmail
>>> is not written in RFC 5321. DoH helps DoC ("helps", not "enables", DNS
>>> over HTTPS was possible before), it does not decide DoC.
>> 
>> Of course, but in fact it appears that one of the primary use cases for DoH is DoC.
> 
> That became a use case after the document was mostly finished.


What I am struggling with is what we think DoC is.  Is Google a could provider in this context or not?  If so, I think many of us were expecting that Google would offer DoH alongside 8.8.8.8 precisely to address the issue directly below.  And what I find interesting is that this seems to move the problem from one control/observation point to another.  And so this brings up a key research question that would be useful to answer, and perhaps those at FF and Chromium could answer it:

Is there a suitable user interface that will keep users from harming themselves with DoH?

That question itself begs the question, “How could a user harm him or herself with DoH”?   That is in itself a research question, but at least let me give one analogy to show how that might happen: consider the fly-by-night-shady-VPN-for-free providers that spy on all of your traffic, advertising at users who say, “we’ll get you around all DNS blockers.  Just click here to change your settings, and it will all Just Work.”

I think that’s what Joe and CDT are out to stop with the code of conduct (maybe I misunderstand), and it argues against a user knob.  It might be possible to provide users some sort of intelligent choice, and I would imagine that some of the players have put some serious thought into it.


> 
>> I would have thought that the primary use case for DoH was to bypass network censorship, but when I suggested as much during the discussion on the draft, the response I got suggested that the authors really hadn’t had that in mind, and that indeed the use case they had had in mind was DNS resolution in HTTP sessions by Javascript clients.
> 
> You are probably misattributing, or misremembering, this discussion. It certainly wasn't me, and I'd be quite surprised if it was Patrick. Both of us were motivated to bypass network censorship. We *also* had a secondary use case, which was real DNS resolution by JavaScript applications (not "clients”).

This matches my (perhaps faulty) recollection.

> 
>> Which is, pretty much, DoC,
> 
> Centralizing resolution on chosen providers has nothing to do with "cloud" unless the user choose a cloud provider.

I think one of us (perhaps me) is being pedantic about the definition of cloud.

> 
>> although not the use case that subsequently emerged, where browsers do it instead of using the local resolver.
> 
> A browser vendor (Mozilla) does use a cloud provider as their default DoH server. That browser vendor has not explained why.

And what I would suggest is that we need a crisp problem statement, but I do not see a protocol issue here either (at least not yet).

I do see a potential protocol issue for enterprises, in as much as split-horizon is a thing, but I don’t know if that should be addressed inside DoH or through some other means such as an MDM, where configuration is tweaked to address it.  We’ve discussed that here before (long ago).  The protocol part I could see would be some nifty signal that indicates that split horizon is in effect in some way.  And it’s not strictly doh, but perhaps just a reserved RR of some form (being very speculative here).  But even that would be subject to abuse.

Eliot