From nobody Fri Feb 1 10:23:26 2019 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B8B131146; Fri, 1 Feb 2019 10:23:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: doh@ietf.org, adam@nostrum.com, tale@dd.org, doh-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154904540481.28529.17912538174448620865.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2019 10:23:24 -0800 Archived-At: Subject: [Doh] doh - New Meeting Session Request for IETF 104 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 18:23:25 -0000 A new meeting session request has just been submitted by David C Lawrence, a Chair of the doh working group. --------------------------------------------------------- Working Group Name: DNS Over HTTPS Area Name: Applications and Real-Time Area Session Requester: David Lawrence Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: First Priority: dprive dnsop httpbis Second Priority: dispatch dnssd teep hrpc People who must be present: Adam Roach Benjamin M. Schwartz David C Lawrence Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Feb 7 02:51:18 2019 Return-Path: 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 35A8F12DDA3 for ; Thu, 7 Feb 2019 02:51:17 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 ZWazZ3jwMfoj for ; Thu, 7 Feb 2019 02:51:15 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285FB13107E for ; Thu, 7 Feb 2019 02:51:14 -0800 (PST) Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 6C40E9FD6E for ; Thu, 7 Feb 2019 10:51:06 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 484D9ACCEC3; Thu, 7 Feb 2019 11:51:06 +0100 (CET) Date: Thu, 7 Feb 2019 11:51:06 +0100 From: bert hubert To: doh@ietf.org Message-ID: <20190207105106.GB1772@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [Doh] panel discussion on DoH/DoC X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 10:51:17 -0000 Hello everyone, Last weekend at FOSDEM in Brussels there were three sessions on DNS Privacy, Daniel Stenberg presented a keynote session “DNS over HTTPS – the good, the bad and the ugly”, Vittorio Bertola discussed “The DoH Dilemma” while Daniel, Stéphane Bortzmeyer and I formed a DNS Privacy Panel expertly moderated by Jan-Piet Mens. I wrote up what I learned on https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/ and added some strongly worded conclusions on what I think of "DoC-by-default". So what is DoC? A lot of the animosity towards DoH is not actually directed at DoH-the-protocol. The problem people have is with centralizing DNS on cloud operators ("DoC"). For further discussions, if someone is venting on DoC but calling it DoH, we can point out that they should not direct their anger at the poor DoH protocol that can't help what people do with it. Anyhow, this and much more can be found here: https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/ I hope this will be useful to you. Bert From nobody Thu Feb 7 04:55:54 2019 Return-Path: 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 D519E12D4F2 for ; Thu, 7 Feb 2019 04:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 fiBpnpds0k2m for ; Thu, 7 Feb 2019 04:55:51 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 4706B126C7E for ; Thu, 7 Feb 2019 04:55:51 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id e5so11677789qtr.12 for ; Thu, 07 Feb 2019 04:55:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mT8JQuf5UgITjcnom93fh6WWM0SJf3jXYg/NLPLY5PY=; b=XscjMWhi3qUYyennn2X7PILd1rLi+ynWJJ0WHTGO3+KLT/qWTxAbXd1jso+3o82n+n OKM7v9UnKN0Nt1dzn+mvruN/EdTEWqaMQyHjrJD4PTb2luiSMaBUBbyLUsVgR6I8um1J lvx5px6LWUT5xC6WGkqmPeNrbc3p6mK3o2eKuHrRzqHM8bghYfEd8ZCMKiiWTef0Ycmx +L1i5NIngmp3A0u5+SDlww7/Y07+T/YZuXH7hL5Jldn7JcI0UkHZ/mOMKKP+OhEGZ/RF hYo9JihkM/Z2d1VersgLhMNan2JebIrhzX8o+nEwBWa1KCmaDHoWKCtOa1rCpoiGk0XL jeAQ== 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=mT8JQuf5UgITjcnom93fh6WWM0SJf3jXYg/NLPLY5PY=; b=HaWiox1dGlXh2ZDiPtr8/HYqrdzQ7AgyQmVaYiI8VbHthqo309GtqNQaEMItTxKsum SyKL1DhS8Bm/nf6GUImhwgKVPW6uIBU5rsgpVu6NlFeqqIv6NtyzubkjKoGZUV4aFCHc +lnjHpwKRlfyvUpa2hvMZjqkNp/sDOOCSr0TByxFpsYR4i62DAOYm9S88B8Fkb7J3Ynn B+BZj9K07apX0qqXq+6gh69ZZlgPdpATiFgEjSDR2f/sT6aU9hOCZBAwbLFZ4yiRJA2Q E/XMiHgAyW82xkHSZYq64OyipG8gdYgLY8/VZmI+38yC/kmZlXq/UMjLY3Sr2WnaCfyg xfSw== X-Gm-Message-State: AHQUAuZWC7KrrA++x5XwALEvJPYdJLNHZVK+LQI2HERNdz+jof/zFw8t TN4h1bOu0EDPe4MVNBsMnHHJ7YcwJlI= X-Google-Smtp-Source: AHgI3Ib7Vj/8m1/eTx3sDjMp2uGKtZkT7NgsvzGMRx3AlG/ZVjyJCZVvfGwq6FvMgqIrLBFYgDtKiA== X-Received: by 2002:ac8:7518:: with SMTP id u24mr11927445qtq.75.1549544150444; Thu, 07 Feb 2019 04:55:50 -0800 (PST) Received: from [10.0.100.12] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id x202sm23390978qka.67.2019.02.07.04.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 04:55:49 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4B3906A5-F753-4B41-B992-9090D4A6FBE2" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Feb 2019 07:55:46 -0500 In-Reply-To: <20190207105106.GB1772@server.ds9a.nl> Cc: doh@ietf.org To: bert hubert References: <20190207105106.GB1772@server.ds9a.nl> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 12:55:53 -0000 --Apple-Mail=_4B3906A5-F753-4B41-B992-9090D4A6FBE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 7, 2019, at 5:51 AM, bert hubert = wrote: > For further discussions, if someone is venting on DoC but calling it = DoH, we > can point out that they should not direct their anger at the poor DoH > protocol that can't help what people do with it. You could get into a really big fight with the HRPC folks about this = statement. DoH is perfectly designed to support the DoC use case, so = doesn=E2=80=99t that mean that it effectively _is_ DoC? It=E2=80=99s = only _not_ DoC if there=E2=80=99s some way to prevent it from being DoC, = and there isn=E2=80=99t. So you might as well own it. --Apple-Mail=_4B3906A5-F753-4B41-B992-9090D4A6FBE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 7, 2019, at 5:51 AM, bert hubert <bert.hubert@powerdns.com> wrote:
For further discussions, if someone is venting on DoC but = calling it DoH, we
can point out that they should not direct their anger at the = poor DoH
protocol that = can't help what people do with it.

You could get into a really big fight with = the HRPC folks about this statement.   DoH is perfectly designed to = support the DoC use case, so doesn=E2=80=99t that mean that it = effectively _is_ DoC?   It=E2=80=99s only _not_ DoC if there=E2=80=99= s some way to prevent it from being DoC, and there isn=E2=80=99t.   =  So you might as well own it.

= --Apple-Mail=_4B3906A5-F753-4B41-B992-9090D4A6FBE2-- From nobody Thu Feb 7 05:03:20 2019 Return-Path: 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 0B3C0130DC8 for ; Thu, 7 Feb 2019 05:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 MQyPYZ3O1OXj for ; Thu, 7 Feb 2019 05:03:15 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3149130934 for ; Thu, 7 Feb 2019 05:03:15 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 9CD8428053A; Thu, 7 Feb 2019 14:03:13 +0100 (CET) Received: from relay01.prive.nic.fr (pa-th3.interco.nic.fr [192.134.4.74]) by mx4.nic.fr (Postfix) with ESMTP id 96688280281; Thu, 7 Feb 2019 14:03:13 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 92CE86427BE0; Thu, 7 Feb 2019 14:03:13 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 86E5D4014E; Thu, 7 Feb 2019 14:03:13 +0100 (CET) Date: Thu, 7 Feb 2019 14:03:13 +0100 From: Stephane Bortzmeyer To: Ted Lemon Cc: bert hubert , doh@ietf.org Message-ID: <20190207130313.7g7hf4swaopnr75e@nic.fr> References: <20190207105106.GB1772@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Debian GNU/Linux 9.7 X-Kernel: Linux 4.9.0-8-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:03:18 -0000 On Thu, Feb 07, 2019 at 07:55:46AM -0500, Ted Lemon wrote a message of 90 lines which said: > You could get into a really big fight with the HRPC folks about this > statement. I'll ask them :-) > DoH is perfectly designed to support the DoC use case, so doesn’t > that mean that it effectively _is_ DoC? It’s only _not_ DoC if > there’s some way to prevent it from being DoC, and there isn’t. > So you might as well own it. 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. From nobody Thu Feb 7 05:09:09 2019 Return-Path: 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 CE683130934 for ; Thu, 7 Feb 2019 05:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 LWTBqlHO5ZAv for ; Thu, 7 Feb 2019 05:09:01 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 5BFCA12F1A6 for ; Thu, 7 Feb 2019 05:09:01 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id y16so6371792qki.7 for ; Thu, 07 Feb 2019 05:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=07IphiE+9aC1UuQb1Gv6dtLb+mNwfA3s32qGZYc/whk=; b=vNkpoiQTUQqGJ++9PeyC8T0AovbZ8H/uJCz1ou6DElNo4mJf0fjvFKyZKPwUXw+Ibp 9Sz2r1UyDgswYNevmOf73hsG1hL8VYrgo1dJnuctKNW9mndpvI+Jy7e3PnQhf3ryk1sw ma7MGcX26NeYLtf6IeJpHfO36yQXXUh1MsgHli8HpkYP7/DdaaNnl7RguamMryI3qNDz F4PF2GJMFAHObEsTwA5EoOytXmh0DE1nzwpLtpoexfw7I0N6lfq+7mbKj/3wvGjWhe9v pAG2YlkKHM07mignEZaBV+1+2g9ZF9G0d0RwSy2BL1LoaQWqOelJm4KgRwi7O33GXqYu g/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=07IphiE+9aC1UuQb1Gv6dtLb+mNwfA3s32qGZYc/whk=; b=t9yVmCERNaxcoM7DB4hSZWjqnYcMYit0FpIlvauKS5ZMBE/44QdptjuJ46z51uuKV/ ptOUdWghkh7XhVmEJErvyIG3hY50ZYjleVxwF9H6KGjdizZuIK8tpNmRDTvd0bj03Kdi KGrJVN7uxlUISXIKAwXZ4UHcgHsMQq4xlfLZSVzgVV5oLHdwF3cHMp4iI9VHRnsce/jX nxZLW351kvNNJiWzI/77iJQF9nOQIaO8CRtC9/yuQ4p5him4BRtcb8Y8fdyBQJJvwI5z 3DJdC+mi/dWXflHF0aHcFQ9bC9nAkDZhL/0MQnUr2ULVfF1PSsO5SCAumJRW9je3TWls VNmg== X-Gm-Message-State: AHQUAuZ1UyJOzH7Yj+FmFVDRD+9i+7ieTaq9hcrC33vsIqBQaI4PaDkh zx+1CWsLkUnlbjMKqkSl2d6h2w== X-Google-Smtp-Source: AHgI3IapUabNSNNpVae7JynfUMYcyoPvmTuYilRSBzBCCEjfKvvC1Gk6tWMIG8nZ50NZWm3fn8wNsg== X-Received: by 2002:a37:6e86:: with SMTP id j128mr11828906qkc.46.1549544940480; Thu, 07 Feb 2019 05:09:00 -0800 (PST) Received: from [10.0.100.12] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id b27sm13824177qkj.17.2019.02.07.05.08.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 05:08:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ted Lemon In-Reply-To: <20190207130313.7g7hf4swaopnr75e@nic.fr> Date: Thu, 7 Feb 2019 08:08:58 -0500 Cc: bert hubert , doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3445.102.3) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:09:08 -0000 On Feb 7, 2019, at 8:03 AM, Stephane Bortzmeyer = 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. 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=E2=80=99t had that in mind, and that indeed the use case = they had had in mind was DNS resolution in HTTP sessions by Javascript = clients. Which is, pretty much, DoC, although not the use case that = subsequently emerged, where browsers do it instead of using the local = resolver. There isn=E2=80=99t a criticism in here from me=E2=80=94it seems clear = that DoC is something that exists or doesn=E2=80=99t 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. From nobody Thu Feb 7 05:16:10 2019 Return-Path: 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 152F612950A for ; Thu, 7 Feb 2019 05:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fA2XYmjm7LAz for ; Thu, 7 Feb 2019 05:16:06 -0800 (PST) Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F391294D0 for ; Thu, 7 Feb 2019 05:16:06 -0800 (PST) Received: from [2001:470:78c8:2:65fc:c318:cd2d:2bb1] by time-travellers.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1grjYL-0005mN-Qr for doh@ietf.org; Thu, 07 Feb 2019 13:17:17 +0000 To: doh@ietf.org References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> From: Shane Kerr Message-ID: <70dc8e21-4808-af5a-1d46-4154fc369954@time-travellers.org> Date: Thu, 7 Feb 2019 14:16:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:16:08 -0000 Ted, On 07/02/2019 14.08, Ted Lemon wrote: > On Feb 7, 2019, at 8:03 AM, Stephane Bortzmeyer 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. 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. Which is, pretty much, DoC, although not the use case that subsequently emerged, where browsers do it instead of using the local resolver. In theory one could send DoH queries to the server where you were getting an HTML page from, for any names that need resolution on that page. This would be a anti-DoC, indeed probably more decentralized than DNS itself is today. If this model requires DNSSEC then it's not even that horrible, since web server operators would not be able to spoof or hijack DNS names. Cheers, -- Shane From nobody Thu Feb 7 05:17:14 2019 Return-Path: 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 EAD241295D8 for ; Thu, 7 Feb 2019 05:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ayAbpnYD1dQR for ; Thu, 7 Feb 2019 05:17:11 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08991294D0 for ; Thu, 7 Feb 2019 05:17:11 -0800 (PST) Received: from open-xchange.com (unknown [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 99D156A296; Thu, 7 Feb 2019 14:17:09 +0100 (CET) Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 8D6E53C085A; Thu, 7 Feb 2019 14:17:09 +0100 (CET) Date: Thu, 7 Feb 2019 14:17:09 +0100 (CET) From: Vittorio Bertola To: Ted Lemon Cc: doh@ietf.org Message-ID: <1630977697.16646.1549545429521@appsuite.open-xchange.com> In-Reply-To: References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev3 X-Originating-Client: open-xchange-appsuite Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:17:13 -0000 > Il 7 febbraio 2019 alle 14.08 Ted Lemon ha scritto: >=20 > There isn=E2=80=99t a criticism in here from me=E2=80=94it seems clear th= at DoC is something that exists or doesn=E2=80=99t based on what browser ve= ndors do, and if we really care about it, the knob we have to turn is not n= ot having the specification, but rather being selective in what browsers we= use, or in how they are configured. Which of course depends on a) having a practical possibility of choice amon= g many browsers having many different policies, and b) the browsers letting= you configure your resolver freely. Ciao, --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu Feb 7 05:23:00 2019 Return-Path: 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 EF1AD1294D0 for ; Thu, 7 Feb 2019 05:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 VFTtexCgbJBw for ; Thu, 7 Feb 2019 05:22:56 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id B8C6812872C for ; Thu, 7 Feb 2019 05:22:56 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id B09485F40965; Thu, 7 Feb 2019 14:22:55 +0100 (CET) Received: from [192.168.2.138] (p4FC21EFD.dip0.t-ipconnect.de [79.194.30.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 291F45F401BB; Thu, 7 Feb 2019 14:22:55 +0100 (CET) From: "Ralf Weber" To: "Shane Kerr" Cc: doh@ietf.org Date: Thu, 07 Feb 2019 14:22:53 +0100 X-Mailer: MailMate (1.12.4r5594) Message-ID: <36F04A63-E7BD-49EC-B908-CAB9A376C9B1@fl1ger.de> In-Reply-To: <70dc8e21-4808-af5a-1d46-4154fc369954@time-travellers.org> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <70dc8e21-4808-af5a-1d46-4154fc369954@time-travellers.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:22:59 -0000 Moin! On 7 Feb 2019, at 14:16, Shane Kerr wrote: > In theory one could send DoH queries to the server where you were > getting an HTML page from, for any names that need resolution on that > page. This would be a anti-DoC, indeed probably more decentralized > than DNS itself is today. > > If this model requires DNSSEC then it's not even that horrible, since > web server operators would not be able to spoof or hijack DNS names. That model is horrible as it removes the possibility for DNS being a central control point and pretty much every enterprise applications out there (split horizon). Even with DNSSEC the results could be horrible as the CDN view from a server might be way different then from a client. Please don’t go there. So long -Ralf —-- Ralf Weber From nobody Thu Feb 7 05:23:17 2019 Return-Path: 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 B51261294D0 for ; Thu, 7 Feb 2019 05:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 XNBPLKNCxlwE for ; Thu, 7 Feb 2019 05:23:14 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 2D02A130E0E for ; Thu, 7 Feb 2019 05:23:14 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id u188so6402259qkh.8 for ; Thu, 07 Feb 2019 05:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=BCiTwH/iwz/dsFDE+4yH7D7M05Z0zmXD1w0Rngm/BPs=; b=rtRbX8J1JD4VL0vNhvPclX8Hrsy3J1G6slA6AE06MdThNlfuLT4TfnOpbPMpCzQMXV C7fzmpRAMLZqNmQiURd0Q+uJ+/8Vw5uWtmlDoVnSeVADMVGzOD1E2UXIC42CIhG8USt8 vIvvF6AlSiYzfr262qoVJQoMhXvBGZA6nULSxkIV4ILV/1hnVMotJrGOkAbrmrxF7tnY XwM0qRo9LEISEYllINbCk8p5ZJ42Re4GK5MgaVuVxx/ohemBWXatMJGhyEh8pDzuwT6i JMVp76LX1uqnvsLVw10WzS18WevfQpDLUAZdMoNGOOtwYJCz89iKNkiZbGqHcwuTGXnw lllg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BCiTwH/iwz/dsFDE+4yH7D7M05Z0zmXD1w0Rngm/BPs=; b=DAn086Q+ea7o4yXGzxRleW4A7bxPX7Oqz4Z1Bx8SsVohL1f+/gLvP1RLuS+Goh0aRC VRPb4iXNQ386uF41u8EpiuCFo7bvlgo/mMfdcXqEbM2yX4a+Z92fbrbd01Ku2G62Ban8 h+rhuUDJHSV/4by3YItjN0OSnDSPbC3Voc5b3DTi+e1v8kS1DAZIjjM244g4nMBu7lMa RvuZZwNDw1LWxF4WRhrzyeXR7jddIzOBnbYiL0rvmBf2vmeDOeRGZgAg25oB19QLkf5B WrPFwfU39d+KhRCVLDK4Rtq0TUqxot5zHdng8WuXPUodKJ/jiUrE4yLcPwjzQBI2gYRQ 2t3Q== X-Gm-Message-State: AHQUAuaQjS6LEaqckVwbJZVqbFH5iAaym4Fo8C0IfgOWPpA9zD5LO2S1 5auRHUFLrVDCUm+smxhN/S4zcqnQ3Sk= X-Google-Smtp-Source: AHgI3IYaO5nG34YqLHhylAvuq6ROc9qAUptzrVdR7OdWqf2IDIUiw5/aUvRF+KjW4K/vUcgKA3r2Rw== X-Received: by 2002:a37:8b41:: with SMTP id n62mr11485186qkd.262.1549545793222; Thu, 07 Feb 2019 05:23:13 -0800 (PST) Received: from [10.0.100.12] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id e49sm22482058qta.0.2019.02.07.05.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 05:23:12 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E66A327-F684-47C0-8972-6B1972C71B68" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ted Lemon X-Priority: 3 In-Reply-To: <1630977697.16646.1549545429521@appsuite.open-xchange.com> Date: Thu, 7 Feb 2019 08:23:11 -0500 Cc: doh@ietf.org Message-Id: References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <1630977697.16646.1549545429521@appsuite.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3445.102.3) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:23:16 -0000 --Apple-Mail=_3E66A327-F684-47C0-8972-6B1972C71B68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 7, 2019, at 8:17 AM, Vittorio Bertola = wrote: > Which of course depends on a) having a practical possibility of choice = among many browsers having many different policies, and b) the browsers = letting you configure your resolver freely. Yes, it does. UTSL? > On Feb 7, 2019, at 8:16 AM, Shane Kerr = wrote: > In theory one could send DoH queries to the server where you were = getting an HTML page from, for any names that need resolution on that = page. This would be a anti-DoC, indeed probably more decentralized than = DNS itself is today. >=20 > If this model requires DNSSEC then it's not even that horrible, since = web server operators would not be able to spoof or hijack DNS names. Except that perhaps I want to block, I don=E2=80=99t know, name = resolution for various ad bug sites? And then if the browser has a = secure way past my block, suddenly I=E2=80=99m seeing ads again. = Whether you believe that ads are immoral or not, the fact is that this = wrests control away from the end user. --Apple-Mail=_3E66A327-F684-47C0-8972-6B1972C71B68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 7, 2019, at 8:17 AM, Vittorio Bertola <vittorio.bertola@open-xchange.com> = wrote:
Which of = course depends on a) having a practical possibility of choice among many = browsers having many different policies, and b) the browsers letting you = configure your resolver freely.

Yes, it does.   UTSL?

On Feb 7, 2019, at 8:16 AM, Shane Kerr <shane@time-travellers.org> = wrote:
In = theory one could send DoH queries to the server where you were getting = an HTML page from, for any names that need resolution on that page. This = would be a anti-DoC, indeed probably more decentralized than DNS itself = is today.

If this model requires = DNSSEC then it's not even that horrible, since web server operators = would not be able to spoof or hijack DNS names.

Except that perhaps I want to block, I = don=E2=80=99t know, name resolution for various ad bug sites?   And = then if the browser has a secure way past my block, suddenly I=E2=80=99m = seeing ads again.   Whether you believe that ads are immoral or = not, the fact is that this wrests control away from the end = user.


= --Apple-Mail=_3E66A327-F684-47C0-8972-6B1972C71B68-- From nobody Thu Feb 7 05:52:03 2019 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Thu, 7 Feb 2019 13:51:54 +0000 Cc: Stephane Bortzmeyer , doh@ietf.org, bert hubert Content-Transfer-Encoding: quoted-printable Message-Id: <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:52:01 -0000 > On 7 Feb 2019, at 13:08, Ted Lemon wrote: >=20 > There isn=E2=80=99t a criticism in here from me=E2=80=94it seems clear = that DoC is something that exists or doesn=E2=80=99t 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=E2=80=99d 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. From nobody Thu Feb 7 06:04:27 2019 Return-Path: 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 886DA126DBF for ; Thu, 7 Feb 2019 06:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 bcsss5nlCdjp for ; Thu, 7 Feb 2019 06:04:23 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 AAF14124BE5 for ; Thu, 7 Feb 2019 06:04:23 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id m9so6502018qkl.4 for ; Thu, 07 Feb 2019 06:04:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4kdN2WLmuIcyHLVBPI2HQtJw2uZVXAdsJMNpXNjHZD0=; b=BvDSKbXN1SeLD0a0zpwz760K+HMCVMrIOL07xG8zXXGYAKS9icdC3LzICWDinCddvc OJm3/inpX+O9yajufhhga/KF7InM3nME/tg+3sZmJhVFD0sBW7TlFygpQF9TvttZ5UvO 1kxrmg9bV82u3kDGuQjpftL8sq1Ua+sZ65yyqIuf2KikBglNYx9aMn551ZDid2Wpjo20 5CVMVuq4EM+JlseAUOBRPlH6bhIbEgiMiThbrliHbHszdEOsQjjNM+Euw14m9bs0mBOb i3FEICtRqvLnbn/d2qSGGt2lrNsvfU1OzFxJmRgfPp6XzuMRx836N4YsxmzG28wr5fkz Fw8Q== 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=4kdN2WLmuIcyHLVBPI2HQtJw2uZVXAdsJMNpXNjHZD0=; b=HdccS8ahyS2/0gJ/zkoQXt5MhcLtqzDA1Lj1v/ja4ONqz9KHIDZACUfIvsgtNSQpUZ tImJk2xjad3aMn1Yw6H4QF6ifHBiG2oJtgNBcIQb5mIuoPxO6FqwErxkq1MDJmpr8LxO ua+M3lJ3FOqHfYNxf47SvuTAxbgRrMVFh/UbIWZLevePih2azXsD5EU5hFGmNapp6f2g udx6uUfkBj4TYBLAo+G/rDU9TUiyNkkC6gyHj/ok9SzuUUDgwbErkPsqZBlth71dfP/E jMdhgyiG8XthDKVnSQUILTe3LdRqqZVRpRufBs28d0hXRjrFoMALN+roUO9M1u34DAT/ YpMQ== X-Gm-Message-State: AHQUAuZTYqBMUc6rj57zo6zFyJP6NHqhNUx4EM24V4N3tPQIw1a+s8mH OkDLScJ/hhAMw6BwftZ6zMwnxg== X-Google-Smtp-Source: AHgI3IY3KTYwBrKQHIGQepWAv3BY2kgGPqJLNx/jP/hLWOpOzer0Rw7UcewVDOU51zUlHk+OjmzAAQ== X-Received: by 2002:ae9:ea02:: with SMTP id f2mr9390052qkg.178.1549548262823; Thu, 07 Feb 2019 06:04:22 -0800 (PST) Received: from [10.0.10.34] (c-73-186-137-119.hsd1.nh.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id 13sm2521340qtv.78.2019.02.07.06.04.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Feb 2019 06:04:21 -0800 (PST) From: Ted Lemon Message-Id: <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_EB3927E9-B8F0-47C0-BCF5-0FC76BDFAA37" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Feb 2019 09:04:18 -0500 In-Reply-To: <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> Cc: Stephane Bortzmeyer , doh@ietf.org, bert hubert To: Jim Reid References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:04:26 -0000 --Apple-Mail=_EB3927E9-B8F0-47C0-BCF5-0FC76BDFAA37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 7, 2019, at 8:51 AM, Jim Reid wrote: > These sorts of meta-issues need to be documented and I think this WG = might be the best place to do that. Doh? Why not DPRIVE or DNSOP? I agree that we should talk about this; not sure DoH is the right place = to have the conversation though. --Apple-Mail=_EB3927E9-B8F0-47C0-BCF5-0FC76BDFAA37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Feb 7, 2019, at 8:51 AM, Jim Reid <jim@rfc1035.com> wrote:
These sorts of meta-issues need to be documented and I think = this WG might be the best place to do = that.

Doh? =   Why not DPRIVE or DNSOP?

I agree that we should talk about this; = not sure DoH is the right place to have the conversation = though.

= --Apple-Mail=_EB3927E9-B8F0-47C0-BCF5-0FC76BDFAA37-- From nobody Thu Feb 7 06:18:20 2019 Return-Path: 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 19FE212730E for ; Thu, 7 Feb 2019 06:18:19 -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 q9nvdW3datkb for ; Thu, 7 Feb 2019 06:18:17 -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 C508B126CC7 for ; Thu, 7 Feb 2019 06:18:17 -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 923F0242109D; Thu, 7 Feb 2019 14:18:16 +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 In-Reply-To: <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> Date: Thu, 7 Feb 2019 14:18:16 +0000 Cc: DoH Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <9561DB79-FEF3-48A8-8ACA-A345958087FD@rfc1035.com> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:18:19 -0000 > On 7 Feb 2019, at 14:04, Ted Lemon wrote: >=20 > On Feb 7, 2019, at 8:51 AM, Jim Reid wrote: >> These sorts of meta-issues need to be documented and I think this WG = might be the best place to do that. >=20 > Doh? Why not DPRIVE or DNSOP? DoH=E2=80=99s more likely to have web clue than those two WGs.=20 The DoH WG=E2=80=99s explictly chartered to analyse "the security and = privacy issues that could arise from accessing DNS over HTTPS.=E2=80=9D DPRIVE and DNSOP are = not. I agree with you that a discussion is needed about where best to = consider these DoH/DoC trust issues. Perhaps that can get some agenda = time in Prague? From nobody Thu Feb 7 06:20:50 2019 Return-Path: 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 9666F128B36 for ; Thu, 7 Feb 2019 06:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5bc5pMVdmBh1 for ; Thu, 7 Feb 2019 06:20:45 -0800 (PST) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 EA1961289FA for ; Thu, 7 Feb 2019 06:20:44 -0800 (PST) Received: by mail-it1-x12b.google.com with SMTP id z7so80110iti.0 for ; Thu, 07 Feb 2019 06:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V5sCW6xY+r9F6szWcjsMzEUOnoKiMzxDrv5W75BwA34=; b=tw3lSrkHAW2LrKWxTdsE54Ljth96L0Ejym5zm8t6pW+aZmfe0vomLMbR1XBXlVG8E0 4fo7duD4hAJVwbtLNjRMDW/19NK6RcSKBtmjlAF3/q1jf6Y8pqthnODtqS6I5oauURE4 2NBBQpymmFsjexJ89DPoEu5yIaQXFV9AOISTZacB0Fe3vOfvYlgV2uiVF1diB5u1ujen UdBZI5U8J5j5Ork/cTlblfHJ7vZerpr8MjiS/2XkClsscDqO+eIwoSf3Hw+/9kK4XBLv zty5rH5gEIx9mCL0CwXp+UxRmeVIVMvZ+OM9imjcx9oyLbpR4oSDtJrbvq0nHs97wg/U Fevg== 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=V5sCW6xY+r9F6szWcjsMzEUOnoKiMzxDrv5W75BwA34=; b=uM2In8QPc7S3zNFKANT9KjJE4vijsK02CBXd7mMeRvH8ss0weB95Q1FP6H9LnYYprN rNoszecjjWvcmM1yamnn7LiRq6+eWcF8g+crL+jX5ZFQfYPliTJBgH3tISyBSGHKmA77 M8zXX7KXp6Uh4IGpMt8or7u2isXB5RAr5tegNOMuU+s3jR8uDfT71iNx2tJJ/YipxGkh dralktiPCM2dunVOoqB9XEJuKL+4vvGfa3drTjUfcECLfMEL2cPPyu0huHc8YnX53c8f mYDanG8EMXCMA7JeaWo/6tWuKYEAfDi48MIbKSAsaZa6wAwXe1VRpROCRVMzuhKR6iuk fC7A== X-Gm-Message-State: AHQUAuYiovF0aU1sGXhjDmNObMsLIhJQPNPhunqH7dAqGPy5/pnsty// HXU58NMVg/NQNYeds+63OKylqIvH6e9He8+ewSU9Ja6o X-Google-Smtp-Source: AHgI3IahiT9VEnvYKb4H3iznFCnopIL8OgM+8dkIgX6RvPVV0ayMZgreE/zDe320QDIt1Bb7kXXM9ER0wTvcNuc9j/k= X-Received: by 2002:a24:434f:: with SMTP id s76mr3494816itb.123.1549549244207; Thu, 07 Feb 2019 06:20:44 -0800 (PST) MIME-Version: 1.0 References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <1630977697.16646.1549545429521@appsuite.open-xchange.com> In-Reply-To: From: Valentin Gosu Date: Thu, 7 Feb 2019 15:20:32 +0100 Message-ID: To: Ted Lemon Cc: Vittorio Bertola , doh@ietf.org Content-Type: multipart/alternative; boundary="000000000000435b1805814e8c00" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:20:47 -0000 --000000000000435b1805814e8c00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 7 Feb 2019 at 14:23, Ted Lemon wrote: > On Feb 7, 2019, at 8:17 AM, Vittorio Bertola < > vittorio.bertola@open-xchange.com> wrote: > > Which of course depends on a) having a practical possibility of choice > among many browsers having many different policies, and b) the browsers > letting you configure your resolver freely. > > > Yes, it does. UTSL? > > On Feb 7, 2019, at 8:16 AM, Shane Kerr wrote: > > In theory one could send DoH queries to the server where you were getting > an HTML page from, for any names that need resolution on that page. This > would be a anti-DoC, indeed probably more decentralized than DNS itself i= s > today. > > If this model requires DNSSEC then it's not even that horrible, since web > server operators would not be able to spoof or hijack DNS names. > > > Except that perhaps I want to block, I don=E2=80=99t know, name resolutio= n for > various ad bug sites? And then if the browser has a secure way past my > block, suddenly I=E2=80=99m seeing ads again. Whether you believe that = ads are > immoral or not, the fact is that this wrests control away from the end us= er. > I think a very important point to make is that the existence of the DoH RFC does not affect these sort of usecases at all. If an ad site wanted to load ads without being constrained by DNS it could always hardcode IP addresses, or use their own homegrown variety of DNS over HTTP(S) with the server of their choice. The same is true for IoT devices. And even for browsers. If Google wanted to perform all DNS resolutions using "frankenDNS over gQUIC", there's hardly a way you can stop them. Where having a DoH RFC is immensely helpful is that you now have lots compatible server and client implementations. If you want to increase your privacy in a coffee shop, just point your stub resolver to a DoH server - be it Cloudflare, Google, or your own pi-hole that you have at home. And when browsers implement DoH, it's easier to have a choice of DoH servers, because implementations follow the same RFC. --000000000000435b1805814e8c00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 7 Feb 2019 at 14:23, Ted Lemon <mellon@fugue.com> wrote:
On Feb= 7, 2019, at 8:17 AM, Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
Which of course depends on a) having a practical p= ossibility of choice among many browsers having many different policies, an= d b) the browsers letting you configure your resolver freely.

Yes, it does. =C2=A0 UTS= L?

In the= ory one could send DoH queries to the server where you were getting an HTML= page from, for any names that need resolution on that page. This would be = a anti-DoC, indeed probably more decentralized than DNS itself is today.

If this model requires D= NSSEC then it's not even that horrible, since web server operators woul= d not be able to spoof or hijack DNS names.

Except that perhaps I want to block, I don=E2=80=99t know, name resoluti= on for various ad bug sites? =C2=A0 And then if the browser has a secure wa= y past my block, suddenly I=E2=80=99m seeing ads again. =C2=A0 Whether you = believe that ads are immoral or not, the fact is that this wrests control a= way from the end user.

I think = a very important point to make is that the existence of the DoH RFC does no= t affect these sort of usecases at all. If an ad site wanted to load ads wi= thout being constrained by DNS it could always hardcode IP addresses, or us= e their own homegrown variety of DNS over HTTP(S) with the server of their = choice. The same is true for IoT devices. And even for browsers. If Google = wanted to perform all DNS resolutions using "frankenDNS over gQUIC&quo= t;, there's hardly a way you can stop them.

Wh= ere having a DoH RFC is immensely helpful is that you now have lots compati= ble server and client implementations. If you want to increase your privacy= in a coffee shop, just point your stub resolver to a DoH server - be it Cl= oudflare, Google, or your own pi-hole that you have at home.
And when browsers implement DoH, it's easier to have a choice of DoH s= ervers, because implementations follow the same RFC. --000000000000435b1805814e8c00-- From nobody Thu Feb 7 06:21:08 2019 Return-Path: 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 BEC961286D8 for ; Thu, 7 Feb 2019 06:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YwbqdRK7OykT for ; Thu, 7 Feb 2019 06:21:02 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653D01292F1 for ; Thu, 7 Feb 2019 06:21:02 -0800 (PST) Received: from open-xchange.com (unknown [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 6CDC56A298; Thu, 7 Feb 2019 15:21:00 +0100 (CET) Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 605A13C0B4B; Thu, 7 Feb 2019 15:21:00 +0100 (CET) Date: Thu, 7 Feb 2019 15:20:59 +0100 (CET) From: Vittorio Bertola To: Ted Lemon Cc: doh@ietf.org Message-ID: <1503183837.15474.1549549260349@appsuite.open-xchange.com> In-Reply-To: <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev3 X-Originating-Client: open-xchange-appsuite Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:21:06 -0000 > Il 7 febbraio 2019 alle 15.04 Ted Lemon ha scritto: > > On Feb 7, 2019, at 8:51 AM, Jim Reid < jim@rfc1035.com> wrote: > > These sorts of meta-issues need to be documented and I think this WG might be the best place to do that. > > Doh? Why not DPRIVE or DNSOP? > > I agree that we should talk about this; not sure DoH is the right place to have the conversation though. These are not "meta-issues", these are policy issues, the more so if we accept that there is no problem in the protocol itself, but rather in how it is being used. Moreover, these issues affect lots of non-technical stakeholders, and I suspect that they will soon pop up in several venues other than the IETF. This said, it would still be good to address them at the IETF as well, but this looks more like a job for DPRIVE, which has the word "policy" in its charter and "Document Best Current Practices for operating DNS Privacy services" as one of its objectives. (Though any place could be fine, and some may also argue that this is not really in the scope of any existing WG, since we are not just talking about DNS operators but also about DoH client implementers, though they could easily be the same entity.) Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu Feb 7 06:28:19 2019 Return-Path: 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 EC0C9127287 for ; Thu, 7 Feb 2019 06:28:16 -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 zZG7DZvtkx02 for ; Thu, 7 Feb 2019 06:28:15 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF85126C15 for ; Thu, 7 Feb 2019 06:28:15 -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 07C9924211EE; Thu, 7 Feb 2019 14:28:13 +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 X-Priority: 3 In-Reply-To: <1503183837.15474.1549549260349@appsuite.open-xchange.com> Date: Thu, 7 Feb 2019 14:28:12 +0000 Cc: Ted Lemon , doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> To: Vittorio Bertola X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 14:28:17 -0000 > On 7 Feb 2019, at 14:20, Vittorio Bertola = wrote: >=20 > but this looks more like a job for DPRIVE, which has the word "policy" = in its charter and "Document Best Current Practices for operating DNS = Privacy services" OTOH DoH didn=E2=80=99t exist when DPRIVE was created and what was meant = then by DNS privacy is not quite the same as is meant today. I think DoH is the better choice. Though there=E2=80=99s enough = ambiguity/overlap between the WGs that the ADs might need to decide = this. From nobody Thu Feb 7 07:33:18 2019 Return-Path: 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 C1662124C04 for ; Thu, 7 Feb 2019 07:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=cdt.org 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 KPEazz_0pTXQ for ; Thu, 7 Feb 2019 07:33:14 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 D974E126D00 for ; Thu, 7 Feb 2019 07:33:13 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id u16so394689otk.8 for ; Thu, 07 Feb 2019 07:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZ8esZE3MyYm6XdqXnqYIL5VoxScYMZb2GVuF+6Kpd8=; b=J2ptf1Hc8xl0T32WVEVtFXcZaE5TZzX9i5XTz/xCyrAxV0Di9UaVdDDBcuM7F//nr0 oAxg35uv7vh0krtu0naOlYMDL+SnqDSMh0SdFI6A6S8Oqwqj+e1WmHbbwI2T/FRepWwA prbMf/KF3buFwOrXDfIEhk4Eu4ukxYJ9UPHLw= 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=fZ8esZE3MyYm6XdqXnqYIL5VoxScYMZb2GVuF+6Kpd8=; b=B+gFKJLOc5HDxzE2lHiY3epqhxG7qy9BhyMwCze8UvO99QTVTdZODifqgbynf7mTZ7 eMfhABIoNYtpUr3K9cq4La00QRLLaA/128uNsXqOTIP8Jc/k/bS1xffPbdKw8FFfcKzs qfym325Q6PiuZxRKeS5SueyZNT979rRgRHDrDQEKTxlGIG8RrV2/q3vVms2twcyD4rvN PKqXb28qdjnhhbFzVLkRMteWiWFmKHjuGSzI+EjBa9dgbXlg/vBRvjflkvvr6OZEMFDD n/qdC862MbiQL3Md3OfVpPw04bUsI+fXM7+3E2IOGmDCKUALA7FjhDaYPGn8yj34hjCW V5Dw== X-Gm-Message-State: AHQUAubHhiXTehnm2xXn5dvoXaOmxm+glZ+qb+cYm1IkiMiQkiXXN0hf PmN8A80PjYkNWcaCquAHe8ioTe/lg3GWpSvezxZoqQ== X-Google-Smtp-Source: AHgI3IYHakjnPUWeuJFxGN7jlLE51AVyBKIjyczPP7fFS3p1LbtJE64zPmEE7Jc294SkCGACYReELp6vXIHUKE6g08s= X-Received: by 2002:aca:b882:: with SMTP id i124mr598937oif.127.1549553592838; Thu, 07 Feb 2019 07:33:12 -0800 (PST) MIME-Version: 1.0 References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com> In-Reply-To: <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com> From: Joseph Lorenzo Hall Date: Thu, 7 Feb 2019 10:33:01 -0500 Message-ID: To: Jim Reid Cc: Vittorio Bertola , doh@ietf.org, Ted Lemon Content-Type: multipart/alternative; boundary="00000000000076444605814f8ff3" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:33:16 -0000 --00000000000076444605814f8ff3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Heya, I tried to think of a few good questions to the FOSDEM DNS privacy panel [1] and included the following (forgive what may be a naive question!): ---- 3\. Software like browsers seem to want to have a list of DOH providers that they can shuffle queries across in order to minimize the raw quantity of queries any given DOH service sees from a given user. Right now the big DOH services all have very very different privacy policies and terms of service making such a list impossible as you'd be comparing apples to oranges (e.g., one second you are talking to CF's 1.1.1.1 which a very strong privacy policy and the next minute you are talking to Google's 8.8.8.8 which has a much less strong privacy policy). How should application developers decide which kind of DOH service to build into their offerings? (My own organization, CDT, is going to start an effort in a few months to try and bring DOH providers together to set some baseline "rules of the road" for these kinds of services and we'd love to work with others thinking about the "wild west" of DOH.) ---- I'm about to go on leave for a bit (18-Feb up to Prague) but would love to help think through what might make sense here. We did a project last year with VPN providers where we sought to clarify some "rules of the road", so to speak, and ended up basically with a standard questionnaire that providers answered ( https://cdt.org/issue/privacy-data/vpns/ , https://cdt.org/insight/unedited-answers-signals-of-trustworthy-vpns/ ). best, Joe [1]: https://gist.github.com/jpmens/be639dfd798dba2d65fb1c98e209e3f8#gistcomment= -2812589 On Thu, Feb 7, 2019 at 9:28 AM Jim Reid wrote: > > > > On 7 Feb 2019, at 14:20, Vittorio Bertola < > vittorio.bertola@open-xchange.com> wrote: > > > > but this looks more like a job for DPRIVE, which has the word "policy" > in its charter and "Document Best Current Practices for operating DNS > Privacy services" > > OTOH DoH didn=E2=80=99t exist when DPRIVE was created and what was meant = then by > DNS privacy is not quite the same as is meant today. > > I think DoH is the better choice. Though there=E2=80=99s enough ambiguity= /overlap > between the WGs that the ADs might need to decide this. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 Don't miss out! CDT's Tech Prom is April 10, 2019, at The Anthem. Please join us: https://cdt.org/annual-dinner/ --00000000000076444605814f8ff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Heya, I tried to think of a few good questions to the FOSDEM= DNS privacy panel [1] and included the following (forgive what may be a na= ive question!):

----

= 3\. Software like browsers seem to want to have a list of DOH providers tha= t they can shuffle queries across in order to minimize the raw quantity of = queries any given DOH service sees from a given user. Right now the big DOH= services all have very very different privacy policies and terms of servic= e making such a list impossible as you'd be comparing apples to oranges= (e.g., one second you are talking to CF's 1.1.1.1 which a very strong = privacy policy and the next minute you are talking to Google's 8.8.8.8 = which has a much less strong privacy policy). How should application develo= pers decide which kind of DOH service to build into their offerings? (My ow= n organization, CDT, is going to start an effort in a few months to try and= bring DOH providers together to set some baseline "rules of the road&= quot; for these kinds of services and we'd love to work with others thi= nking about the "wild west" of DOH.)

----

I'm about to go on leave for a bit (= 18-Feb up to Prague) but would love to help think through what might make s= ense here. We did a project last year with VPN providers where we sought to= clarify some "rules of the road", so to speak, and ended up basi= cally with a standard questionnaire that providers answered ( https://cdt.org/issue/privacy-data/= vpns/ , https://cdt.org/insight/unedited-answers-signals-of-trus= tworthy-vpns/ ).

best, Joe

On T= hu, Feb 7, 2019 at 9:28 AM Jim Reid <= jim@rfc1035.com> wrote:


> On 7 Feb 2019, at 14:20, Vittorio Bertola <vittorio.bertola@open-xchang= e.com> wrote:
>
> but this looks more like a job for DPRIVE, which has the word "po= licy" in its charter and "Document Best Current Practices for ope= rating DNS Privacy services"

OTOH DoH didn=E2=80=99t exist when DPRIVE was created and what was meant th= en by DNS privacy is not quite the same as is meant today.

I think DoH is the better choice. Though there=E2=80=99s enough ambiguity/o= verlap between the WGs that the ADs might need to decide this.

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--
Joseph Lorenzo = Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401= K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-= key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F86 6987 40A9 = A871

Don't miss out! CDT's Tech Prom i= s April 10, 2019, at The
Anthem. Please join us: https://cdt.org/annual-dinner/
--00000000000076444605814f8ff3-- From nobody Thu Feb 7 07:36:29 2019 Return-Path: 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 ; 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 ; 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 ; 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 To: Ted Lemon CC: DoH WG Thread-Topic: [Ext] [Doh] panel discussion on DoH/DoC Thread-Index: AQHUvvriWr2g4FnVZku9EOIcpvQYkw== Date: Thu, 7 Feb 2019 15:36:24 +0000 Message-ID: <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> In-Reply-To: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:36:28 -0000 T24gRmViIDcsIDIwMTksIGF0IDU6MDggQU0sIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4g d3JvdGU6DQo+IA0KPiBPbiBGZWIgNywgMjAxOSwgYXQgODowMyBBTSwgU3RlcGhhbmUgQm9ydHpt ZXllciA8Ym9ydHptZXllckBuaWMuZnI+IHdyb3RlOg0KPj4gVGhlIHByb3RvY29scyBhcmUgbm90 IGlubm9jZW50ICh0aGV5IGVuYWJsZSwgdGhleSBlbmNvdXJhZ2UsIHRoZXkNCj4+IGRpc2NvdXJh Z2UpIGJ1dCB0aGV5IGFyZSBub3QgZXZlcnl0aGluZyBlaXRoZXIuIFRoZSBkb21pbmFuY2Ugb2Yg R21haWwNCj4+IGlzIG5vdCB3cml0dGVuIGluIFJGQyA1MzIxLiBEb0ggaGVscHMgRG9DICgiaGVs cHMiLCBub3QgImVuYWJsZXMiLCBETlMNCj4+IG92ZXIgSFRUUFMgd2FzIHBvc3NpYmxlIGJlZm9y ZSksIGl0IGRvZXMgbm90IGRlY2lkZSBEb0MuDQo+IA0KPiBPZiBjb3Vyc2UsIGJ1dCBpbiBmYWN0 IGl0IGFwcGVhcnMgdGhhdCBvbmUgb2YgdGhlIHByaW1hcnkgdXNlIGNhc2VzIGZvciBEb0ggaXMg RG9DLiAgDQoNClRoYXQgYmVjYW1lIGEgdXNlIGNhc2UgYWZ0ZXIgdGhlIGRvY3VtZW50IHdhcyBt b3N0bHkgZmluaXNoZWQuDQoNCj4gSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhhdCB0aGUgcHJpbWFy eSB1c2UgY2FzZSBmb3IgRG9IIHdhcyB0byBieXBhc3MgbmV0d29yayBjZW5zb3JzaGlwLCBidXQg d2hlbiBJIHN1Z2dlc3RlZCBhcyBtdWNoIGR1cmluZyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgZHJh ZnQsIHRoZSByZXNwb25zZSBJIGdvdCBzdWdnZXN0ZWQgdGhhdCB0aGUgYXV0aG9ycyByZWFsbHkg aGFkbuKAmXQgaGFkIHRoYXQgaW4gbWluZCwgYW5kIHRoYXQgaW5kZWVkIHRoZSB1c2UgY2FzZSB0 aGV5IGhhZCBoYWQgaW4gbWluZCB3YXMgRE5TIHJlc29sdXRpb24gaW4gSFRUUCBzZXNzaW9ucyBi eSBKYXZhc2NyaXB0IGNsaWVudHMuICANCg0KWW91IGFyZSBwcm9iYWJseSBtaXNhdHRyaWJ1dGlu Zywgb3IgbWlzcmVtZW1iZXJpbmcsIHRoaXMgZGlzY3Vzc2lvbi4gSXQgY2VydGFpbmx5IHdhc24n dCBtZSwgYW5kIEknZCBiZSBxdWl0ZSBzdXJwcmlzZWQgaWYgaXQgd2FzIFBhdHJpY2suIEJvdGgg b2YgdXMgd2VyZSBtb3RpdmF0ZWQgdG8gYnlwYXNzIG5ldHdvcmsgY2Vuc29yc2hpcC4gV2UgKmFs c28qIGhhZCBhIHNlY29uZGFyeSB1c2UgY2FzZSwgd2hpY2ggd2FzIHJlYWwgRE5TIHJlc29sdXRp b24gYnkgSmF2YVNjcmlwdCBhcHBsaWNhdGlvbnMgKG5vdCAiY2xpZW50cyIpLg0KDQo+IFdoaWNo IGlzLCBwcmV0dHkgbXVjaCwgRG9DLA0KDQpDZW50cmFsaXppbmcgcmVzb2x1dGlvbiBvbiBjaG9z ZW4gcHJvdmlkZXJzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggImNsb3VkIiB1bmxlc3MgdGhlIHVz ZXIgY2hvb3NlIGEgY2xvdWQgcHJvdmlkZXIuIA0KDQo+IGFsdGhvdWdoIG5vdCB0aGUgdXNlIGNh c2UgdGhhdCBzdWJzZXF1ZW50bHkgZW1lcmdlZCwgd2hlcmUgYnJvd3NlcnMgZG8gaXQgaW5zdGVh ZCBvZiB1c2luZyB0aGUgbG9jYWwgcmVzb2x2ZXIuDQoNCkEgYnJvd3NlciB2ZW5kb3IgKE1vemls bGEpIGRvZXMgdXNlIGEgY2xvdWQgcHJvdmlkZXIgYXMgdGhlaXIgZGVmYXVsdCBEb0ggc2VydmVy LiBUaGF0IGJyb3dzZXIgdmVuZG9yIGhhcyBub3QgZXhwbGFpbmVkIHdoeS4NCg0KLS1QYXVsIEhv ZmZtYW4= From nobody Thu Feb 7 07:46:13 2019 Return-Path: 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 57B96126D00 for ; Thu, 7 Feb 2019 07:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 c0O0-luHdEbt for ; Thu, 7 Feb 2019 07:46:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9444E12008F for ; Thu, 7 Feb 2019 07:46:10 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x17Fk54B051014 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Feb 2019 09:46:06 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549554367; bh=FuBVXOkHiIyIumazdvK/Z7XVh3eL8WZPf6mopnawcPc=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oFhCecDpuMYFBkOLv2TJGqIbv4JVuP82Vwy86wL7nQxz3sgfduFNzPzZESRjwdlIR vN7XNTHmEm/4R1wHMXPhts6Ay3mVv64FEzk+bFhO9R1y51cSHorM8petESNlvAY/Du OI79QDu/JIVOkmMiXQGHuyzI6wWnaTeJnw3onW3Q= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Paul Hoffman , Ted Lemon Cc: DoH WG References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> From: Adam Roach Message-ID: <54d1803d-c0a1-1324-8c0c-41214d05eaa9@nostrum.com> Date: Thu, 7 Feb 2019 09:46:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 15:46:12 -0000 On 2/7/19 9:36 AM, Paul Hoffman wrote: > >> 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. The claim that Firefox has a cloud provider as its default DoH server isn't wrong on its face, but the implication that Firefox uses DoH by default is. The claim that Mozilla has not explained why, however, is flatly false. There's been a lot of electronic ink spilled on the topic; including, notably: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/ /a From nobody Thu Feb 7 08:04:34 2019 Return-Path: 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 ; 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 ; 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 ; 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 Message-Id: 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 , DoH WG , Joseph Lorenzo Hall To: Paul Hoffman References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:04:33 -0000 --Apple-Mail=_5ED6B7C2-51D4-4D73-98A4-0E6F240A0891 Content-Type: multipart/alternative; boundary="Apple-Mail=_912195A8-0150-4D28-8354-F2F12A36E8EA" --Apple-Mail=_912195A8-0150-4D28-8354-F2F12A36E8EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 wrote: >=20 > On Feb 7, 2019, at 5:08 AM, Ted Lemon wrote: >>=20 >> On Feb 7, 2019, at 8:03 AM, Stephane Bortzmeyer = 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. >>=20 >> Of course, but in fact it appears that one of the primary use cases = for DoH is DoC. >=20 > 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, =E2=80=9CHow could a user harm = him or herself with DoH=E2=80=9D? 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, =E2=80=9Cwe=E2=80=99= ll get you around all DNS blockers. Just click here to change your = settings, and it will all Just Work.=E2=80=9D I think that=E2=80=99s 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. >=20 >> 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=E2=80=99t had that in mind, and that indeed the use case they had = had in mind was DNS resolution in HTTP sessions by Javascript clients. >=20 > 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=E2=80=9D). This matches my (perhaps faulty) recollection. >=20 >> Which is, pretty much, DoC, >=20 > 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. >=20 >> although not the use case that subsequently emerged, where browsers = do it instead of using the local resolver. >=20 > 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=E2=80=99t 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=E2=80=99ve 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=E2=80=99s 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 --Apple-Mail=_912195A8-0150-4D28-8354-F2F12A36E8EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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, =E2=80=9CHow could a user harm him or herself = with DoH=E2=80=9D?   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, =E2=80=9Cwe=E2=80=99ll get you = around all DNS blockers.  Just click here to change your settings, and it will all Just = Work.=E2=80=9D

I think that=E2=80=99s 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=E2=80=99t 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=E2=80=9D).

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=E2=80=99= 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=E2=80=99ve 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=E2=80=99s 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
= --Apple-Mail=_912195A8-0150-4D28-8354-F2F12A36E8EA-- --Apple-Mail=_5ED6B7C2-51D4-4D73-98A4-0E6F240A0891 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlxcVwoACgkQh7ZrRtnS ejOWAwf/fNVIWwpQpDZRNS9QWjRpcdfTvbxd5IZ/Sw9mncnp924c/jDdNN5DbSF+ kXKSMRScU1yumBoc+bUVMs8s1qzvlcCUgoq7zP0IT/B73mkA7hOSFipr/JPOeEnP 5szjNIzRJ3xGKASQZGjQuBW4oEPCdyVXto9lr5AyrpPKG2oqx+7dzJfmcZYt+HE2 oo+xsNN9m+LS33+IK5LUYe+KAQR4VPky/lHLeTGXNv/C44MQBSNRwFwdTMtMUIhT VkHOC2BQqTsIjj2TrmLWqw+D2hVyWIkEIYFhhywttJDb7xd0I0O4BBkOLAczZnpv 8/ehKTwiHrMUe3ymsCtBNU76CZYxBA== =VVv/ -----END PGP SIGNATURE----- --Apple-Mail=_5ED6B7C2-51D4-4D73-98A4-0E6F240A0891-- From nobody Thu Feb 7 08:06:51 2019 Return-Path: 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 8439B126D00 for ; Thu, 7 Feb 2019 08:06:49 -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 RiTsiXPjhsad for ; Thu, 7 Feb 2019 08:06:47 -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 BD91412008F for ; Thu, 7 Feb 2019 08:06:47 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 7 Feb 2019 08:06:45 -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 08:06:45 -0800 From: Paul Hoffman To: Adam Roach CC: DoH WG Thread-Topic: [Doh] [Ext] panel discussion on DoH/DoC Thread-Index: AQHUvvxAEP+7HWaqMUqobPKZXoU3rqXVBmAA Date: Thu, 7 Feb 2019 16:06:44 +0000 Message-ID: <7A52C280-F26A-4C2E-B77E-2A8C019151F3@icann.org> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> <54d1803d-c0a1-1324-8c0c-41214d05eaa9@nostrum.com> In-Reply-To: <54d1803d-c0a1-1324-8c0c-41214d05eaa9@nostrum.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="us-ascii" Content-ID: <20C3C242F5EC8B4E82AA99E3B5CE391E@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:06:50 -0000 On Feb 7, 2019, at 7:46 AM, Adam Roach wrote: >=20 > On 2/7/19 9:36 AM, Paul Hoffman wrote: >>=20 >>> 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 Do= H server. That browser vendor has not explained why. >=20 >=20 > The claim that Firefox has a cloud provider as its default DoH server isn= 't wrong on its face, but the implication that Firefox uses DoH by default = is. Sorry, I certainly didn't mean to imply that. The dialog where you can turn= on DoH is completely clear that it is off by default. > The claim that Mozilla has not explained why, however, is flatly false. T= here's been a lot of electronic ink spilled on the topic; including, notabl= y: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-fir= efox/ We disagree that that article from six months ago explains why Cloudflare i= s still the default provider.=20 --Paul Hoffman= From nobody Thu Feb 7 08:26:26 2019 Return-Path: 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 CE9571271FF for ; Thu, 7 Feb 2019 08:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 fqpfv9oTb9g8 for ; Thu, 7 Feb 2019 08:26:23 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D933B1289FA for ; Thu, 7 Feb 2019 08:26:23 -0800 (PST) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 73FD81760F3 for ; Thu, 7 Feb 2019 08:26:23 -0800 (PST) Received: (qmail 31079 invoked from network); 7 Feb 2019 16:26:23 -0000 Received: from c-98-248-50-174.hsd1.ca.comcast.net (HELO ?10.0.200.101?) (ask@mail.dev@98.248.50.174) by smtp.develooper.com with ESMTPA; 7 Feb 2019 16:26:23 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= In-Reply-To: <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> Date: Thu, 7 Feb 2019 08:26:10 -0800 Cc: Ted Lemon , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.102.3) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:26:25 -0000 > On Feb 7, 2019, at 7:36, Paul Hoffman wrote: >=20 > 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"). Another use case is to allow DNS server implementors to build on the = significant investments being done in HTTP/QUIC/etc software and = infrastructure. Ask From nobody Thu Feb 7 08:28:43 2019 Return-Path: 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 28E6D1289FA for ; Thu, 7 Feb 2019 08:28:43 -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=[none] 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 4IKEfHO-8FR6 for ; Thu, 7 Feb 2019 08:28:42 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AD41271FF for ; Thu, 7 Feb 2019 08:28:42 -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 E761224211EE; Thu, 7 Feb 2019 16:28:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Thu, 7 Feb 2019 16:28:39 +0000 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <2F5FDCAE-DA5A-4F32-A7FD-397F312E44A9@rfc1035.com> References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> To: Eliot Lear X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:28:43 -0000 > On 7 Feb 2019, at 16:04, Eliot Lear wrote: >=20 > Is there a suitable user interface that will keep users from harming = themselves with DoH? First, define harm :-) From nobody Thu Feb 7 08:41:40 2019 Return-Path: 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 4770A124BF6 for ; Thu, 7 Feb 2019 08:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 V-JsEOW5U0FX for ; Thu, 7 Feb 2019 08:41:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 95F941271FF for ; Thu, 7 Feb 2019 08:41:36 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x17GfCPT060382 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Feb 2019 10:41:14 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549557674; bh=8by/jpjCWw12XKmaBkKKPf4fhx49otdE2upy40gTrPA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=SN29nG69lMJn+hm9PCUEQXwkUSNN2VHxqltLlza9Ld3m237CxKCbhhIzWkvjHwwzG XcRn6023HHOuPOSwfxB3RQNao1RjKfk/pAenmOrj7rE0fcNuoObMDI/X2aYmZXdP2E 5xcoB8TdL/0W8jZr9ftkFHrioM78+As4ND4AWAmg= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Paul Hoffman Cc: DoH WG References: <20190207105106.GB1772@server.ds9a.nl> <20190207130313.7g7hf4swaopnr75e@nic.fr> <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> <54d1803d-c0a1-1324-8c0c-41214d05eaa9@nostrum.com> <7A52C280-F26A-4C2E-B77E-2A8C019151F3@icann.org> From: Adam Roach Message-ID: <64c7992e-88c2-facb-ced5-1b912ae3216b@nostrum.com> Date: Thu, 7 Feb 2019 10:41:07 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <7A52C280-F26A-4C2E-B77E-2A8C019151F3@icann.org> Content-Type: multipart/alternative; boundary="------------5DE247B9F9C09A21786BD2F4" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 16:41:38 -0000 This is a multi-part message in MIME format. --------------5DE247B9F9C09A21786BD2F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/7/19 10:06 AM, Paul Hoffman wrote: > On Feb 7, 2019, at 7:46 AM, Adam Roach wrote: >> On 2/7/19 9:36 AM, Paul Hoffman wrote: >>>> 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. >> >> The claim that Firefox has a cloud provider as its default DoH server isn't wrong on its face, but the implication that Firefox uses DoH by default is. > Sorry, I certainly didn't mean to imply that. The dialog where you can turn on DoH is completely clear that it is off by default. > >> The claim that Mozilla has not explained why, however, is flatly false. There's been a lot of electronic ink spilled on the topic; including, notably: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/ > We disagree that that article from six months ago explains why Cloudflare is still the default provider. I thought the following text in the article I cited was pretty clear: "We’ve chosen Cloudflare because they agreed to a very strong privacy agreement that protects your data." If you want a little more meat on that statement, I'll clarify that the agreement here isn't just some informal "put these words up on a webpage" kid of thing. There's a formal legal agreement in place between Mozilla and Cloudflare that ensures that Cloudflare is handling DoH queries with the standards of privacy that Mozilla demands as part of its core mission. /a --------------5DE247B9F9C09A21786BD2F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/7/19 10:06 AM, Paul Hoffman wrote:
On Feb 7, 2019, at 7:46 AM, Adam Roach <adam@nostrum.com> wrote:

On 2/7/19 9:36 AM, Paul Hoffman wrote:


          

            
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.


        

        

The claim that Firefox has a cloud provider as its default DoH server isn't wrong on its face, but the implication that Firefox uses DoH by default is.


      

      
Sorry, I certainly didn't mean to imply that. The dialog where you can turn on DoH is completely clear that it is off by default.



      

        
The claim that Mozilla has not explained why, however, is flatly false. There's been a lot of electronic ink spilled on the topic; including, notably: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/


      

      
We disagree that that article from six months ago explains why Cloudflare is still the default provider. 


    

    


    

    
I thought the following text in the article I cited was pretty
      clear: "We’ve chosen Cloudflare because they agreed to a very
        strong privacy agreement that protects your data."

    
If you want a little more meat on that statement, I'll clarify
      that the agreement here isn't just some informal "put these words
      up on a webpage" kid of thing. There's a formal legal agreement in
      place between Mozilla and Cloudflare that ensures that Cloudflare
      is handling DoH queries with the standards of privacy that Mozilla
      demands as part of its core mission.

    

    
/a

    

  


--------------5DE247B9F9C09A21786BD2F4--


From nobody Thu Feb  7 08:49:40 2019
Return-Path: 
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 7A8B1124BF6 for ; Thu,  7 Feb 2019 08:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.22
X-Spam-Level: 
X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 T34vQ36Q_X5C for ; Thu,  7 Feb 2019 08:49:38 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AD0C31200D8 for ; Thu,  7 Feb 2019 08:49:38 -0800 (PST)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x17GnB7d061634 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Feb 2019 10:49:13 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549558154; bh=17W80pTVqgXu/bP90UyrV9ieK0vJqCCdlsdqzy5qCl4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=FWXr6sIeUMFZYhrjoXOkEXiyf0a1m0stdVvCrQErco0e8jmproU85NPuGWMpyF7m4 lDlJQOVtPcpd6lBv0bMoqPgY+7ebaHmh7MIpNZ/fRpPCs1mgLZdvegfdMRgVT2OkhC eQaxoMHC9kyL39l0e9Nt3/Dt2HmBfC/CGO6qLX+o=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Eliot Lear , Paul Hoffman 
Cc: DoH WG , Ted Lemon , Joseph Lorenzo Hall 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org> 
From: Adam Roach 
Message-ID: <2073b35e-1383-bae1-b80e-3f3a0db6031f@nostrum.com>
Date: Thu, 7 Feb 2019 10:49:06 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2019 16:49:39 -0000

On 2/7/19 10:04 AM, Eliot Lear wrote:
> 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?


If there were a pat answer to this question, we would have gone to 
release with DoH last summer. The user experience around activating and 
configuring DoH remains, as you suggest, a research topic. The standard 
here is informed consent.

/a


From nobody Thu Feb  7 08:58:36 2019
Return-Path: 
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 D5383129532 for ; Thu,  7 Feb 2019 08:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 qDhAuONE5ELP for ; Thu,  7 Feb 2019 08:58:21 -0800 (PST)
Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5145F124BF6 for ; Thu,  7 Feb 2019 08:58:20 -0800 (PST)
Received: from server.ds9a.nl (ip565244ed.adsl-surfen.hetnet.nl [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 7281E9FD6E; Thu,  7 Feb 2019 16:58:17 +0000 (UTC)
Received: by server.ds9a.nl (Postfix, from userid 1000) id 47B02ACCEFF; Thu,  7 Feb 2019 17:58:17 +0100 (CET)
Date: Thu, 7 Feb 2019 17:58:17 +0100
From: bert hubert 
To: Adam Roach 
Cc: Eliot Lear , Paul Hoffman , DoH WG , Ted Lemon , Joseph Lorenzo Hall 
Message-ID: <20190207165817.GB17102@server.ds9a.nl>
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org>  <2073b35e-1383-bae1-b80e-3f3a0db6031f@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2073b35e-1383-bae1-b80e-3f3a0db6031f@nostrum.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2019 16:58:25 -0000

On Thu, Feb 07, 2019 at 10:49:06AM -0600, Adam Roach wrote:
> If there were a pat answer to this question, we would have gone to release
> with DoH last summer. The user experience around activating and configuring
> DoH remains, as you suggest, a research topic. The standard here is informed
> consent.

I just enabled DoH to Cloudflare with a single click in Firefox.

I did not get any warning or explanation what this would mean. It had a
prefilled entry for Cloudflare that I can't even change from the UI.

https://imgur.com/a/WQrRG5Z has a screenshot.

You might ponder if as a data controller you might have a duty to do more
than this, especially since it hardcodes Cloudflare. 

Because it does not look like informed consent to me.

	Bert


From nobody Thu Feb  7 09:00:28 2019
Return-Path: 
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 B0D94129508 for ; Thu,  7 Feb 2019 09:00:25 -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_HIGH=-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 U-OkylLmk_4U for ; Thu,  7 Feb 2019 09:00:23 -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 823D4129284 for ; Thu,  7 Feb 2019 09:00:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5131; q=dns/txt; s=iport; t=1549558821; x=1550768421; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=3VdBXMrYCm0jAD9wkr+jqDqKWYxIq1cnFYa8uC+6YVg=; b=RW0RgQdL0sX6no2V//ckVEJomP/FLwE8kBnngU7Fw0QocN330I83FHHx pZr4e3ta/SankzSrXITqSQvIDVLER4xgO2agZclib4qch/mV7QPa+hTNd +rkRYXBgU02fl3Gk35jo2hQ8pX82h8S4r1VotkftXUCUfC2oFfn8QpBJJ E=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADZY1xc/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGDOzInhAOIGl+NHXyRJoVvgXsIAwEBhGwCg0o?= =?us-ascii?q?0CQ0BAwEBAgEBAm0ohUoBAQEDASNWBQsLBBQqAgJXBhODJAGBeQitS4EvhUS?= =?us-ascii?q?EVw+CLj+JbYF/gREnH4IXNYgKMYIEIgKRAJIQCYRGjX8ZikqIC5kSgmoCBAY?= =?us-ascii?q?FAhSBRjiBVjMaCBsVZQGCQT6QID4DMI56AQE?=
X-IronPort-AV: E=Sophos;i="5.58,344,1544486400";  d="asc'?scan'208,217";a="9879799"
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 17:00:19 +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 x17H0I3d030098 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Feb 2019 17:00:18 GMT
From: Eliot Lear 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_68649E47-3EE6-4408-8263-89E1CC4CA047"; 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 18:00:16 +0100
In-Reply-To: <2073b35e-1383-bae1-b80e-3f3a0db6031f@nostrum.com>
Cc: Paul Hoffman , DoH WG , Ted Lemon , Joseph Lorenzo Hall 
To: Adam Roach 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org>  <2073b35e-1383-bae1-b80e-3f3a0db6031f@nostrum.com>
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: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2019 17:00:26 -0000

--Apple-Mail=_68649E47-3EE6-4408-8263-89E1CC4CA047
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7C69890B-C393-4D05-86F2-FEB66F669BFF"


--Apple-Mail=_7C69890B-C393-4D05-86F2-FEB66F669BFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Adam,

> On 7 Feb 2019, at 17:49, Adam Roach  wrote:
>=20
> On 2/7/19 10:04 AM, Eliot Lear wrote:
>> 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:
>>=20
>> Is there a suitable user interface that will keep users from harming =
themselves with DoH?
>=20
>=20
> If there were a pat answer to this question, we would have gone to =
release with DoH last summer. The user experience around activating and =
configuring DoH remains, as you suggest, a research topic. The standard =
here is informed consent.


Again, I haven=E2=80=99t been tracking this for quite some time, and so =
I didn=E2=80=99t want to presume that there wasn=E2=80=99t work done in =
this space.  Also, I=E2=80=99m quite certain you meant =E2=80=9Cmeaningful=
 consent=E2=80=9D above.  Another question I wonder is whether there are =
times when DoH will be active and when it will not be active, again =
somewhat based on the enterprise use case, or whether it should either =
be enabled or disabled.  The issue is that if it can flip from one to =
the other, do you have to signal the user?  If you do, that becomes both =
real estate and signalling issues, the latter of which is subject to =
habituation.

Again, researchy stuff.  Which leads me to another question- if DoH has =
mostly finished in the IETF, maybe this becomes more of a topic for the =
IRTF?

Eliot

--Apple-Mail=_7C69890B-C393-4D05-86F2-FEB66F669BFF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi =
Adam,

On 7 Feb 2019, at 17:49, Adam Roach <adam@nostrum.com> =
wrote:

On 2/7/19 10:04 AM, Eliot Lear wrote:
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?


If there were a =
pat answer to this question, we would have gone to release with DoH last =
summer. The user experience around activating and configuring DoH =
remains, as you suggest, a research topic. The standard here is informed =
consent.


Again, I haven=E2=80=99t =
been tracking this for quite some time, and so I didn=E2=80=99t want to =
presume that there wasn=E2=80=99t work done =
in this space.  Also, I=E2=80=99m quite certain you meant =
=E2=80=9Cmeaningful consent=E2=80=9D above.  Another question I =
wonder is whether there are times when DoH will be active and when it =
will not be active, again somewhat based on the enterprise use case, or =
whether it should either be enabled or disabled.  The issue is that =
if it can flip from one to the other, do you have to signal the user? =
 If you do, that becomes both real estate and signalling issues, =
the latter of which is subject to habituation.

Again, researchy stuff.  Which =
leads me to another question- if DoH has mostly finished in the IETF, =
maybe this becomes more of a topic for the IRTF?

Eliot
=

--Apple-Mail=_7C69890B-C393-4D05-86F2-FEB66F669BFF--

--Apple-Mail=_68649E47-3EE6-4408-8263-89E1CC4CA047
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlxcZCAACgkQh7ZrRtnS
ejP4DwgAwLx37buxuPFElBQxdlKfERqX3/rrsUid4EIb7xuHgDuaBoMVNhPA47W8
3vDbTUa6b620s7CQbkBZ8SC0ShlX0s4xfeV7+b+WYvf8uX0Motcdaz6TZbOTcjsE
0PxkkbMtikAeBiXpAyhfluWDzbLjnYS6vlxOBgE8mklTFz+6RvrnheRWiee6elBY
x4ixX+FKvKWRFbOOjHJmjUEH/mAuQMm4bML2i+KC9Lrq3Jokomadvwz454gOt0UC
YmeYhdut52hiwQwph0On3z/4sqNqdgsWcLHRsjTtSyYKhYarhfjck9WEcKK63CMm
n33+sfC0+TotIfCjfcN2N2/B1BZ+eQ==
=OBnT
-----END PGP SIGNATURE-----

--Apple-Mail=_68649E47-3EE6-4408-8263-89E1CC4CA047--


From nobody Thu Feb  7 09:17:39 2019
Return-Path: 
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 450C5130E7F for ; Thu,  7 Feb 2019 09:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.22
X-Spam-Level: 
X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 Dj2_4NucfT5N for ; Thu,  7 Feb 2019 09:17:34 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1874F130E6C for ; Thu,  7 Feb 2019 09:17:34 -0800 (PST)
Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x17HHRrZ066489 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Feb 2019 11:17:29 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549559850; bh=0Hn5MlG8EEEAhoEq/V9S44b+v4ktWR2s/ciH6HfL59U=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Zg73ap6/hK8Mm1s543ztlN+C/S6tC3/E+V0g6ecANCR6qrzMupw/zfaehjJSVvF+Q h+s0U6BIjjjIBzmIcUyMpHeINLKylumxGI+MBTMH4zU4cLW2jx28tatNAbuk8Gbkw/ FkRqqEev/OJsyFSvPR48JEsTbxO8WDg98adIKg6w=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at
To: Eliot Lear 
Cc: Paul Hoffman , DoH WG , Ted Lemon , Joseph Lorenzo Hall 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <7A2202F4-FAE9-4282-BC0B-8229A9A6E016@icann.org>  <2073b35e-1383-bae1-b80e-3f3a0db6031f@nostrum.com> 
From: Adam Roach 
Message-ID: <9f86d7ca-8edc-8069-774b-0fe36f102838@nostrum.com>
Date: Thu, 7 Feb 2019 11:17:21 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Feb 2019 17:17:37 -0000

On 2/7/19 11:00 AM, Eliot Lear wrote:
> Again, researchy stuff.  Which leads me to another question- if DoH 
> has mostly finished in the IETF, maybe this becomes more of a topic 
> for the IRTF?

You're talking largely about user interface issues. I'd be extremely 
wary of throwing that into a forum populated primarily by engineers. 
I've learned enough about UI to appreciate that it's a wildly different 
discipline than engineering, and that there's not much hope of quickly 
training engineers on an excruciatingly complex topic that people have 
made multi-decade careers out of.


On 2/7/19 10:58 AM, bert hubert wrote:
> I just enabled DoH to Cloudflare with a single click in Firefox.
>
> I did not get any warning or explanation what this would mean. It had a
> prefilled entry for Cloudflare that I can't even change from the UI.

As above, I don't think the I{E,R}TF is the correct forum to debate 
specific UI decisions.

/a


From nobody Fri Feb  8 00:26:25 2019
Return-Path: 
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 338F91288BD for ; Fri,  8 Feb 2019 00:26:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 RCjjs8wNjvxf for ; Fri,  8 Feb 2019 00:26:22 -0800 (PST)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E841286D8 for ; Fri,  8 Feb 2019 00:26:21 -0800 (PST)
Received: from [2001:470:78c8:2:65fc:c318:cd2d:2bb1] by time-travellers.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1gs1VV-0000DC-JY for doh@ietf.org; Fri, 08 Feb 2019 08:27:33 +0000
To: doh@ietf.org
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com> 
From: Shane Kerr 
Message-ID: 
Date: Fri, 8 Feb 2019 09:26:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2019 08:26:24 -0000

Joe,

On 07/02/2019 16.33, Joseph Lorenzo Hall wrote:
> 3\. Software like browsers seem to want to have a list of DOH providers 
> that they can shuffle queries across in order to minimize the raw 
> quantity of queries any given DOH service sees from a given user. Right 
> now the big DOH services all have very very different privacy policies 
> and terms of service making such a list impossible as you'd be comparing 
> apples to oranges (e.g., one second you are talking to CF's 1.1.1.1 
> which a very strong privacy policy and the next minute you are talking 
> to Google's 8.8.8.8 which has a much less strong privacy policy). How 
> should application developers decide which kind of DOH service to build 
> into their offerings? (My own organization, CDT, is going to start an 
> effort in a few months to try and bring DOH providers together to set 
> some baseline "rules of the road" for these kinds of services and we'd 
> love to work with others thinking about the "wild west" of DOH.)
> 
> ----
> 
> I'm about to go on leave for a bit (18-Feb up to Prague) but would love 
> to help think through what might make sense here. We did a project last 
> year with VPN providers where we sought to clarify some "rules of the 
> road", so to speak, and ended up basically with a standard questionnaire 
> that providers answered ( https://cdt.org/issue/privacy-data/vpns/ , 
> https://cdt.org/insight/unedited-answers-signals-of-trustworthy-vpns/ ).

My feeling is that we should avoid any design or recommendations 
involving multiple upstreams.

My reasoning is that I think that trying to direct queries to multiple 
resolvers is going to run the risk of leaking more information than 
protecting it more.

Certainly a naive approach of just sending to a random server won't 
work, as that basically insures that every resolver operator will see 
every user action pretty quickly.

Trying to isolate to specific user actions might make sense - for 
example send all the queries based on visiting a give web site to a 
single resolver operator. That involves some knowledge about what a 
session or other meaningful grouping of privacy is.

Really I tend to think that in the end we'll re-visit the same problems 
that Tor and other obfuscating overlay networks have tried to address, 
and likely end up with similar solutions. I don't think the DNS 
community understands enough about this to start designing protocols at 
the IETF today. Maybe the web community does, as they are (usually) 
closer to the end user?

Cheers,

--
Shane


From nigel.tedeschi@bt.com  Fri Feb  8 09:57:50 2019
Return-Path: 
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 0B09D1294FA for ; Fri,  8 Feb 2019 09:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 BPKsIc6V-Up6 for ; Fri,  8 Feb 2019 09:57:47 -0800 (PST)
Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D257A124BF6 for ; Fri,  8 Feb 2019 09:57:46 -0800 (PST)
Received: from tpw09926dag07h.domain1.systemhost.net (10.9.202.46) by RDW083A012ED68.bt.com (10.187.98.38) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Feb 2019 17:55:23 +0000
Received: from tpw09926dag07f.domain1.systemhost.net (10.9.202.38) by tpw09926dag07h.domain1.systemhost.net (10.9.202.46) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 8 Feb 2019 17:57:42 +0000
Received: from tpw09926dag07f.domain1.systemhost.net ([fe80::39eb:b031:eb4f:b2c9]) by tpw09926dag07f.domain1.systemhost.net ([fe80::39eb:b031:eb4f:b2c9%12]) with mapi id 15.00.1395.000; Fri, 8 Feb 2019 17:57:42 +0000
From: 
To: 
Thread-Topic: Re: [Doh] Request for the DOH WG to adopt draft-hoffman-resolver-associated-doh
Thread-Index: AdS/168z1HbSsezNSMeCO3LqHus/Gw==
Date: Fri, 8 Feb 2019 17:57:42 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.9.202.242]
Content-Type: multipart/alternative; boundary="_000_fb31ef17a8a34557a3582fecf1b659c0tpw09926dag07fdomain1sy_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Doh] Request for the DOH WG to adopt draft-hoffman-resolver-associated-doh
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2019 18:00:19 -0000

--_000_fb31ef17a8a34557a3582fecf1b659c0tpw09926dag07fdomain1sy_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

WRT the draft - from an ISP perspective we agree it makes sense that it be =
adopted somewhere, probably not the DoH WG? We share concerns mentioned bef=
ore that it'd be better to take a more holistic view of DNS services discov=
ery. As an example within a discovery algorithm, are we indicating DoH repr=
esents the Apex of possible DNS solution choices? This Apex question become=
s more interesting when an application doesn't include a UI to capture a us=
er's choice from a shortlist.



Additionally, many ISPs provide "parental controls / content blocking capab=
ilities",  & Malware detection capabilities at a customer's request, it mig=
ht be useful to understand how these higher layer services, might be mainta=
ined within an overarching DNS discovery service?



Regards

Nigel Tedeschi


--_000_fb31ef17a8a34557a3582fecf1b659c0tpw09926dag07fdomain1sy_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











WRT the d=
raft – from an ISP perspective we agree it makes sense that it be ado=
pted somewhere, probably not the DoH WG? We share concerns mentioned before=
 that it'd be better to take a more holistic
 view of DNS services discovery. As an example within a discovery algorithm=
, are we indicating DoH represents the Apex of possible DNS solution choice=
s? This Apex question becomes more interesting when an application doesn=
217;t include a UI to capture a user’s
 choice from a shortlist. 


&nbs=
p;


Additiona=
lly, many ISPs provide “parental controls / content blocking capabili=
ties”,  & Malware detection capabilities at a customer’=
;s request, it might be useful to understand how these higher layer
 services, might be maintained within an overarching DNS discovery service?=



 


Regards


Nigel Tedeschi






--_000_fb31ef17a8a34557a3582fecf1b659c0tpw09926dag07fdomain1sy_--


From nobody Fri Feb  8 13:19:46 2019
Return-Path: 
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 E181C1293B1 for ; Fri,  8 Feb 2019 13:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_PASS=-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=cdt.org
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 bIi094B_h8Rd for ; Fri,  8 Feb 2019 13:19:43 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 D617412426A for ; Fri,  8 Feb 2019 13:19:42 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id s5so8231750oth.7 for ; Fri, 08 Feb 2019 13:19:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jC33PuxJjmD7UwZOOTmy8COiP6sXmgaLHOpeE736xu8=; b=KzHEv3PZ6R/HIhvKZJQMokVeCradp05YerBiTr/CTOrJK/OXysJn26f8DRg7s0Ai2U 32C1DMw8Bjr+kJaskfJy3bKelWI4JocQ++uS66rrWBuSqzdBgF0g3ZDO3n8Knc+SEje8 9BdsLqOu5M96zJgyvaIOAxAEhPjm9ukYXSfhQ=
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=jC33PuxJjmD7UwZOOTmy8COiP6sXmgaLHOpeE736xu8=; b=F1jc5hV9ql152cgedbmjAt0+tp6JgXlwRqVb7UlssACoCD6EHhhfrr6nJYSrZRHTs9 6qeyN6mYbUQ1u2yM3WqE4VRwSSnJTEHqQ1QOQcnrGlI9LrLQqBt53Kf1mzamxv/EQsUV qgdVi5Md1WX0P9FABINesKGQB8xCvXgxfZgCymuyy2JfK8K7hSPU031u+q+ZSp4GGDNS ElZ7qYOeLcLD0u2A7CaMkCfhY0j67mw5HFgXt0USTDQEWzA8RtWpNAJMZz1DjL9GdzSq xKXkeKjKCCpO75z7JkGewBkleFrzbj+6rNJXQFhVoBODKvLC47M605HoJEDtHp3J6ltg NSyA==
X-Gm-Message-State: AHQUAua9hLq+Hl4VeCDAQUSHrr/ZOT1KyATOUX1G7rbwvsdyPqG7OLap zxcLA8SZmP3lXrGdex0cBdyoldBAqUjIrmsx5/JM4dZq
X-Google-Smtp-Source: AHgI3IbwxWKc9hCRH3a3LMl+YDdaYFEdrPPoVLwRQD2j8nsdtI5/+PwYW553Tcv5nsTtLIlvoqzFdprz/PE5+5imVR4=
X-Received: by 2002:a9d:a83:: with SMTP id 3mr15646820otq.88.1549660781892; Fri, 08 Feb 2019 13:19:41 -0800 (PST)
MIME-Version: 1.0
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>  
In-Reply-To: 
From: Joseph Lorenzo Hall 
Date: Fri, 8 Feb 2019 16:19:31 -0500
Message-ID: 
To: Shane Kerr 
Cc: doh@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006d6bc705816884d2"
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Feb 2019 21:19:45 -0000

--0000000000006d6bc705816884d2
Content-Type: text/plain; charset="UTF-8"

On Fri, Feb 8, 2019 at 3:26 AM Shane Kerr  wrote:

> Joe,
>
> On 07/02/2019 16.33, Joseph Lorenzo Hall wrote:
> > 3\. Software like browsers seem to want to have a list of DOH providers
> > that they can shuffle queries across in order to minimize the raw
> > quantity of queries any given DOH service sees from a given user. Right
> > now the big DOH services all have very very different privacy policies
> > and terms of service making such a list impossible as you'd be comparing
> > apples to oranges (e.g., one second you are talking to CF's 1.1.1.1
> > which a very strong privacy policy and the next minute you are talking
> > to Google's 8.8.8.8 which has a much less strong privacy policy). How
> > should application developers decide which kind of DOH service to build
> > into their offerings? (My own organization, CDT, is going to start an
> > effort in a few months to try and bring DOH providers together to set
> > some baseline "rules of the road" for these kinds of services and we'd
> > love to work with others thinking about the "wild west" of DOH.)
> >
> > ----
> >
> > I'm about to go on leave for a bit (18-Feb up to Prague) but would love
> > to help think through what might make sense here. We did a project last
> > year with VPN providers where we sought to clarify some "rules of the
> > road", so to speak, and ended up basically with a standard questionnaire
> > that providers answered ( https://cdt.org/issue/privacy-data/vpns/ ,
> > https://cdt.org/insight/unedited-answers-signals-of-trustworthy-vpns/ ).
>
> My feeling is that we should avoid any design or recommendations
> involving multiple upstreams.
>
> My reasoning is that I think that trying to direct queries to multiple
> resolvers is going to run the risk of leaking more information than
> protecting it more.
>
> Certainly a naive approach of just sending to a random server won't
> work, as that basically insures that every resolver operator will see
> every user action pretty quickly.
>
> Trying to isolate to specific user actions might make sense - for
> example send all the queries based on visiting a give web site to a
> single resolver operator. That involves some knowledge about what a
> session or other meaningful grouping of privacy is.
>
> Really I tend to think that in the end we'll re-visit the same problems
> that Tor and other obfuscating overlay networks have tried to address,
> and likely end up with similar solutions. I don't think the DNS
> community understands enough about this to start designing protocols at
> the IETF today. Maybe the web community does, as they are (usually)
> closer to the end user?
>
>
Those are great points and I may have taken some liberty with the the
"multiplexing across many DOH providers" statement as I'm not really sure
what browsers want to do, it just seems like having one or a few options is
not ideal. Anyway, I recognize that the work I'm interested in is not
protocol work (as far as I can tell), so I'll stop bugging folks here!
best, Joe

--0000000000006d6bc705816884d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Fri, Feb 8, 2019 at 3:26 AM Shane =
Kerr <shane@time-travellers=
.org> wrote:
Joe,



On 07/02/2019 16.33, Joseph Lorenzo Hall wrote:

> 3\. Software like browsers seem to want to have a list of DOH provider=
s 

> that they can shuffle queries across in order to minimize the raw 

> quantity of queries any given DOH service sees from a given user. Righ=
t 

> now the big DOH services all have very very different privacy policies=
 

> and terms of service making such a list impossible as you'd be com=
paring 

> apples to oranges (e.g., one second you are talking to CF's 1.1.1.=
1 

> which a very strong privacy policy and the next minute you are talking=
 

> to Google's 8.8.8.8 which has a much less strong privacy policy). =
How 

> should application developers decide which kind of DOH service to buil=
d 

> into their offerings? (My own organization, CDT, is going to start an =


> effort in a few months to try and bring DOH providers together to set =


> some baseline "rules of the road" for these kinds of service=
s and we'd 

> love to work with others thinking about the "wild west" of D=
OH.)

> 

> ----

> 

> I'm about to go on leave for a bit (18-Feb up to Prague) but would=
 love 

> to help think through what might make sense here. We did a project las=
t 

> year with VPN providers where we sought to clarify some "rules of=
 the 

> road", so to speak, and ended up basically with a standard questi=
onnaire 

> that providers answered ( https://cdt.org/issue/privacy=
-data/vpns/ , 

> https://cdt.org/insight/un=
edited-answers-signals-of-trustworthy-vpns/ ).



My feeling is that we should avoid any design or recommendations 

involving multiple upstreams.



My reasoning is that I think that trying to direct queries to multiple 

resolvers is going to run the risk of leaking more information than 

protecting it more.



Certainly a naive approach of just sending to a random server won't 
work, as that basically insures that every resolver operator will see 

every user action pretty quickly.



Trying to isolate to specific user actions might make sense - for 

example send all the queries based on visiting a give web site to a 

single resolver operator. That involves some knowledge about what a 

session or other meaningful grouping of privacy is.



Really I tend to think that in the end we'll re-visit the same problems=
 

that Tor and other obfuscating overlay networks have tried to address, 

and likely end up with similar solutions. I don't think the DNS 

community understands enough about this to start designing protocols at 
the IETF today. Maybe the web community does, as they are (usually) 

closer to the end user?



Those are great points and I may have =
taken some liberty with the the "multiplexing across many DOH provider=
s" statement as I'm not really sure what browsers want to do, it j=
ust seems like having one or a few options is not ideal. Anyway, I recogniz=
e that the work I'm interested in is not protocol work (as far as I can=
 tell), so I'll stop bugging folks here! best, Joe



--0000000000006d6bc705816884d2--


From nobody Sun Feb 10 15:51:33 2019
Return-Path: 
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 892871295D8 for ; Sun, 10 Feb 2019 15:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=qb/zr04W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TSEd29HB
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 ov1pJ4UUc0J2 for ; Sun, 10 Feb 2019 15:51:29 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5278F12958B for ; Sun, 10 Feb 2019 15:51:29 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5A58D21A90 for ; Sun, 10 Feb 2019 18:51:28 -0500 (EST)
Received: from web3 ([10.202.2.213]) by compute1.internal (MEProxy); Sun, 10 Feb 2019 18:51:28 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:from:to:mime-version:content-transfer-encoding :content-type:references:subject:in-reply-to:date; s=fm1; bh=2Sv k+RDkcxyGtOrauqR9mVlKDiHJW1+mMmOBBJ5czSE=; b=qb/zr04WOkigDCy0GxH QPMLrMuPAobNbIVDYShq7ZQkScLB4E2emSWkQrPcW8SaRdETDomPmeILTSw7G5JY rr+e1LWP5yAx8JHtCKSlU0iUTWrGHnpWii9QXnoMb5oeOOGSEKyUUEKYjVmFnQbc tSACQnne1jZ2mSNehEc+osn1IU4X4oaMk6gUgsBZJl9W4Z5Lh5grLG9ZQN6fCice /I8ojLHkc9ky1sBRTTHylK+m4Gpkd8csVn45Z59g2lR0KAOJRZPt322sBEuobgUy zyMvdgRV3LUP+q8ZKJuEwGef3pRXLLAEH2gTVe0S2/8bTvOJuNfB+2FLBPCCx66n PxQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=2Svk+RDkcxyGtOrauqR9mVlKDiHJW1+mMmOBBJ5cz SE=; b=TSEd29HBybkPUwbiuxEFUiu/G99xYZJaqpgw6y6athAPCY2vTHgBH3ffm js34F26WUy0u93kl5ZRiudjOUOvITU5Yfg/nfua1+M3WMvt645zXfUeHbu/JiSC/ 4pdy5CEYqRdORvX0FU3JW/1RN6gP1oAlaKLczYNZQ6WuOMsZt/iNdNvk9stRLnwX nY8NySjKV30hcrPF+7kq2ZtgqzsPwUb6oDmtehxs4vZygy2k91/6MZl70PJaalKJ nMPIdUbKsAVaN2vDl9X/rugmMClSo/9Ov5y7xG2QpWOFnwrXbottRXFAKFo+5csH sXBa8MPNT1Z8zOkIXuqONxeTWJsXQ==
X-ME-Sender: 
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleejgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefkhffvggfgtgfofhfujgffsehtjeertdertdejnecuhfhrohhmpe forghrthhinhcuvfhhohhmshhonhcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeen ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenuc evlhhushhtvghrufhiiigvpedt
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 99) id BF2EA9E567; Sun, 10 Feb 2019 18:51:27 -0500 (EST)
Message-Id: <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com>
From: Martin Thomson 
To: doh@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-e6290ad1
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>   
In-Reply-To: 
Date: Mon, 11 Feb 2019 10:51:27 +1100
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Feb 2019 23:51:31 -0000

On Sat, Feb 9, 2019, at 08:19, Joseph Lorenzo Hall wrote:
> Those are great points and I may have taken some liberty with the the
> "multiplexing across many DOH providers" statement as I'm not really sure
> what browsers want to do, it just seems like having one or a few options is
> not ideal. Anyway, I recognize that the work I'm interested in is not
> protocol work (as far as I can tell), so I'll stop bugging folks here!

I don't think that this is entirely crazy.  I agree with Shane that trying to load balance between servers or randomly route to servers is likely to be worse than just picking one, but one option we've considered is picking one server randomly and using that consistently thereafter.  (Cue all the second-order questions regarding how to use that for tracking, etc...)

There is also talk of finding ways to route requests to servers that might own the same name, but that's far more risky.  In other words, this is not a decided matter because it is so clearly not simple.


From nobody Sun Feb 10 16:11:01 2019
Return-Path: 
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 A86821295EC for ; Sun, 10 Feb 2019 16:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=a7r1Y+/I; dkim=pass (1024-bit key) header.d=yitter.info header.b=PIbvphku
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 fTASMvte9gTj for ; Sun, 10 Feb 2019 16:10:57 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAEB1295D8 for ; Sun, 10 Feb 2019 16:10:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 3F62BBCBCC; Mon, 11 Feb 2019 00:10:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1549843856; bh=VBas1olkbiSh/Dt78QXHP7LH63he2fxknhn8t/6ouR0=; h=From:To:Date:In-Reply-To:References:Subject:From; b=a7r1Y+/I5VtILpu1asy7KlfAOvfqKEkgbrrbB3tFTqFXvohTkLrHnwRNIq5LOYyg5 aBVgewf7+T8tQFX9LiIGB6cjLv3RrgfazvYkppemlHYK3ViQjM9yGvB2imNXYbaunY sxGCfDU51gY+6lKE0VOY+gHKpOF5MAj5aIk3xpHE=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3yuRD7rBqnS; Mon, 11 Feb 2019 00:10:55 +0000 (UTC)
From: Andrew Sullivan 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1549843855; bh=VBas1olkbiSh/Dt78QXHP7LH63he2fxknhn8t/6ouR0=; h=From:To:Date:In-Reply-To:References:Subject:From; b=PIbvphkujRcS52zD5M+5d8Hfx6XPGJTGTzsaJ8JBDkXT/t6k4ra+USTLEMAW8XZCx lxOUooYNChGZp22+s6LbyB+z+woIPUs2KQKsituH2a3kRR7A/qyJA+XQg+Bs2t9qzl icAc+4So7NoGkxYTCB7W69uz4ZVPEFglUqaywh84=
To: Martin Thomson , 
Date: Sun, 10 Feb 2019 19:10:53 -0500
Message-ID: <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
In-Reply-To: <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com>
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 00:10:59 -0000

Also, what do you mean exactly by "picking one server"?  The back end state 
surely (!?) won't be shared and there's no reason to suppose names or 
numbers get you to "the same" thing. So ...?

A
--
Andrew Sullivan
Please excuse my clumbsy thums.

On February 10, 2019 18:51:37 Martin Thomson  wrote:

> On Sat, Feb 9, 2019, at 08:19, Joseph Lorenzo Hall wrote:
>> Those are great points and I may have taken some liberty with the the
>> "multiplexing across many DOH providers" statement as I'm not really sure
>> what browsers want to do, it just seems like having one or a few options is
>> not ideal. Anyway, I recognize that the work I'm interested in is not
>> protocol work (as far as I can tell), so I'll stop bugging folks here!
>
> I don't think that this is entirely crazy.  I agree with Shane that trying 
> to load balance between servers or randomly route to servers is likely to 
> be worse than just picking one, but one option we've considered is picking 
> one server randomly and using that consistently thereafter.  (Cue all the 
> second-order questions regarding how to use that for tracking, etc...)
>
> There is also talk of finding ways to route requests to servers that might 
> own the same name, but that's far more risky.  In other words, this is not 
> a decided matter because it is so clearly not simple.
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh




From nobody Sun Feb 10 16:16:54 2019
Return-Path: 
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 3CD8B1295EC for ; Sun, 10 Feb 2019 16:16:53 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 u_uYcz8Pniu0 for ; Sun, 10 Feb 2019 16:16:51 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 92009129284 for ; Sun, 10 Feb 2019 16:16:50 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id r10-v6so7338300ljj.4 for ; Sun, 10 Feb 2019 16:16:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KaAx8tjnDFu7aA+m/fqCNCPwflniW+8/9ShTZKu0ORY=; b=zoijzi9gLOlHw14deDYXG1vmKyFqKgQ/MCb/allS6aPlN8NgfudE+TxmrgRH8k6u4Y QRkS9ZxpUkJk1LJtfc7+HKQhribzverFMTfJsqzjGevDEMVQK7RU73SS1ZN+7GWh1WfA uz4/4VYl+q8t/RAu5SrgMGbsxG0h3+k7y9cuxgiMLbvNztimLl/9bq2YE8KZJYP2LyOF VSTvoBq9T0PGmZoBhjGQM4bd+Jsnfry43ohEuyHmxIFXpGvGk6pwW5LCuphOYH4bOxNT b+ruH3n3mO88VHIJW30Sc5fEEIVcU+fKZ/eoQ+cw5R/bMSE39aXNtKoItRczMFQI4QZ4 A2ew==
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=KaAx8tjnDFu7aA+m/fqCNCPwflniW+8/9ShTZKu0ORY=; b=K4NCtkbvxyUyrM02pqBywejraNrfTF/eieTxmgUnR+QPR/pBTSvbFSOdO6CJWzno3G nMuzM5k1S8M8l3qMOPatd/CEedv1Up8ho9RLbPmTU92CeqrkxaTsAGRGW19G3xKMdccW vcUttf3e3AJNQTkM1TBHMLjGsFndFJu7/Qqs+4htHk/uwKDGlz/JY86jmxE9QOBgTiwh YWgdZJL4C3klzA7gtZ/peXXrwWvYKXiaGZaVDHq0p3M11kWITb+RzYNiNY2fXNkdGSzm VFisFsqKzEkyrJfaRbAiJJT9ZVVdYj8v8elW2Zw4FUZQrSCKKpFAmiIE3dWn9QbSrbmo g4jg==
X-Gm-Message-State: AHQUAuZPGi+LE9xV3T3rKiJ7doCFoVSyasKj1Xep+KIiMX+gKrYVw/08 d+tI8GwWnnjtl+sasysJC+KrkzhHuCApVCYGOmW6Yg==
X-Google-Smtp-Source: AHgI3IZ/snetSkqU8podMJ87jv5yRmzlJFSB+NmnEYEq8PId14O2uDxnbHkLj7ZXzuqS7E2UFcTMQdObWdde17SXUzA=
X-Received: by 2002:a2e:810f:: with SMTP id d15-v6mr2633568ljg.86.1549844208715;  Sun, 10 Feb 2019 16:16:48 -0800 (PST)
MIME-Version: 1.0
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
In-Reply-To: <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
From: Eric Rescorla 
Date: Sun, 10 Feb 2019 16:16:10 -0800
Message-ID: 
To: Andrew Sullivan 
Cc: Martin Thomson , DoH WG 
Content-Type: multipart/alternative; boundary="00000000000084a21805819339dd"
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 00:16:53 -0000

--00000000000084a21805819339dd
Content-Type: text/plain; charset="UTF-8"

n Sun, Feb 10, 2019 at 4:11 PM Andrew Sullivan 
wrote:

> Also, what do you mean exactly by "picking one server"?  The back end
> state
> surely (!?) won't be shared and there's no reason to suppose names or
> numbers get you to "the same" thing. So ...?
>

The general idea would be to have a list of DoH servers (operators, not
machines) and then to randomly select one for each client. We haven't
decided to do this, so also haven't decided on how we'd implement it :)

-Ekr


> A
> --
> Andrew Sullivan
> Please excuse my clumbsy thums.
>
> On February 10, 2019 18:51:37 Martin Thomson  wrote:
>
> > On Sat, Feb 9, 2019, at 08:19, Joseph Lorenzo Hall wrote:
> >> Those are great points and I may have taken some liberty with the the
> >> "multiplexing across many DOH providers" statement as I'm not really
> sure
> >> what browsers want to do, it just seems like having one or a few
> options is
> >> not ideal. Anyway, I recognize that the work I'm interested in is not
> >> protocol work (as far as I can tell), so I'll stop bugging folks here!
> >
> > I don't think that this is entirely crazy.  I agree with Shane that
> trying
> > to load balance between servers or randomly route to servers is likely
> to
> > be worse than just picking one, but one option we've considered is
> picking
> > one server randomly and using that consistently thereafter.  (Cue all
> the
> > second-order questions regarding how to use that for tracking, etc...)
> >
> > There is also talk of finding ways to route requests to servers that
> might
> > own the same name, but that's far more risky.  In other words, this is
> not
> > a decided matter because it is so clearly not simple.
> >
> > _______________________________________________
> > Doh mailing list
> > Doh@ietf.org
> > https://www.ietf.org/mailman/listinfo/doh
>
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>

--00000000000084a21805819339dd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


n Sun, Feb 10, 2019 at 4:11 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Also, what do you mean exactly by "picking one server"?=C2=A0 =
The back end state 

surely (!?) won't be shared and there's no reason to suppose names =
or 

numbers get you to "the same" thing. So ...?

The general idea would be to have a list of DoH servers (op=
erators, not machines) and then to randomly select one for each client. We =
haven't decided to do this, so also haven't decided on how we'd=
 implement it :)

-Ekr




A

--

Andrew Sullivan

Please excuse my clumbsy thums.



On February 10, 2019 18:51:37 Martin Thomson <mt@lowentropy.net> wrote:



> On Sat, Feb 9, 2019, at 08:19, Joseph Lorenzo Hall wrote:

>> Those are great points and I may have taken some liberty with the =
the

>> "multiplexing across many DOH providers" statement as I&=
#39;m not really sure

>> what browsers want to do, it just seems like having one or a few o=
ptions is

>> not ideal. Anyway, I recognize that the work I'm interested in=
 is not

>> protocol work (as far as I can tell), so I'll stop bugging fol=
ks here!

>

> I don't think that this is entirely crazy.=C2=A0 I agree with Shan=
e that trying 

> to load balance between servers or randomly route to servers is likely=
 to 

> be worse than just picking one, but one option we've considered is=
 picking 

> one server randomly and using that consistently thereafter.=C2=A0 (Cue=
 all the 

> second-order questions regarding how to use that for tracking, etc...)=


>

> There is also talk of finding ways to route requests to servers that m=
ight 

> own the same name, but that's far more risky.=C2=A0 In other words=
, this is not 

> a decided matter because it is so clearly not simple.

>

> _______________________________________________

> Doh mailing list

> Doh@ietf.org

> https://www.ietf.org/mailman/listinfo/doh







_______________________________________________

Doh mailing list

Doh@ietf.org

https://www.ietf.org/mailman/listinfo/doh




--00000000000084a21805819339dd--


From nobody Sun Feb 10 16:23:03 2019
Return-Path: 
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 95AFD1295D8 for ; Sun, 10 Feb 2019 16:23:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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=yitter.info header.b=OpCndC0l; dkim=pass (1024-bit key) header.d=yitter.info header.b=WL5V9lOU
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 LWj2YkkBD-I7 for ; Sun, 10 Feb 2019 16:22:59 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217EF12958B for ; Sun, 10 Feb 2019 16:22:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 22882BCBCC; Mon, 11 Feb 2019 00:22:58 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1549844578; bh=2/GDCQ2SM+FXlih+3rlUwJ3ayc1lKXXVJ2QoLQX+ROI=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=OpCndC0lBHA7I4L7De7zjFakx8+bKYNynvMXj7nAACKihftpD++vhF4gsIZsUtx6g RlirD8lgVQEWzYvoPxe+2AXJWOVkprxJqAuT9SfpLIigX+sUgjSIbsIr6dFBQ38qgm Q5ibpMY7sxGKv7xI5mJyZGsUjJr3hrMGqZAgp/zs=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNjcRwmuOWnh; Mon, 11 Feb 2019 00:22:57 +0000 (UTC)
From: Andrew Sullivan 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1549844577; bh=2/GDCQ2SM+FXlih+3rlUwJ3ayc1lKXXVJ2QoLQX+ROI=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=WL5V9lOUWZII42samQXQ5bo0hnG78C2NGdCc3VwA3fgNd5zSsxK6+1dwd6bESE5X4 ORSL1KRw55rlhjZT3WMXk0sIux6bQ5TokwdhbX6jEzBytpjvhN8MbHBxhehY1F52R5 F0kaIZJ31fkkzrXSsOc+z+yBnCzWvhtYCb0+G3ig=
To: Eric Rescorla 
CC: Martin Thomson , DoH WG 
Date: Sun, 10 Feb 2019 19:22:55 -0500
Message-ID: <168d9ef7318.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
In-Reply-To: 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------168d9ef74ef58d7278b49a485f"
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 00:23:01 -0000

This is a multi-part message in MIME format.
------------168d9ef74ef58d7278b49a485f
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit

Ah, "operators" was the bit I'd missed. I'm not too sure I feel my heart 
soar over the idea of entrenching by application various vendor 
preferences, but I cheerfully concede that it's already reality anyway.

A
-- 
Andrew Sullivan
Please excuse my clumbsy thums.
On February 10, 2019 19:16:58 Eric Rescorla  wrote:
> n Sun, Feb 10, 2019 at 4:11 PM Andrew Sullivan  wrote:
>
> Also, what do you mean exactly by "picking one server"?  The back end state
> surely (!?) won't be shared and there's no reason to suppose names or
> numbers get you to "the same" thing. So ...?
>
> The general idea would be to have a list of DoH servers (operators, not 
> machines) and then to randomly select one for each client. We haven't 
> decided to do this, so also haven't decided on how we'd implement it :)
>
> -Ekr
>
>
> A
> --
> Andrew Sullivan
> Please excuse my clumbsy thums.
>
> On February 10, 2019 18:51:37 Martin Thomson  wrote:
>
>> On Sat, Feb 9, 2019, at 08:19, Joseph Lorenzo Hall wrote:
>>> Those are great points and I may have taken some liberty with the the
>>> "multiplexing across many DOH providers" statement as I'm not really sure
>>> what browsers want to do, it just seems like having one or a few options is
>>> not ideal. Anyway, I recognize that the work I'm interested in is not
>>> protocol work (as far as I can tell), so I'll stop bugging folks here!
>>
>> I don't think that this is entirely crazy.  I agree with Shane that trying
>> to load balance between servers or randomly route to servers is likely to
>> be worse than just picking one, but one option we've considered is picking
>> one server randomly and using that consistently thereafter.  (Cue all the
>> second-order questions regarding how to use that for tracking, etc...)
>>
>> There is also talk of finding ways to route requests to servers that might
>> own the same name, but that's far more risky.  In other words, this is not
>> a decided matter because it is so clearly not simple.
>>
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh


------------168d9ef74ef58d7278b49a485f
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Ah, "operators" was the bit I'd missed. I'm not too sure =
I feel my heart soar over the idea of entrenching by application various ve=
ndor preferences, but I cheerfully concede that it's already reality anyway=
. 

A
-=
- 
Andrew Sullivan
Pleas=
e excuse my clumbsy thums.










On February 10, 2019 19:16:58 Eric Rescorla <ekr@rtfm.com> w=
rote:




n Sun, Feb 10, 2019 at 4:11 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Also, what do you mean exactly by "picking one server"?  The back e=
nd state 

surely (!?) won't be shared and there's no reason to suppose names or 

numbers get you to "the same" thing. So ...?

The general idea would be to have a list of DoH servers (operators, n=
ot machines) and then to randomly select one for each client. We haven't de=
cided to do this, so also haven't decided on how we'd implement it :)

-Ekr




A

--

Andrew Sullivan

Please excuse my clumbsy thums.



On February 10, 2019 18:51:37 Martin Thomson <mt@lowentropy.net> wrote:



> On Sat, Feb 9, 2019, at 08:19, Joseph Lorenzo Hall wrote:

>> Those are great points and I may have taken some liberty with the =
the

>> "multiplexing across many DOH providers" statement as I'm not real=
ly sure

>> what browsers want to do, it just seems like having one or a few o=
ptions is

>> not ideal. Anyway, I recognize that the work I'm interested in is =
not

>> protocol work (as far as I can tell), so I'll stop bugging folks h=
ere!

>

> I don't think that this is entirely crazy.  I agree with Shane th=
at trying 

> to load balance between servers or randomly route to servers is likely=
 to 

> be worse than just picking one, but one option we've considered is pic=
king 

> one server randomly and using that consistently thereafter.  (Cue=
 all the 

> second-order questions regarding how to use that for tracking, etc...)=


>

> There is also talk of finding ways to route requests to servers that m=
ight 

> own the same name, but that's far more risky.  In other words, th=
is is not 

> a decided matter because it is so clearly not simple.

>

> _______________________________________________

> Doh mailing list

> Doh@ietf.org

> https://www.ietf.org/mailman/listinfo/doh







_______________________________________________

Doh mailing list

Doh@ietf.org

https://www.ietf.org/mailman/listinfo/doh


















------------168d9ef74ef58d7278b49a485f--


From nobody Mon Feb 11 03:41:05 2019
Return-Path: 
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 7DDFF130E8D for ; Mon, 11 Feb 2019 03:41:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 tp-ccLY3y6wp for ; Mon, 11 Feb 2019 03:41:02 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC55C130E8A for ; Mon, 11 Feb 2019 03:41:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5993CBE4D; Mon, 11 Feb 2019 11:40:58 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcSr2kaziuDI; Mon, 11 Feb 2019 11:40:57 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E34D1BE4C; Mon, 11 Feb 2019 11:40:56 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1549885257; bh=BtPyJQQNcFTDT43MvWwq73T9f3UyIzI4CQxv9wUyLdk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Fe95DcMl3xohwjzyj+3rbkcJ0JwOXYv8rwe+Z98eSBHPbKwW3BGzL2EZNyP6X22sP +RBOb3GoMDAm8nRFbSyBEdoadXmEuv8r9hn4t0mg0Ts+O4ZQXAwxHxq8b47+NpnU2o D4mM4pZaj5TVfZpLokL2tQ1Cs9oGMKKBdxU4Ju9M=
To: Eric Rescorla , Andrew Sullivan 
Cc: DoH WG , Martin Thomson 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> 
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: 
Date: Mon, 11 Feb 2019 11:40:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pKyXjC1FZxXr275DknEANcNmYuYrexNGC"
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 11:41:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pKyXjC1FZxXr275DknEANcNmYuYrexNGC
Content-Type: multipart/mixed; boundary="ofu3H9A8yJxjfIiwZmkG77kjJbuZMlkiO";
 protected-headers="v1"
From: Stephen Farrell 
To: Eric Rescorla , Andrew Sullivan 
Cc: DoH WG , Martin Thomson 
Message-ID: 
Subject: Re: [Doh] panel discussion on DoH/DoC
References: <20190207105106.GB1772@server.ds9a.nl>
 
 <20190207130313.7g7hf4swaopnr75e@nic.fr>
 
 <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com>
 <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com>
 <1503183837.15474.1549549260349@appsuite.open-xchange.com>
 <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>
 
 
 
 <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com>
 <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
 
In-Reply-To: 

--ofu3H9A8yJxjfIiwZmkG77kjJbuZMlkiO
Content-Type: multipart/mixed;
 boundary="------------C6FB0A37E4581B5AB0EDBD34"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------C6FB0A37E4581B5AB0EDBD34
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 11/02/2019 00:16, Eric Rescorla wrote:
> The general idea would be to have a list of DoH servers (operators, not=

> machines) and then to randomly select one for each client. We haven't
> decided to do this, so also haven't decided on how we'd implement it :)=


I agree that picking one like that is no worse and likely better than
round robin or similar, when considering how the DoH servers can affect
the browser user's privacy in "normal" scenarios. I'd guess that the
censorship scenario might call for something else though, esp if the
selected DoH server becomes unresponsive. Be interested if you've
thoughts on that. (Not sure myself what browser behaviours might be
best in such failure cases.)

Cheers,
S.

--------------C6FB0A37E4581B5AB0EDBD34
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X
CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq
Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h
cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp
MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB
ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ
yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V
4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy
I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg
2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc
/MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp
IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL
CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m
x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw
aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG
+48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk
kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr
pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT
iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy
BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV
LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M
zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95
8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6
TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK
CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L
ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G
+po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf
Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+
q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm
ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD
BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius
gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK
gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds
tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36
ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh
KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ
4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA
cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c
b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73
gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR
yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC
98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE
z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME
p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl
74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks
lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2
B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV
hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK
WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc
p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw
QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk
OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI
/awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH
JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0
b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI
BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7
NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt
zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63
6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a
5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO
8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9
tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn
20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8
/iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS
fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU
Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK
W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC
LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU
6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L
nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq
gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6
Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5
wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9
g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2
Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A
WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU
hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR
SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK
ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq
ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u
U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc
r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr
WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt
U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7
O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez
GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf
pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC
6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2
D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe
A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ
/Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt
PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr
em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96
Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh
x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ
oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P
/1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8
Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ
gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5
SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2
oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA
ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA
ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM
eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS
/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ
IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO
KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DJ121
-----END PGP PUBLIC KEY BLOCK-----

--------------C6FB0A37E4581B5AB0EDBD34--

--ofu3H9A8yJxjfIiwZmkG77kjJbuZMlkiO--

--pKyXjC1FZxXr275DknEANcNmYuYrexNGC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxhX0gACgkQWrL68XsX
K+qmgg//bzisOXhkQDadNPdKcDvI85EsvoGHN59qrgadV1EY+Yg6OSVx4vj1MK51
UZw8227wKYmQol1ITwLGoNs4crJlexgHnsfDedMIJsdATvuFhGf6UVWqK8IMl84V
BrAaiu1fTrs/Ehf6cBA7RXTqllE65edWP55MWR7s5yfpCuaX1t2IX45JK7jny73B
0W8U0QKDu4OVehZ5GY1w62U49+LscPdYkYH+uYEefVv1/G/GDqEN4SwET+IrxsER
4C1Lb/onx7CYmGgAJ3i/rxpJl8gjYl3mBrzkUh7XxFuG9hjbIbeVziaxzZQmVr5P
+gbxItg+JJQrIvRVQg9fmkntJawIKfECOa9NsTfadBUCZ2IfcjXgpbPRxWHMnLES
fQepyT6CtkaJxjWrl00+B2N3ZQSdYPcctiiudWJ8mOym1NTocWY5yhOz6rkAGeOF
krMbVrVKLaUfZGkmhUj1SdrUi6kppwFjwVuEaHS7e2CJ+yYQrG9Tl6bsxX8qBmL/
8r7jxMeZ4l6FDqhCnZTfO+SC/E1TObalL4YF28cPr1V7SKZT2Qc4QyNTeGDyM96t
i8pulvsgt7eC54aYvJ3a1XHgIWorRoJDKKM5QZWEDkesPgZTjRqnaRwgW0IucN7B
Sedtf+J/43br8zsro7tiXvxblj+QRUD7YSepO79haYmxJM6ShGw=
=6+mS
-----END PGP SIGNATURE-----

--pKyXjC1FZxXr275DknEANcNmYuYrexNGC--


From nobody Mon Feb 11 04:11:36 2019
Return-Path: 
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 03FBE1286D8 for ; Mon, 11 Feb 2019 04:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KAQaxAo9ycZk for ; Mon, 11 Feb 2019 04:11:33 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4976A130E8D for ; Mon, 11 Feb 2019 04:11:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1940; q=dns/txt; s=iport; t=1549887093; x=1551096693; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=KVYCjqvPdF38PjoazYY/DU50q1O2eg47EJuQNS4svJ0=; b=gusXzw43ss34UAH77fp2lGelnTFP712jl63QP5tmkjDtCqelqR/l9RHC ZWczBfqLWoiR7RvddVo451ThiBk8iMRYUj/dATNt5Vt5P+bbqkJJVirx0 PaoBAhKyGULjnTEr1q4G59aaJLf/tGFwEbx9P3A4ZJW63d9Zr8pp2pH0W 4=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAzZWFc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgzsyJ4weX40bmBOBewgDAQGEbAKDYDQ?= =?us-ascii?q?JDQEDAQECAQECbSiFSgEBAQECAXkFCwsYLlcGE4MkAYF5CKpthUSEVA+CLj+?= =?us-ascii?q?JbYF/gTgfgkyIO4IEIgKRBIYri3AJhEeOCRmKUIgQmSqCawIEBgUCFIFGOIF?= =?us-ascii?q?WMxoIGxU7KgGCQT6BaRiOHz4DMIxiAQE?=
X-IronPort-AV: E=Sophos; i="5.58,358,1544486400"; d="asc'?scan'208"; a="9952398"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2019 12:11:30 +0000
Received: from [10.61.201.117] ([10.61.201.117]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x1BCBTTK024828 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Feb 2019 12:11:30 GMT
From: Eliot Lear 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_395C848E-7056-4B02-AEB1-24F9F4B3AB86"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 11 Feb 2019 13:11:29 +0100
In-Reply-To: 
Cc: Eric Rescorla , Andrew Sullivan , DoH WG , Martin Thomson 
To: Stephen Farrell 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>  
X-Mailer: Apple Mail (2.3445.102.3)
X-Outbound-SMTP-Client: 10.61.201.117, [10.61.201.117]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 12:11:35 -0000

--Apple-Mail=_395C848E-7056-4B02-AEB1-24F9F4B3AB86
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 11 Feb 2019, at 12:40, Stephen Farrell  =
wrote:
>=20
> Signed PGP part
>=20
> Hiya,
>=20
> On 11/02/2019 00:16, Eric Rescorla wrote:
>> The general idea would be to have a list of DoH servers (operators, =
not
>> machines) and then to randomly select one for each client. We haven't
>> decided to do this, so also haven't decided on how we'd implement it =
:)
>=20
> I agree that picking one like that is no worse and likely better than
> round robin or similar, when considering how the DoH servers can =
affect
> the browser user's privacy in "normal" scenarios.

If you pick more than one and your information then subsequently leaks, =
how do you establish who leaked it?  One could keep a log, but then one =
has to protect the log.  One could devise some interesting hash-based =
selection algorithm, but the inputs would have to remain stable and the =
algorithm somehow accessible.

Sounds messy.

Eliot

--Apple-Mail=_395C848E-7056-4B02-AEB1-24F9F4B3AB86
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlxhZnEACgkQh7ZrRtnS
ejOgRgf/V64zc5nZVpBVo61nOE4IMKuRhB0iTx2cQh5Q+9Wu9xOb8nCR8T2H2hvw
B0PbsS588UQ9LaB8/EKd3SkmjxMdiFoI6BxmPZiSMWAXzAclK7oZS8DPLg78a+bt
ix9YVJCCyH5nE0VrAgTP816IACNltxKoxs7czjveQHmAmT4LW1d21RpHIA+TWyNH
xxZo83rXHVbL3nmbRbnAyV9VRfwXOeRN8uN2r74y5cx7mOhV6VU4DgyntlBoi8ij
Uv7eKok3UOAwa/BX2FvGz62NwuwOxIWIErQv9TiQko4G+t4nx9be0AmzaDQhrzpI
/QUkVYmv9fhK9hMzejWyDraytS6F0g==
=xc94
-----END PGP SIGNATURE-----

--Apple-Mail=_395C848E-7056-4B02-AEB1-24F9F4B3AB86--


From nobody Mon Feb 11 05:21:03 2019
Return-Path: 
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 CA6C9130E8F for ; Mon, 11 Feb 2019 05:21:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lOyq05N6N7q8 for ; Mon, 11 Feb 2019 05:21:00 -0800 (PST)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFCE12D4EA for ; Mon, 11 Feb 2019 05:21:00 -0800 (PST)
Received: from open-xchange.com (unknown [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 586126A23E; Mon, 11 Feb 2019 14:20:54 +0100 (CET)
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 4B2B13C20A4; Mon, 11 Feb 2019 14:20:54 +0100 (CET)
Date: Mon, 11 Feb 2019 14:20:53 +0100 (CET)
From: Vittorio Bertola 
To: Stephen Farrell , Eric Rescorla ,  Andrew Sullivan 
Cc: DoH WG 
Message-ID: <2108215800.1884.1549891254241@appsuite.open-xchange.com>
In-Reply-To: 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev7
X-Originating-Client: open-xchange-appsuite
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 13:21:02 -0000

> Il 11 febbraio 2019 alle 12.40 Stephen Farrell  ha scritto:
> 
> 
> Hiya,
> On 11/02/2019 00:16, Eric Rescorla wrote:
>> The general idea would be to have a list of DoH servers (operators, not machines) and then to randomly select one for each client. We haven't decided to do this, so also haven't decided on how we'd implement it :)
>
> I agree that picking one like that is no worse and likely better than round robin or similar, when considering how the DoH servers can affectthe browser user's privacy in "normal" scenarios. I'd guess that the censorship scenario might call for something else though, esp if the selected DoH server becomes unresponsive. Be interested if you've thoughts on that. (Not sure myself what browser behaviours might be best in such failure cases.)

Sooner or later, this will have to be addressed as a much broader architectural issue: the original assumption that all DNS resolvers give the same reply to all DNS queries everywhere to everyone, so it doesn't really matter which one you use, has been false for quite some time already, due to several use cases of which only a small minority pertains to censorship. Should we get back to the original principle - as a centralized/randomized DoH server set would possibly imply - or should we find ways to make localized DNS policies exist and work well?

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy


From nobody Mon Feb 11 09:19:07 2019
Return-Path: 
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 1A04B1310BA for ; Mon, 11 Feb 2019 09:19:05 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 pbJxxicjRWWh for ; Mon, 11 Feb 2019 09:19:03 -0800 (PST)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 E01051310A8 for ; Mon, 11 Feb 2019 09:19:02 -0800 (PST)
Received: by mail-lf1-x134.google.com with SMTP id m11so8369330lfc.6 for ; Mon, 11 Feb 2019 09:19:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6IK6ZC3k976kG68jeRxMezRcWD+FtPq5nZv2ZHUVSQU=; b=s34K/3vzG6tfOTzMHCuTpPpeHVdysc528Ma7R1H4lrhMG/uDvqxVLl3OFchuawoaV3 1lPb/xY3G7RfFwcvhIII2UNoMdq7FK8VvrsBCH5wG4WXp7hlAkYzbahbFFNWOBL26Qt0 1NpbHrlpus+b6So9NaZ9q/LKYaUcTVfaOhphtefHWdvUnQM4vwIzgxipEq5bDJwTASvz wOe8aDEKwuIirIWFxjVwD+ENsFt2F/wNhXJC0ekfCkKwNGr3VAKYzYi+HLTaLEc7Y67i fJaQLZjNQSe/M/7qxbSytMX0QwJhoViDEw48L9E75xkSgn5zu2uYVTZkjrbAvzekuvkZ jmiw==
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=6IK6ZC3k976kG68jeRxMezRcWD+FtPq5nZv2ZHUVSQU=; b=jx25fCOVdrRYw9FYxiSZ5zZ5iPl03P9u6MIJmkERG1xFRQwnPOmSGIQw/v/+8AWEl1 36MtxTILkM6Vnl7D+UYcOf7dn/W4x47bhNevhkUHcvQMbcqUmvHR1f0d4lEIJOUmf0ba SprviyoE6kwGx5jiX4xxI4m5FiQZi3tQMsnEeHJvFjFclvogRUxH1KNvETxLTLPRQ8CB C7k9/u17FkVNRAL3Gpl8j0qI5hWvk/HzuU1zUhs7Ckd2EvBGG4sUxb5UimsiUJ1HW1vA 961Mp3oklC5OJXLBOBVvoDqX9C/obq8nQXWBj0BHNYQjq4mepvdbRySY39AenWJYZmkw 6K8g==
X-Gm-Message-State: AHQUAuae73dUBNMJ0VHkgBLq3hv61zqfAmdyFk8o2g2NVeyEy0P3uMMh 7ZuKvI8mew0kDOzfm2NsQoRA68/hMPodk8aU3nf7TQ==
X-Google-Smtp-Source: AHgI3Ibvy8+QQ820i3yFNAibPP7MXc7QP04u6xwuSwQk50FWUzY+U8SHItC9sGOTaHQfC7dbyTSVaosV1ZE2x/R5f1A=
X-Received: by 2002:a19:9904:: with SMTP id b4mr22809630lfe.95.1549905540934;  Mon, 11 Feb 2019 09:19:00 -0800 (PST)
MIME-Version: 1.0
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>  
In-Reply-To: 
From: Eric Rescorla 
Date: Mon, 11 Feb 2019 09:18:24 -0800
Message-ID: 
To: Stephen Farrell 
Cc: Andrew Sullivan , DoH WG ,  Martin Thomson 
Content-Type: multipart/alternative; boundary="0000000000003411320581a181d1"
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 17:19:05 -0000

--0000000000003411320581a181d1
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 11, 2019 at 3:40 AM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 11/02/2019 00:16, Eric Rescorla wrote:
> > The general idea would be to have a list of DoH servers (operators, not
> > machines) and then to randomly select one for each client. We haven't
> > decided to do this, so also haven't decided on how we'd implement it :)
>
> I agree that picking one like that is no worse and likely better than
> round robin or similar, when considering how the DoH servers can affect
> the browser user's privacy in "normal" scenarios. I'd guess that the
> censorship scenario might call for something else though, esp if the
> selected DoH server becomes unresponsive. Be interested if you've
> thoughts on that. (Not sure myself what browser behaviours might be
> best in such failure cases.)
>

Well, as I said, we haven't really sorted this out. But it's also kind of
out of scope for this WG.

-Ekr


> Cheers,
> S.
>

--0000000000003411320581a181d1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Feb 11, 2019 at 3:40 AM Steph=
en Farrell <stephen.farrell=
@cs.tcd.ie> wrote:


Hiya,



On 11/02/2019 00:16, Eric Rescorla wrote:

> The general idea would be to have a list of DoH servers (operators, no=
t

> machines) and then to randomly select one for each client. We haven=
9;t

> decided to do this, so also haven't decided on how we'd implem=
ent it :)



I agree that picking one like that is no worse and likely better than

round robin or similar, when considering how the DoH servers can affect

the browser user's privacy in "normal" scenarios. I'd gue=
ss that the

censorship scenario might call for something else though, esp if the

selected DoH server becomes unresponsive. Be interested if you've

thoughts on that. (Not sure myself what browser behaviours might be

best in such failure cases.)

Well, as I=
 said, we haven't really sorted this out. But it's also kind of out=
 of scope for this WG.

-Ekr




Cheers,

S.




--0000000000003411320581a181d1--


From nobody Mon Feb 11 09:30:08 2019
Return-Path: 
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 A05AD1310A8 for ; Mon, 11 Feb 2019 09:30:06 -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 ErzjdQO2POFH for ; Mon, 11 Feb 2019 09:30:05 -0800 (PST)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C862A1310A0 for ; Mon, 11 Feb 2019 09:30:04 -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 1D815242109D; Mon, 11 Feb 2019 17:30:02 +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 
In-Reply-To: 
Date: Mon, 11 Feb 2019 17:30:01 +0000
Cc: DoH WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <781D20D5-D130-4B50-B7A9-317C0660FF12@rfc1035.com>
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>   
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 17:30:07 -0000

On 11 Feb 2019, at 17:18, Eric Rescorla  wrote:
>=20
>> On Mon, Feb 11, 2019 at 3:40 AM Stephen Farrell =
 wrote:
>>=20
>> I agree that picking one like that is no worse and likely better than
>> round robin or similar, when considering how the DoH servers can =
affect
>> the browser user's privacy in "normal" scenarios. I'd guess that the
>> censorship scenario might call for something else though, esp if the
>> selected DoH server becomes unresponsive. Be interested if you've
>> thoughts on that. (Not sure myself what browser behaviours might be
>> best in such failure cases.)
>=20
> Well, as I said, we haven't really sorted this out. But it's also kind =
of out of scope for this WG.

Hmmm. Wouldn't the WG=E2=80=99s charter commitments on privacy and =
security apply to this topic?

Picking your favourite DoH service/server would probably be out of scope =
for the WG. However I think the privacy and security considerations that =
should be part of that selection decision would be in scope for the WG.


From nobody Mon Feb 11 09:36:40 2019
Return-Path: 
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 3CAFA1310FD for ; Mon, 11 Feb 2019 09:36:28 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 jXIIhw8fdr10 for ; Mon, 11 Feb 2019 09:36:25 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 4FB151310D7 for ; Mon, 11 Feb 2019 09:36:25 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id n23so8427967lfl.4 for ; Mon, 11 Feb 2019 09:36:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0XPw7FYUxdxaUBHReMe/7r/iTkUf68xK8tQ+owOlPKc=; b=JPbJ87Vqah7+VlA3aDE6i1VLstSczFDcqOnf5fxMSUkspqT9Tfq3COnTxzz7Mep7hU n8VmFw8mzhmOoci13r21iWEZkwXk2tvzwiRh+o6Ad/febCG4xZr6YaH/W8d60wAkOuVC eGyR3a8AxvmLT46AZIceQVeGzS3yRbJLdrQ+aq3X1cuMhacZtGmtzey2Nno6mYanTxnQ JnnxPU0TQ034XENtJWEvHvO9m8thzbW1kaHxCsLbYMxLdTg0HgNhXU4/JwW6ZhaNyAOT ERdmBQxaUrr2Wj4zHKeHHfbaCv8TYzuSy2+/f/FqWvq+WcMN0M8vF4p67Mex36XM/KU4 X4JQ==
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=0XPw7FYUxdxaUBHReMe/7r/iTkUf68xK8tQ+owOlPKc=; b=G5VDkhqbz2nxo54xusIGaU0jKxLYU/+wN3ZcK8bD1zVO4hX00HSGn6htw1yPDleUOs 4c31oz5kpT1rzXOf05uuyK06np9tupq/xL6/drg8GVhyxelWyry4495iUsSQRQGDdGwW hwLy5QSCcSZ115qlxk7VpgIMJ1mRKrtGN47b0V5cj1X3Hb1VUEqeWcZEvKm08xWyo8Zs MOFYythjUS4MK2i/kc9ai4l3GYyNQe/oZLHBXGVobwHZzImPlmgRHx7M8aYkGgCG9w/s tl6mKBUEqnrEL/8cZ0hakV6GxfvlmXCMUWv8iRlRkoO+RwuYaviKp8gmlGrluXJvZlBX mOXA==
X-Gm-Message-State: AHQUAubEyoITTDaX4q8dcs/AymMXN9cer5DeVdOTA2tmTYyrWL5m2rRM 4amkNZ+mh/QgOsODVbFKbNZ3q41klgw4zUH0KbdTiseO
X-Google-Smtp-Source: AHgI3Ia+dYYs5/Rd9Dj40198CI54TR2bj/GumNc4ObvzGRnVqKsdSN0pRMG9oPoVIobk5qmLWnMebxHfW6y4WWSBkzE=
X-Received: by 2002:ac2:51bc:: with SMTP id f28mr2778864lfk.123.1549906583233;  Mon, 11 Feb 2019 09:36:23 -0800 (PST)
MIME-Version: 1.0
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>    <781D20D5-D130-4B50-B7A9-317C0660FF12@rfc1035.com>
In-Reply-To: <781D20D5-D130-4B50-B7A9-317C0660FF12@rfc1035.com>
From: Eric Rescorla 
Date: Mon, 11 Feb 2019 09:35:46 -0800
Message-ID: 
To: Jim Reid 
Cc: DoH WG 
Content-Type: multipart/alternative; boundary="000000000000542f6f0581a1bfa5"
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 17:36:39 -0000

--000000000000542f6f0581a1bfa5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 11, 2019 at 9:30 AM Jim Reid  wrote:

> On 11 Feb 2019, at 17:18, Eric Rescorla  wrote:
> >
> >> On Mon, Feb 11, 2019 at 3:40 AM Stephen Farrell <
> stephen.farrell@cs.tcd.ie> wrote:
> >>
> >> I agree that picking one like that is no worse and likely better than
> >> round robin or similar, when considering how the DoH servers can affec=
t
> >> the browser user's privacy in "normal" scenarios. I'd guess that the
> >> censorship scenario might call for something else though, esp if the
> >> selected DoH server becomes unresponsive. Be interested if you've
> >> thoughts on that. (Not sure myself what browser behaviours might be
> >> best in such failure cases.)
> >
> > Well, as I said, we haven't really sorted this out. But it's also kind
> of out of scope for this WG.
>
> Hmmm. Wouldn't the WG=E2=80=99s charter commitments on privacy and securi=
ty apply
> to this topic?
>
> Picking your favourite DoH service/server would probably be out of scope
> for the WG. However I think the privacy and security considerations that
> should be part of that selection decision would be in scope for the WG.
>

Well, the WG was chartered to design this protocol and "analyze the
security and privacy issues". I think the main spec has done that.

Resolver selection seems pretty out of scope for that charter.

-Ekr

--000000000000542f6f0581a1bfa5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




=

On Mon, Feb 11, 2019 at 9:30 AM Jim R=
eid <jim@rfc1035.com> wrote:
On 11 Feb 2019, a=
t 17:18, Eric Rescorla <ekr@rtfm.com> wrote:

> 

>> On Mon, Feb 11, 2019 at 3:40 AM Stephen Farrell <stephen.farrell@cs.tcd.ie<=
/a>> wrote:

>> 

>> I agree that picking one like that is no worse and likely better t=
han

>> round robin or similar, when considering how the DoH servers can a=
ffect

>> the browser user's privacy in "normal" scenarios. I&=
#39;d guess that the

>> censorship scenario might call for something else though, esp if t=
he

>> selected DoH server becomes unresponsive. Be interested if you'=
;ve

>> thoughts on that. (Not sure myself what browser behaviours might b=
e

>> best in such failure cases.)

> 

> Well, as I said, we haven't really sorted this out. But it's a=
lso kind of out of scope for this WG.



Hmmm. Wouldn't the WG=E2=80=99s charter commitments on privacy and secu=
rity apply to this topic?



Picking your favourite DoH service/server would probably be out of scope fo=
r the WG. However I think the privacy and security considerations that shou=
ld be part of that selection decision would be in scope for the WG.

Well, the WG was chartered to design this prot=
ocol and "analyze the security and privacy issues". I think the m=
ain spec has done that.

Resolver selection seems p=
retty out of scope for that charter.

-Ekr



--000000000000542f6f0581a1bfa5--


From nobody Mon Feb 11 14:41:05 2019
Return-Path: 
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 9513E129524 for ; Mon, 11 Feb 2019 14:41:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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=cs.tcd.ie
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 Gug7g0C9HO9S for ; Mon, 11 Feb 2019 14:41:01 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070F81279E6 for ; Mon, 11 Feb 2019 14:41:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4706EBE38; Mon, 11 Feb 2019 22:40:55 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d23l6h1SAQdO; Mon, 11 Feb 2019 22:40:54 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4943BE2F; Mon, 11 Feb 2019 22:40:53 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1549924853; bh=yQqBn18kYLIzrYVevZQV/tAj9EeuWaqumjNmbVZKr/o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=G0di9nlx5aQ8fl61uODFzDOkhE8Zv5p21dZO7GZJhRgGoD+txH0rjtbrv/Zd7f+2c E0xGWiug5zW5R+9wRDQ8PWTh/Smq+gJ/YK6+1U6jzt/hqtf7qipn0M7qwaSd29N1/v 1tldor52h3tB7RcMxtAxGU5MKXFeHXwDJxwGp07E=
To: Eric Rescorla 
Cc: Andrew Sullivan , DoH WG , Martin Thomson 
References: <20190207105106.GB1772@server.ds9a.nl>  <20190207130313.7g7hf4swaopnr75e@nic.fr>  <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com> <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com> <1503183837.15474.1549549260349@appsuite.open-xchange.com> <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>    <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com> <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>   
From: Stephen Farrell 
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <9271e075-40cd-7bb9-9a0d-ca8e74654b4e@cs.tcd.ie>
Date: Mon, 11 Feb 2019 22:40:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="r7Mw1MRX3YVBoygIw7BWx0nbFjrBiaP2h"
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Feb 2019 22:41:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--r7Mw1MRX3YVBoygIw7BWx0nbFjrBiaP2h
Content-Type: multipart/mixed; boundary="sIzI5nc2QVCzBFjAhGHgabEhyymGBYVF0";
 protected-headers="v1"
From: Stephen Farrell 
To: Eric Rescorla 
Cc: Andrew Sullivan , DoH WG ,
 Martin Thomson 
Message-ID: <9271e075-40cd-7bb9-9a0d-ca8e74654b4e@cs.tcd.ie>
Subject: Re: [Doh] panel discussion on DoH/DoC
References: <20190207105106.GB1772@server.ds9a.nl>
 
 <20190207130313.7g7hf4swaopnr75e@nic.fr>
 
 <637C85D5-EACC-4C39-A220-753AC83FD78A@rfc1035.com>
 <35CBC108-69C9-4EB9-AACE-EEB39F802456@fugue.com>
 <1503183837.15474.1549549260349@appsuite.open-xchange.com>
 <97216205-8415-42F6-BF24-5FFB589FC887@rfc1035.com>
 
 
 
 <1549842687.561412.1655109464.1F2DA0B4@webmail.messagingengine.com>
 <168d9e46ec8.278b.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>
 
 
 
In-Reply-To: 

--sIzI5nc2QVCzBFjAhGHgabEhyymGBYVF0
Content-Type: multipart/mixed;
 boundary="------------DDC9D062B76DC74A31E32E4E"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------DDC9D062B76DC74A31E32E4E
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 11/02/2019 17:18, Eric Rescorla wrote:
> On Mon, Feb 11, 2019 at 3:40 AM Stephen Farrell 
> wrote:
>=20
>>
>> Hiya,
>>
>> On 11/02/2019 00:16, Eric Rescorla wrote:
>>> The general idea would be to have a list of DoH servers (operators, n=
ot
>>> machines) and then to randomly select one for each client. We haven't=

>>> decided to do this, so also haven't decided on how we'd implement it =
:)
>>
>> I agree that picking one like that is no worse and likely better than
>> round robin or similar, when considering how the DoH servers can affec=
t
>> the browser user's privacy in "normal" scenarios. I'd guess that the
>> censorship scenario might call for something else though, esp if the
>> selected DoH server becomes unresponsive. Be interested if you've
>> thoughts on that. (Not sure myself what browser behaviours might be
>> best in such failure cases.)
>>
>=20
> Well, as I said, we haven't really sorted this out. But it's also kind =
of
> out of scope for this WG.

Sure. I wasn't implying anything about scope, I was just interested
in the problem as it seems relevant for people on this list. "Haven't
got there yet" is a perfectly good answer.

Cheers,
S.

>=20
> -Ekr
>=20
>=20
>> Cheers,
>> S.
>>
>=20

--------------DDC9D062B76DC74A31E32E4E
Content-Type: application/pgp-keys;
 name="0x5AB2FAF17B172BEA.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x5AB2FAF17B172BEA.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem
CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT
q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE
gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy
+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5
iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9
to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV
B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5
FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK
7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t
lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB
tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9
UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG
CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk
rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr
sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ
sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG
nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk
d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv
Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG
FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV
N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v
ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv
tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9
UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok
Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm
uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT
AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ
IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5
DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X
CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq
Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h
cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp
MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB
ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ
yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V
4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy
I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv
X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg
2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc
/MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu
4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5tDJTdGVwaGVuIEZhcnJlbGwgKDIwMTcp
IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJCZQmAAUL
CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m
x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1yw
aps8HGUNhLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG
+48od+Xn7qg6LT7GrHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXk
kTFaSGYJj3yIP4R6IgwBYGMzDXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRr
pZtXB1XQc23ZZmrlTkl2HaThL6w3YKdiTi1NbuMeOxZqtXcUshII45sANm4HuWNT
iRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS3MmGgVS4ZoX8+VaPGpXdQVFy
BMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml3OEuIQiP2ehRt/HV
LMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi2/Jrsz6M
zh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95
8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6
TzKjGjruq8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxIkBHAQQAQgABgUCWj1SoAAK
CRAvPIc2gF+NovMcCACVZPo1cQa3D+vWaIo0ZyinO/MgtD2gHysoj1T0Qvq05//L
ZXmhh578bJANvdl2g/HFhhwl/5HKIfWcyipQhmJklp/dsleKcNnn4B18T75RHY0G
+po3ILq7evbiOjUH+xqApti1aCxi1GocsPghaLfsxmtXKMG4Xu7XhDTv66GOrqZf
Y7+0ekJjD9Dza1t5NE/JR/VZA4B8PWR8Glb0+8C9rkjD0VZ5ekJdHPDGcJmFh8Z+
q25LDoI8Fgt1uKSowvoVnsQO5MFv/y6bXArtj1uB4hAL4JiOFgHlFdrW0MlFpvYm
ziW4K9JHTD8KAfDbrb3e2W97ZDpROuYfE/lTbYOWiQI9BBMBCAAnBQJaPVAyAhsD
BQkJlCYABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEFqy+vF7Fyvq0mkP/ius
gsf6Z4/Tu+vHzBbl5i6oKI8ZieH8JfEgXx4ut9t7l3hBGC2r7DpR5A8zLMpEhGIK
gFcHagksFkfLEE/FmWDfd1MysQafxBYrHaI27P2tkxfI5JYV6247TV39pQ93kGds
tsjIrmh/zEJCVczoofxtz72BDt51H2Z8tN28F/YVHnbaGDwFEEzWKYpze87y/f36
ogcdGO6LDEEEIA6Ee0dGxleuKlLS4UDTt0zjo6L8TyiyPHp9C3+UfnP8837Zp3Fh
KstIBd+vWgPdHFg2G5aDIYUvrj9UJBvVgaN/RnkwE+dab2OBSg5jkr141JLQvzdZ
4mOUXn5D9Y6AH6tvj0+ubYMV6j35L1/ZXncuXPVYiylcmDp/6f2WYcT3gx9CPUYA
cLMjQV4vX2W8z4uEPyMlIJuGsLf7KhvLL8BQ6zlncT6eONfUUX9UJUCzqI5rqL5c
b5jWGHeKvbLWRyQnlq5PXQxJTwYRm71rJTgzejc33LE6Nqg/Q25Dgwwsv+f+7i73
gB5loc80Fef+FV9VFGalFe0Yq8m0UASmkYRh7MH5ssoibpeWk+SGfBjOV4tnsAwR
yjYLpAzxA8HeDcmlLeypGEDmsQ/iUvXoGaKOYX4Ieg8T/PCAplsqnJUOq8hbkgOC
98gLZfiltkNG8YhQpoZIHj6SxmBRSc3K99CvanuOiQIzBBABCAAdFiEEfhcKBFyE
z0YOK3mgEO952f2DUxIFAlu3JJsACgkQEO952f2DUxJ4qRAAmbjiO3WTAeBCB4ME
p2N2+XQCMTTFURDGuJnqU/+X//fhhPRq4V/OxgisKFKlBcAS2hsECvg6HDVSz4Fl
74fk/y+botG4/CjMLdKPB9fgh5zz72i3q0hWDixt50NKBv8IIVWOyYgZxDU/vcks
lMEnqbFgJX+CfdALpvAM4WjuQP0UMcKNE3xd+EdDhD1xjK3Tq4XfWob9q6aBZgL2
B4IaADCIeDDE1hv0agnSJmMJE7Bti8tNxCCxVRbZtOaxVHXdRUoOx2XTaxFXupxV
hbpHRrdFrwq51f6e3bkfkNEZ3fzYpnlbynJ2zL++JO8P3Pq/S6UKEFjEB50i8YgK
WuFvGUsQ+YiDgiZU4saqxSBWbfYn3lY6MSSTg8RnXbFIMG3CFImqYk1uhaV+bDjc
p0htjzM2F98g7c3o7sWx0bGarId4uhOmpj7JJVQ+lu7Jby6Ocj8n//7qF1Nn11Cw
QlCVaeAq5Y5DmZrnww9I3zzOWWyqFkAVCM3GqeRLMvplD6/+O+5FF7XoHzQB47nk
OyZtawy/9gssPWZKLv4qHLYS0wGGCiNbCsYy90s3pfeafM0kSxxjIvEz21KT6LJI
/awu2ErQFWCkDMFJ1p/97MjPrQ/6d4cPO140V/wyfuWaBiTVqa9mgnb2zn6fYfDH
JEvl1UzIx3JCae25tty1+qtnS0i0LlN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbkB0
b2xlcmFudG5ldHdvcmtzLmNvbT6JAj0EEwEIACcFAlo9UVoCGwMFCQmUJgAFCwkI
BwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+o7HBAAxHAdFkBGZ9gJK8w7
NUYS9C6enGYtAYoKH5G3Bn3YScjErNfQtHYb53KwBQpVSOv1HcN8hbQ8mLTgn9lt
zNwNSuv0XxIswi807HRSIZ4vYDiS5VKV1YkLYK5bLY5O4alVdzqM+AZQqkuHBu63
6n+C0ED6UwLhVBFfSNvBQVAdoq6gvr+IE8rCIKTMNGwNcgVPbF+YxP7UZM6p7s2a
5MIqGw7URSfaqfuztibXGOBLFbSwLGqHSSnOXBfEeDrwdZ+ur8cXIIPRIeCTVmeO
8bGgpgBqNQXG9oyGN+TrYAC+4Ahi0UjCk7QGj8tf3xICKoQpYyfceNBZJ/969gV9
tVgvRxUjxUwc9kZbi0c8XYMTq5GCvBIh1D6BOW9QBM2SsNgG3l36+e3+c2LDdyKn
20C1IzGLVDdcCtz42/onQ/e9sMlzFrfLjs5SO2/TnLvp2JtsIQXyb/T5qd0GE5j8
/iwfZR+uVTVVEsUl1a+Yllzt6sdR7RIhhKpKaKzEAk4d0+VHdz7zEkQRRSjbPVoS
fy8c/kld9Fi8Buna+ZkKpcwIW+D4XP83pGcl0XUv6AyqwS1LnEt+jv/+PSXskYtU
Lzn8Z35iKkSAH/5Nz6GCZk6ORPNv/6+UI92BpUbu/G2tBwK8bPgAg+gJxBx3G7MK
W7VRCmM5UrtAK9A3O70VjPyMkHSJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLC
LAf/X/9vRTZWtwSXxiBCA54a6hg9IvW0mvPUqgXfvrhtOk0IFucLKrTXK8J/NcmU
6ulxOovVbQ+Bin6gtHeCmSa/W523g/NXCOuFTnS/MyVibNL4+RCFwqGysl++Cm+L
nj1MmasE9kO+CNdervx8APfxV7D6OYrG4eGag+LdFR6VpJn6tRT0/WvyT8l+Oqiq
gdhXHv+0MvkkD9TX5LlJW4VB/yRvWkkmL5N5c5zYh+NcfTPhQ5S9dOorVzrm65d6
Itn0937Ennau7s7fiFdA0BHjWqEAFLsBIXQfCFjjKjdsKA4xlSiX7X7ElmPYpWa5
wwTQ66dL0anMd9y1DJCMOHe4gYkCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9
g1MSBQJbtyScAAoJEBDvedn9g1MSY7sP+gKR0rFU1g+GtB+hSdtwPRbacvml2eL2
Jc5Eq37J9hAqxHyt5V0If7s8IyVA2GXgdfwULBWbXGDUDiUkh20OPQRUS8G9Sf8A
WRuG25q5C8ZzWygykL88RKXJZDFtA49CeqO5Bq5syBhq4QfiSTffQHIp3h0boPGU
hSBEUQpooMXYQClNARQ+z/uRzR5bUi9wxdXNnxTn9ia4ASlaBPvUYTGY1jW2HrRR
SwpI12+UaWsvc3jJtQ8X0kxgJ7jsFF1uqquIZ5eflQv+PHHg2RJSy37u0UFGb+OK
ZEkzlmbPokKCYhzBR5PcD6sgdlaJNcidmto9u1oV6yZT8J2W4CTuUclgxt6f3lZq
ZeVLnNnbHyKUdeypwLlqYISulfnMhZ3A6Bgpf2BtjL6KJbFtPBYmYdxI+HZyY49u
U2ZHhRu+CSQ1y7zGKSX0gRp5hE7+A4XJtsT6lTLhbi9aiZTG1S6zKNhl3qNNzszc
r27PrvFiyGhpuYQuzdQl2PMGbOI6Ojif3sab53NO3RLsLOM09wIlr95yKLlkXkUr
WcvUJGrw6HKm8j5opXHTwmJOAbDpc6cMDu+ITRu4spdCnQJcE8RkO8tKyaLuh2Gt
U5kYSBK97yr5VviX1FK6rY14LLmnE16OPiK2tiVBKy9nGM0DKtY+K9WcoRZ7s/d7
O0bMfzcNPtGLuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiez
GPuBHmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9Wf
pHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC
6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2
D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFe
A7PbTuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ
/Vf3vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbpt
PEcmoazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKr
em5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96
Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYgh
x8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQ
oqj1gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P
/1tF6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8
Wpfdn3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJ
gx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5
SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2
oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtA
ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIA
ypqYo3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoM
eDQkd0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS
/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZ
IMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XO
KVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST
=3DJ121
-----END PGP PUBLIC KEY BLOCK-----

--------------DDC9D062B76DC74A31E32E4E--

--sIzI5nc2QVCzBFjAhGHgabEhyymGBYVF0--

--r7Mw1MRX3YVBoygIw7BWx0nbFjrBiaP2h
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlxh+fQACgkQWrL68XsX
K+rY6Q/+IvwRCrQweuK0uBxaM5LueQ4U9lcGU8I12wMY7eyJfymhTCVYCPOgbrYR
IAYmCFbCWITkD67HSU/wxmAy0BExGwneVQrijhind1eJeYjpBp4pvVyjFRangerc
Hi0wPognl86oO9XHJsoj9a8m/1Yc9i94VNx6sKKOubuy19F55z2eGtmU1Z3maThi
BpR0jv3odKzc3yrP4QCffU36rsj/TinwCvsLaXxIRIj4hCdgDuzPytnItFcalZjU
5+OiYa6RTA0OIIMxlkx9xr/QrwusUn9Qz1XzQBQ7JxHrcTiWcCQI74eLPrtTBFoc
0sDoLRODWM1+15Z4Ry/cG9t//mtRf5CDG+U2Ecf2GXX/5lDjglL/IUmZNaMTWFRy
zMPV6RoMxAWlorUr9Sq2MFz5m6mLIfbJYQXBrycJNcHLlcLy/dkr25CMOnS0QpFJ
J7mC7NZdeE8GFd3W6cobwmNVhBlKHWd8QfPRASIigXwWHKhdznjrRtvhn0uajDaV
IqJKRWayao27xOJP1phcYiQU3UpND3AotR1DoQdgsOxLa/N620373v613JJrh1NT
ygZ2wr8Is82ESZgkgCIARhpuD1r27+E/5pzL9+/w0+pTdp1ty6yjNdtwk5r0j6QW
Y/stW0KTsP2MWzuKArm0+kXN1x9nPh65HHf+cY1bQZlWlUJBMuo=
=7nGd
-----END PGP SIGNATURE-----

--r7Mw1MRX3YVBoygIw7BWx0nbFjrBiaP2h--


From nobody Mon Feb 18 12:43:28 2019
Return-Path: 
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 CE830130FFF for ; Mon, 18 Feb 2019 12:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 TOWVFK6cpt2h for ; Mon, 18 Feb 2019 12:43:25 -0800 (PST)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9A3130FF4 for ; Mon, 18 Feb 2019 12:43:24 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id BDA149C19A; Mon, 18 Feb 2019 15:43:22 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23659.6378.752275.829496@gro.dd.org>
Date: Mon, 18 Feb 2019 15:43:22 -0500
From: Dave Lawrence 
To: doh@ietf.org
Archived-At: 
Subject: [Doh] Adopted: draft-hoffman-resolver-associated-doh
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Feb 2019 20:43:27 -0000

The Call for Adoption of draft-hoffman-resolver-associated-doh is
complete, and being as there were no strong objections to taking it
on as a doh working group item, it is adopted.

It has been observed that there is some relevance to DNS-over-TLS
discovery as well, and thus a question as to whether this work is
more suited to the dprive working group.  Our evaluation is that
while there is some compatible work, the bulk of the complexity is
specific to DoH and will best be handled in this group.  dprive will
be duly informed so that people interested in the issue can follow
it here.

Paul will soon republish the draft suitably named as a working group
document, and we anticipate heading to Last Call by 1 July 2019.


From nobody Mon Feb 18 22:05:29 2019
Return-Path: 
X-Original-To: doh@ietf.org
Delivered-To: doh@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 520D9130E7B; Mon, 18 Feb 2019 22:05:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: doh@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: doh@ietf.org
Message-ID: <155055632730.25962.7915853693250299967@ietfa.amsl.com>
Date: Mon, 18 Feb 2019 22:05:27 -0800
Archived-At: 
Subject: [Doh] I-D Action: draft-ietf-doh-resolver-associated-doh-00.txt
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2019 06:05:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Over HTTPS WG of the IETF.

        Title           : Associating a DoH Server with a Resolver
        Author          : Paul Hoffman
	Filename        : draft-ietf-doh-resolver-associated-doh-00.txt
	Pages           : 10
	Date            : 2019-02-18

Abstract:
   Browsers and web applications may want to know if there are one or
   more DoH servers associated with the DNS recursive resolver that the
   operating system is already using.  This would allow them to get DNS
   responses from a resolver that the user (or, more likely, the user's
   network administrator) has already chosen.  This document describes
   two protocols for a resolver to tell a client what its associated DoH
   servers are.  It also describes a protocol for a client to find out
   the address of the resolver it is using, if it cannot find that
   address by an operating system API or some other means.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-doh-resolver-associated-doh/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-00
https://datatracker.ietf.org/doc/html/draft-ietf-doh-resolver-associated-doh-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Feb 19 07:03:03 2019
Return-Path: 
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 D1C6012F19D for ; Tue, 19 Feb 2019 07:03:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 xr3zbD6l7obv for ; Tue, 19 Feb 2019 07:02:55 -0800 (PST)
Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E0B12870E for ; Tue, 19 Feb 2019 07:02:55 -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; Tue, 19 Feb 2019 07:02:47 -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; Tue, 19 Feb 2019 07:02:47 -0800
From: Paul Hoffman 
To: DoH WG 
Thread-Topic: [Ext] [Doh] I-D Action: draft-ietf-doh-resolver-associated-doh-00.txt
Thread-Index: AQHUyBkgDj8fxp34yUuJsPBo7e2+PqXnvkOA
Date: Tue, 19 Feb 2019 15:02:47 +0000
Message-ID: <9467326F-84D6-4A05-85BA-C3C3BBF4BE5A@icann.org>
References: <155055632730.25962.7915853693250299967@ietfa.amsl.com>
In-Reply-To: <155055632730.25962.7915853693250299967@ietfa.amsl.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="us-ascii"
Content-ID: <8FE0A2E301B4494D8ECE3FB0217F4E3A@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-resolver-associated-doh-00.txt
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Feb 2019 15:03:02 -0000

The GitHub repo for the draft is at
   https://github.com/dohwg/draft-ietf-doh-resolver-associated-doh
Given that this is not a complicated draft, but it has lots of parts, I pro=
pose that we use the GitHub issue tracker just to note issues, not discuss =
them: discussions happen here on the list. Pull Requests are accepted (and =
encouraged for editorial nits), but will be held until before new drafts ap=
pear.

--Paul Hoffman=


From nobody Mon Feb 25 10:36:24 2019
Return-Path: 
X-Original-To: doh@ietf.org
Delivered-To: doh@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDAB130F33 for ; Mon, 25 Feb 2019 10:36:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.92.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155111978171.10711.7819117795743865651.idtracker@ietfa.amsl.com>
Date: Mon, 25 Feb 2019 10:36:21 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [Doh] Milestones changed for doh WG
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
List-Id: DNS Over HTTPS 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Feb 2019 18:36:22 -0000

Changed milestone "Resolver Associated DoH Last Call", set state to active
from review, accepting new milestone.

Changed milestone "Submit Resolver Associated DoH to the IESG", set state to
active from review, accepting new milestone, added
draft-ietf-doh-resolver-associated-doh to milestone.

URL: https://datatracker.ietf.org/wg/doh/about/