Re: [Add] Mozilla's DoH resolver policy

Peter Saint-Andre <stpeter@mozilla.com> Fri, 12 April 2019 17:14 UTC

Return-Path: <stpeter@mozilla.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDBA1202EF for <add@ietfa.amsl.com>; Fri, 12 Apr 2019 10:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_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=mozilla.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 rKoTgtwdZaKk for <add@ietfa.amsl.com>; Fri, 12 Apr 2019 10:14:03 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 DC6F71202EC for <add@ietf.org>; Fri, 12 Apr 2019 10:14:02 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id v10so9097366iom.8 for <add@ietf.org>; Fri, 12 Apr 2019 10:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/k9leyWcq8CnSfzwcZji4+9iX0W4Tx4968tXJrdzhIQ=; b=LjUH051vTzm8cLnOSV9HoAPHcj0tPrM8Wgv3r4Jx47fd8jzqnnBm24W+VB/xcwxEKe rJw3xBxeYYBxz6ryjyE7pbga4xriNLCiVii6owFUGE4a9XZkpZMitdanv3u6hbzhfy2u ebEZXV3U8o6y0Cu93BgsqQRKD1DIyXxqnpohw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/k9leyWcq8CnSfzwcZji4+9iX0W4Tx4968tXJrdzhIQ=; b=n4M6njKDRSctx9HNVWZ9olh6Zai4nsfP31bPIW0V2eYlxu8MFoq+vmUHf/68WYT84w z5/sWNBe1Bju/HSTsjXcZuHdSo9yTR/IcTfhmXmanGQP5gx90EzGUj3hIgM/SEZVdA78 jT7ZNCBxXa4TWpReqTgCb296hsMDvTiaRYFTteLp7A8QqZsqHcrN90mWdgDaEDiHY/85 H0sarOBajbzPa13aaCK6VjjaeRYojmLt+MvNeeEs71OzvArns+JL+N9kcIQ9k6HMydga s1/DQljNlBV57rlhdaEjkbg1QerlAfn7lqf5X5rZ+goPyjnyJcj4PqIa2TeleZkpwOE/ HcVg==
X-Gm-Message-State: APjAAAViQca6i9ezQdkd6DSnvBQGBj/Vyk9IcEEcrBxKh8EHli8cFlJ/ 8Tl5UnwNJez2xaIW7xpghijp99xIQRs=
X-Google-Smtp-Source: APXvYqz8mLCWcQcFako/qEIcsuM8sRs1Rbe+jvg7kQxsN62RjPFdhe4IqUvLDQNVquwP8+uDzhYYpg==
X-Received: by 2002:a5d:8543:: with SMTP id b3mr33459542ios.234.1555089242120; Fri, 12 Apr 2019 10:14:02 -0700 (PDT)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k22sm16007392iog.10.2019.04.12.10.14.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 10:14:01 -0700 (PDT)
To: Wes Hardaker <wjhns1@hardakers.net>
Cc: add@ietf.org
References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <b64761dc-dfab-e4e1-4bfb-82d607efa590@riseup.net> <alpine.LRH.2.21.1904101324530.9940@bofh.nohats.ca> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <af5f5c76-0095-65a0-39d1-d29d4bb0e906@mozilla.com> <ybl36mn8b54.fsf@w7.hardakers.net>
From: Peter Saint-Andre <stpeter@mozilla.com>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V
Message-ID: <f9d0cd98-db0c-7f42-d351-d9a5002c4765@mozilla.com>
Date: Fri, 12 Apr 2019 11:14:00 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <ybl36mn8b54.fsf@w7.hardakers.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/XFlZelYqkophiyO_Jxq53cSuJiI>
Subject: Re: [Add] Mozilla's DoH resolver policy
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2019 17:14:05 -0000

Hi Wes,

On 4/12/19 10:02 AM, Wes Hardaker wrote:
> Peter Saint-Andre <stpeter@mozilla.com> writes:
> 
>> We (Mozilla) do not want to encourage centralization, which is why we
>> have published criteria for becoming a trusted recursive resolver within
>> Firefox.
> 
> There are problem with this:

There are always problems. :-)

> 1) Regardless of how many items you have listed, most of your users will
> take the default. 

We are well (perhaps painfully) aware of this.

> Have you considered randomly selecting defaults for
> each user?  If they all pass your policy test, then this should be
> acceptable?

We have considered this, as Ekr noted in his message on March 27th:

https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZiU91v6hLw

> 2) Regardless of how many items you have listed, and which one a
> particular user may select, you're still providing centralization from
> their point of view.  It doesn't matter how many in the list there are
> if all a given users queries still arrive at the same place.  That's
> still centralization. 

Personally I don't know that most users have a "point of view" regarding
centralization. Definitions might vary, but in my experience many people
think centralization occurs when a given kind of service is provided by
only one or a few entities. If we can build an ecosystem wherein there
are dozens of DoH providers, is that centralization?

> Have you considered randomly rotating all queries
> through every item in the list, 

We've considered random rotation but "there are problems with this".

> or turning the list into a series of
> checkboxes instead of a single-choice radio dialog 

There are non-trivial UX challenges and we're studying how to present
the right options to users.

> to avoid centralizing
> my privacy (which suddenly becomes less private)?

The point of defining criteria and policies (with contractual
obligations in place) is to protect user privacy in comparison to the
current state of the world. It's not clear to me why you believe that
your definition of centralization results in degradation of user
privacy, but perhaps you could explain that more fully.

Peter