IETF Logo Mail Archive

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

Paul Hoffman <paul.hoffman@icann.org> Thu, 07 February 2019 15:36 UTC

Return-Path: <paul.hoffman@icann.org>
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 0E5151271FF for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 07:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, 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 NEGeGCA8CehY for <doh@ietfa.amsl.com>; Thu, 7 Feb 2019 07:36:26 -0800 (PST)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F67126D00 for <doh@ietf.org>; Thu, 7 Feb 2019 07:36:26 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 7 Feb 2019 07:36:24 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Thu, 7 Feb 2019 07:36:24 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ted Lemon <mellon@fugue.com>
CC: DoH WG <doh@ietf.org>
Thread-Topic: [Ext] [Doh] panel discussion on DoH/DoC
Thread-Index: AQHUvvriWr2g4FnVZku9EOIcpvQYkw==
Date: Thu, 07 Feb 2019 15:36:24 +0000
Message-ID: <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@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>
In-Reply-To: <FD7BFAFF-88B9-49BF-A652-3649ADCD53F9@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9447476A400B024B8FCC27EBEE00F243@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/KX9FhKh38qrBtL2L52v_qAtHV9U>
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 15:36:28 -0000

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.

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

> Which is, pretty much, DoC,

Centralizing resolution on chosen providers has nothing to do with "cloud" unless the user choose a cloud provider. 

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

--Paul Hoffman

v2.23.0 | Report a Bug | By Email