From nobody Mon Apr 8 11:24:40 2019 Return-Path: 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 8D9881201E6; Mon, 8 Apr 2019 11:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 fYItcDuzXSCS; Mon, 8 Apr 2019 11:20:02 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 E6A541200A1; Mon, 8 Apr 2019 11:19:58 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id p16so11923625iod.2; Mon, 08 Apr 2019 11:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=n7PXX5w8k50J/E8Pymhjie+q5xHUwUi7o5Ex45cxw58=; b=BiyFo23NO9Dnmmsg4dBn2cmhO9sFirx6Kpz1zkiJisNw+lE/ykaCMNengypS2/XTrE 7nuDzeyb26xTBjOQVCpAQkf8TSgFUykl7V/1l1AibriNisZfhUv90WKCuc4qq1r5Iqsp qMW62UsJ3z+/ZN7OY280z1u/uLuHJXeGpAzUyIMo9a6qgRU4tF8p0fKe9ijbYbJRtNiP hJ71MQWYH5sp/OphVxzZG1zy/R9HdevCEJhozZkCH1vuagKTh1TQDmbFRD+OtYQbF9YN BEfo3rITHQNVReS2mRkF+vSZkBwUvC3eQ65UdulG0NQjuc53ZNaf9A38aeXg59fcK+sr 8jCg== X-Gm-Message-State: APjAAAVsr60j1gkwludIx25Kg13W+nf/zyCI3maXzABNKxdVDB+myu6U 4GpSfL/IMtEkd1rKpjkHu4PSA7/Cpi8ubGkd4K9tUyL1 X-Google-Smtp-Source: APXvYqzLCsCMpNEHvs2ms85uQwuwOzMBrIWAiF0cWSF37DwMRBCCTpej8qUb01wCvGmUjY5Vz0n+/lDCHAnvjG9hPQc= X-Received: by 2002:a6b:7417:: with SMTP id s23mr21147710iog.2.1554747597606; Mon, 08 Apr 2019 11:19:57 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Mon, 8 Apr 2019 14:19:46 -0400 Message-ID: To: doh@ietf.org, dprive@ietf.org, dnsop@ietf.org, add@ietf.org Cc: doh-chairs@ietf.org, dprive-chairs@ietf.org, dnsop-chairs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 08 Apr 2019 11:24:39 -0700 Subject: [Add] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 18:20:04 -0000 A mailing list has been created for the ongoing discussion of issues with DNS over HTTPS, DNS over TLS, implementation choices for those, application usage, operational concerns, privacy concerns, performance concerns, and any other such. Please take all that related discussion to the new list and please stop discussing it on DOH, DPRIVE, DNSOP, and any other lists =E2=80=94 that will keep the related discussion in one place, and avoid fragmenting it and having people repeat themselves because of the fragmentation. The new list is called ADD =E2=80=94 Applications Doing DNS: https://www.ietf.org/mailman/listinfo/add ...and it's in the "to" list of this message. Subscriptions are now open. With this message I=E2=80=99m asking the working group chairs for DOH, DPRI= VE, and DNSOP to be strict about stopping discussion of these topics on their lists, and directing people to the new =E2=80=9CADD=E2=80=9D list. Of course, work directly relevant to the charters of these working groups should continue on their respective lists, as usual. For the longer term, the relevant ADs are discussing the right path. At the moment that looks like a BoF in Montreal (IETF 105) aimed at forming an =E2=80=9CADD=E2=80=9D working group, most likely in the ART Area= but with significant crossover expected and desired from Ops, Sec, Int, and probably the rest of the solar system IETF community. Barry Leiba, ART AD From nobody Mon Apr 8 15:43:31 2019 Return-Path: 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 F0EC312036B for ; Mon, 8 Apr 2019 15:43:29 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 g5BhJxESRFTR for ; Mon, 8 Apr 2019 15:43:28 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 D5C111201DC for ; Mon, 8 Apr 2019 15:43:24 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id k2so17587556qtm.1 for ; Mon, 08 Apr 2019 15:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BD/4UXKUI5omWn2SAqo3sobXgzQqCMCtmUj+tc4WIr4=; b=iu9L70y5Ygb8QygavbFZhNeJCLiVSakPe7KNDIyblmjEVaIQxqxpGxGhpuNZunUbWb 5DaJ4jdaQXMb3P19nWgJqK/rYgLgVrcPaDxRJYJ3gRwfkdFNcrX9hoEvmdjxj3WyjzWD DyLFE2P+KPt5c+frfe+sxwkDsjJZXVxutK7D2sK4H3sjZzXmWKHrLREuHYPvEP1rng5D iVddVn+GVsCfq4CD8zunnocOFx6WxdaX0rSddiqZYa0rSGR+4PC6K0qb4+ukQN2rRJcf pKfy7Sh488KieeyMYQKnqsGWzAjF2vmVX3uI9Vg40zc6rejH4dJWPY478SoS6ugqBZlw lLkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BD/4UXKUI5omWn2SAqo3sobXgzQqCMCtmUj+tc4WIr4=; b=dWgB/I2KVCr0ibyslXbTF0hrGkreKxsjqOjd6oaEdwOASN9Ds/OqXfsKqcIE1fxEOz CZG+Fz6zaOOBNiyOH7AIv4zn+/3gfCCHJICuhswZHs8xK/r9WHCHqpdqIAFPwoNJD2lB oeuVes5F0u+4LvrB0NF7TjX/ArqHL8SbnFvNZF7Sso0DF+/qB117MGH338Iu2bVWpJbV johAAFD5oJy8F6FPhkue7gzY1d02VCfYCNuYiSSqVAUM1++JwqolWRXMJPu8d3Z7bNjS wNlcgQuxgVsmiTp99g+pScUvP/cRsyf6sKYdZWDmFMRHYNnsM21WwX/BHutg2r9gIeQ2 T7eg== X-Gm-Message-State: APjAAAWqDkVvZn9Wan3VdiPrRsKsViMXVFlNla8MmNTReVtmaUf/NR7B keJ2sJVuXs2fjw13GfwBwUz5HTv/acYf7rjd/PLJT2Foi/Q= X-Google-Smtp-Source: APXvYqyyol0UhJgrC7cOmC4Ejt1GBYxBXsD7UwP6WgpOpteT4kseoTwEEcIcGRVd5nzu1tvkr3h+uGkl46Ou+eUspDY= X-Received: by 2002:a0c:ad15:: with SMTP id u21mr27051164qvc.37.1554763403527; Mon, 08 Apr 2019 15:43:23 -0700 (PDT) MIME-Version: 1.0 From: Brian Dickson Date: Mon, 8 Apr 2019 15:43:12 -0700 Message-ID: To: add@ietf.org Content-Type: multipart/alternative; boundary="000000000000608dd905860c9025" Archived-At: Subject: [Add] Applications Doing DNS... X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 22:43:30 -0000 --000000000000608dd905860c9025 Content-Type: text/plain; charset="UTF-8" Greetings, everyone. So, here are my thoughts on "Applications Doing DNS". First, the mailing list ("add") is a fantastic idea. Second, the subject matter, "applications doing DNS", is a not such a great idea, IMHO, at least as far as each application doing its own DNS. As I see it, there are several things that are largely orthogonal: - Transport used for carrying DNS queries (UDP 53, TCP 53, DoT, DoH, DoX, etc.) - Choice of resolver - Place(s) where resolver choice(s) are (or can be) implemented and configured. - Standardization of the cross-transport and cross-application elements (where the common denominator is, obviously, DNS). The privacy issues involved can be addressed by the transport(s). However, there is nothing in the protocols for those transports that mandates the integration of those transports into the respective applications, and that is where a frank conversation should probably happen, and that conversation should be on this list. There are two or more security issues that sometimes get mixed together, to the detriment of the conversation. One is host security. The other is network security (for some value of "network"). One observation is that as a general rule, on most hosts, the very existence of a stub resolver of some flavor (or possibly a recursive or forwarder) is required if it is a general purpose host. Along with that is that historically, managing that component has been done independently from any applications using that resolver. The next observation is that separating the management of applications from resolver provides a degree of benefit from the security model, akin to separation of duties, or role based access, in the way the respective components are managed. (Hosts without proper role based user/admin separation would be the exception that proves the wisdom of doing so.) Here's my suggestion/proposal: Please, let us give some consideration to maintaining that separation, even as the transport and/or resolver choices get augmented and/or changed. The benefits from improved privacy would be improved, at little to no cost to the initial application whose requirement for privacy has motivated transport improvements. The two additional benefits are providing more control and security over any needed configuration to support the new and improved transport, and the avoidance of fragmenting or balkanizing the set of resolvers and configurations, as more and more applications see the value in such privacy improvements. I see the value in a separate discussion on those orthogonal issues, such as transport choice and its impact on network security. Let us please keep those issues out of this discussion. Again, the reasons I'm suggesting this is (longer list than all of the above): - Maintaining the status quo on host security (keeping DNS resolver software and configuration separate from applications) - Making the resolver management scale (one resolver rather than many) - Limit the potential attack surface on hosts - Potential for exposing more DNS results through common API (e.g. getdns) regardless of the transport used - Potential for better integrated resolver/transport (single drop-in replacement for whatever is used currently on a host, which would facilitate any/all transports that are developed) Sincerely, Brian Dickson --000000000000608dd905860c9025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings, everyone.

So, here are my th= oughts on "Applications Doing DNS".

First, the= mailing list ("add") is a fantastic idea.

Second, the subject matter, "applications doing DNS", is a not= such a great idea, IMHO, at least as far as each application doing its own= DNS.

As I see it, there are several things that a= re largely orthogonal:
  • Transport used for carrying DNS qu= eries (UDP 53, TCP 53, DoT, DoH, DoX, etc.)
  • Choice of resolver
    • =
  • Place(s) where resolver choice(s) are (or can be) implemented and confi= gured.
  • Standardization of the cross-transport and cross-application= elements (where the common denominator is, obviously, DNS).
= The privacy issues involved can be addressed by the transport(s).

However, there is nothing in the protocols for those = transports that mandates the integration of those transports into the respe= ctive applications, and that is where a frank conversation should probably = happen, and that conversation should be on this list.

<= div>There are two or more security issues that sometimes get mixed together= , to the detriment of the conversation. One is host security. The other is = network security (for some value of "network").

One observation is that as a general rule, on most hosts, the very = existence of a stub resolver of some flavor (or possibly a recursive or for= warder) is required if it is a general purpose host. Along with that is tha= t historically, managing that component has been done independently from an= y applications using that resolver.

The next obser= vation is that separating the management of applications from resolver prov= ides a degree of benefit from the security model, akin to separation of dut= ies, or role based access, in the way the respective components are managed= . (Hosts without proper role based user/admin separation would be the excep= tion that proves the wisdom of doing so.)

Here'= ;s my suggestion/proposal:
Please, let us give some consideration= to maintaining that separation, even as the transport and/or resolver choi= ces get augmented and/or changed.

The benefits fro= m improved privacy would be improved, at little to no cost to the initial a= pplication whose requirement for privacy has motivated transport improvemen= ts.
The two additional benefits are providing more control and se= curity over any needed configuration to support the new and improved transp= ort, and the avoidance of fragmenting or balkanizing the set of resolvers a= nd configurations, as more and more applications see the value in such priv= acy improvements.

I see the value in a separate di= scussion on those orthogonal issues, such as transport choice and its impac= t on network security. Let us please keep those issues out of this discussi= on.

Again, the reasons I'm suggesting this is = (longer list than all of the above):
  • Maintaining the stat= us quo on host security (keeping DNS resolver software and configuration se= parate from applications)
  • Making the resolver management scale (one= resolver rather than many)
  • Limit the potential attack surface on h= osts
  • Potential for exposing more DNS results through common API (e.= g. getdns) regardless of the transport used
  • Potential for better in= tegrated resolver/transport (single drop-in replacement for whatever is use= d currently on a host, which would facilitate any/all transports that are d= eveloped)
Sincerely,
Brian Dickson
--000000000000608dd905860c9025-- From nobody Mon Apr 8 16:00:59 2019 Return-Path: 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 812C4120121 for ; Mon, 8 Apr 2019 16:00:57 -0700 (PDT) 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 23rnVfvcEF0l for ; Mon, 8 Apr 2019 16:00:55 -0700 (PDT) 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 C8BD01200C7 for ; Mon, 8 Apr 2019 16:00:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8BBC5BE2C; Tue, 9 Apr 2019 00:00:52 +0100 (IST) 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 ZHxugex8XAtJ; Tue, 9 Apr 2019 00:00:51 +0100 (IST) 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 C3657BE20; Tue, 9 Apr 2019 00:00:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554764450; bh=waqV/BBCWDltIVr3Sr6k8LdnLF0t49EmaW8w/fjXt0A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=xSxtQWMu/qwX1tgBHBnvan1CjW7YsJnmJyyB1nOjsD3BnjrHbz45UL4kxe7h6zrJC Q6WYZIVz/7gFNmQvdoh/K2rF0Kma7oboUJZ1UrFxySh20N7PMoHOlAtbO2u9yy4w55 8D3NRGuwBzdhRe+kSWo41hns6hLhKtJJJkckjllw= To: Brian Dickson , add@ietf.org References: 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: <8b37b3ed-1161-91cb-ef38-0496f8ca7bd6@cs.tcd.ie> Date: Tue, 9 Apr 2019 00:00:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RamO39hQIYeWFHbRLppVg8xyXjmbWyeWe" Archived-At: Subject: Re: [Add] Applications Doing DNS... X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 23:00:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RamO39hQIYeWFHbRLppVg8xyXjmbWyeWe Content-Type: multipart/mixed; boundary="SOOdTpkKlnY4gapYw659i2CoEDqYcxkqn"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson , add@ietf.org Message-ID: <8b37b3ed-1161-91cb-ef38-0496f8ca7bd6@cs.tcd.ie> Subject: Re: [Add] Applications Doing DNS... References: In-Reply-To: --SOOdTpkKlnY4gapYw659i2CoEDqYcxkqn Content-Type: multipart/mixed; boundary="------------BC2D8011F07A2672AE9FA57A" Content-Language: en-GB This is a multi-part message in MIME format. --------------BC2D8011F07A2672AE9FA57A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/04/2019 23:43, Brian Dickson wrote: > Greetings, everyone. >=20 > So, here are my thoughts on "Applications Doing DNS". >=20 > First, the mailing list ("add") is a fantastic idea. >=20 Partly agree with that, disagree with a lot (but not all) of the rest of your mail. *A* mailing list is a good idea, and this one will do. The list name is off-base a bit. I think that the privacy and control issues related to Do53 or DoT or DoH, whether or not the OS' resolver is used, all need to be in scope for any putative WG or else we'll not be analysing the right problems. S. --------------BC2D8011F07A2672AE9FA57A 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------BC2D8011F07A2672AE9FA57A-- --SOOdTpkKlnY4gapYw659i2CoEDqYcxkqn-- --RamO39hQIYeWFHbRLppVg8xyXjmbWyeWe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyr0qIACgkQWrL68XsX K+qQqxAAkaJvBisLejVCbnyhxaa+BKdoywEVCYgIL1CZTZYFNMvpmdMeKgYP0nhW QbLO3WSjVUSGRh90SDCPzUML0XDq80Wc/iOnpUdVbbuzeukA9tmMnO1w2dvDG+fN zHtfG1fnhhHjbJb5Q9bpHbICT9hOI7QiVo+fXcm+bzPDE07D8eyzDN5el1MaVEdp +jN+2jeV7sHppOKlgXO6Grt4u89O5qSDrFUDc/yqFagEjLXQnlyuVC0LS9zJKsjx l0yYqRm/iunEhIZc4SOea5opOE81IFRJdHz04DjS1Grhbt57ekjSNz6aKT2y/TOL YnXQAKX2Kim8dz58TJ7Orpl+FKG04PgNDiaEyFqBhKAuxxfz0plKSUDEOJApMxsP wc/pfGqK409m6ksW63KK2FvxysTFd68PX+sctPpac31kXSj+9ibVPNCXMQTmuUm2 MDYNFxfMDvo+IjphlyxDXycVOeJ3CVTwpFuhDMTvRfpdnl0+L+o/zk2/5/hPFyU8 vPTH7mLG8EEhAKj12YzZTkkcr3TbD1+0yz9spNBhKXgX5w+NxI2vZmfXc5rEQOws B56rnxB2gTGh76mE05d8icl+UWAF8GtQA6E+zqwX+tA6svgb+mIkrd9vLIah77ka kw1Lu19mEZY91WhHCGF78WnqgnmKv2NiHdp95TKOnRLcQzH9WjQ= =wlyx -----END PGP SIGNATURE----- --RamO39hQIYeWFHbRLppVg8xyXjmbWyeWe-- From nobody Tue Apr 9 06:07:33 2019 Return-Path: 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 E07891207F3 for ; Tue, 9 Apr 2019 06:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_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 (2048-bit key) header.d=open-xchange.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 sWR2vmVz3a9O for ; Tue, 9 Apr 2019 06:07:30 -0700 (PDT) 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 CCA401207F2 for ; Tue, 9 Apr 2019 06:07:29 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [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 C5BCD6A255; Tue, 9 Apr 2019 15:07:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554815247; bh=2eH/451r/LM4MoJVoZCC5o/OFomBqYu65qJSrzVbZ/c=; h=Date:From:To:In-Reply-To:References:Subject:From; b=sMF4G+AuMThYErY5e32PqFOv5MC+3abJuT6SGchKSCbbjKStcAi/x5MdfrOQLLAeA Nmz33+4cl7onjooLLqu3lVTGQM12Xa4nsY8Z8AGIvLGwluC10nADmElV3r/kUbUyFF o3IqhAN9OVN2yYVcbmT7ihEE5tfHwvm5wABMZ9cut62UQxTcd+z87WWXvE5H2mP70A DlFSORZEI6tUyzIo0iaX4CBtAHOD6bxRCTfXtEbXlbX2cyfMbWjqscvSDY13XBbKiX bWHFwm/2lODgaii3fZdgKJ3HOFPHq4OzNpQjbq6h6QRFWXKSXJw8PJAmqdW9jUc5AA 3WhHlJt65ukwg== 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 B98DF3C020F; Tue, 9 Apr 2019 15:07:27 +0200 (CEST) Date: Tue, 9 Apr 2019 15:07:27 +0200 (CEST) From: Vittorio Bertola To: Stephen Farrell , add@ietf.org Message-ID: <1264936982.14595.1554815247698@appsuite.open-xchange.com> In-Reply-To: <8b37b3ed-1161-91cb-ef38-0496f8ca7bd6@cs.tcd.ie> References: <8b37b3ed-1161-91cb-ef38-0496f8ca7bd6@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14594_114860551.1554815247692" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Add] Applications Doing DNS... X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 13:07:32 -0000 ------=_Part_14594_114860551.1554815247692 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 9 aprile 2019 alle 1.00 Stephen Farrell < stephen.farrell@cs.tcd.ie mailto:stephen.farrell@cs.tcd.ie > ha scritto: > > The list name is off-base a bit. I think that the privacy > and control issues related to Do53 or DoT or DoH, whether > or not the OS' resolver is used, all need to be in scope > for any putative WG or else we'll not be analysing the > right problems. > Speaking of a broader discussion, I am increasingly convinced that we have a basic problem of lack of clarity, or even of consensus, on what the requirements for "modern" DNS service are. The DNS was conceived as a public distributed database that would always give back the same reply to the same query, that would only serve universal names, that would be provided locally as an integral part of the Internet access service, and that had no need for customized replies, for privacy protection or for control points of any kind. This has changed over time, in a stretch of almost 30 years, and now the DNS looks more like a directory service that orchestrates traffic across the Internet as well as on private networks, and customizes the directions it gives according to a broad set of factors. This was done by piling new specs and new practices over and over onto the original basic idea, and so, IMHO, it is also the root of the "camel" problem that was so successfully exposed by Bert Hubert at IETF 101. Now, attempting to rethink the requirements for the DNS from scratch could be futile, but any system coming out of the present discussions would be much better if it were the result of systematic planning, rather than of one patch after another, fixing one problem while creating others (and DoH is just the last instance of this). On the other hand, I would be concerned if this discussion became broader in scope and time, while in the meantime DoH gets deployed as per today's plans and "good night to the bucket" (which, translated, is a typically Roman way of saying that time's up and the current status quo will last forever). That would make any effort useless. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_14594_114860551.1554815247692 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 9 aprile 2019 alle 1.00 Stephen Farrell < stephen.farrell@cs.tcd.ie> ha scritto:

The list name is off-base a bit. I think that the privacy
and control issues related to Do53 or DoT or DoH, whether
or not the OS' resolver is used, all need to be in scope
for any putative WG or else we'll not be analysing the
right problems.
Speaking of a broader discussion, I am increasingly convinced that we have a basic problem of lack of clarity, or even of consensus, on what the requirements for "modern" DNS service are.

The DNS was conceived as a public distributed database that would always give back the same reply to the same query, that would only serve universal names, that would be provided locally as an integral part of the Internet access service, and that had no need for customized replies, for privacy protection or for control points of any kind. This has changed over time, in a stretch of almost 30 years, and now the DNS looks more like a directory service that orchestrates traffic across the Internet as well as on private networks, and customizes the directions it gives according to a broad set of factors.

This was done by piling new specs and new practices over and over onto the original basic idea, and so, IMHO, it is also the root of the "camel" problem that was so successfully exposed by Bert Hubert at IETF 101.

Now, attempting to rethink the requirements for the DNS from scratch could be futile, but any system coming out of the present discussions would be much better if it were the result of systematic planning, rather than of one patch after another, fixing one problem while creating others (and DoH is just the last instance of this).

On the other hand, I would be concerned if this discussion became broader in scope and time, while in the meantime DoH gets deployed as per today's plans and "good night to the bucket" (which, translated, is a typically Roman way of saying that time's up and the current status quo will last forever). That would make any effort useless.

Ciao,

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_14594_114860551.1554815247692-- From nobody Tue Apr 9 07:26:34 2019 Return-Path: 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 EF4B6120821 for ; Tue, 9 Apr 2019 07:26:32 -0700 (PDT) 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, 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 (1024-bit key) header.d=hopcount.ca 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 VN6mJcTFICaG for ; Tue, 9 Apr 2019 07:26:30 -0700 (PDT) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 2B8E312081D for ; Tue, 9 Apr 2019 07:26:30 -0700 (PDT) Received: by mail-it1-x12c.google.com with SMTP id u65so5180475itc.2 for ; Tue, 09 Apr 2019 07:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:subject:message-id:date:to; bh=DSrl6IqhHgT/sHrjo3L/LFjqQ5UuvJ+u1cGzwWkgcLw=; b=OWCqu93LY0wpzlcVoWTbUCePL/ZyNdLRr+BsCEbTrF28nNH8RTjjLN6dnpWHKEnXj4 wTaOMi4etS8AArw0DVys/2ajv0ods2ZMgk07jzkAJMxuVJmwKSWvzzcTrp3MWld6rt5L PDbw1VUF2jS00wdz0gQXakoa2CJHSwz3B2Ch8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=DSrl6IqhHgT/sHrjo3L/LFjqQ5UuvJ+u1cGzwWkgcLw=; b=oHDQTSzfbHOAP8qLjOcs+dABlSiXQqVCAphZj6hGM5J/0A3GJPdhUgVIYvK0OJJiGW 9YcyoRplhqP+Tjtk9r/e142KrP03rp42SwxvqvMnF+M68GxkTCFKL25GB4EUUc8WhuF8 LXY70DGIcyBDOQ7KFsYfUqZQzTdEg1tIIEhwLlLFk0vAV626bBI6tf1ZQENotazdssIb A3RvwBhwfZv4ZjMw/u4OZfaDqg6d5V4D51o9L4PRj/kkzDSpYyV5dr+GDx3MBA/AfZYI rqnSdoFCln8vX9hbo2MroP7u5WZ9j8jnKafgfznXtQ7wIqU+I8oPjpMotMijkK2ACwRt mMAQ== X-Gm-Message-State: APjAAAWqacGBJxQ0G4V6Xu4Xb1IQ9pc99FiJGwtJv67uVI8yDSSlEzjs Dp3CDhQOuDQM5ug/jrEjAosQnCzhepKFKaqN X-Google-Smtp-Source: APXvYqxhMSc51Aum1vezR1CR9rsN7ij1FhBRlcAuS465LHYFfzQVwN0CHqjRumtcK9tV3NYV862IkA== X-Received: by 2002:a24:ac56:: with SMTP id m22mr21962342iti.25.1554819988820; Tue, 09 Apr 2019 07:26:28 -0700 (PDT) Received: from anchovy.localdomain (198-84-196-112.cpe.teksavvy.com. [198.84.196.112]) by smtp.gmail.com with ESMTPSA id v134sm6645735ita.16.2019.04.09.07.26.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 07:26:27 -0700 (PDT) From: Joe Abley Content-Type: multipart/signed; boundary="Apple-Mail=_8376792A-79DF-42DE-A190-30EFC7425061"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> Date: Tue, 9 Apr 2019 10:26:22 -0400 To: add@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 14:26:33 -0000 --Apple-Mail=_8376792A-79DF-42DE-A190-30EFC7425061 Content-Type: multipart/alternative; boundary="Apple-Mail=_25311D4B-73B2-4D79-B10D-0802B48633E3" --Apple-Mail=_25311D4B-73B2-4D79-B10D-0802B48633E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, Vittorio and Stephen reminded me of some handwaving I inflicted on = various people in the Hilton bar in Prague. Perhaps now is the time to = widen the circle of injury. Consider an end-user who wants to use some service over the Internet. = I'll suggest we can consider the overall engagement between the end-user = and the service in terms of a number of phases, each of which has some = characteristics that are usefully different from others. My intent is to = see whether we can reduce the scope of the problem from "all resolution = in the world, ever" to something smaller. For example, in the taxonomy below, I think we are mainly arguing about = mechanisms within the initialisation phase. I speculate about different = name resolution protocols being architecturally viable in the following = established phase. -- Initialisation Phase -- The end-user uses an application to begin a session with some service or = other. Unless the addresses of the relevant service endpoints in the = network are hard-coded into the application (in which case stern = frowny-face) this will involve some name resolution. For popular services today that name resolution often involves = enterprise DNS services who generate responses based on a set of = criteria specified by the service provider, e.g. the (city, provider) = pair that the DNS provider guesses corresponds to the end-user, based on = things like the EDNS(0) client-subnet option, the address of the = resolver, etc. This process involves approximations and assumptions. The = QNAMEs are generally generic (e.g. they are bigservice.org = , not user-specific-random-label.bigservice.org = ). The end-user uses a resolver that has been provided as part of the = process of joining the local network, or one that has been = hand-configured by the end-user, or one that is specified by the vendor = of the application. The result of the resolution process is a set of one or more initial = service endpoints, layer-3 addresses. The application stands up one or = more transport layer sessions to those initial service endpoints. Those = transport layer sessions often incorporate some end-point authentication = (e.g. a bundle of TLS sessions with some appropriate certificate = validation process). The control point whereby someone (e.g. a resolver operator, an on-path = network operator) can prevent the application from communicating with = the service by DNS name exists within this phase. The choice of name = resolution mechanism in this phase is hence contentious. The control point whereby an on-path network operator can prevent the = application from communicating with the service by layer-3 address = exists within this phase. This is potentially independent of the choice = of name resolution protocol or transport. There is potential for metadata surveillance during this phase -- the = fact that an application located at one address is attempting to = initialise a service using a particular DNS name. This is a potential = privacy concern. There is potentially a similar risk based on layer-3 = address which is independent of name resolution. -- Established Phase -- The application begins to communicate with the service end-points. Additional name resolution may well occur during this phase since = popular services are distributed, network performance and topology is = dynamic and end-users are mobile. The QNAMEs involved might be = user-specific and designed to trigger cache-misses (e.g. incorporating = pseudo-random 64-character labels), e.g. because there is some = user-specific behaviour that is incorporating the resolution process as = a communications channel, or for reasons of traffic-engineering as = described in the enterprise DNS commentary above, or because it's more = reliable than using low TTLs, or something like that. By the time an application's engagement with a service enters this = phase, the opportunity to block the engagement has passed. The nature of = the name resolution that exists within this phase is therefore = potentially less contentious than in the initialisation phase. The = communications channels between the application and the service endpoint = have been authenticated at this point, and so to some degree the same = trust that the application puts in those channels for other objects = might also apply to name resolution. As a thought experiment, perhaps a particular web service is easier to = manage if all the resolution in the established phase happens inside the = same HTTPS bundle that carries HTML and other objects; performance = measurements executed in javascript in a browser could be shared with = the service provider which could then push user-specific names to = optimise service performance and that process might be architecturally = cleaner and cheaper than using the more circuitous approach necessary = with enterprise DNS services. The control points mentioned in the = initialisation phase are unavailable in this case, but perhaps that's = ok. Even without such sophisticated resolution requirements, making the = service provider directly responsible for the name resolution involved = in using their service eliminates some attack vectors, e.g. the chance = that some required resolution in this established phase might be = hijacked by a third party as part of a phishing attack. -- Termination Phase -- For many web services this seems like it is probably a noop, but it = seems wrong not to include it by way of acknowledging that all good = things must surely end. Joe --Apple-Mail=_25311D4B-73B2-4D79-B10D-0802B48633E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

Vittorio and = Stephen reminded me of some handwaving I inflicted on various people in = the Hilton bar in Prague. Perhaps now is the time to widen the circle of = injury.

Consider= an end-user who wants to use some service over the Internet. I'll = suggest we can consider the overall engagement between the end-user and = the service in terms of a number of phases, each of which has some = characteristics that are usefully different from others. My intent is to = see whether we can reduce the scope of the problem from "all resolution = in the world, ever" to something smaller.

For example, in the taxonomy below, I = think we are mainly arguing about mechanisms within the initialisation = phase. I speculate about different name resolution protocols being = architecturally viable in the following established phase.

-- Initialisation Phase = --

The = end-user uses an application to begin a session with some service or = other. Unless the addresses of the relevant service endpoints in the = network are hard-coded into the application (in which case stern = frowny-face) this will involve some name resolution.

For popular services = today that name resolution often involves enterprise DNS services who = generate responses based on a set of criteria specified by the service = provider, e.g. the (city, provider) pair that the DNS provider guesses = corresponds to the end-user, based on things like the EDNS(0) = client-subnet option, the address of the resolver, etc. This process = involves approximations and assumptions. The QNAMEs are generally = generic (e.g. they are bigservice.org, not user-specific-random-label.bigservice.org).

The end-user uses a = resolver that has been provided as part of the process of joining the = local network, or one that has been hand-configured by the end-user, or = one that is specified by the vendor of the application.

The result of the = resolution process is a set of one or more initial service endpoints, = layer-3 addresses. The application stands up one or more transport layer = sessions to those initial service endpoints. Those transport layer = sessions often incorporate some end-point authentication (e.g. a bundle = of TLS sessions with some appropriate certificate validation = process).

The = control point whereby someone (e.g. a resolver operator, an on-path = network operator) can prevent the application from communicating with = the service by DNS name exists within this phase. The choice of name = resolution mechanism in this phase is hence contentious.

The control point = whereby an on-path network operator can prevent the application from = communicating with the service by layer-3 address exists within this = phase. This is potentially independent of the choice of name resolution = protocol or transport.

There is potential for metadata surveillance during this = phase -- the fact that an application located at one address is = attempting to initialise a service using a particular DNS name. This is = a potential privacy concern. There is potentially a similar risk based = on layer-3 address which is independent of name resolution.

-- Established Phase = --

The = application begins to communicate with the service end-points.

Additional name = resolution may well occur during this phase since popular services are = distributed, network performance and topology is dynamic and end-users = are mobile. The QNAMEs involved might be user-specific and designed to = trigger cache-misses (e.g. incorporating pseudo-random 64-character = labels), e.g. because there is some user-specific behaviour that is = incorporating the resolution process as a communications channel, or for = reasons of traffic-engineering as described in the enterprise DNS = commentary above, or because it's more reliable than using low TTLs, or = something like that.

By the time an application's engagement with a service enters = this phase, the opportunity to block the engagement has passed. The = nature of the name resolution that exists within this phase is therefore = potentially less contentious than in the initialisation phase. The = communications channels between the application and the service endpoint = have been authenticated at this point, and so to some degree the same = trust that the application puts in those channels for other objects = might also apply to name resolution.

As a thought experiment, perhaps a = particular web service is easier to manage if all the resolution in the = established phase happens inside the same HTTPS bundle that carries HTML = and other objects; performance measurements executed in javascript in a = browser could be shared with the service provider which could then push = user-specific names to optimise service performance and that process = might be architecturally cleaner and cheaper than using the more = circuitous approach necessary with enterprise DNS services. The control = points mentioned in the initialisation phase are unavailable in this = case, but perhaps that's ok.

Even without such sophisticated = resolution requirements, making the service provider directly = responsible for the name resolution involved in using their service = eliminates some attack vectors, e.g. the chance that some required = resolution in this established phase might be hijacked by a third party = as part of a phishing attack.

-- Termination Phase --

For many web services = this seems like it is probably a noop, but it seems wrong not to include = it by way of acknowledging that all good things must surely = end.


Joe
= --Apple-Mail=_25311D4B-73B2-4D79-B10D-0802B48633E3-- --Apple-Mail=_8376792A-79DF-42DE-A190-30EFC7425061 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----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXKyrjgAKCRA0jwy9hlI6 LO68AKClBr2YD7OZrsWGgf0JHWmqvCYuIACdE+AZjiFbb5Dp+eumJ2nhGzKWS/4= =aKQr -----END PGP SIGNATURE----- --Apple-Mail=_8376792A-79DF-42DE-A190-30EFC7425061-- From nobody Tue Apr 9 08:04:58 2019 Return-Path: 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 02AAF1202EB for ; Tue, 9 Apr 2019 08:04:57 -0700 (PDT) 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 b6ZZCPQUE2ao for ; Tue, 9 Apr 2019 08:04:54 -0700 (PDT) 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 5E2101202EC for ; Tue, 9 Apr 2019 08:04:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3FFE5BE2E; Tue, 9 Apr 2019 16:04:52 +0100 (IST) 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 PbxV1BlxbxT1; Tue, 9 Apr 2019 16:04:52 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 08BC2BE20; Tue, 9 Apr 2019 16:04:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554822292; bh=3rm4lcmE0spl3qpRwUTQgYToMGUtbq+AWJ9iIjQQCf4=; h=To:References:From:Subject:Date:In-Reply-To:From; b=CckCL7S/QQk4VR26fefz/wZ84GkQgWSossb5MKcIGQEvWLe0GSB1pWsfNrh1NR+R/ OviZl43rKMOapDOyyyeictHBhc9aiokRJH4py+yNaaEluSUPOF8iC709XlfYJGl4Yi 9XJM24dP//IVFt3I2JACcOKzUs8NEs/h6idp9vwI= To: Joe Abley , add@ietf.org References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> 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: Tue, 9 Apr 2019 16:04:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MnBmplSTYJFINrYylUjzLRXImnTU6V2yQ" Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 15:04:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MnBmplSTYJFINrYylUjzLRXImnTU6V2yQ Content-Type: multipart/mixed; boundary="FTZvRIYg9n7jseAGKT8mUlOXh5rjZVBkI"; protected-headers="v1" From: Stephen Farrell To: Joe Abley , add@ietf.org Message-ID: Subject: Re: [Add] lifecycle of an engagement between an application and a service References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> In-Reply-To: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> --FTZvRIYg9n7jseAGKT8mUlOXh5rjZVBkI Content-Type: multipart/mixed; boundary="------------CEDE93DE4750D516C15B4B41" Content-Language: en-GB This is a multi-part message in MIME format. --------------CEDE93DE4750D516C15B4B41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 09/04/2019 15:26, Joe Abley wrote: > Perhaps now is the time to widen the circle of injury. Heh:-) I think starting discussion that way could be useful, thanks. One note on your mail and one possible new "phase" below. (Both of which I think provide arguments one could use regardless of whatever place in this discussion one starts from.) The note: > There is potential for metadata surveillance during > this phase I think it's more than potential:-( But what I wanted to note was that the DNS service could also have already been borked and might send the transport connection to somewhere dangerous. (E.g. in the case of a compromised home router or an unwisely user-selected DNS service provider.) The possible additional phase: There's also maybe an "it's not fecking working" phase, that could be caused by, or avoided by, by a choice of DNS service endpoint. And the DNS server choices in place will impact on whomever an end user might contact whilst in that phase. Maybe "support phase" could be a name for this? Again, I'd emphasise that I reckon the above points provide arguments both for those who like, or dislike, the particular DoH-deployment that's the proximate cause for this discussion. Cheers, S. --------------CEDE93DE4750D516C15B4B41 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------CEDE93DE4750D516C15B4B41-- --FTZvRIYg9n7jseAGKT8mUlOXh5rjZVBkI-- --MnBmplSTYJFINrYylUjzLRXImnTU6V2yQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlystJIACgkQWrL68XsX K+rekg//ajr10fKkKfOeJAJdNAye2ln4qqw945WHbzmYjRS0hQQgyRC44zDMkWR8 LGICiuq8AcOrngGRgTlE/OD4zPVAjrP7VYF4Dkabfz/gqVvuS9O1UTbb/ULSYeQj cN+FQvGTajpVslGrpm+aSDIDjElnvZJ3WBG7/WD4dkxLFWWHY+josNFtX8nSNMkp wJfpZJPSQ9Nij7VKI/Au8ro09DcYmjkfqWKrwN7ilRLxZe/thZ+Voy1u47McaRJe 1KJixQiqFuD0XFSHQ8qlY5yJtjX/C7ZcBpGntCYQf8PuLp3KZOl70jZtV+KZYyBk Q8ehU3vUj9IVAQf7O3skxCWVavoqs8cfxQ9zaH9M6LdAYLWwu/p3ERibzRDiiNJd WCPAAWOESWRzW1flSOC059D19xxdbWcstlxIvGkSmo7NFQCMY7dxAb+/FWtrTYqz nTuOis7e4jiMZRxQUWmc6vq6ayC15n6Siz/SPlgaLUsD2BwXdRmwX0mLhQiH4GEo NpFozdNk5plkeaxpK2iM6/1uyWRIqYpdd0zOPm0hMn5ccngMX5McED+Lwm1L2GCW 3jm8mU4wSgLjKTgBXq0J0SgoMXf5cufrJopMnZYKnO4ouDyXuU3a8YJ4sKQR5A/m JOb2OBYOB5/BLwxUrM2MsN2XVPRJsWqTwGIohUOf6WqcvhhveOQ= =rumT -----END PGP SIGNATURE----- --MnBmplSTYJFINrYylUjzLRXImnTU6V2yQ-- From nobody Tue Apr 9 08:26:33 2019 Return-Path: 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 888DF120868 for ; Tue, 9 Apr 2019 08:26:31 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 gSAFiSrpiSza for ; Tue, 9 Apr 2019 08:26:30 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 F3615120864 for ; Tue, 9 Apr 2019 08:26:29 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id c4so14621364ioh.9 for ; Tue, 09 Apr 2019 08:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=z/go0z8Il51l8gx0kzperwWtngR8xjv7mGygx24Kf84=; b=bN26M7aKN3G6yCpX8jy3qndMhpwWIVOrLGSQi3woRfRNPDpStYRD+tnObRlkmES6qp fUUA1VMBVXbPQ+CgxooQhOGNKp7yx+c1tPrAtHb2g6sg1KqB3iPLfj5UOJ7AXhpAHLFT mBtXq+Ng9uZBwFWe2AW2uJgtWJiOT0oGOzTjU= 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=z/go0z8Il51l8gx0kzperwWtngR8xjv7mGygx24Kf84=; b=C8j7pppuEtLG12G26djmVqsH5/WDElBkvWIiwVknigZS8NH350KnPmrr8zV+VuvGJk JTEh6H1qBmLi0PBKbLMs6dRk1n4YLrkQMGijWqPenM/k3G7spvihpVgPgHu+puDfN5mU POkHbOKIgpTV5iWTsvyrQYvlel3K97HDeBwGHS/xniGz9DW92IXCVHVghTR29WYVmVh8 r7FFLXfk0J0lmCxQtBaHWqbUnokrsBY+x4OVN0haMrdG6NLk4x2LGD9YFbptl5xM3yli Ni+sO+taYgyXO5xcYxmqLhDB6perZQVCwRto6Cpuxpiikaz03tz2mwDjlJOsOAma7sM8 YijA== X-Gm-Message-State: APjAAAWAr/2Zg+OzF1ZLQ/7ELTfQEs8I57XeTYw1gbQfbmHwysFODi3F 2mOArdDS64/atqNrAgVQwDFUqQ== X-Google-Smtp-Source: APXvYqz7W3aE53+sTHe90Z309vjtBCh4hqyAtUYamZpNPRZ2OKxuNfy19PCogdELxWfgQ42siekl6A== X-Received: by 2002:a5e:950f:: with SMTP id r15mr10353976ioj.88.1554823589152; Tue, 09 Apr 2019 08:26:29 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:d051:81:490:288e? ([2607:f2c0:e786:128f:d051:81:490:288e]) by smtp.gmail.com with ESMTPSA id 80sm6790894itk.38.2019.04.09.08.26.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 08:26:27 -0700 (PDT) From: Joe Abley Message-Id: <6EA8E030-B3E1-43DD-AF55-93A5285F342B@hopcount.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_E09C2FD6-C28D-4F36-910F-FC3635A6BB39"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 9 Apr 2019 11:26:26 -0400 In-Reply-To: Cc: add@ietf.org To: Stephen Farrell References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 15:26:32 -0000 --Apple-Mail=_E09C2FD6-C28D-4F36-910F-FC3635A6BB39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Apr 2019, at 11:04, Stephen Farrell = wrote: > The note: >=20 >> There is potential for metadata surveillance during >> this phase >=20 > I think it's more than potential:-( Well, it's is possible that there's somewhere in the world where it's = not happening as a matter of course. You never know. > But what I wanted to note was that the DNS service could > also have already been borked and might send the transport > connection to somewhere dangerous. (E.g. in the case of > a compromised home router or an unwisely user-selected DNS > service provider.) I think that's true. The control point could be welcome intervention ("I am using OpenDNS out = of choice", "I am visiting Paul Vixie's house and the company and the = beer more than make up for the fact that my libertarian views on = end-user freedom are being compromised") or it could be uninvited = meddling (compromised CPE, on-path attack, poisoned upstream cache). I suppose those particular examples of welcome intervention have the = characteristic that if the application detects the control (e.g. DNSSEC = validation failed, in some future utopia of DNSSEC deployment) the = application's recourse is the same as the intended intervention, which = is resolution failure. There might be others that don't line up that = way, though. Uninvited meddling might have the goal of taking you off down a dark = alley so you can be relieved of private data, in which case = identification of the meddling by the application might mitigate, or it = might be to lie you down on the ground and give you a good kicking, by = which colourful aphorism I mean denial of service, in which case DNSSEC = failure is aligned with the undesired outcome. Authentication of the service using means other than DNS (e.g. TLS = certificate validation for services that use TLS) can presumably provide = some mitigation of the case where DNS lies lead the application to = connect somewhere it shouldn't. > The possible additional phase: >=20 > There's also maybe an "it's not fecking working" phase, > that could be caused by, or avoided by, by a choice of > DNS service endpoint. And the DNS server choices in place > will impact on whomever an end user might contact whilst > in that phase. Maybe "support phase" could be a name for > this? This sounds like the selection of a resolver to support the resolution = that happens in the initialisation phase. Conventionally (e.g. on my laptop, as far as I know) this is something = that happens system-wide, either automatically through things like PPP = or DHCP or manually-configured by an end-user or an administrator. There were some examples from the recent shouting when it was = application-specific, though. I think Paul's example was a chromekey (or = something; I don't really watch television) that was hard-coded to use = 8.8.8.8 regardless of user or local network preference. Other pitchforks = were variously levelled at Mozilla for Firefox's = currently-off-by-default use of a dedicated resolver, which is either an = application-specific example or another system-wide one (considering the = browser to be a system that hosts individual applications). I suppose regardless of whether a choice is system-wide or = application-specific it's still a choice that has implications for = control vs. privacy in the initialisation phase. Joe --Apple-Mail=_E09C2FD6-C28D-4F36-910F-FC3635A6BB39 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----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXKy5ogAKCRA0jwy9hlI6 LMZpAJ9g8QMWwzEc2k0Hhrw/fZV1Xk/E9ACcDQEff+CN4Y+8DcF642zseAoegN0= =F2yB -----END PGP SIGNATURE----- --Apple-Mail=_E09C2FD6-C28D-4F36-910F-FC3635A6BB39-- From nobody Tue Apr 9 09:32:47 2019 Return-Path: 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 AC7EA1208D2 for ; Tue, 9 Apr 2019 09:32:39 -0700 (PDT) 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 5u393CtosFgb for ; Tue, 9 Apr 2019 09:32:37 -0700 (PDT) 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 981E71208C5 for ; Tue, 9 Apr 2019 09:32:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70BB5BE2C; Tue, 9 Apr 2019 17:32:33 +0100 (IST) 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 CFqvF0FS9utK; Tue, 9 Apr 2019 17:32:33 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1DE49BE20; Tue, 9 Apr 2019 17:32:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554827553; bh=IPCctEQHUF0EJrHNjGw8/Qw/HuaXLnlxcMPXYJbopUA=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=ZUi5MSWJzkHqEiMlM7nBlf2vzDnn9iE2HYzpe4dhPD8h/1/gsw4xNxiLnIS/YJiEw FwmD76raZMTx4qJ7v3SVslmgVmdCkWWl5T5Kc1p3Rv6X41yBxS8gEsi3nXSs65omhz QcEdPocyzC9+R7IxI6+pjH1y5lCH4AOX09duQIzM= To: Joe Abley Cc: add@ietf.org References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> <6EA8E030-B3E1-43DD-AF55-93A5285F342B@hopcount.ca> 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: Tue, 9 Apr 2019 17:32:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6EA8E030-B3E1-43DD-AF55-93A5285F342B@hopcount.ca> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="byaWcvXO1Xi1go3V6qmOE7AyX135nLZle" Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 16:32:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --byaWcvXO1Xi1go3V6qmOE7AyX135nLZle Content-Type: multipart/mixed; boundary="7VI6c6BfeJYGe0ABdXvmhsE4sUocF25ND"; protected-headers="v1" From: Stephen Farrell To: Joe Abley Cc: add@ietf.org Message-ID: Subject: Re: [Add] lifecycle of an engagement between an application and a service References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> <6EA8E030-B3E1-43DD-AF55-93A5285F342B@hopcount.ca> In-Reply-To: <6EA8E030-B3E1-43DD-AF55-93A5285F342B@hopcount.ca> --7VI6c6BfeJYGe0ABdXvmhsE4sUocF25ND Content-Type: multipart/mixed; boundary="------------5D7DF3604B04EE58C5663276" Content-Language: en-GB This is a multi-part message in MIME format. --------------5D7DF3604B04EE58C5663276 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 09/04/2019 16:26, Joe Abley wrote: >> The possible additional phase: >>=20 >> There's also maybe an "it's not fecking working" phase, that could >> be caused by, or avoided by, by a choice of DNS service endpoint. >> And the DNS server choices in place will impact on whomever an end >> user might contact whilst in that phase. Maybe "support phase" >> could be a name for this? > > This sounds like the selection of a resolver to support the > resolution that happens in the initialisation phase. That wasn't what I tried to describe, so maybe let me try again. If a user thinks they are up and running nicely with some DNS setup (as a result of the "initialisation phase"), then at some later time, that user might try resolve some name that then doesn't work. Some (perhaps short time) later, the user might then contact someone to complain, and that is what might mark the start of the "support phase." One reason that a putative support phase may differ is that whomever the user contacts might or might not have been involved with the actual DNS setup resulting from the initialisation phase. As with all the variables here, that (user complains to wrong place) is something that already happens but in the context of this discussion, it may be that whomever is contacted (be that a web site, browser or ISP) just can't see the same problem because of the DNS setup. On the other side of the coin, it could be that some DNS setups might produce fewer user- visible issues and so less support confusion/cost, and that might be somewhat measurable. Cheers, S. --------------5D7DF3604B04EE58C5663276 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5D7DF3604B04EE58C5663276-- --7VI6c6BfeJYGe0ABdXvmhsE4sUocF25ND-- --byaWcvXO1Xi1go3V6qmOE7AyX135nLZle Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlysySAACgkQWrL68XsX K+q7IBAAh3LhgnPEPsk9SIh0wvgBasi7DJ9MeVWoXpyFE31bvY251mb4ScY4m0Aq lnIRFjPBkswHxaf+ZP8BhCeKNnHCMuC3LPx6OAFh7uHevk/Q7yZMaE7oKLmEEXpK 2tuJghu7DB64MDJBBdgyPVXRiFxXYzYlDYwXkzQZLfWKlmQQ6ZyjMn2esh1hokFX Vyh1UBrem4wv/o9R9J5Siait7eIVYmOXcVs0cjHkEXWQ8RstBZublePW3LMmQXFe AsBZe4dMqm6lNwzUC/yzjMv30bcCpmKOfl6K4gWGHye+w8CT8qESonHNg2AwVAVD Bw7YcGkPIExlQZvx2+bQatTPPHpzkI8r+ZqsiRsoua3PsxHuFKcUZ+bETjajq3yD AiY8hdjfcLOQaSvc03hR/uqU0b79dg2ABrJbfdiRqr7WmPOou3DsSd0W3c9guq+U pQjOFAIJM1FF07xUD+d9AmaDrBdt+4je1s4GhG8EkZ8ufjv03L2Np9i/BjBQCTL9 qEnQ2Vn52yUG1BBb8vH7eIWi2kedBeEwznRr+CbiBRKDBGz5tCk/+wpSMdW0G1DR CRU3Yq9zKiH+gte9oiJWqemu3UWtHGsug6ku75IZ4zETqOTzPX0wnBbEcg+ajFuY NVNqV745WizWo1DnaA51dp8BAjs7wjGPvYgd/dD1DDTBZBC8kec= =R2Z5 -----END PGP SIGNATURE----- --byaWcvXO1Xi1go3V6qmOE7AyX135nLZle-- From nobody Tue Apr 9 09:36:37 2019 Return-Path: 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 C72B4120144 for ; Tue, 9 Apr 2019 09:36:35 -0700 (PDT) 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 S2jFkXGx6BTb for ; Tue, 9 Apr 2019 09:36:33 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id A876B120323 for ; Tue, 9 Apr 2019 09:36:33 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 3DBA25F40475; Tue, 9 Apr 2019 18:36:32 +0200 (CEST) Received: from [192.168.2.138] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 572985F403AE; Tue, 9 Apr 2019 18:36:31 +0200 (CEST) From: "Ralf Weber" To: "Joe Abley" Cc: add@ietf.org Date: Tue, 09 Apr 2019 18:36:29 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 16:36:36 -0000 Moin! On 9 Apr 2019, at 16:26, Joe Abley wrote: > By the time an application's engagement with a service enters this > phase, the opportunity to block the engagement has passed. The nature > of the name resolution that exists within this phase is therefore > potentially less contentious than in the initialisation phase. The > communications channels between the application and the service > endpoint have been authenticated at this point, and so to some degree > the same trust that the application puts in those channels for other > objects might also apply to name resolution. Can we please stop this train of thought. We have no mechanism to associate that a domain is bound to a service, so the client has no idea if what he gets send back from the server actually belongs to that service and we are past the point where a service is made of one client server connection. It easily can be hundreds in parallel to different entities and even if we had a mechanism (certs, DNSSEC) to validate the answer send back it could be wrong for that client especially in a multi CDN world. > As a thought experiment, perhaps a particular web service is easier to > manage if all the resolution in the established phase happens inside > the same HTTPS bundle that carries HTML and other objects; performance > measurements executed in javascript in a browser could be shared with > the service provider which could then push user-specific names to > optimise service performance and that process might be architecturally > cleaner and cheaper than using the more circuitous approach necessary > with enterprise DNS services. The control points mentioned in the > initialisation phase are unavailable in this case, but perhaps that's > ok. So we share more data to more parties for something that already works today. Where is the advantage? It is way more complicated and puts way more stuff into the browser than just DNS, and introduces new otherwise unnecessary signaling. I can to see how this is architectural cleaner. So long -Ralf —-- Ralf Weber From nobody Tue Apr 9 09:46:08 2019 Return-Path: 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 59779120144 for ; Tue, 9 Apr 2019 09:46:06 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 NRTtnVlODf6K for ; Tue, 9 Apr 2019 09:46:04 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 AD297120026 for ; Tue, 9 Apr 2019 09:46:04 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id f22so6037167ita.3 for ; Tue, 09 Apr 2019 09:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6MZHmYFEGlwsUL5fm/+jT5zS0wFWuhiillxYSFPpM6A=; b=Gw+VgVyoTwhTfbZXtRgB+vuqm/S6s6hNe75giceSi364HFyd3pJO/1gsu3X6q1MxBJ 2WK8hio2ZCEFvMeyiYTiUSB193K+f1IhUr1x7X8OL2PXCFaG4dvczXMBe8DKCC5/wCY8 b6scbVp1rpcnZaOJxT0nQa39yKj5OQmUP3UZA= 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=6MZHmYFEGlwsUL5fm/+jT5zS0wFWuhiillxYSFPpM6A=; b=K3X1MGbNtsb5qxrRYQVUe9cOplSlvlfpJuwKnKXVKCeRs/OHjvxpEiGxhsx4m20NLY 1XkbeaRRbgU/vZZ68YAcZlUKymJDpnEjA0Kp1d38wX77MfhQqXxTMl7wRYRCPvIoh0Jx 22q6/4qr77Eo2nVlybFg74zFjm36cnCs901CoRG5BDNR/wA3YjZY8e1BRK2vmhXYw89D qy9ZV+XljXJfB0UPAWbuYFg7cDtaP0sGLq8FUq2OPLCIkl0g5Ump7AdhgZHa+b99IjCG QCC8Vow+hXYAIOyiXCw4goqvkaQG5fpZpAwOMSONQ+3G5aljoCJATp7SScxFo+n1vpoU 5V8A== X-Gm-Message-State: APjAAAX8eH95bVwntiPcVcoE1AcFEexO8gP53XWn5v7tWQkDNrR88Hts iE2BFSpDk3gfVt8t0TAY3cqdpGoAXzzXg+nw X-Google-Smtp-Source: APXvYqwL9dEqNaPuG+YVOy7/9ZH6CStRqUmc8GFUAhsKaC3gyP1P0IgCQi2yRZyhMSAiz5NEefRW7A== X-Received: by 2002:a24:4161:: with SMTP id x94mr26200918ita.83.1554828363853; Tue, 09 Apr 2019 09:46:03 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:d051:81:490:288e? ([2607:f2c0:e786:128f:d051:81:490:288e]) by smtp.gmail.com with ESMTPSA id a8sm13126580iol.35.2019.04.09.09.46.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 09:46:02 -0700 (PDT) From: Joe Abley Message-Id: <2BF7C7CC-69B5-4BF7-98A7-A2466ACD3761@hopcount.ca> Content-Type: multipart/signed; boundary="Apple-Mail=_FC70A30D-10E2-43B0-B0C8-2DBF341C2424"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 9 Apr 2019 12:45:59 -0400 In-Reply-To: Cc: add@ietf.org To: Ralf Weber References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 16:46:07 -0000 --Apple-Mail=_FC70A30D-10E2-43B0-B0C8-2DBF341C2424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ralph, On 9 Apr 2019, at 12:36, Ralf Weber wrote: > On 9 Apr 2019, at 16:26, Joe Abley wrote: >> By the time an application's engagement with a service enters this = phase, the opportunity to block the engagement has passed. The nature of = the name resolution that exists within this phase is therefore = potentially less contentious than in the initialisation phase. The = communications channels between the application and the service endpoint = have been authenticated at this point, and so to some degree the same = trust that the application puts in those channels for other objects = might also apply to name resolution. > Can we please stop this train of thought. We have no mechanism to = associate that a domain is bound to a service, so the client has no idea = if what he gets send back from the server actually belongs to that = service and we are past the point where a service is made of one client = server connection. In that thought experiment some (non-DNS), transport-layer = authentication has already happened. So that's exactly the mechanism to = bind name resolution within the context of that session to a unique = session cache that's populated in-band. > It easily can be hundreds in parallel to different entities and even = if we had a mechanism (certs, DNSSEC) to validate the answer send back = it could be wrong for that client especially in a multi CDN world. I think you're presupposing a particular architecture that has holes. = Perhaps try to imagine one that doesn't? >> As a thought experiment, perhaps a particular web service is easier = to manage if all the resolution in the established phase happens inside = the same HTTPS bundle that carries HTML and other objects; performance = measurements executed in javascript in a browser could be shared with = the service provider which could then push user-specific names to = optimise service performance and that process might be architecturally = cleaner and cheaper than using the more circuitous approach necessary = with enterprise DNS services. The control points mentioned in the = initialisation phase are unavailable in this case, but perhaps that's = ok. > So we share more data to more parties for something that already works = today. No, we share less data with fewer parties. Instead of service providers = using third-party enterprise DNS providers to generate session-specific = responses based on data that's harvested from real-user monitoring = across a swathe of fourth-party sites, performance monitoring, traffic = steering, etc can all happen within the bounds of a service contract = that is already established for the purpose of using the actual service. But really there was a reason why I labelled these as thought = experiments and separated the lifecycle into phases. You're arguing = against a thought experiment in precisely the part of the whiteboard = that I suggest is unimportant for the purposes of the current discussion = :-) Joe --Apple-Mail=_FC70A30D-10E2-43B0-B0C8-2DBF341C2424 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----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXKzMRwAKCRA0jwy9hlI6 LDlLAJ9rKpC2wY8Q2h7AbgnZE7ymkwngYwCePYdeapzd4CpJhWCFb7Nzyy7P7YY= =RjDL -----END PGP SIGNATURE----- --Apple-Mail=_FC70A30D-10E2-43B0-B0C8-2DBF341C2424-- From nobody Tue Apr 9 09:55:22 2019 Return-Path: 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 E6E25120458 for ; Tue, 9 Apr 2019 09:55:20 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 zd453X2sl95z for ; Tue, 9 Apr 2019 09:55:18 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 C3663120423 for ; Tue, 9 Apr 2019 09:55:18 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id p23so14294054iol.13 for ; Tue, 09 Apr 2019 09:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OPK3/wLSPYEQ9CV0aAvd2xjyYPm5HWQk0eu8FA6C9Uo=; b=AGe6MEZzNrO7V/J4MqHOF2Gdc9+R4Da+SJAQZJiTrM/OeN0oooI2/nEEg/BlbRnJ41 I6f4e6l9/qPURZN8lfBGen7F0AohrvqkKuitBAp8gRX8ZIzbQ0aY1SLQao6QifKBnemD Z0vB1siUQJsKjK6hfiTLQ5PeYHn2vrw+CnvE8= 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=OPK3/wLSPYEQ9CV0aAvd2xjyYPm5HWQk0eu8FA6C9Uo=; b=RS9KF2mOkgdP2PL4E6OBW88ljRmR7hJJlwqatiWjt9X6Cu2UUDdGcyD9ihm4cAUI2k UlW0xTcvvPeQs0L+r4d110mQdGTdTPRPGu72IpeFg76zmzlYcVXmd8yOwwes3kJ8EoJd 4blz+5keKS295CSGHOh6gXrKk6mwFTlJBFJz4mHAtHwhHD1j0Qj1dzryg+uEBIjH6MTT kjxmWaVAonepxAKVOextLCl4RvO+vu9ZWftgdiqnkbj1KPPohIF/B/q4JEKwIgZWWqeB 7UbRPTTG0WWBN8l5LE6sB+9igayP5uf9NL8FhHeB61x94iXx7jmm/SPVHqiAeI4GpN2w maaA== X-Gm-Message-State: APjAAAVhvTdpBhvscc1KbFuPbiLmbx8UpNB3J8M2ljEj83hFRy2f9ga5 pR/JbXZJZQYCqa7YkFPTMrLkOKUPdIJsmqTR X-Google-Smtp-Source: APXvYqzrNdGTLKFpVCv53pvRgh9g8SttdBrVPkHVT18mJSY7mzabf5s6MOEjZ0O0vUEy4p3F2GHrTQ== X-Received: by 2002:a5d:97da:: with SMTP id k26mr24207196ios.46.1554828917973; Tue, 09 Apr 2019 09:55:17 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:d051:81:490:288e? ([2607:f2c0:e786:128f:d051:81:490:288e]) by smtp.gmail.com with ESMTPSA id v134sm6855526ita.16.2019.04.09.09.55.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 09:55:16 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_85AC2275-73D5-4A9A-A9B6-587B6EF1C280"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 9 Apr 2019 12:55:14 -0400 In-Reply-To: Cc: add@ietf.org To: Stephen Farrell References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> <6EA8E030-B3E1-43DD-AF55-93A5285F342B@hopcount.ca> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 16:55:21 -0000 --Apple-Mail=_85AC2275-73D5-4A9A-A9B6-587B6EF1C280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Apr 2019, at 12:32, Stephen Farrell = wrote: > That wasn't what I tried to describe, so maybe let me > try again. >=20 > If a user thinks they are up and running nicely with some > DNS setup (as a result of the "initialisation phase"), > then at some later time, that user might try resolve some > name that then doesn't work. The phases I described were intended to be in the context of a single = session between an application and a service (what I half-heartedly = referred to as an "engagement" since I think the word session is a bit = loaded). The initialisation phase is the front door, with all the signposts and = locks and visitor's books associated with that. In the established phase you're shuffling between offices inside the = building in a way that might well be invisible to the outside world, = although maybe the building has windows that allow people to peer in. The termination phase doesn't matter so much. Climb out of a window if = you like. Are you talking about the problem of wandering into a wall whilst inside = the building? Or of finding some other building entirely? It seems like the use of a separate resolution protocol in the = established phase makes support easier. If things don't work properly = while I'm using the booktweet service, I blame the booktweet service = people. If you can't get booktweet to load properly, whatever that = means, that feels like an Internet problem. But as I tried to say to = Raph just now, the use of a different resolution protocol is intended to = illlustrate the difference in sensitivities between the phases, not that = the established phase can't use (e.g.) the same local resolvers as were = used in the initialisation phase. Joe --Apple-Mail=_85AC2275-73D5-4A9A-A9B6-587B6EF1C280 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----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXKzOcgAKCRA0jwy9hlI6 LGjnAKChz6yzqJkrRJ3s1+ZGGg5rFcLEUQCcCFg8mChRMepBEMjQ/OJ4Za+QzNc= =y9zW -----END PGP SIGNATURE----- --Apple-Mail=_85AC2275-73D5-4A9A-A9B6-587B6EF1C280-- From nobody Tue Apr 9 10:29:29 2019 Return-Path: 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 9F7BA120049 for ; Tue, 9 Apr 2019 10:29:28 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=nomountain-net.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 beTSsTjI5xDL for ; Tue, 9 Apr 2019 10:29:27 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 07728120047 for ; Tue, 9 Apr 2019 10:29:27 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id 188so10110400pfd.8 for ; Tue, 09 Apr 2019 10:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=YE9ujv1d4HRDg8vQZxCZrk94JA/8jj8guFxgCpnJYqo=; b=DLiRZRm/Eks5NCmdVqem4yx05q7/45rTgxhWs5D9PqLPNKkW/h+2d1dEcDkWDPTqRI nDv8pqWvHKUfsoovO6p1F9kpvX1bpKWa3ECVCKu07OgeHuGUFgIGfWEBbC9nQRzy4lZ9 Twrijs3GtLXQxJ0G/MSLxw/ccxw1FPvTxNnVczsAPIz/BE4iC4rRx3AR4XtK8bEWspoM C0HAjp7xnFiuf9OB6fYbU4z/5HT0UIn46dIE8i/C3easQPsRgXHk6rlGNfuhS5JNhQ8b Amxb9KfPaICrJOz35+6fn4Zd/gLKqWJOvvbEKhWJhaQLolTlZa3ooNYOdq9WcBVE1hTy zyPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=YE9ujv1d4HRDg8vQZxCZrk94JA/8jj8guFxgCpnJYqo=; b=MTKXKQYlrrg3ztk7VPvvAnUZ+5pKaOVUnUoZtxH8cpArhFC/s6ZL9w5hNrN8+WpdcJ mCw8GLSt01AcRWBhAooXPJVq2SuaDFkt6KSsFxB4G98DAS9qOcLxgR40RQ+toB9Em96h n0/bmrkaeO+FANVqWbCXU7Pm4PJNgOpZxbn8XMsN3VZWaNd1v+16dGkfdgEm6HQEcz0/ +GF7+bVBxdGYFsLr25/lgZsr+JO/qIokCkniaDv0obwZxvUgzPfZLiq/JKtG8tQeAlN2 vD0MpENlfq5qbcuOcT1f9ouKBTcy5gQ9tSFaoaXpNLj/eUsfsL/yvccREqV4Bmb9puts 1mDQ== X-Gm-Message-State: APjAAAU2WWCKhrheTjM5jhSIB70uMCLYOYWgjQmTRo6cY2lvbIaUjI3F LSNhegfvXRwo+i1C0Nm8VSM2HlVJNQ== X-Google-Smtp-Source: APXvYqyJD2Xg8HS3rkWQvsAAEIlPuyAb8fOwwOR1JgP2Xx2Drd9xDJeSb4i9SO4KTqkqkrRfBTqyMg== X-Received: by 2002:a63:e653:: with SMTP id p19mr35406411pgj.284.1554830966231; Tue, 09 Apr 2019 10:29:26 -0700 (PDT) Received: from aspen.local ([216.67.81.206]) by smtp.gmail.com with ESMTPSA id a17sm55125219pfj.123.2019.04.09.10.29.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Apr 2019 10:29:25 -0700 (PDT) To: add@ietf.org References: <8b37b3ed-1161-91cb-ef38-0496f8ca7bd6@cs.tcd.ie> <1264936982.14595.1554815247698@appsuite.open-xchange.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: Date: Tue, 9 Apr 2019 09:29:23 -0800 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: <1264936982.14595.1554815247698@appsuite.open-xchange.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uPiVuVzGWS47EgdGOZjEyJhjA3he2aJYO" Archived-At: Subject: Re: [Add] Applications Doing DNS... X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2019 17:29:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uPiVuVzGWS47EgdGOZjEyJhjA3he2aJYO Content-Type: multipart/mixed; boundary="1zdrNQYzj58MSxa4Qal8NpFYs6rv6X9bB"; protected-headers="v1" From: Melinda Shore To: add@ietf.org Message-ID: Subject: Re: [Add] Applications Doing DNS... References: <8b37b3ed-1161-91cb-ef38-0496f8ca7bd6@cs.tcd.ie> <1264936982.14595.1554815247698@appsuite.open-xchange.com> In-Reply-To: <1264936982.14595.1554815247698@appsuite.open-xchange.com> --1zdrNQYzj58MSxa4Qal8NpFYs6rv6X9bB Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/9/19 5:07 AM, Vittorio Bertola wrote: > This > has changed over time, in a stretch of almost 30 years, and now the DNS= > looks more like a directory service that orchestrates traffic across th= e > Internet as well as on private networks, and customizes the directions > it gives according to a broad set of factors. I was going to say that the DNS is used to do those things rather than it does those things itself, but in thinking about it that distinction really isn't a clear one and I think it's part of what makes these discussions so challenging. I don't think I've ever seen a taxonomy of DNS functions in the real world and I think it might be useful in mitigating the discussion's tendency to spin. Melinda --=20 Melinda Shore melinda.shore@nomountain.net Software longa, hardware brevis --1zdrNQYzj58MSxa4Qal8NpFYs6rv6X9bB-- --uPiVuVzGWS47EgdGOZjEyJhjA3he2aJYO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAlys1nMACgkQ37iRcpp2 24+L/A//cDC/bJbPG9c//xrBtLKvWYcinbRbVwrrKctB4HIeLyfcDf1xT3mjwEy/ hH+WEHYVrwbYnFGxDsecuMybRRFH4KF6PnBEcXYZ6dmqogKbWAT8kg9j1Z3gp60t Tr2Fkch3wVokC2pdyyMMgTFBezvNKOekB4FL5fkwIyd21SLYLJmT0hINtSgeR7Az iuHtqAYr7lQlTS3pJUWWQxJ3zzRP8TEZBbZuALGt7+zfQIf7EPZdBcsFQ1bpyHyb qvvHwEY9IUYt1wuozAFqcOltedBHCtu5CjPvjb8NixiJ6RnvwsOJ4RHr1Kzaxkas fwBT+Pp6apaGQSZkP9YMyVVtvrtuC1519GD6MEu1GxJpLMXSXWujNnOgeGRaLJn0 833og45XT2EVqnePMYI/qX0885h3i47hIte10QKxypcF40l946LQA6ukcdD9BbTR 9sT4wMX1k8cfUdRmT6Uz14jY5Bgcuh6hWZXlhUNeSxQ9M7NFJ8xTBhpNaymEHNyw LuT1ysw50aCSYuFxCqostf1J8ToqgS5vO5PhwK9mUIdo7wPvSPZrQs1TN8+6bCBd YhC0HHMTbfmAa9A7oBXpO0qIPwQ8Y2l+Bn0a6reIHIq9h2B5/PjlmAWAcVofEutt qCWAanPZxlAisuRnlm5WM9QjgqLsSfk7YZA+q2Dnk57m02eSkZQ= =jmeN -----END PGP SIGNATURE----- --uPiVuVzGWS47EgdGOZjEyJhjA3he2aJYO-- From nobody Tue Apr 9 22:55:29 2019 Return-Path: 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 ADC161202A0 for ; Tue, 9 Apr 2019 22:55:27 -0700 (PDT) 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 wYjpiH0Y4WRy for ; Tue, 9 Apr 2019 22:55:25 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFDB120048 for ; Tue, 9 Apr 2019 22:55:25 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 485505F40AB5; Wed, 10 Apr 2019 07:55:23 +0200 (CEST) Received: from [172.19.152.49] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 318E65F402C1; Wed, 10 Apr 2019 07:55:22 +0200 (CEST) From: "Ralf Weber" To: "Joe Abley" Cc: add@ietf.org Date: Wed, 10 Apr 2019 07:55:21 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: <29A8B0C7-F58B-4DBB-BE9A-98D5CC926E53@fl1ger.de> In-Reply-To: <2BF7C7CC-69B5-4BF7-98A7-A2466ACD3761@hopcount.ca> References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> <2BF7C7CC-69B5-4BF7-98A7-A2466ACD3761@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 05:55:28 -0000 Moin! On 9 Apr 2019, at 18:45, Joe Abley wrote: > In that thought experiment some (non-DNS), transport-layer > authentication has already happened. So that's exactly the mechanism > to bind name resolution within the context of that session to a unique > session cache that's populated in-band. What if you are connected to an rouge authenticated actor. If you have a connection and do/give something that requires a new connection and then add domain data to it you might have successfully cached/hijacked that new connection. >> It easily can be hundreds in parallel to different entities and even >> if we had a mechanism (certs, DNSSEC) to validate the answer send >> back it could be wrong for that client especially in a multi CDN >> world. > > I think you're presupposing a particular architecture that has holes. > Perhaps try to imagine one that doesn't? There is no such thing says the cynical me. I’ve seen so many secure systems being abused and hacked that I’d rather work with the devil I know (that of course is a very opsy position). > No, we share less data with fewer parties. Instead of service > providers using third-party enterprise DNS providers to generate > session-specific responses based on data that's harvested from > real-user monitoring across a swathe of fourth-party sites, > performance monitoring, traffic steering, etc can all happen within > the bounds of a service contract that is already established for the > purpose of using the actual service. I don’t know how you get that much parties, but in my good old DNS world the stub asks the recursive resolver which asks the authoritative server - with that the connection gets established. > But really there was a reason why I labelled these as thought > experiments and separated the lifecycle into phases. You're arguing > against a thought experiment in precisely the part of the whiteboard > that I suggest is unimportant for the purposes of the current > discussion :-) I though the topic of this list was discussing applications doing DNS and not some service meta discussions. I’m an old grey bearded unix sysadmin, so give me connections and bits on the wire (which the IETF is mostly about) and we can talk. The thought experiment (or at least part of it) sounded exactly like the “resolver less” DNS idea we discussed in a side meeting which has security and other problems as described above. So long -Ralf —-- Ralf Weber From nobody Tue Apr 9 23:50:30 2019 Return-Path: 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 4B86B120149 for ; Tue, 9 Apr 2019 23:50:29 -0700 (PDT) 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 05MW_2e1MQEm for ; Tue, 9 Apr 2019 23:50:26 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 2EACA120071 for ; Tue, 9 Apr 2019 23:50:26 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id c1so581572qkk.4 for ; Tue, 09 Apr 2019 23:50:26 -0700 (PDT) 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=fXUubnzdixSO+ggX5jhM2jnO/CSh+M9SADy5zHgBZYo=; b=JqAQ3Ve/4LqMydt+BugBBX+haJrqb7pfRU4eofHvNBeNu84a4NbiVlrofr0ScT95Jo z681mHo4ZFzEb7lob8eUwHh2kMN0PZBfnMz+osYhy075sER05kgtlyOH45/zCguhHPPG MORkoyLcEPor93iQ9fODiAFTZ2fj2rOyxxa40HAWjUAL7Opfu69u2vILSxoJLVYbwrYf n2zyOaaayHOKeqxSzUGwU//cVKOF3V8La414x6jBuMOs/dZpcEEsF25Z5mUblFXTuMUI Xu2+owUsDgSKpNpCdzob3x2WzcHwDAT231uSOCtgbuDSd60+QV1V3EAq1vxPmU+EWeQA KPJQ== 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=fXUubnzdixSO+ggX5jhM2jnO/CSh+M9SADy5zHgBZYo=; b=HmY+QlEGMDN9vBB+XmHrxNu7+j2ChRrVziJ2pyMruLAJ1GfJ8hMANsK2G7pks6Ur0/ J1LHGR2VITQuiPIWPpNsURUZGeB3rsWIGFno58qV6je6TW6NsDpkOToJS3J38aZueumQ kxRicI3Rg9EYz+84Ta44JlXTeBq1+BOVDM4HrrC/KpoUfX5r/rXY5jeOpSEBBXruEeyn u8m0qqT9HQZZf02IJ6HuHd/gVaExhIL65/0UuQCP/fFNDeYHuay7ZxSu7QGSq2f9Kpnn 2B3TTeF6jhkvKFF+3hVwhUnE4SUJ4vlQcN8v6tyOXg9DpNMFySxJ5JlV8KzpfnavkT65 ih9Q== X-Gm-Message-State: APjAAAUh+VKcFvS1VhxygTkiERjEd3/KhjqMPzPTLOL3UIeO7ojT7GT5 +AepDulCynqcDAkNjWN8prmJl0Y73ejO1WlgVUGCXdmi X-Google-Smtp-Source: APXvYqw2WMCks7StVSKLoWW4UIkMlZElAYr2nv9xSYcQ7y+oGUDA4CVjcDhK+PiCcp/94MAu0IXVwkA/REr/3Z74svM= X-Received: by 2002:a37:a650:: with SMTP id p77mr32052946qke.256.1554879025271; Tue, 09 Apr 2019 23:50:25 -0700 (PDT) MIME-Version: 1.0 References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> <2BF7C7CC-69B5-4BF7-98A7-A2466ACD3761@hopcount.ca> <29A8B0C7-F58B-4DBB-BE9A-98D5CC926E53@fl1ger.de> In-Reply-To: <29A8B0C7-F58B-4DBB-BE9A-98D5CC926E53@fl1ger.de> From: Brian Dickson Date: Tue, 9 Apr 2019 23:50:12 -0700 Message-ID: To: Ralf Weber Cc: Joe Abley , add@ietf.org Content-Type: multipart/alternative; boundary="000000000000f856e90586277b26" Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 06:50:29 -0000 --000000000000f856e90586277b26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 9, 2019 at 10:55 PM Ralf Weber wrote: > Moin! > > On 9 Apr 2019, at 18:45, Joe Abley wrote: > > In that thought experiment some (non-DNS), transport-layer > > authentication has already happened. So that's exactly the mechanism > > to bind name resolution within the context of that session to a unique > > session cache that's populated in-band. > What if you are connected to an rouge authenticated actor. If you have a > connection and do/give something that requires a new connection and then > add domain data to it you might have successfully cached/hijacked that > new connection. > > (I presume you meant "rogue", probably autocorrect error.) You are correct. This is indeed an apparent flaw in the system described by Joe. Again, this presumes the rogue is the entity to which the "established" connection is established, after which the DNS traffic is encrypted (and trusted). In some ways it is worse, since such a rogue would be the resolver. No resolver poisoning would be needed, if the bad actor were the one operating this resolver. The flip side here is that not only have you given something (DNS queries) to the rogue operator, the rogue can (will) give you bad responses in return (presuming that either the client does not do DNSSEC validation, or that the data is not signed, or both). The rogue would be free to be selective in the bad data (e.g. specific FQDNs or domains), or not. The responses could point at one or more servers, and those servers might serve https using self-signed certs. The success rate might not be high, but... phishing and spam, those don't require high success rates to achieve their goals. > >> It easily can be hundreds in parallel to different entities and even > >> if we had a mechanism (certs, DNSSEC) to validate the answer send > >> back it could be wrong for that client especially in a multi CDN > >> world. > > > > I think you're presupposing a particular architecture that has holes. > > Perhaps try to imagine one that doesn't? > There is no such thing says the cynical me. I=E2=80=99ve seen so many sec= ure > systems being abused and hacked that I=E2=80=99d rather work with the dev= il I > know (that of course is a very opsy position). > > > No, we share less data with fewer parties. Instead of service > > providers using third-party enterprise DNS providers to generate > > session-specific responses based on data that's harvested from > > real-user monitoring across a swathe of fourth-party sites, > > performance monitoring, traffic steering, etc can all happen within > > the bounds of a service contract that is already established for the > > purpose of using the actual service. > I don=E2=80=99t know how you get that much parties, but in my good old DN= S > world the stub asks the recursive resolver which asks the authoritative > server - with that the connection gets established. > What I believe Joe meant was, the other parties (on-path parties) can no longer see the DNS queries/answers, since the DNS traffic is encrypted. Thus, those parties are no longer parties to the DNS transaction traffic. (Thus, fewer.) > > > But really there was a reason why I labelled these as thought > > experiments and separated the lifecycle into phases. You're arguing > > against a thought experiment in precisely the part of the whiteboard > > that I suggest is unimportant for the purposes of the current > > discussion :-) > I though the topic of this list was discussing applications doing DNS > and not some service meta discussions. I=E2=80=99m an old grey bearded un= ix > sysadmin, so give me connections and bits on the wire (which the IETF is > mostly about) and we can talk. > I believe Joe was breaking down the way that the DNS gets established using TLS, which requires unencrypted DNS queries to "bootstrap" the new DNS "channel"= . (As a grey bearded unix sysadmin myself, I presume "bootstrap" is understood. :-) ) > > The thought experiment (or at least part of it) sounded exactly like the > =E2=80=9Cresolver less=E2=80=9D DNS idea we discussed in a side meeting w= hich has > security and other problems as described above. > Yes. I believe Joe was imagining an example implementation, without naming the implementers or distinguishing the unique aspects they might choose in how they implement, i.e. keeping the thought experiment as generic and as close to the "application doing DNS" as possible. Brian --000000000000f856e90586277b26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 9, 2019 at 10:55 PM Ralf = Weber <dns@fl1ger.de> wrote:
=
Moin!

On 9 Apr 2019, at 18:45, Joe Abley wrote:
> In that thought experiment some (non-DNS), transport-layer
> authentication has already happened. So that's exactly the mechani= sm
> to bind name resolution within the context of that session to a unique=
> session cache that's populated in-band.
What if you are connected to an rouge authenticated actor. If you have a connection and do/give something that requires a new connection and then add domain data to it you might have successfully cached/hijacked that
new connection.


(I presume you meant "rogue"= , probably autocorrect error.)

You are correct. Th= is is indeed an apparent flaw in the system described by Joe.
Aga= in, this presumes the rogue is the entity to which the "established&qu= ot; connection=C2=A0
is established, after which the DNS traffic = is encrypted (and trusted).

In some ways it is wor= se, since such a rogue would be the resolver.
No resolver poisoni= ng would be needed, if the bad actor were the one operating this resolver.<= /div>

The flip side here is that not only have you given= something (DNS queries) to the rogue operator,
the rogue can (wi= ll) give you bad responses in return (presuming that either the client
does not do DNSSEC validation, or that the data is not signed, or bot= h).

The rogue would be free to be selective in the= bad data (e.g. specific FQDNs or domains), or not.
The responses= could point at one or more servers, and those servers might serve https
using self-signed certs. The success rate might not be high, but...= phishing and spam, those
don't require high success rates to= achieve their goals.
=C2=A0
>> It easily can be hundreds in parallel to different entities and ev= en
>> if we had a mechanism (certs, DNSSEC) to validate the answer send =
>> back it could be wrong for that client especially in a multi CDN <= br> >> world.
>
> I think you're presupposing a particular architecture that has hol= es.
> Perhaps try to imagine one that doesn't?
There is no such thing says the cynical me. I=E2=80=99ve seen so many secur= e
systems being abused and hacked that I=E2=80=99d rather work with the devil= I
know (that of course is a very opsy position).

> No, we share less data with fewer parties. Instead of service
> providers using third-party enterprise DNS providers to generate
> session-specific responses based on data that's harvested from > real-user monitoring across a swathe of fourth-party sites,
> performance monitoring, traffic steering, etc can all happen within > the bounds of a service contract that is already established for the <= br> > purpose of using the actual service.
I don=E2=80=99t know how you get that much parties, but in my good old DNS =
world the stub asks the recursive resolver which asks the authoritative server - with that the connection gets established.
What I believe Joe meant was, the other parties (on-path parti= es) can no longer see
the DNS queries/answers, since the DNS traf= fic is encrypted. Thus, those parties
are no longer parties to th= e DNS transaction traffic. (Thus, fewer.)
=C2=A0

> But really there was a reason why I labelled these as thought
> experiments and separated the lifecycle into phases. You're arguin= g
> against a thought experiment in precisely the part of the whiteboard <= br> > that I suggest is unimportant for the purposes of the current
> discussion :-)
I though the topic of this list was discussing applications doing DNS
and not some service meta discussions. I=E2=80=99m an old grey bearded unix=
sysadmin, so give me connections and bits on the wire (which the IETF is mostly about) and we can talk.

I believ= e Joe was breaking down the way that the DNS gets established using TLS,
which requires unencrypted DNS queries to "bootstrap" the= new DNS "channel".
(As a grey bearded unix sysadmin my= self, I presume "bootstrap" is understood. :-) )
=C2=A0=

The thought experiment (or at least part of it) sounded exactly like the =E2=80=9Cresolver less=E2=80=9D DNS idea we discussed in a side meeting whi= ch has
security and other problems as described above.

Yes.=C2=A0 I believe Joe was imagining an example implementation, = without naming the implementers
or distinguishing the unique aspe= cts they might choose in how they implement, i.e. keeping the
tho= ught experiment as generic and as close to the "application doing DNS&= quot; as possible.

Brian=C2=A0
--000000000000f856e90586277b26-- From nobody Wed Apr 10 00:17:38 2019 Return-Path: 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 76CCD1202B2 for ; Wed, 10 Apr 2019 00:17:36 -0700 (PDT) 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 41AEGBu9yXpz for ; Wed, 10 Apr 2019 00:17:34 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 8B86612013E for ; Wed, 10 Apr 2019 00:17:34 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id v32so1661913qtc.10 for ; Wed, 10 Apr 2019 00:17:34 -0700 (PDT) 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=Jsc5DsL7yLQqJmwEPGrsk5ECPqpTqMl80ImEIK+WwOA=; b=Mk3UIa+hI+ePTg5uf+4QNS4N3lt2brWgHdi2Si5ddrMgLU+ljUJsTbTF16a8vu5sAR N8D0U3VwfLAmaVkzJhBcmV3DImt0JxxymsWCo9vIKnbGobae+glpvbhkDnL1TRAWKzeu oTDrKOF71Lj1V+cJpbSGtif/iW3mUTFGQgpyeXVMEzVsuwp/MRTwN91AaBX9nPUMrTO8 YeG/oUmQDT/wwnSIkJ0lMmzI4kPWtZAhcxhMj6p55/xSLK9ZA0jrDqeCu+hn5y/U9Orv w5vbBi0+9sr1Hpv7e2kbFWI9dVHH9ZD9lfr03OJjnkUedLqlwFGPlPy+wLOxueCrQybD vWGQ== 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=Jsc5DsL7yLQqJmwEPGrsk5ECPqpTqMl80ImEIK+WwOA=; b=STniW3ia450UUOb+ZQdf9bcHdd3RQ5J9Uz8KJIyL34HMVhiB32K42MRpkUFfRCx7Ac KK6YyClMJoSVbmHSPCBwAPj7kfsZm1E+20mcIYhUFi/kgeM2957Ms6OBW4FZ7ri1aXtY j2pvUW3sXMNRI5KDFHhDbv/vmlefqzSyzShDG8FE6QnUip47iiYyLoiDXxgy8ii15tV1 WUoxE8LAxGpqc1mjQyFLNa1bobarpRNjFwx5cfQ0CDa9S7o55nrjwt1Yhym0kRq7Odva idpibvuEqtWXx4EZ42WsJmeQhbitZXy0XdFN+PCYoiiPOrJpXrI9Zf0Dmsy6RjOat0nU Fu6Q== X-Gm-Message-State: APjAAAWtiqisvSQkhJyz+2qngAZUltbs62l2bIWLKy0N9XrUaYZc9BfD GRhrrHAYcdk+1XzUKOjeGx+bCWnFkRDyOidSNHg= X-Google-Smtp-Source: APXvYqzBkF0C0M4oyyW0nCaVpVODGrZ0SZnoz9cFvwdx7x79dpU/PSRyV+DEk5FhulNVyKhguynOApOjTKkbxhuMBqU= X-Received: by 2002:a0c:ad15:: with SMTP id u21mr34613092qvc.37.1554880653483; Wed, 10 Apr 2019 00:17:33 -0700 (PDT) MIME-Version: 1.0 References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> In-Reply-To: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> From: Brian Dickson Date: Wed, 10 Apr 2019 00:17:20 -0700 Message-ID: To: Joe Abley Cc: add@ietf.org Content-Type: multipart/alternative; boundary="00000000000004f0bd058627dd33" Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 07:17:36 -0000 --00000000000004f0bd058627dd33 Content-Type: text/plain; charset="UTF-8" [Much of the greatly appreciated flow has been elided by me below, to highlight one area of concern...] On Tue, Apr 9, 2019 at 7:26 AM Joe Abley wrote: > Consider an end-user who wants to use some service over the Internet. > -- Initialisation Phase -- > > The end-user uses an application to begin a session with some service or > other. > -- Established Phase -- > > The application begins to communicate with the service end-points. > The area I want to focus on here, is the distinction between arbitrary end-users (without admin privileges), and end-users with administrative privileges on the machine they are using. In the former case, in the current world, the user *might* not have the ability to select, configure, change, override, or do anything with regards to selection of DNS resolver. (There are a plethora of reasons why the entity who has administrator privileges might disable user access to make these changes, such as third-party DNS resolvers, or custom resolver configurations such as RPZ.) In the current world, such a user might attempt to connect to some arbitrary end-point (such as a web site), and the attempt might fail as a result of how the DNS resolver that the user's machine is using, is operated. Let's presume there is a good reason for this, and that this prevents the user from being exposed to something "bad" (for some value of "bad", such as malware, or offensive content, or similar.) In Joe's thought experiment, it would *appear* the user has the ability to select the service end-point (where the service provides a replacement DNS resolution that pre-empts the pre-existing DNS resolution as provided to the user.) The result is that the user has been provided the means to make changes to DNS, *that the administrator of the machine didn't permit*. The user is now free to use arbitrary DNS servers, whether they are trustworthy or malicious. The scope of the resulting injury may be limited to that single user on the machine in question, but depending on what that injury is (e.g. malware), the consequences may impact more than the individual user, and may impact other machines on the local network. There is also the issue with how user changes can be performed, such as by modifications to configuration files. If there is not some "special sauce" to limit how those configuration files are able to be changed, the general presumption on multi-user systems is that the ownership and permissions would need to allow changes by the user. This in turn means that a malicious application would not require elevated privileges beyond those of the user in question, to change that user's DNS resolver, thus lowering the bar for such resolver changes. Equally true, would be the impact of someone leaving their machine unattended with a browser open. Even if the user were not an administrator, the DNS choice for the user could be changed, which is a much broader and more subtle attack than browsing to a malicious site directly. NB: All of the above is the situation where the user does not have administrative privileges, but enables the user to expose him/herself to hostile resolvers and hostile content as a result, with knock-on effects. In contrast, a user who does have administrative privileges (such as someone who owns their own machine), would already have the ability to change DNS resolvers, so nothing particularly new happens as a result of these changes. (But also, the need for the user to make those changes via the application is a moot issue; the user can already make the change directly on their system.) TL; DR: the ability for a user to select an encrypted channel to a DNS resolver, is in and of itself a privilege escalation, if the user is not a machine administrator. And once the channel is established, control has already been lost. Brian --00000000000004f0bd058627dd33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Much of the greatly appreciated flow has been elided= by me below, to highlight one area of concern...]

On Tue, Apr 9, 2019 at 7:= 26 AM Joe Abley <jabley@hopcount.c= a> wrote:
Consider an end-user who wa= nts to use some service over the Internet.=C2=A0
-- Initialisatio= n Phase --

The end-user uses an application to beg= in a session with some service or other.=C2=A0
-- Established Pha= se --

The application begins to communicate with t= he service end-points.

The area= I want to focus on here, is the distinction between arbitrary end-users (w= ithout admin privileges), and end-users with administrative privileges on t= he machine they are using.

In the former case, in = the current world, the user might not have the ability to select, co= nfigure, change, override, or do anything with regards to selection of DNS = resolver.
(There are a plethora of reasons why the entity who has= administrator privileges might disable user access to make these changes, = such as third-party DNS resolvers, or custom resolver configurations such a= s RPZ.)

In the current world, such a user might at= tempt to connect to some arbitrary end-point (such as a web site), and the = attempt might fail as a result of how the DNS resolver that the user's = machine is using, is operated.

Let's presume t= here is a good reason for this, and that this prevents the user from being = exposed to something "bad" (for some value of "bad", su= ch as malware, or offensive content, or similar.)

= In Joe's thought experiment, it would appear the user has the ab= ility to select the service end-point (where the service provides a replace= ment DNS resolution that pre-empts the pre-existing DNS resolution as provi= ded to the user.)

The result is that the user has = been provided the means to make changes to DNS, that the administrator o= f the machine didn't permit. The user is now free to use arbitrary = DNS servers, whether they are trustworthy or malicious.

The scope of the resulting injury may be limited to that single user = on the machine in question, but depending on what that injury is (e.g. malw= are), the consequences may impact more than the individual user, and may im= pact other machines on the local network.

There is= also the issue with how user changes can be performed, such as by modifica= tions to configuration files.=C2=A0

If there is no= t some "special sauce" to limit how those configuration files are= able to be changed, the general presumption on multi-user systems is that = the ownership and permissions would need to allow changes by the user.=C2= =A0

This in turn means that a malicious applicatio= n would not require elevated privileges beyond those of the user in questio= n, to change that user's DNS resolver, thus lowering the bar for such r= esolver changes.

Equally true, would be the impact= of someone leaving their machine unattended with a browser open. Even if t= he user were not an administrator, the DNS choice for the user could be cha= nged, which is a much broader and more subtle attack than browsing to a mal= icious site directly.

NB: All of the above is the = situation where the user does not have administrative privileges, but enabl= es the user to expose him/herself to hostile resolvers and hostile content = as a result, with knock-on effects.

In contrast, a= user who does have administrative privileges (such as someone who owns the= ir own machine), would already have the ability to change DNS resolvers, so= nothing particularly new happens as a result of these changes.
(= But also, the need for the user to make those changes via the application i= s a moot issue; the user can already make the change directly on their syst= em.)

TL; DR: the ability for a user to select an e= ncrypted channel to a DNS resolver, is in and of itself a privilege escalat= ion, if the user is not a machine administrator. And once the channel is es= tablished, control has already been lost.

Brian
--00000000000004f0bd058627dd33-- From nobody Wed Apr 10 08:20:19 2019 Return-Path: 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 27B081203AA for ; Wed, 10 Apr 2019 08:20:18 -0700 (PDT) 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 J5lvG8qOuonw for ; Wed, 10 Apr 2019 08:20:16 -0700 (PDT) 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 EE7081202FC for ; Wed, 10 Apr 2019 08:20:15 -0700 (PDT) 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; Wed, 10 Apr 2019 08:20:14 -0700 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; Wed, 10 Apr 2019 08:20:14 -0700 From: Paul Hoffman To: "add@ietf.org" Thread-Topic: Mozilla's DoH resolver policy Thread-Index: AQHU77Dlc8CwVfKDqk2z5i9MnPeCkg== Date: Wed, 10 Apr 2019 15:20:13 +0000 Message-ID: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> 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: <35D63D7C05E76E4185B17097FF5F4ED6@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Add] Mozilla's DoH resolver policy X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 15:20:18 -0000 Of likely interest to this group: https://wiki.mozilla.org/Security/DOH-resolver-policy From nobody Wed Apr 10 09:47:21 2019 Return-Path: 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 8919A1203D1 for ; Wed, 10 Apr 2019 09:47:20 -0700 (PDT) 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=portfast.net 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 7aTQTzFIx6hH for ; Wed, 10 Apr 2019 09:47:18 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 025F312030F for ; Wed, 10 Apr 2019 09:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UZBNiLZic3DKgtq6xzAzmguyrVwCM4FFhTT3jHqMVZ8=; b=GglrlErRWJkpUHer8tpCimFosw rvX/cr74b/7pVUAVGrjH4w6EDdWSM45A4CqS1zIWqA9+ErjnvwL1HI3rXFWyVKC+Y5qkLU16NOQbO GONK/bGuMp7OTpmpl+Rms46wmhnZ4DIw1PySVkoMosUsa67Is/TASJ6QqGLOeHu9Ns8o=; Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:65104 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hEGNX-0001gH-E2 (Exim 4.89) for add@ietf.org (return-path ); Wed, 10 Apr 2019 16:47:15 +0000 To: add@ietf.org References: From: Ray Bellis Message-ID: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> Date: Wed, 10 Apr 2019 17:47:14 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 16:47:21 -0000 On 08/04/2019 19:19, Barry Leiba wrote: > For the longer term, the relevant ADs are discussing the right path. > At the moment that looks like a BoF in Montreal (IETF 105) aimed at > forming an “ADD” working group, most likely in the ART Area but with > significant crossover expected and desired from Ops, Sec, Int, and > probably the rest of the solar system IETF community. With respect Barry, I hope this does *not* happen in the ART Area. This whole mess started, IMHO, because some parties are treating the DNS as an application service, and not as part of the infrastructure and network services. Traditionally, name resolution has always been a service that has been configured by the network, and via the operating system, and often (but not always) name resolution would use the DNS. While individual applications are free to open connections to port 53 to perform DNS lookups, the vast majority do not, at least not within their own source code. Sure, they call getaddrinfo() or perhaps even still gethostbyname() - i.e. system-provided library calls that do end up linked into the userspace application, but those still rely on nsswitch.conf and/or resolv.conf and can access all those other naming systems that are *not* DNS. [UNIX specific stuff just given as examples. YOSMV]. For DoH-as-a-service to get universal acceptance it needs (IMHO) to get plugged into those operating system level APIs as Google have done with DoT in Android Pie. If I want to use DoH it has to be a single setting for the whole computer, and not set up separately in every application. By all means have an O/S level UI where the user can manually override the network provided settings, in full knowledge that they may be in violation of the local network's security policies. Having individual applications do that without the informed consent of their users is over-reach, IMHO, whatever their lawyers write into their shrink-wrap licenses. regards, Ray Bellis ISC Research Fellow From nobody Wed Apr 10 10:20:11 2019 Return-Path: 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 EC46E1205D3 for ; Wed, 10 Apr 2019 10:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net 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 WdPqyKOw7EQ7 for ; Wed, 10 Apr 2019 10:20:07 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF341205FA for ; Wed, 10 Apr 2019 10:20:00 -0700 (PDT) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 042381B91B4 for ; Wed, 10 Apr 2019 10:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1554916800; bh=KpFRSdpdpUzfi63ePQcU3K+3dyVZnpkG2i37BVWc6iE=; h=To:References:From:Subject:Date:In-Reply-To:From; b=HjBfgxyZh/UtGX+NWFE1Fvw1U5zBqglxie95drtwBNBetJLA65PU0Gwq3SLedXaIx 1HJ/MwGNLgkgzo2xZ/w6SBbheONBpU3hfRrSzRGXFeSR9JmzRE0UQ3qIwkrRH0WNUw FrYIOv6C+tsRtPH9E8X83QHzpIscQzG5iSpSTbmc= X-Riseup-User-ID: 9BACCB51B6B80B1D41196872B6CCA8EB160517F7B21003C64A709766FB838DBD Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id B320D120AD5 for ; Wed, 10 Apr 2019 10:19:58 -0700 (PDT) To: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> From: nusenu Openpgp: preference=signencrypt Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA== Message-ID: Date: Wed, 10 Apr 2019 17:19:00 +0000 MIME-Version: 1.0 In-Reply-To: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6ydTEhZuwwtOuOFG2yBwydra0aBMHbEyC" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:20:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6ydTEhZuwwtOuOFG2yBwydra0aBMHbEyC Content-Type: multipart/mixed; boundary="xH0HdjhZaT9bYfAwYl2u3qj66TCeV9fle"; protected-headers="v1" From: nusenu To: add@ietf.org Message-ID: Subject: Re: [Add] Mozilla's DoH resolver policy References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> In-Reply-To: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> --xH0HdjhZaT9bYfAwYl2u3qj66TCeV9fle Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Paul Hoffman wrote: > Of likely interest to this group: > https://wiki.mozilla.org/Security/DOH-resolver-policy I'm surprised they don't include DNSSEC in their requirements for DoH server operators aiming to join their TRR program --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --xH0HdjhZaT9bYfAwYl2u3qj66TCeV9fle-- --6ydTEhZuwwtOuOFG2yBwydra0aBMHbEyC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlyuJbgACgkQrWE4wkXN Qn6xQw/+MUb8kcgZEo8YdqEaiKtjKqPlksXB9IN7KB1nUVxtU64qmld0Ovg//yDx j8xOZqOOuESS0jOUVkdW9XAg5M6yj3F5eU7SzQNSWpnG6S67cJfp0c2bfK7I/iGN txE4LRkQhdL3bB/jwAc90QwsrSPY1vv+mtXOrzY53kCB6AHfx5sm6p4M8VnqyKcl s8+cKghFsWaKqf34IdSDyQ4Av6sek7qxsqTzi16OzCgcrD1H9JZc0mQiB9Ad63/X QomnR+V4fF6jMMeF9xMYydSLmfw5zheGlcKP0HfPY++zT5WK9vCWE/PLkunKSXer D1zx4NcnSnPtCrvqEgJTHa2mr0ulcIypoocpl5dTTMbcAb8zSoSLvyOchW71gZnS glv5+BAkINsASoGh4ppRXQJqp8lTxKkqqLX7i7YPNf0mCCuWlPbFxYcLf/KuDn14 S10wdTgofGyIoo9XSVhRzH62/JWkjOECM9LKmimTnV53pzas7FXAb18J7ODHHDcu yGxiu+XbEieSRZlbjXKrVrp0OtSdGO5Csmsh7hnvZjdKbLfV/UwmnPJjEPBWW+M0 hRx7SRS59Lp6Txb+bzWdtUlPkYb7d2chWR27MgsRWR5b9jPt3udEBSziXrcielNx MZYCm/BuDkbc21W5PIe9w7lUWAbY/8SLfPtC1ooizHnuapHtISs= =hrFJ -----END PGP SIGNATURE----- --6ydTEhZuwwtOuOFG2yBwydra0aBMHbEyC-- From nobody Wed Apr 10 10:27:48 2019 Return-Path: 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 4F6B112061E for ; Wed, 10 Apr 2019 10:27:40 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 OOCWtCe8GD2Z for ; Wed, 10 Apr 2019 10:27:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5A5D1120611 for ; Wed, 10 Apr 2019 10:27:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44fWLt6m8szCwD; Wed, 10 Apr 2019 19:27:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1554917254; bh=ZD/s2OtExXb+oRs9bl1xPe4VOTKNqnDXr7YYGJhhEuc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KfeNlF+ayzE98KO8efDhQXy2Tf7aWdNjQT+6cRNo6yFAkXkRkbKIPxt5ysy/5cFdK pMP8nPNpx2uAcrX8wcNRPCOlCaW0Fe/Vt50Ss3TJQZUa2Y05Q8Ymnr15e8iNXKU2pK 6t1gC6Fahin/HD6RBtaYIamapRUV3+1T+o7TUcvA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1BxfKIH0sllZ; Wed, 10 Apr 2019 19:27:32 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 10 Apr 2019 19:27:32 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5D7C039A620; Wed, 10 Apr 2019 13:27:31 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5D7C039A620 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3542F40D358A; Wed, 10 Apr 2019 13:27:31 -0400 (EDT) Date: Wed, 10 Apr 2019 13:27:30 -0400 (EDT) From: Paul Wouters To: nusenu cc: add@ietf.org In-Reply-To: Message-ID: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:27:46 -0000 On Wed, 10 Apr 2019, nusenu wrote: > Paul Hoffman wrote: >> Of likely interest to this group: >> https://wiki.mozilla.org/Security/DOH-resolver-policy > > I'm surprised they don't include DNSSEC in their requirements > for DoH server operators aiming to join their TRR program Same here, although one can argue DNSSEC is just core standard DNS so they do not need to mention it. Where as query minimalization is still fairly new. But especially because some people think DoH/DoT _replaces_ DNSSEC as security method, it would be good for mozilla to clarify this. Of course, that also opens them up to answering why they don't actively support things possible with DNSSEC, such as TLSA support :P Paul From nobody Wed Apr 10 13:50:31 2019 Return-Path: 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 A3E311205FF for ; Wed, 10 Apr 2019 13:50:29 -0700 (PDT) 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 3herrl-YXgrz for ; Wed, 10 Apr 2019 13:50:26 -0700 (PDT) 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 64CEA120114 for ; Wed, 10 Apr 2019 13:50:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BB41FBE47; Wed, 10 Apr 2019 21:50:22 +0100 (IST) 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 xmDilVW2JPMc; Wed, 10 Apr 2019 21:50:20 +0100 (IST) 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 69DB6BE39; Wed, 10 Apr 2019 21:50:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554929420; bh=f3aCPOxmxG5eCU68xWp3L/YPI0IkLkscSyyRxPaFISY=; h=To:References:From:Subject:Date:In-Reply-To:From; b=ELKfkuLF7utu8Pe2hvo7/nwrkJbLtJhR/mCP/7ctL8UEnAGFqJ8bpxJ3YgTqvry4A z90kt0E27aB6BEqJba/NXtEZlqSL6CL6akskYGLOGUcrP+yJsmalBW98CMmBQXlGHv XF15VR7boG21Ts/2QxXaQP/A51N0sTmR9asLQ/TU= To: Ray Bellis , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> 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: <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> Date: Wed, 10 Apr 2019 21:50:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qtDDPRKAIRQQOH5vW42wLq7hMZvA6EXGz" Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 20:50:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qtDDPRKAIRQQOH5vW42wLq7hMZvA6EXGz Content-Type: multipart/mixed; boundary="dglF9bI8Rc95qnqqQrRlwhoQ2pLlIR5Tw"; protected-headers="v1" From: Stephen Farrell To: Ray Bellis , add@ietf.org Message-ID: <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> In-Reply-To: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> --dglF9bI8Rc95qnqqQrRlwhoQ2pLlIR5Tw Content-Type: multipart/mixed; boundary="------------5262C6D4AB3C98FF10BEEE3C" Content-Language: en-GB This is a multi-part message in MIME format. --------------5262C6D4AB3C98FF10BEEE3C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ray, On 10/04/2019 17:47, Ray Bellis wrote: >=20 >=20 > On 08/04/2019 19:19, Barry Leiba wrote: >=20 >> For the longer term, the relevant ADs are discussing the right path. >> At the moment that looks like a BoF in Montreal (IETF 105) aimed at >> forming an =E2=80=9CADD=E2=80=9D working group, most likely in the ART= Area but with >> significant crossover expected and desired from Ops, Sec, Int, and >> probably the rest of the solar system IETF community.= >=20 > With respect Barry, I hope this does *not* happen in the ART Area. FWIW, I'd be neutral about whichever area lands up with some work so long as the right people stay involved and things are appropriately scoped. But you do have a bit of a point too, now that we better know how much this exercises folks mainly involved in the ops/int areas, the IESG really need to organise so that they stay engaged;-) > This whole mess started, IMHO, because some parties are treating the DN= S > as an application service, and not as part of the infrastructure and > network services. I don't think that's accurate. My take is that DNS privacy work started for perfectly valid privacy reasons and that DoT (while a fine thing) wasn't the right tool for some who need that better privacy... hence DoH. IMO it is a problem that an application can't ask-that/tell-if the OS uses DoT (or DoH), and have that work reliably enough on the various platforms on which typical applications run. Applications have similarly preferred foo/TLS to IPsec for some of the same reasons. > Traditionally, name resolution has always been a service that has been > configured by the network, and via the operating system, and often (but= > not always) name resolution would use the DNS. Right. But "tradition" isn't a good argument in itself:-) >=20 > While individual applications are free to open connections to port 53 t= o > perform DNS lookups, the vast majority do not, at least not within thei= r > own source code. >=20 > Sure, they call getaddrinfo() or perhaps even still gethostbyname() - > i.e. system-provided library calls that do end up linked into the > userspace application, but those still rely on nsswitch.conf and/or > resolv.conf and can access all those other naming systems that are *not= * > DNS.=C2=A0=C2=A0 [UNIX specific stuff just given as examples.=C2=A0 YOS= MV]. >=20 > For DoH-as-a-service to get universal acceptance it needs (IMHO) to get= > plugged into those operating system level APIs as Google have done with= > DoT in Android Pie.=C2=A0 If I want to use DoH it has to be a single se= tting > for the whole computer, and not set up separately in every application.= >=20 > By all means have an O/S level UI where the user can manually override > the network provided settings, in full knowledge that they may be in > violation of the local network's security policies. "May be in violation" seems to me a pretty partial way to look at things. There are many networks where there's no "violation" at all associated with any choice of recursive. > Having individual applications do that without the informed consent of > their users is over-reach, IMHO, whatever their lawyers write into thei= r > shrink-wrap licenses. Partly agree. I hate the license-crap the s/w business involves so agree with you there. OTOH, I disagree that informed consent is at all feasible here - we simply cannot expect a typical user to spend literally hours of work needed to really understand the issues here. And without understanding there can be no informed consent, except perhaps in some weasel-wordy manner. IOW, I think arguments about consent here are about as convincing as asking that people look up BGP information before allowing their packets be routed. Cheers, S. >=20 > regards, >=20 > Ray Bellis > ISC Research Fellow >=20 --------------5262C6D4AB3C98FF10BEEE3C 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5262C6D4AB3C98FF10BEEE3C-- --dglF9bI8Rc95qnqqQrRlwhoQ2pLlIR5Tw-- --qtDDPRKAIRQQOH5vW42wLq7hMZvA6EXGz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyuVwsACgkQWrL68XsX K+pHvA//boZBoTVlkzydJ6V9uLO1x8mFNkGRF0Uc/Y9H06CTK9ru3NqCjlU5qY1F UvXSW5T/2RZ7jH5qFhIa8zA2IGi31k/AQ1HyLT/AW5knlkZExaL6C1+xCkHehah2 5sXJ2jnU9+QZyTF8OHxbw6O5BJwtGJvZNbGZDcV4nh4OAbSAsrp8F9lI0ESdV2DY xmuZSIB9maGHKa0ftdkIGhcnf9KF728yDGBT/FkmPSp0BZ6z3JpaD3tSX65ynN7e vnQs3i0F2pjZV9sNBkILhBvilTTjR7IjqQaGI9M8oZUg0YhaWLXiGnwnOJ+XKJTe 8ti1I0d0QhSA7riGY8jxn9mX0PNvD4xnIqMytNzymWdYYgHZ93K7z908P8ejQdxm fz/gsLbfEMF5BaWwLKQnEiibbf9gxNjeWEje2X5k/GHJc5td13uWXD/9xVSePj66 3F815X01rbQIkfFbgD+0Hmyv28bbJPUuHN306lK31Ajg+0179RX/8NTz99hLjiNY 7c3DrxrZDwhWK0S6oodUMR9OJhBkwmkO1PYv/PTNsVm3EN3YnwmEiuzHs2N1HmAA UXzESouyXXgcMXmbwMEkbb7MaFrOeym2gByerN5xkax4W/W1nRJWctJgNaCsNT1m VCJdXLh4H5Qnsi0feFV3y13UpLO0o4vMCZOt3xIoIGVxktsqZrs= =xtwa -----END PGP SIGNATURE----- --qtDDPRKAIRQQOH5vW42wLq7hMZvA6EXGz-- From nobody Wed Apr 10 13:58:36 2019 Return-Path: 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 380AF120643 for ; Wed, 10 Apr 2019 13:58:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 uk_qvf_O6i_B for ; Wed, 10 Apr 2019 13:58:29 -0700 (PDT) Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 1C442120610 for ; Wed, 10 Apr 2019 13:58:29 -0700 (PDT) Received: by mail-wm1-x344.google.com with SMTP id w15so4061014wmc.3 for ; Wed, 10 Apr 2019 13:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=IcoYu//Fg6ZMDzyuUOutn/bTq/pLSvDfo5kcvw9tNj8=; b=Sy96csfiUF86BoPHaB+0uJieUO5MX+5rG52tnXORn/dblLb1+B+j66pi5cqjY+mYsP m7SZgvhmuYgyqPAeeKGp05S5I+bNg+gRnonVe7btD+aPjB15UFd6mk9M9xQ51yt0vgY8 kbIB6shDufBGWzWuvnmK3mVNdaScTzSH8RdQ0EFNiqFQux02CK7mCmirNXUSUZHMowL+ K6gRB0adt2bj0QGLG9uKCcP6LYdCDi8aOb3qZ3vFA4KKViS5qNujvZWn/Ui9bykZ1Sr+ dqqIM6Aki9S8YaYKMXPVsTjqdfO4D7NiQFG2izdYN1h9pxx9LOmn0qbZllWZoeC5Lz1k Lp0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=IcoYu//Fg6ZMDzyuUOutn/bTq/pLSvDfo5kcvw9tNj8=; b=oLK8nHl8AZ6rrc+HmPCVI2Bu4KrpENcCJY1q5nsCGhjo6aIiu6vksisHwj4TjOWGqQ iXCmySp5croy7l1eAIGWx+ZmaGIB4lhylWWkyk5GcYsArX1Wh7SgJ/upcFtujgwPbdOA W/ZrVXoXvwbaP/R8yCSmwH+J2kTsY0yuFeJ+C2r/7xwYbz53rn5HwUVisFF+XJ/zyX71 azbYxaPdYjrmSMOMVEk9DcqQ3jtafQKzzoPADM+HONFHr2eH/SuAwUM6TTfYrcYF6N1/ 0DnnCq7PG72vZguuoJ66ofFvRf6LaMR7bYKFKj+eAhJA4jgfAxJNyYiCMGkfngIObE/f u+sg== X-Gm-Message-State: APjAAAV2qKiugjCkVZgEU/Um27Y6+mVQ92Ep5FeCNAA0YGp07iZGQf2v A9pEufx0Ok/hiY6ADvw1IfeF5IxZ X-Google-Smtp-Source: APXvYqzs9GA4jbSN4VMVKtmMv6LrTvLEBhNx7uny10EhPTjQ0+Irry3819Nd7bi2w9dwQydg/aukkw== X-Received: by 2002:a05:600c:2189:: with SMTP id e9mr4200467wme.4.1554929907369; Wed, 10 Apr 2019 13:58:27 -0700 (PDT) Received: from ROADKILL.home (host86-181-254-92.range86-181.btcentralplus.com. [86.181.254.92]) by smtp.gmail.com with ESMTPSA id v6sm45904782wrt.56.2019.04.10.13.58.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 13:58:27 -0700 (PDT) To: Ray Bellis , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> From: Thomas Peterson Message-ID: <452dec9b-1222-4e75-07b8-b497547d0e30@gmail.com> Date: Wed, 10 Apr 2019 21:58:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 20:58:34 -0000 As we go up the networking layers in OSI from physical to application we go from most privileged components in a system from networking hardware, through to kernel drivers, the kernel, and finally into userland, and at layers 4/5 is usually the boundary between kernel and userland[0]. Putting a DoH client into kernel space changes that architecture quite significantly, and I am skeptical implementors like glibc for example would be up for this. Regards [0] Yes I am aware of userland Layer 3, or even userland network drivers. These too break this mold. On 10/04/2019 17:47, Ray Bellis wrote: > > > On 08/04/2019 19:19, Barry Leiba wrote: > >> For the longer term, the relevant ADs are discussing the right path. >> At the moment that looks like a BoF in Montreal (IETF 105) aimed at >> forming an “ADD” working group, most likely in the ART Area but with >> significant crossover expected and desired from Ops, Sec, Int, and >> probably the rest of the solar system IETF community. > > With respect Barry, I hope this does *not* happen in the ART Area. > > This whole mess started, IMHO, because some parties are treating the > DNS as an application service, and not as part of the infrastructure > and network services. > > Traditionally, name resolution has always been a service that has been > configured by the network, and via the operating system, and often > (but not always) name resolution would use the DNS. > > While individual applications are free to open connections to port 53 > to perform DNS lookups, the vast majority do not, at least not within > their own source code. > > Sure, they call getaddrinfo() or perhaps even still gethostbyname() - > i.e. system-provided library calls that do end up linked into the > userspace application, but those still rely on nsswitch.conf and/or > resolv.conf and can access all those other naming systems that are > *not* DNS.   [UNIX specific stuff just given as examples.  YOSMV]. > > For DoH-as-a-service to get universal acceptance it needs (IMHO) to > get plugged into those operating system level APIs as Google have done > with DoT in Android Pie.  If I want to use DoH it has to be a single > setting for the whole computer, and not set up separately in every > application. > > By all means have an O/S level UI where the user can manually override > the network provided settings, in full knowledge that they may be in > violation of the local network's security policies. > > Having individual applications do that without the informed consent of > their users is over-reach, IMHO, whatever their lawyers write into > their shrink-wrap licenses. > > regards, > > Ray Bellis > ISC Research Fellow > From nobody Wed Apr 10 14:01:57 2019 Return-Path: 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 974F1120341 for ; Wed, 10 Apr 2019 14:01:55 -0700 (PDT) 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=portfast.net 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 ENNDs4ro-TL4 for ; Wed, 10 Apr 2019 14:01:53 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 3C79F1202EE for ; Wed, 10 Apr 2019 14:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=jgRUKZ7PFjurGPlq/5Z5Q2ZMNRqlG2NEh5tR1pv8ibk=; b=OvWGB9rPv357nhOiSzXVGATpqX POUQqHlZVJo7pS4h3iWoF4sq+YR45mE4QtmmsHZKBA6bd8WNVH6aoroLhwtbixw0ffAgDxGaTUwNr 9P/99tG2kabU7Nq7VBwKIMFEDHhDSqCfgykKn2y13TTI9p6Pxy22H7WquLSLDkgdu3RI=; Received: from [88.212.170.147] (port=65426 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hEKLv-0004aB-9d (Exim 4.89) (return-path ); Wed, 10 Apr 2019 21:01:51 +0000 To: Thomas Peterson , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <452dec9b-1222-4e75-07b8-b497547d0e30@gmail.com> From: Ray Bellis Message-ID: Date: Wed, 10 Apr 2019 22:01:50 +0100 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: <452dec9b-1222-4e75-07b8-b497547d0e30@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 21:01:56 -0000 On 10/04/2019 21:58, Thomas Peterson wrote: > As we go up the networking layers in OSI from physical to application we > go from most privileged components in a system from networking hardware, > through to kernel drivers, the kernel, and finally into userland, and at > layers 4/5 is usually the boundary between kernel and userland[0]. > > Putting a DoH client into kernel space changes that architecture quite > significantly, and I am skeptical implementors like glibc for example > would be up for this. Nobody was talking about kernel space. Technically, most UNIX do actually perform their naming lookups from userspace, but they do it with O/S provided APIs that honour the network provided name servers, unless manually configured otherwise. Ray From nobody Wed Apr 10 15:29:56 2019 Return-Path: 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 2540212008B for ; Wed, 10 Apr 2019 15:29:55 -0700 (PDT) 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] 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 KGOqkYmL19OQ for ; Wed, 10 Apr 2019 15:29:53 -0700 (PDT) Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (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 7DF49120049 for ; Wed, 10 Apr 2019 15:29:53 -0700 (PDT) Received: from elwha.brokendns.net (elwha.brokendns.net [206.125.172.202]) by burnttofu.net (8.15.2/8.15.2) with ESMTPS id x3AMTehv008699 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 10 Apr 2019 18:29:42 -0400 (EDT) (envelope-from michael@brokendns.net) Received: from kimberton.burnttofu.net (unknown [IPv6:2604:5500:c2c2:fb00::7777]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id B26B06772D; Wed, 10 Apr 2019 15:29:42 -0700 (PDT) To: Stephen Farrell , Ray Bellis , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> From: Michael Sinatra Message-ID: Date: Wed, 10 Apr 2019 15:29:37 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.6.2 (burnttofu.net [162.217.113.18]); Wed, 10 Apr 2019 18:29:44 -0400 (EDT) Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 22:29:55 -0000 On 2019-04-10 13:50, Stephen Farrell wrote: >> This whole mess started, IMHO, because some parties are treating the DNS >> as an application service, and not as part of the infrastructure and >> network services. > > I don't think that's accurate. My take is that DNS privacy work > started for perfectly valid privacy reasons and that DoT (while > a fine thing) wasn't the right tool for some who need that better > privacy... hence DoH. I realize you realize that begs the following question... :-) What's "better" about the privacy afforded by DoH? If applications choose which DNS server to use without the informed consent of the user or in ways that obfuscate the DNS transaction and undermine the user's control, that potentially _erodes_ privacy. If DoH encourages network administrators in certain regulatory (imagined or real) domains to do inline TLS decryption, that potentially _erodes_ the user's privacy. IMO, this mess started for two reasons: First, DoH advocates internalized a particular definition of privacy and made the assumption that DoH maximized privacy according to that definition, within the constraints of a particular set of use-cases. Based on the debate in these forums, it doesn't feel like DoH advocates considered the full range of use-cases, and how different sets of users define "privacy." Second, applications developers like Mozilla made the assumption that their vetting of DNS providers was sufficient to justify announcing their intent to use said providers by default, rather than leaving that decision as a user opt-in. (And the announcement of intent was enough to create this mess, even if they didn't or won't follow-through.) It's perfectly reasonable to say that DoH improves certain aspects of privacy under certain use-cases. It's also reasonable to recognize, and appropriately disclaim, that there are use-cases and circumstances where DoH can undermine privacy. This is why I believe we need to continue work on draft-reid-doh-operator-00, draft-livingood-doh-implementation-risks-issues-03, and draft-bertola-bcp-doh-clients-00. >> Having individual applications do that without the informed consent of >> their users is over-reach, IMHO, whatever their lawyers write into their >> shrink-wrap licenses. > > Partly agree. I hate the license-crap the s/w business involves so > agree with you there. OTOH, I disagree that informed consent is at > all feasible here - we simply cannot expect a typical user to spend > literally hours of work needed to really understand the issues here. I think your definition of "typical user" is unduly narrow. Regardless, DoH doesn't absolve the user from understanding the issues at hand. It simply migrates the management of a component of the user's personal information from "network" to "application," potentially without informing the user or letting them opt-in. IMO the IETF can and should take a stand that this is not the desired BCP for DoH. > And without understanding there can be no informed consent, except > perhaps in some weasel-wordy manner. IOW, I think arguments about > consent here are about as convincing as asking that people look up > BGP information before allowing their packets be routed. I think your analogy is wide of the mark. The correct analogy would be having users select network providers on the basis of their privacy policies and their routing hygiene (prefix filtering, MANRS-compliance, origin-validation practices, etc.). You might say, "but not all users do that!" and you would certainly be right. But some do take those factors into consideration (or they ask knowledgeable folks to make informed recommendations) and they should be given the necessary information to make an informed decision. And the IETF *can* influence this through BCPs. michael From nobody Wed Apr 10 15:56:00 2019 Return-Path: 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 B44C1120647 for ; Wed, 10 Apr 2019 15:55:58 -0700 (PDT) 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 vz4xQyBp34bz for ; Wed, 10 Apr 2019 15:55:55 -0700 (PDT) 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 78E94120253 for ; Wed, 10 Apr 2019 15:55:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B066BE2F; Wed, 10 Apr 2019 23:55:52 +0100 (IST) 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 2oMq6hlcpERB; Wed, 10 Apr 2019 23:55:50 +0100 (IST) 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 3C9E4BE2E; Wed, 10 Apr 2019 23:55:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554936950; bh=Ljl8K9+V4XkDHzX7a1F4+vuKdO6A6RvFXWpHPuziKGU=; h=To:References:From:Subject:Date:In-Reply-To:From; b=NGkYCDxytV357p+V2kDGI+6hUXZejsZVTLrp82/I1BbGzGfNJJunqZ8OoS+uS4Ahg I5G82vJj5NFpH3rFa3lUwXw7uNJBzq3bs2+iVLK0GFgF0nuIGy+qjs45tsZnFtW9NU 3vlI914+pgVCUXDPssXGDJTzVXuRystr2jIWKxts= To: Michael Sinatra , Ray Bellis , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> 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: Wed, 10 Apr 2019 23:55:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Zt3qtDl4d03qTHpnHvuoMJbLCoXauc0WI" Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 22:55:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Zt3qtDl4d03qTHpnHvuoMJbLCoXauc0WI Content-Type: multipart/mixed; boundary="jTRZJhORmObBrAhAVYT6jROVpvW2RQ2cC"; protected-headers="v1" From: Stephen Farrell To: Michael Sinatra , Ray Bellis , add@ietf.org Message-ID: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> In-Reply-To: --jTRZJhORmObBrAhAVYT6jROVpvW2RQ2cC Content-Type: multipart/mixed; boundary="------------4747B6D8C3D31555669BBF0D" Content-Language: en-GB This is a multi-part message in MIME format. --------------4747B6D8C3D31555669BBF0D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 10/04/2019 23:29, Michael Sinatra wrote: >=20 >=20 > On 2019-04-10 13:50, Stephen Farrell wrote: >=20 >>> This whole mess started, IMHO, because some parties are treating the = DNS >>> as an application service, and not as part of the infrastructure and >>> network services. >> >> I don't think that's accurate. My take is that DNS privacy work >> started for perfectly valid privacy reasons and that DoT (while >> a fine thing) wasn't the right tool for some who need that better >> privacy... hence DoH. >=20 > I realize you realize that begs the following question... :-) >=20 > What's "better" about the privacy afforded by DoH?=20 Eh.. that was in the paragraph from which you quoted above... in the bit you didn't quote;-) Basically, if the application wants to know that DNS privacy is being applied, it has to do it itself. (There are other arguments, and I'm not a browser-maker so they may have other reasons they think more important.) > If applications > choose which DNS server to use without the informed consent of the user= I've already disputed the possibility of informed consent here. (And will do again below:-) > or in ways that obfuscate the DNS transaction and undermine the user's > control, that potentially _erodes_ privacy. If DoH encourages network > administrators in certain regulatory (imagined or real) domains to do > inline TLS decryption, that potentially _erodes_ the user's privacy. Yes, if people bugger about MitM'ing TLS, that harms us all. Every time we see an interesting uptick in use of TLS in any sphere, we see claims that we'll be overwhelmed by MitMs to defeat that and arguments that the putative potential fault for that lies with whomever is causing the uptick. The fact that that keeps happening seems to be evidence that uses of TLS between intended endpoints are not being overwhelmed in that way. That's a good thing IMO even if there are a few more MitM attack boxes deployed than previously when pretty much everything was in clear and utterly vulnerable. In the current discussion, if you do control the client endpoint, then manage that well and you'll have no need to bugger with TLS at all. If you do not control the endpoint (or are inept in doing so) then I'd be interested in how you propose to go about MitM'ing TLS. >=20 > IMO, this mess started for two reasons: >=20 > First, DoH advocates internalized=20 Your or my guesses as to who internalised what seem unlikely to be a useful part of the discussion. (You'll note I framed my explanation in terms of what's visible-to/controllable-by different bits of s/w running on a machine, and not in terms of people's motivations, which I think ought not be a topic for discussion here.) > a particular definition of privacy and > made the assumption that DoH maximized privacy according to that > definition, within the constraints of a particular set of use-cases. > Based on the debate in these forums, it doesn't feel like DoH advocates= > considered the full range of use-cases, and how different sets of users= > define "privacy." >=20 > Second, applications developers like Mozilla made the assumption that > their vetting of DNS providers was sufficient to justify announcing > their intent to use said providers by default, rather than leaving that= > decision as a user opt-in. (And the announcement of intent was enough > to create this mess, even if they didn't or won't follow-through.) >=20 > It's perfectly reasonable to say that DoH improves certain aspects of > privacy under certain use-cases. It's also reasonable to recognize, an= d > appropriately disclaim, that there are use-cases and circumstances wher= e > DoH can undermine privacy. This is why I believe we need to continue > work on draft-reid-doh-operator-00, > draft-livingood-doh-implementation-risks-issues-03, and > draft-bertola-bcp-doh-clients-00. >=20 >>> Having individual applications do that without the informed consent o= f >>> their users is over-reach, IMHO, whatever their lawyers write into th= eir >>> shrink-wrap licenses. >> >> Partly agree. I hate the license-crap the s/w business involves so >> agree with you there. OTOH, I disagree that informed consent is at >> all feasible here - we simply cannot expect a typical user to spend >> literally hours of work needed to really understand the issues here. >=20 > I think your definition of "typical user" is unduly narrow. Regardless= , > DoH doesn't absolve the user from understanding the issues at hand. It= > simply migrates the management of a component of the user's personal > information from "network" to "application," potentially without > informing the user or letting them opt-in. IMO the IETF can and should= > take a stand that this is not the desired BCP for DoH. >=20 >> And without understanding there can be no informed consent, except >> perhaps in some weasel-wordy manner. IOW, I think arguments about >> consent here are about as convincing as asking that people look up >> BGP information before allowing their packets be routed. >=20 > I think your analogy is wide of the mark.=20 My argument was not an analogy. To re-iterate: "without understanding there can be no informed consent" is the core of my argument on this part of the discussion. I'm quite happy to defend that proposition (which is not an analogy). Cheers, S > The correct analogy would be > having users select network providers on the basis of their privacy > policies and their routing hygiene (prefix filtering, MANRS-compliance,= > origin-validation practices, etc.). You might say, "but not all users > do that!" and you would certainly be right. But some do take those > factors into consideration (or they ask knowledgeable folks to make > informed recommendations) and they should be given the necessary > information to make an informed decision. And the IETF *can* influence= > this through BCPs. >=20 > michael >=20 --------------4747B6D8C3D31555669BBF0D 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------4747B6D8C3D31555669BBF0D-- --jTRZJhORmObBrAhAVYT6jROVpvW2RQ2cC-- --Zt3qtDl4d03qTHpnHvuoMJbLCoXauc0WI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyudHUACgkQWrL68XsX K+rlWg/9HwO5/Lgy/U69UgaVK1NEAhspSOu6OB1cUp9C3AuLKBgcfZb53+F+mQia AAjTV+ZD0ZqhpCx8JJURHM9ZC6wteKhWoeIkLihe5eBA8fJ3nslDsp4rh5RSumHL CW81ohQe3iAKfoe7NfdOrd+FJC3eOtf+S10YpgT/rEoLWvgcJ2NhLtQJJRkg1xEX oFBWhWnw0Odo4Jm9oFeoRG/Un7q2OwtvAe9Ok13y0nKLM4FzgrHBASEb63w1WcVc EKZIxBuYqj3hwkXQJ3egIyrapAPh6ApyMF/hbJ69XWA++jEwr/P0ka0BPmnRbwwe bEh7HeL1JR+6ZD0V+8VQbFGgQ8KGw6ZSHYNW/Wu8pb1Y/PoF0znvJ05piDCzWdRM k3KAYBFVvvzd4fMEDvixIOWxB4dsT9gvvKvDYoaiSDOBrk/M8mTevVaZhFLBiDFB Iu1L6wp1ew/P9lysmQbu18ujoPYBz+fC3eZzAxLJxiFhKarn2QbACOjCnh3ObLiV sHhPKFwDShzMx8g22rK8P3Hb5gdYA2NrodgKK4IF3XMAX0EH1mDtF5vgWeA8wNEr LEPPOkYuVjrp+0FgUUMy4VcahIRs/XhrpSEs/wLH/73kYd/RUXG5JpbUm8/6rqG9 mbKhwQ1RNv62C6GZgqiJMXTVoOIw7qEp9jWXFbqpQCntCyhsmog= =+DMM -----END PGP SIGNATURE----- --Zt3qtDl4d03qTHpnHvuoMJbLCoXauc0WI-- From nobody Wed Apr 10 16:51:57 2019 Return-Path: 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 637E41203B9 for ; Wed, 10 Apr 2019 16:51:56 -0700 (PDT) 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] 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 GGhrD9-NBjjo for ; Wed, 10 Apr 2019 16:51:54 -0700 (PDT) Received: from burnttofu.net (burnttofu.net [IPv6:2607:fc50:1:9d00::9977]) (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 03B9A1203AD for ; Wed, 10 Apr 2019 16:51:53 -0700 (PDT) Received: from elwha.brokendns.net (elwha.brokendns.net [IPv6:2607:f2f8:a544:0:0:0:0:2]) by burnttofu.net (8.15.2/8.15.2) with ESMTPS id x3ANpfuQ009034 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 10 Apr 2019 19:51:43 -0400 (EDT) (envelope-from michael@brokendns.net) Received: from kimberton.burnttofu.net (unknown [IPv6:2604:5500:c2c2:fb00::7777]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by elwha.brokendns.net (5.65c/IDA-1.4.4/5.63) with ESMTPSA id DD8AA6773B; Wed, 10 Apr 2019 16:51:43 -0700 (PDT) To: Stephen Farrell , Ray Bellis , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> From: Michael Sinatra Message-ID: <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> Date: Wed, 10 Apr 2019 16:51:38 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.6.2 (burnttofu.net [IPv6:2607:fc50:1:9d00:0:0:0:9977]); Wed, 10 Apr 2019 19:51:45 -0400 (EDT) Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 23:51:56 -0000 On 2019-04-10 15:55, Stephen Farrell wrote: > Eh.. that was in the paragraph from which you quoted above... in > the bit you didn't quote;-) Oh, I am sorry about that...(seriously) > Basically, if the application wants to know that DNS privacy > is being applied, it has to do it itself. (There are other > arguments, and I'm not a browser-maker so they may have other > reasons they think more important.) Okay, what I am about to say is going to sound sarcastic but it's not. The reason I didn't quote that text is it seemed like you were discussing application signaling and that seemed so distant from my definition of privacy that it didn't appear to be relevant. If you are saying that privacy == application knowledge of whether encrypted transport is being used, then that supports my point that DoH presupposes a particular definition of privacy and I would agree that DoH does improve privacy according to that definition. But there are other definitions. For example, a reasonable person may define privacy (or one aspect of it) as the number of external entities that have access to personal information. If an application uses DoH to choose some third party (say Cloudflare) to do DNS resolution instead of my local on-network DNS recursive server, then Cloudflare has access to my DNS queries, where, in the past they didn't. My ISP and application providers continue to have access to connection (netflow) data and HTTP(S) requests, which they did in the past. >> If applications >> choose which DNS server to use without the informed consent of the user > > I've already disputed the possibility of informed consent here. > (And will do again below:-) > >> or in ways that obfuscate the DNS transaction and undermine the user's >> control, that potentially _erodes_ privacy. If DoH encourages network >> administrators in certain regulatory (imagined or real) domains to do >> inline TLS decryption, that potentially _erodes_ the user's privacy. > > Yes, if people bugger about MitM'ing TLS, that harms us all. > > Every time we see an interesting uptick in use of TLS in any > sphere, we see claims that we'll be overwhelmed by MitMs to > defeat that and arguments that the putative potential fault > for that lies with whomever is causing the uptick. The fact > that that keeps happening seems to be evidence that uses of > TLS between intended endpoints are not being overwhelmed in > that way. That's a good thing IMO even if there are a few > more MitM attack boxes deployed than previously when pretty > much everything was in clear and utterly vulnerable. > > In the current discussion, if you do control the client endpoint, > then manage that well and you'll have no need to bugger with TLS > at all. If you do not control the endpoint (or are inept in > doing so) then I'd be interested in how you propose to go about > MitM'ing TLS. Totally agree, and that's one of the reasons I am a big supporter of TLS 1.3, in whose favor the same arguments were made. But I am uneasy about giving ammo to the other side. > Your or my guesses as to who internalised what seem unlikely to > be a useful part of the discussion. (You'll note I framed my > explanation in terms of what's visible-to/controllable-by different > bits of s/w running on a machine, and not in terms of people's > motivations, which I think ought not be a topic for discussion > here.) Totally disagree. If we can't be explicit about the motivations that drive efforts like DPRIVE and DoH, then we can't attempt to align those motivations with those of users (broadly defined), and we will continue to create solutions that are counter to how our users view privacy. >>> And without understanding there can be no informed consent, except >>> perhaps in some weasel-wordy manner. IOW, I think arguments about >>> consent here are about as convincing as asking that people look up >>> BGP information before allowing their packets be routed. >> >> I think your analogy is wide of the mark. > > My argument was not an analogy. You specifically stated that arguments in favor of informed consent can't be convincing and you gave an unsatisfactory analogy in support of that statement. > To re-iterate: > > "without understanding there can be no informed consent" > > is the core of my argument on this part of the discussion. The proposition is not an analogy, but the evidence you submitted in its support was. (Actually, the evidence you submitted was an analogy that attempted to contradict counter-arguments to your point, but whatever. I am not keeping score.) > I'm > quite happy to defend that proposition (which is not an analogy). Save it. I am not interested in having the IETF take the position that it's impossible for users to make informed technology choices and that therefore, said users should not be empowered to do so, and that instead, application developers should wield such power. michael From nobody Wed Apr 10 17:37:45 2019 Return-Path: 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 1C4DF120362 for ; Wed, 10 Apr 2019 17:37:43 -0700 (PDT) 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 AeiGtMQ_PAUB for ; Wed, 10 Apr 2019 17:37:40 -0700 (PDT) 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 B5B3A12011B for ; Wed, 10 Apr 2019 17:37:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0D644BE39; Thu, 11 Apr 2019 01:37:35 +0100 (IST) 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 jyURLti7TQgg; Thu, 11 Apr 2019 01:37:33 +0100 (IST) 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 69487BE2F; Thu, 11 Apr 2019 01:37:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554943053; bh=Ui35rh1khF0iGjTmnpBAN45pCMX9txMv5StNJ/3t7VE=; h=To:References:From:Subject:Date:In-Reply-To:From; b=svbBBCDi0rQmzp1EAoPkiAXSAUiVLs4aaeF/K9dA6G2FBlQMEgf+DpVviWHFCrtZO 4c6R6YULZ/xcY1jljzSYBV4Nd8SDkyX+wpk/+dLVkjg9Ero1aT0VIqVuBIsFfCsGrU wBjHTwRU/Pj63YwYNTgC+VXII0Ges6XfIAedt7/I= To: Michael Sinatra , Ray Bellis , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> 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: <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> Date: Thu, 11 Apr 2019 01:37:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QAwfcWsGGWmia9YIWgKrh7ieznlhTwX7j" Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 00:37:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QAwfcWsGGWmia9YIWgKrh7ieznlhTwX7j Content-Type: multipart/mixed; boundary="OcORZo4OIm4XkguTutV3ghpnhGQbkzzQv"; protected-headers="v1" From: Stephen Farrell To: Michael Sinatra , Ray Bellis , add@ietf.org Message-ID: <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> In-Reply-To: <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> --OcORZo4OIm4XkguTutV3ghpnhGQbkzzQv Content-Type: multipart/mixed; boundary="------------58FECC88D6D2C8FB49A82FE3" Content-Language: en-GB This is a multi-part message in MIME format. --------------58FECC88D6D2C8FB49A82FE3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 11/04/2019 00:51, Michael Sinatra wrote: > On 2019-04-10 15:55, Stephen Farrell wrote: >=20 >> Eh.. that was in the paragraph from which you quoted above... in >> the bit you didn't quote;-) >=20 > Oh, I am sorry about that...(seriously) No probs. >=20 >> Basically, if the application wants to know that DNS privacy >> is being applied, it has to do it itself. (There are other >> arguments, and I'm not a browser-maker so they may have other >> reasons they think more important.) >=20 > Okay, what I am about to say is going to sound sarcastic but it's not. > The reason I didn't quote that text is it seemed like you were > discussing application signaling and that seemed so distant from my > definition of privacy that it didn't appear to be relevant. If you are= > saying that privacy =3D=3D application knowledge of whether encrypted > transport is being used,=20 No, "=3D=3D" isn't correct. But "requires" gets close. IOW, an application (developer) can't really deal effectively with whatever good definition of DNS privacy they use, if there's a blood-brain barrier like sending cleartext to localhost:53 or calling getaddrinfo() on all of the platforms on which that application gets deployed. I would hope such an application developer would also then do qname minimisation, not send client-subnet (unless needed) etc, so just using TLS is not at all the definition of DNS privacy (for me at least). And I would also hope that that same application developer cares about more than just DNS privacy. As it happens, I think browsers do not do a good job on privacy as they've been far too fanatical about performance and market-share over the last decade+, but that doesn't mean that their efforts at DNS privacy are fake or worthless. > then that supports my point that DoH > presupposes a particular definition of privacy and I would agree that > DoH does improve privacy according to that definition. But there are > other definitions. For example, a reasonable person may define privacy= > (or one aspect of it) as the number of external entities that have > access to personal information.=20 Sure. I agree. And also that the concentration of lots (and lots and lots) of people's personal information in any one entity is pretty crap. And worse than crap when there are effectively only O(1) such entities on the Internet. There is however a technical challenge - privacy does require some hiding in the crowd, which seems call for centralising things some. Maybe we've yet to learn how to do that better or how to setup the right number of crowds in which to hide. > If an application uses DoH to choose > some third party (say Cloudflare) to do DNS resolution instead of my > local on-network DNS recursive server, then Cloudflare has access to my= > DNS queries, where, in the past they didn't. My ISP and application > providers continue to have access to connection (netflow) data and > HTTP(S) requests, which they did in the past. That argument ("the n/w provider still gets the stuff") seems to conflict with a bunch of other arguments from folks who claim to be unhappy with FF/CF's DoH-plans. (FWIW, I do think that, should arrangements like the FF/CF deal become common, then n/w operators would have access to less data. I also think that's ok.) >=20 >>> If applications >>> choose which DNS server to use without the informed consent of the us= er >> >> I've already disputed the possibility of informed consent here. >> (And will do again below:-) >> >>> or in ways that obfuscate the DNS transaction and undermine the user'= s >>> control, that potentially _erodes_ privacy. If DoH encourages networ= k >>> administrators in certain regulatory (imagined or real) domains to do= >>> inline TLS decryption, that potentially _erodes_ the user's privacy. >> >> Yes, if people bugger about MitM'ing TLS, that harms us all. >> >> Every time we see an interesting uptick in use of TLS in any >> sphere, we see claims that we'll be overwhelmed by MitMs to >> defeat that and arguments that the putative potential fault >> for that lies with whomever is causing the uptick. The fact >> that that keeps happening seems to be evidence that uses of >> TLS between intended endpoints are not being overwhelmed in >> that way. That's a good thing IMO even if there are a few >> more MitM attack boxes deployed than previously when pretty >> much everything was in clear and utterly vulnerable. >> >> In the current discussion, if you do control the client endpoint, >> then manage that well and you'll have no need to bugger with TLS >> at all. If you do not control the endpoint (or are inept in >> doing so) then I'd be interested in how you propose to go about >> MitM'ing TLS. >=20 > Totally agree, and that's one of the reasons I am a big supporter of TL= S > 1.3, in whose favor the same arguments were made. But I am uneasy abou= t > giving ammo to the other side. >=20 >> Your or my guesses as to who internalised what seem unlikely to >> be a useful part of the discussion. (You'll note I framed my >> explanation in terms of what's visible-to/controllable-by different >> bits of s/w running on a machine, and not in terms of people's >> motivations, which I think ought not be a topic for discussion >> here.) >=20 > Totally disagree. If we can't be explicit about the motivations that > drive efforts like DPRIVE and DoH, then we can't attempt to align those= > motivations with those of users (broadly defined), and we will continue= > to create solutions that are counter to how our users view privacy. Well, I can be explicit about my motivations. It'd be wrong for me to describe yours though. If we disagree about that, that's not the end of the world ('cause I already know what you're thinking:-). My experience though is that ascribing motives to other people in contentious email discussions tends to turn out somewhere between badly and really awful. >=20 >=20 >>>> And without understanding there can be no informed consent, except >>>> perhaps in some weasel-wordy manner. IOW, I think arguments about >>>> consent here are about as convincing as asking that people look up >>>> BGP information before allowing their packets be routed. >>> >>> I think your analogy is wide of the mark.=20 >> >> My argument was not an analogy. >=20 > You specifically stated that arguments in favor of informed consent > can't be convincing and you gave an unsatisfactory analogy in support o= f > that statement. Ah, fair enough. (Except of course that it was an excellent analogy to support my proposition:-) >=20 >> To re-iterate: >> >> "without understanding there can be no informed consent" >> >> is the core of my argument on this part of the discussion.=20 > The proposition is not an analogy, but the evidence you submitted in it= s > support was. (Actually, the evidence you submitted was an analogy that= > attempted to contradict counter-arguments to your point, but whatever. > I am not keeping score.) >=20 >> I'm >> quite happy to defend that proposition (which is not an analogy). >=20 > Save it. I am not interested in having the IETF take the position that= > it's impossible for users to make informed technology choices and that > therefore, said users should not be empowered to do so, and that > instead, application developers should wield such power. But that's not my argument. Informed consent is entirely possible, but the probability of it happening is miniscule. There is therefore no point in pretending that informed consent could ever be depended upon in this case. ISTM therefore that everyone calling for so-called consent (whether that be a ISP unhappy about the Moz/CF stuff, or a web-site and/or browser supposedly asking about cookies), *and* everyone saying that they already have so-called consent and therefore don't need to ask, (for whatever definition of those words have kept their lawyers happy) seems to be espousing a position that's somewhere between highly-mistaken and a bunch of self-serving lies. Cheers, S. >=20 > michael >=20 --------------58FECC88D6D2C8FB49A82FE3 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------58FECC88D6D2C8FB49A82FE3-- --OcORZo4OIm4XkguTutV3ghpnhGQbkzzQv-- --QAwfcWsGGWmia9YIWgKrh7ieznlhTwX7j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyujEsACgkQWrL68XsX K+qhIA//R7WJY9BGhbuV4mP+Any///H0Q2Mx1Gr8w+WCCd8fXFIC24oVJ60giKa/ 3XFXYXps6W2O3b7J+EA9XkDwxUEUX7sk6jEYWfQWofOpcZAwBr8WdDLh4iavGmEN zCrSE2gAou86V+tM96KyasSOe7QCj/ajHHmGk4UuclBWrQ2NSWUVThaOR1VsE8+O V3u0gofAa+eLDy0YE8Lpm1zz+NCnqTOqanIC2eUgO6udH3hfhu5QhCMEDupRjw1v Pry3lnWBhsht1/4bowNIfLvvOB6LmoyzyYOcIOZdyw/pRH3DsM6iS0/F7neK+PoX uOhRU4e9PER/DWzQMj/cb4p6HYDvwKs/piAd4tcx6HsCl3p/8JPvluNLpJJ1y6MW FQIdmxw6Brdv/wGTJVP4u+wejEhhK4Nb6kA1jDXqUYnt00xq7JmjQYYxRryeEswX 393Q0hjrX4KaCfr+kYPR4hugFHaFJ3C7eZLVcHCnD6FHiCIOgij36kB8UHAfPXuJ BY4uwkLon/aD5qluLazHXUjT8e8ldmwhTaUbF4VCLcxZA08oI/whrcv33YS5I3QW DqVksjs449XLCZJqjhaZEQQXMOSu7/ze6MwMsdmHC75CTabcWywebKhvlgMwkoI7 2dGGGS0IeT25o7GG7jX9vM2EUX9efWA4ce/uIfHlcvVQeSZythM= =UMQo -----END PGP SIGNATURE----- --QAwfcWsGGWmia9YIWgKrh7ieznlhTwX7j-- From nobody Wed Apr 10 17:54:01 2019 Return-Path: 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 1DCAC120125 for ; Wed, 10 Apr 2019 17:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 hTLjvvkL7g3D for ; Wed, 10 Apr 2019 17:53:56 -0700 (PDT) Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 7F6F112043D for ; Wed, 10 Apr 2019 17:53:56 -0700 (PDT) Received: by mail-it1-x141.google.com with SMTP id q14so6846297itk.0 for ; Wed, 10 Apr 2019 17:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iSM6TuiyKvY9XgKt705TBwOqyWGVh3BuKJspKNrkRX4=; b=Znr3eFqGmXUNNFdaWToO31fj7aRPJX4zi3n7hpttF83OL7fCXJGRRCyDD187UlM90b tAfyQMWt/NR4Km6AYQm+C0qTSa0tnZSliUgSXXOxRYMGDnzLNUJsDALKj7oHHsErec+C 8fl9dMaJvaovKenz3X7zx2DOCCFIyAEUa5fi7zDwkMRpn8GjlS7opH/giOfyiwpmu+A/ 5K7006B4MAp9+eb/Bn5pD1UdIm/H9csvKWqnq6EAnQXJBiXY7eoW+hYfA4+n95qVU8pQ ASrCthbalhDfqkr+YRZcvvpov6skOFvNxxX7Iiw0HX8QwsWaVeA+uGiyXFauqVasADkl ir0g== 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=iSM6TuiyKvY9XgKt705TBwOqyWGVh3BuKJspKNrkRX4=; b=IpL10LAaWhwHxj6eddIsgb9p5QjXigFlmADJd5CHPIgvvgv7vBbRUmURqZQzdL79k6 4tiGIPd3Pgh/a0M4F6U08r812ZFAulhtMDjwEbVeSA7yCuLpUKaR8psA0P1xUea92FBl Ag9oEKXzAYCl2iO57OqsxwtRLrKybq26e+vH4ZZ/JDFsypwFudNPYhWPVcKxqim0fkRD AWspJ+rsOU72MotOyFhUsmAjRxjG177WWp8C2tUHVpIBjnq2lAoIF9agTRkjRyXBfAVG no5Q4FcD5aswSWWrFvR9zzLTfK7wfBX8a1ZPgRyS8Y1uXcV+iGDm6WhuxR+v1rTtEIr/ krEQ== X-Gm-Message-State: APjAAAXs05PrnUQ2fZ5U5IVjvlhZeHrGnefpvWf4l6vrb5KvPbkug2Uo OztxVhPef4hqNMeSQ1KFGuDRXQtbe/Q9DHjGMXCTgSdTpOE= X-Google-Smtp-Source: APXvYqz0WGjpydOTnPS23yftV838KenFVeNXGHWk0XW+rx/qK/vtGFhoZKprwfqFCY8bRU1hJGvZCi3GFkxw4TWd/tI= X-Received: by 2002:a24:ed4d:: with SMTP id r74mr6166164ith.79.1554944035806; Wed, 10 Apr 2019 17:53:55 -0700 (PDT) MIME-Version: 1.0 References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> In-Reply-To: <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> From: George Michaelson Date: Thu, 11 Apr 2019 10:53:44 +1000 Message-ID: To: Stephen Farrell Cc: Michael Sinatra , Ray Bellis , add@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 00:54:00 -0000 it's probably naieve of me, but I did mentally segment my thoughts abouy DoH (and DoT and DoC and ...) into two parts. 1) the characterization of on-the-wire or in-protocol encoding and structural forms 2) the other stuff, including whats baked into a browser and whats under user control. I feel 1) is easier, but also crucial because without it, we face developers writing their own lightweight JS to encode a HOSTS.TXT model of reference by name to IP addressed objects. I am led to believe this is going to happen anyway and maybe this is a moment which has passed (or passes to other hands) because its unstoppable. 2) is where the meat in the sandwich is. I had not understood the distinct tensions (tussles?) here between regulatory oversight, centralization and actual user desire. I dislike the aspect of this problem that presents as an operators "not on my network" view but I now understand it has distinct flavours: People who have obligations in law, need to understand how technology affects their obligations in law. I would be very upset if DoH emerged as a system I cannot (as the user behind the keyboard) control. If it emerges as a "never you mind about that" technology, I'd be very upset and I think a lot of users would be very upset. I don't see a reason to mis-characterize actors (CF) in this, so a single entity standing up a service which people CAN code to, is quite different to things being baked into code in a browser. I should stress i doubt very much any browser doing DoH would or could bake it in, without exposing user controls. I would like to continue to think we're realistic about our limits to affect the system overall. It would surprise me if Microsoft (for instance) did not intend coding things stand-alone, or Google, or Firefox, or Opera. I don't sense the people who might code to this are yet converged into a standards-baking room. Maybe I am wrong there too? PS if anyone feels objectified by how I "spoke" in prior mails or at a microphone, I apologize un-reservedly. -G From nobody Wed Apr 10 18:05:49 2019 Return-Path: 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 F260B120460 for ; Wed, 10 Apr 2019 18:05:47 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 b-ftfmvfjhZb for ; Wed, 10 Apr 2019 18:05:46 -0700 (PDT) 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 0C0FD120125 for ; Wed, 10 Apr 2019 18:05:46 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id b74so2462500qkg.9 for ; Wed, 10 Apr 2019 18:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=U56cOKa48iKRymJJODX5C0lPbi5JQwak+AJbPRufWZE=; b=CaAJoHXzKxT9uEJ8QVd6PLSAOzWY/ZPm+o1x1touw4WiNZqgusc8cHSH3gVApR+IdT qFjwcR2rZLgoekNIBCq1YJW5bV28Onei2tQehoCOCbGD/QHz66mUjEQs1ZqVK0iTXEsM QCoPDk+VuT2Aaqa0NLFA+R7OTW02WgkeBFbbVMRw0HcfYAIC2QtpRYbE1Mg3RtKcqiVd 1F43FihSKNvxzdRWVvB8ZZ4/lzdr2HhZr+zuxyQZETYgLJ5CyTs6RIFxwx0Zxw29YDQE Fd2mVfKB1RU52mU/ZgvGawE1hr3TVTS375B2ONKhQk3j7b464WVM0wHNz93jHkRDRlmr pKlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U56cOKa48iKRymJJODX5C0lPbi5JQwak+AJbPRufWZE=; b=sOaGS+miRf+hz0h5QQg4NAkikIPVL5MJuAFYAZp2+V5IjS6UlQZkw+gHHYucMrYJTR 30XjCbZFRZMPVHFcVn3jd2WoWKkwX4972W4VYE9vCsXl1Hg2gh5zA1ageuRlbfHQSQe1 f8g590HOkl82iZkFHbLbs6chOZiKdQScrG1hpfMkVqYBem7kCKyFDQi6Gy8OiVkqpn4s KzEAzoI7/2g0paRu7maghVQHzkGR++BMVQ73H0lzPBijs9qBsTJ0ZuIVHV6167WISeOK GHLSXFZaxG4Hdu6V7etuqpEY7AyYb0ptehpsg0rkyBbqNMNKGrRiY1qXqMIw9Ltyq8Jl bAVQ== X-Gm-Message-State: APjAAAXmwRTI6ux9r+RvKrFSbE4b4v2mAWDa7ORNfvONR+mS5frrEmDZ XM3ZTkORKR/5K7xdjQnJcPf1cxnOpCqFAyu145NJKeWb X-Google-Smtp-Source: APXvYqzitfg8xrelNs/XLytpaSuJSQfFZVayp5QyyBWtwerZArEblI78tSZeXHj44NFwYpG+HroI7auGaNS2ROt3Z1s= X-Received: by 2002:a37:a650:: with SMTP id p77mr36493685qke.256.1554944744470; Wed, 10 Apr 2019 18:05:44 -0700 (PDT) MIME-Version: 1.0 From: Brian Dickson Date: Wed, 10 Apr 2019 18:05:32 -0700 Message-ID: To: add@ietf.org Content-Type: multipart/alternative; boundary="00000000000023bdd7058636c91d" Archived-At: Subject: [Add] Functional requirements? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 01:05:48 -0000 --00000000000023bdd7058636c91d Content-Type: text/plain; charset="UTF-8" Some of the discussions have shed some light on the underlying issues. I think it would be helpful to ferret out the actual (functional) requirements as articulated by various parties, or on behalf of those not currently in the conversation per se (users, host administrators, network administrators, security folks). Getting to the bottom of these, and separating the "what" (goal) from the "how" (mechanisms, protocols, whatever), can hopefully create enough flexibility to start finding solutions that meet the functional requirements, without requiring actual compromise on what those requirements are. I'd like to propose specific functional requirement for refinement, and once refined, to get feedback from folks on how they view those requirements. Since there will no doubt be opinions, I suggest ways of making the assessments of those requirements both concrete, and expressive. I'm thinking that a numeric score would be useful, where a negative value means "opposes", a positive value means "supports", a zero means "don't care", and the size of the positive/negative expresses how strongly the position is held. There's not much point in having a lot of fine-grained values; orders of magnitude are called for. I suggest values "1", "100", "10000", and "100,000,000" (i.e. 1e0, 1e2, 1e4, and 1e8), where the largest value is basically, "You realize, of course, this means war." I'll go first, with what I perceive as examples of actual functional requirements: 1. "The application needs to know that the DNS query is encrypted to the DNS resolver". 2. "The application need to know the identity of the DNS resolver used." 3. "The machine administrator needs to provide (i.e. restrict) the choice (or choices) of DNS resolver." 4. "The machine administrator and/or network administrator need to provide the choice (or choices) of encrypted transport." 5. "Each application/user combination, should be free to select the choice of DNS resolver and encrypted transport, from among those offered/available on the host OS." 6. "The encryption used should be a minimum of TLS1.3." 7. "The host OS should be the sole intermediary for establishing DNS resolver connections, and the applications should only do DNS resolutions by way of such an intermediary." 8. "The host OS intermediary should not have access to the unencrypted DNS queries." 9. "The host OS intermediary or the application, should validate server TLS certificates before using any given TLS connection." 10. "Policies may be imposed on the host administrator regarding allowed options for encrypted transport. The host administrator may enforce those policies." And now I'll provide an example of why it is necessary to tease out the real functional requirements. SF has previously stated, "Basically, if the application wants to know that DNS privacy is being applied, it has to do it itself." I hold this to be not technically true. So long as the application does the TLS key exchange, it can do so cooperatively with some other application controlling things like the establishing the TCP connection (including resolving the IP address of the named endpoint), and pre-validating the offered server TLS certificate. I'm not intentionally picking on SF here. I am using this one example to illustrate that there is value in everyone examining their own positions, and being as precise as possible without over-simplifying or overstating the actual requirements. I agree with Ray, that having things continue to operate in a centralized manner is highly preferable (and I stated so before.) However, I think that as long as we can all come to agreement on what the real (functional) requirements are, we can pave the way for multiple implementations of the central function, rather than restricting it to what the libc maintainers are willing to agree to. The end result should be, IMHO, analogous to the UI interaction of, "Foo is not your default DNS resolver proxy; would you like to change it?", much like it is/was with the choice of default browser. And the applications who want DNS privacy should be able to interoperate with any such implementation, i.e. the specifications should enable interoperability. Let's start with the requirements, and see how far we can get? Brian --00000000000023bdd7058636c91d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some of the discussions have shed some light on the underl= ying issues.

I think it would be helpful to ferret out t= he actual (functional) requirements as articulated by various parties, or o= n behalf of those not currently in the conversation per se (users, host adm= inistrators, network administrators, security folks).

<= div>Getting to the bottom of these, and separating the "what" (go= al) from the "how" (mechanisms, protocols, whatever), can hopeful= ly create enough flexibility to start finding solutions that meet the funct= ional requirements, without requiring actual compromise on what those requi= rements are.

I'd like to propose specific func= tional requirement for refinement, and once refined, to get feedback from f= olks on how they view those requirements.

Since th= ere will no doubt be opinions, I suggest ways of making the assessments of = those requirements both concrete, and expressive.

= I'm thinking that a numeric score would be useful, where a negative val= ue means "opposes", a positive value means "supports", = a zero means "don't care", and the size of the positive/negat= ive expresses how strongly the position is held. There's not much point= in having a lot of fine-grained values; orders of magnitude are called for= . I suggest values "1", "100", "10000", and &= quot;100,000,000" (i.e. 1e0, 1e2, 1e4, and 1e8), where the largest val= ue is basically, "You realize, of course, this means war."
<= div>
I'll go first, with what I perceive as examples of a= ctual functional requirements:

  1. "The a= pplication needs to know that the DNS query is encrypted to the DNS resolve= r".
  2. "The application need to know the identity of the DNS= resolver used."
  3. "The machine administrator needs to prov= ide (i.e. restrict) the choice (or choices) of DNS resolver."
  4. = "The machine administrator and/or network administrator need to provid= e the choice (or choices) of encrypted transport."
  5. "Each = application/user combination, should be free to select the choice of DNS re= solver and encrypted transport, from among those offered/available on the h= ost OS."
  6. "The encryption used should be a minimum of TLS1= .3."
  7. "The host OS should be the sole intermediary for est= ablishing DNS resolver connections, and the applications should only do DNS= resolutions by way of such an intermediary."
  8. "The host O= S intermediary should not have access to the unencrypted DNS queries."=
  9. "The host OS intermediary or the application, should validate= server TLS certificates before using any given TLS connection."
    10. <= li>"Policies may be imposed on the host administrator regarding allowe= d options for encrypted transport. The host administrator may enforce those= policies."
And now I'll provide an example of= why it is necessary to tease out the real functional requirements.

SF has previously stated, "Basically, if the applica= tion wants to know that DNS privacy
is being applied, it has to do it = itself."
=C2=A0
I hold this to be not technically true. = So long as the application does the TLS key exchange, it can do so cooperat= ively with some other application controlling things like the establishing = the TCP connection (including resolving the IP address of the named endpoin= t), and pre-validating the offered server TLS certificate.

I'm not intentionally picking on SF here. I am using this one ex= ample to illustrate that there is value in everyone examining their own pos= itions, and being as precise as possible without over-simplifying or overst= ating the actual requirements.

I agree with Ray, t= hat having things continue to operate in a centralized manner is highly pre= ferable (and I stated so before.) However, I think that as long as we can a= ll come to agreement on what the real (functional) requirements are, we can= pave the way for multiple implementations of the central function, rather = than restricting it to what the libc maintainers are willing to agree to.

The end result should be, IMHO, analogous to the UI= interaction of, "Foo is not your default DNS resolver proxy; would yo= u like to change it?", much like it is/was with the choice of default = browser. And the applications who want DNS privacy should be able to intero= perate with any such implementation, i.e. the specifications should enable = interoperability.

Let's start with the require= ments, and see how far we can get?

Brian

--00000000000023bdd7058636c91d-- From nobody Wed Apr 10 20:12:06 2019 Return-Path: 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 E83431201AC for ; Wed, 10 Apr 2019 20:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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=CJLy6ABz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rLz55eDu 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 Bo4ipMZUevRb for ; Wed, 10 Apr 2019 20:12:04 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502841201A9 for ; Wed, 10 Apr 2019 20:12:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7CD0F2129D for ; Wed, 10 Apr 2019 23:12:03 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 10 Apr 2019 23:12:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=d8+X9/i/k4/RAqECeLsCE1wbLGHljIo X3ZnLAWX0jL8=; b=CJLy6ABz7JxbE+/6KlgRRdJXhvtYqiPQqwUl5BovPp45mcU khB1oxm1fOFjczss/z/cvYFf+risaj0Xm0PNUzmjIebbxxINkRkTJAfGPULPCgeB 40k7Ttzm83SRDPK1JO5vMgG/YWAeZ1p+UFx0QcSDRMFOilmDFogE/KFC7oWNUVWL Z/+ni5W4DHFPu+6KuuEQpe1WsHFAwKV0swUaHYmu2TUXMndoaMZin/33KocrGN08 dnanal5tXP3yMSztXllo/6F8z+/JlaaFzHhILNw602ftuuL4+nbxdnNVVv6pcaSa ffJive0A4ZNY2LgTwaXEnbMYkS3EIRfTmdeXCaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=d8+X9/ i/k4/RAqECeLsCE1wbLGHljIoX3ZnLAWX0jL8=; b=rLz55eDuoYgXFJXz/WKvfQ W2VIvsL8ynh6odFmevvKTPS1ZEwwgdyLOCrnBf9U24hypu0Crr68vGgZGnhrFCu8 PY9wIEU76TF2luOBRkHUOm2pDIj4j40+0ZV7nNdiYu7X95/pkpm8KTDidMF/ofri 2dsCBF3Wewm0E1/9w3BzwihNTReI1rBmPgcgkGE6JuTu8WSu6yJ229jp2hSmvz3r JTCqZYogCfaYgfAY4SMqVq2i+7CagM8P7K7EB4UavwuKJf3rMJvpaQqLJIGQ2Pvw ryWgkWlnYVPZQxUTHycIJXyLsJo3du1nJ0p0tPsJ4is9jH4O8c7GpQ1oOGhFvPlA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudekgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehmohiiihhllhgrrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3804B7C130; Wed, 10 Apr 2019 23:12:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> Date: Wed, 10 Apr 2019 23:12:06 -0400 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 03:12:06 -0000 On Thu, Apr 11, 2019, at 03:27, Paul Wouters wrote: > On Wed, 10 Apr 2019, nusenu wrote: > > > Paul Hoffman wrote: > >> Of likely interest to this group: > >> https://wiki.mozilla.org/Security/DOH-resolver-policy > > > > I'm surprised they don't include DNSSEC in their requirements > > for DoH server operators aiming to join their TRR program > > Same here, although one can argue DNSSEC is just core standard DNS so > they do not need to mention it. Where as query minimalization is still > fairly new. We don't believe that DNSSEC is essential to our primary goals, which are improving privacy of browsing activity. As a browser, we can't condition our behaviour on whether DNSSEC was present and valid for a variety of reasons (some of which we might discuss separately), but we do value resolvers that perform DNSSEC validation. Requiring query minimization is in keeping with the privacy goal, whereas DNSSEC requirements would expand the scope more than we were comfortable with. From nobody Wed Apr 10 23:47:13 2019 Return-Path: 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 6256A120268 for ; Wed, 10 Apr 2019 23:47:10 -0700 (PDT) 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 7z1V5ucCmUAS for ; Wed, 10 Apr 2019 23:47:07 -0700 (PDT) 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 64DCA120269 for ; Wed, 10 Apr 2019 23:47:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8E924BE47; Thu, 11 Apr 2019 07:47:03 +0100 (IST) 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 AAghpmPGmXJI; Thu, 11 Apr 2019 07:47:02 +0100 (IST) 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 DD8C4BE2F; Thu, 11 Apr 2019 07:47:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554965222; bh=k2lfukzJazkcNnh6dkNR+IUzxbEzcJGQfwI/EwB0uWQ=; h=To:References:From:Subject:Date:In-Reply-To:From; b=hLV6Jh6AHHG1UWFeIpzlj5unsH906VqpTa1Hb02geBu96W4Nymcxu4Ln9w7HB9oRi 0GJjN1zfJT8SzNya4UP7kYB6mKduts5eSIF1WmXf+jPsz5xOLCfkeuWhzoVqOX6D1y Q/Gp3Jxo1mcJh/bilBiYudbZf3LtpiMH3Uxu26tU= To: Brian Dickson , add@ietf.org References: 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: Thu, 11 Apr 2019 07:47:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8l9JlU2GyjiniNNW5ElxnfeLOS96Vo1Kq" Archived-At: Subject: Re: [Add] Functional requirements? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 06:47:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8l9JlU2GyjiniNNW5ElxnfeLOS96Vo1Kq Content-Type: multipart/mixed; boundary="crTntKHlMAyChnJpgghPcW3SO0udyQsl0"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson , add@ietf.org Message-ID: Subject: Re: [Add] Functional requirements? References: In-Reply-To: --crTntKHlMAyChnJpgghPcW3SO0udyQsl0 Content-Type: multipart/mixed; boundary="------------71A5FD337141A23EBA2578B6" Content-Language: en-GB This is a multi-part message in MIME format. --------------71A5FD337141A23EBA2578B6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Not sure about the idea of scoring requirements. Could be a good one or not - I'll need to ponder it. Just on this bit... On 11/04/2019 02:05, Brian Dickson wrote: > SF has previously stated, "Basically, if the application wants to know = that > DNS privacy > is being applied, it has to do it itself." >=20 > I hold this to be not technically true. So long as the application does= the > TLS key exchange, it can do so cooperatively with some other applicatio= n > controlling things like the establishing the TCP connection (including > resolving the IP address of the named endpoint), and pre-validating the= > offered server TLS certificate. It would be possible yes to have TLS run via some TCP proxy Hard to see the point though. It is not possible for such a TCP proxy to see the TLS server cert with TLS1.3 unless that TCP proxy is a TLS MitM attacker, in which case someone has to have configured the application and the TCP proxy is unnecessary in the first place, for the enforcement of admin policy. With TLS1.3 such a TCP proxy can still apply it's policy based on the SNI in the ClientHello. That may however also go away with ESNI (it'll not be clear how widely that can be deployed for maybe a year or so, but I'd hope the answer is "widely"; there'd also be a bootstrap issue to tackle with using ESNI whilst contacting your fav DNS recursive but that may be solveable.). With TLS1.2 sure, such a TCP proxy could check the SNI or the server certificate. (Earlier TLS versions are in the process of being deprecated so we don't need to worry about 'em, but they're the same as TLS1.2 in this respect.) However, I don't see what'd motivate an application developer to use such a weird TLS stack, nor do I think it'd be likely that that weird stack would work everywhere, meaning that the application developer would also need a normal TLS stack. I'd guess in such a situation application developers would just not bother with the weird TLS stack at all. So I don't think that scenario is likely enough to warrant much study TBH. >=20 > I'm not intentionally picking on SF here.=20 I don't feel picked on at all! You and anyone should feel entirely free to pick holes in whatever silliness I emit. (I am however assuming I'm the SF you mean, be embarrassing if I' wrong there:-) Cheers, S. --------------71A5FD337141A23EBA2578B6 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------71A5FD337141A23EBA2578B6-- --crTntKHlMAyChnJpgghPcW3SO0udyQsl0-- --8l9JlU2GyjiniNNW5ElxnfeLOS96Vo1Kq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyu4uQACgkQWrL68XsX K+qGohAAiZLkS9rufPO7DEDwxAoolNFDvsEDGIRHQ61RDXvjUWc1AIAidFIMCS3g aSH0w/44s7cZRvkwasaMoWQwAzRizlUOE2qRG26ksxl1gy+Zsummf8Bam+J03Ira mVC5i2/ajYcSLzj+9hAQoKAFQmo+Zi1rjsD4Q+PSQNTPoDGh5rk0f/2DEAQstcWi jsRBs5jiLzd/nXECMONIgs1ce6pK5xHmRyFSFYcuUukRMwXcWGjituQeqvuIBDCp TGoAelsJskKiMeygn4ijOt9OdlenZDQk/14Aj0i9Y+Gcov85XbfizM6OZxdU77ZN j+75kWYPnpIXdEm65ByWV/mU1PIzZVMaF1WPVZdRuLdtMbvbLbb5V9JMtarPiXI+ dhDshZTX+FcHO+TFtB3zbSwf2TvTyI6VZ/of8HZWhRbat+0KCdJYWg2hKg49M1mT dPDN+3V4zorBiXmNwQz89bT1ru/jKreGjyk7ZnvvzHWbyM/nPShwhqKI30wij4S8 Of/jxpQ5x1HodEHXROd9Bphasx4V6N/Wxq8I1yOA34ecqf1y7Mk9hKDEizERrsNH n25aiSdVtqB4Bzjw0g2B9QZEDhl0yW2WTfb+UCn+N5TJ4Yr+cm85dOT0J9inTrQr 4HBFoe84cfdzF2rvKHrKHtblxclKFLAducTAT4vbKekbqWxoolA= =geUv -----END PGP SIGNATURE----- --8l9JlU2GyjiniNNW5ElxnfeLOS96Vo1Kq-- From nobody Thu Apr 11 01:53:56 2019 Return-Path: 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 099FE120661 for ; Thu, 11 Apr 2019 01:53:46 -0700 (PDT) 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 SeOEkzqsWGmy for ; Thu, 11 Apr 2019 01:53:43 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 933BE1204C3 for ; Thu, 11 Apr 2019 01:53:42 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 7DEAD5F40B77; Thu, 11 Apr 2019 10:53:41 +0200 (CEST) Received: from [172.19.152.251] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 8DAEB5F40066; Thu, 11 Apr 2019 10:53:40 +0200 (CEST) From: "Ralf Weber" To: "Stephen Farrell" Cc: "Michael Sinatra" , "Ray Bellis" , add@ietf.org Date: Thu, 11 Apr 2019 10:53:39 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> In-Reply-To: References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 08:53:50 -0000 Moin! On 11 Apr 2019, at 0:55, Stephen Farrell wrote: > Basically, if the application wants to know that DNS privacy > is being applied, it has to do it itself. (There are other > arguments, and I'm not a browser-maker so they may have other > reasons they think more important.) There is nothing in DoT that prevents you from doing that, so it’s clearly not the reason why DoH was done. As others said if the goal was to hide in normal traffic that is exactly what malware does, and this is what created a big problem for a lot of people trying to stop malware. So long -Ralf —-- Ralf Weber From nobody Thu Apr 11 01:59:40 2019 Return-Path: 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 41FAB12013E for ; Thu, 11 Apr 2019 01:59:39 -0700 (PDT) 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 obAEH1G09rk9 for ; Thu, 11 Apr 2019 01:59:38 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8FD1200FC for ; Thu, 11 Apr 2019 01:59:38 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 0595A5F40A42; Thu, 11 Apr 2019 10:59:36 +0200 (CEST) Received: from [172.19.152.251] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 6B8195F40043; Thu, 11 Apr 2019 10:59:36 +0200 (CEST) From: "Ralf Weber" To: "Martin Thomson" Cc: add@ietf.org Date: Thu, 11 Apr 2019 10:59:35 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> In-Reply-To: <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 08:59:39 -0000 Moin! On 11 Apr 2019, at 5:12, Martin Thomson wrote: > We don't believe that DNSSEC is essential to our primary goals, which > are improving privacy of browsing activity. As a browser, we can't > condition our behaviour on whether DNSSEC was present and valid for a > variety of reasons (some of which we might discuss separately), but we > do value resolvers that perform DNSSEC validation. So why not make DNSSEC validation in the resolver a requirement? It doesn’t interfere with local policy and offers significant benefits for the user. Validation in the client would be nicer, but requiring it in the resolver is a good first step. So long -Ralf —-- Ralf Weber From nobody Thu Apr 11 02:04:46 2019 Return-Path: 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 75CD4120149 for ; Thu, 11 Apr 2019 02:04:45 -0700 (PDT) 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 eRvY895frdMN for ; Thu, 11 Apr 2019 02:04:43 -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 5E3CB1200FC for ; Thu, 11 Apr 2019 02:04:43 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id x3so4673238iol.10 for ; Thu, 11 Apr 2019 02:04:43 -0700 (PDT) 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=ZaEQe6sMwhuAqimKvI44HHeNTVQJELN8qxpHTMtL++Y=; b=HPIo/KLqXHc0CrTFHM/Gje1AC75r1Z1st1+vu36tCCKDC6Dqjd9Puo63c0MpLUoSvf 5bR2soGmCnBZrTu0CWfSWM5S2osjWgDR4h001SkmytWKWEG6OWVZ5WYn6F1ew+ElCvsD Ba2s6/EkE5EpZuD8EvRaSE32h3nMEky9jb6qvmD97pcriFaWENdD8iEaBq8Cv6oOF6x+ dG8bQkHVnuiBgzdgdc5cxi1feyTff6vf9Rx0oRuQkFfdNAnUEa86P1huPBl+ovj+A1wG N2BTk/CXS3MiEcU3TAj6Ud205rB4v+F1MvJD1B1bRjIMeowXnhZ81Zg3bHbIxMg5gftW tFrw== 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=ZaEQe6sMwhuAqimKvI44HHeNTVQJELN8qxpHTMtL++Y=; b=Zhi6clNkeBvyTtnOAF/brPOJbdRXSjhTdQ8des81I4xpsiKk4S/qS767Mpv6f7ILZ0 axvIPEY2LhsDmo2+AKaXDQpi3X1SeH8FCEFeezbe8/Q2/nSRJxPVptVLxQywPs9sWcFq m7CpSH0PxcggsLh5o+spicse4c0A8SivX/xUZ4C26nOC2G6IMF5eRrzlYchYEDooGVc7 SHzuJMfbC5mKokmdKQOq8rWFz0PoiyjJzbublHPy/E6/iTZvAP3OE4ZnHEh/KGP/aDOf EWxSUkDWzAUruVwLeeDuaNynCohCJ2654DK2Lo+Xmz0C006VR0VfJ09tKD/XHS2NZVSl KKiA== X-Gm-Message-State: APjAAAWfF7CK5zTNpYlAwHj+aW9dW/HWk2nT0bUDQ5snjp3gRmX6qhiq Kgwvw3xSIOkoTXQDHKBA8D8Ms7htFa4wxpMxMrrpVCDHXnx2rA== X-Google-Smtp-Source: APXvYqzznzd9KkZ7X9aKQZkYlrxjd9Gp4ZEpR7ig7IKq317YS43hqo9wmZfZaG7S1OoiomgINfFSlI8818Dv28H3V/c= X-Received: by 2002:a6b:d913:: with SMTP id r19mr18920514ioc.76.1554973482492; Thu, 11 Apr 2019 02:04:42 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> In-Reply-To: <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> From: Valentin Gosu Date: Thu, 11 Apr 2019 11:04:31 +0200 Message-ID: To: Ralf Weber Cc: Martin Thomson , add@ietf.org Content-Type: multipart/alternative; boundary="0000000000000f27ff05863d7a85" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:04:45 -0000 --0000000000000f27ff05863d7a85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 11 Apr 2019 at 10:59, Ralf Weber wrote: > Moin! > > On 11 Apr 2019, at 5:12, Martin Thomson wrote: > > We don't believe that DNSSEC is essential to our primary goals, which > > are improving privacy of browsing activity. As a browser, we can't > > condition our behaviour on whether DNSSEC was present and valid for a > > variety of reasons (some of which we might discuss separately), but we > > do value resolvers that perform DNSSEC validation. > So why not make DNSSEC validation in the resolver a requirement? It > doesn=E2=80=99t interfere with local policy and offers significant benefi= ts > for the user. Validation in the client would be nicer, but requiring it > in the resolver is a good first step. > Because at the moment a DNSSEC failure response from the DoH server is identical to an NXDOMAIN response, which causes us to fallback to regular DNS anyway. See https://bugzilla.mozilla.org/show_bug.cgi?id=3D1525854 --0000000000000f27ff05863d7a85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 11 Apr 2019 at 10:59, Ralf Weber <dns@fl1ger.de> wrote:
Moin!

On 11 Apr 2019, at 5:12, Martin Thomson wrote:
> We don't believe that DNSSEC is essential to our primary goals, wh= ich
> are improving privacy of browsing activity.=C2=A0 As a browser, we can= 't
> condition our behaviour on whether DNSSEC was present and valid for a =
> variety of reasons (some of which we might discuss separately), but we=
> do value resolvers that perform DNSSEC validation.
So why not make DNSSEC validation in the resolver a requirement? It
doesn=E2=80=99t interfere with local policy and offers significant benefits=
for the user. Validation in the client would be nicer, but requiring it in the resolver is a good first step.

B= ecause at the moment a DNSSEC failure response from the DoH server is ident= ical to an NXDOMAIN response, which causes us to fallback to regular DNS an= yway.


--0000000000000f27ff05863d7a85-- From nobody Thu Apr 11 02:08:42 2019 Return-Path: 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 F01DF120287 for ; Thu, 11 Apr 2019 02:08:40 -0700 (PDT) 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 (2048-bit key) header.d=open-xchange.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 RVsiZ5mnX6f1 for ; Thu, 11 Apr 2019 02:08:38 -0700 (PDT) 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 A00D31200FC for ; Thu, 11 Apr 2019 02:08:38 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [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 F29E26A23C; Thu, 11 Apr 2019 11:08:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554973717; bh=x+lyP6NHnYh7FH0NdmWF8JN3KpFLaFEcQ5hS+IsJLvI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=X/3lPsg8XR88yPpjy6l3dvRyhz3m9QoD1qKluDjBM3HkIyZklVcZHQOlun4wEACK5 bWvyHXFvmrYbjVhrkaNjLAQaqIzyTGNp2A9BLAJLucB1pS2Dg6emMeMjmLACPketce LUssI22qAFQaVDfCS7KUqh0cW4wWk5D1o5PeovMyJbAsOxwpxybHxOcUg2debIRx0B EdGvKG5h7b3SVgFzNiRN65AomlKKFtaB4nAgLuXZCbOceV45EybGBp0DyMrabLhXRt x7ETP/GBD9ZEOBuqOoKDIkKoeWpkXBVkhe6Okf9PtBuk8eynOJLQPK/lWhKKn+JLze jBu/JEgQrQa/A== 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 E4DFD3C0358; Thu, 11 Apr 2019 11:08:36 +0200 (CEST) Date: Thu, 11 Apr 2019 11:08:36 +0200 (CEST) From: Vittorio Bertola To: Ralf Weber , Martin Thomson Cc: add@ietf.org Message-ID: <994839978.18707.1554973716877@appsuite.open-xchange.com> In-Reply-To: <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> 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-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:08:41 -0000 > Il 11 aprile 2019 alle 10.59 Ralf Weber ha scritto: > > So why not make DNSSEC validation in the resolver a requirement? It=20 > doesn=E2=80=99t interfere with local policy and offers significant benefi= ts=20 > for the user. Validation in the client would be nicer, but requiring it= =20 > in the resolver is a good first step. More generally, while I understand Mozilla's desire to ensure certain stand= ards to their users, I think it would be better to have a broader definitio= n of what a "good resolver" is, both in terms of scope (not just privacy, b= ut DNSSEC etc), in terms of consensus (and the effort is already ongoing in= DPRIVE) and in terms of compliance: I don't know Mozilla's plans for audit= ing their trusted resolvers (are there any?), but it would make more sense = to have an independent industry effort that certifies resolvers, rather tha= n having each of them go through multiple accreditation processes for multi= ple applications, which would raise entry barriers for public resolvers and= , again, promote centralization.=20 (Unless we imagine that the choice of resolvers and their accreditation cri= teria will be a competitive factor among applications, but that would IMHO = pose a number of issues.) 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 Apr 11 02:11:27 2019 Return-Path: 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 6CA2B120287 for ; Thu, 11 Apr 2019 02:11:25 -0700 (PDT) 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] 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 GimUeB6x2S6j for ; Thu, 11 Apr 2019 02:11:24 -0700 (PDT) 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 45D6312028B for ; Thu, 11 Apr 2019 02:11:24 -0700 (PDT) Received: from [172.17.16.14] (unknown [195.70.2.54]) (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 D9D96242109D; Thu, 11 Apr 2019 09:11:21 +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, 11 Apr 2019 10:11:20 +0100 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> To: Valentin Gosu X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:11:25 -0000 > On 11 Apr 2019, at 10:04, Valentin Gosu = wrote: >=20 > Because at the moment a DNSSEC failure response from the DoH server is = identical to an NXDOMAIN response, which causes us to fallback to = regular DNS anyway. DNSSEC failures return SERVFAIL (something bad/unrecoverable has = happened). That's very different from NXDOMAIN responses (the = name/class/qtype doesn't exist). I hope DoH servers don't consider these = things to be the same because they're not. From nobody Thu Apr 11 02:15:14 2019 Return-Path: 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 E33E512028E for ; Thu, 11 Apr 2019 02:15:12 -0700 (PDT) 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 m3uinRHheA3D for ; Thu, 11 Apr 2019 02:15:11 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3729A120287 for ; Thu, 11 Apr 2019 02:15:11 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 93EFA5F40BE1; Thu, 11 Apr 2019 11:15:09 +0200 (CEST) Received: from [172.19.152.251] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 BE22C5F405CA; Thu, 11 Apr 2019 11:15:04 +0200 (CEST) From: "Ralf Weber" To: "Valentin Gosu" Cc: add@ietf.org, "Martin Thomson" Date: Thu, 11 Apr 2019 11:15:04 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:15:13 -0000 Moin! On 11 Apr 2019, at 11:04, Valentin Gosu wrote: > On Thu, 11 Apr 2019 at 10:59, Ralf Weber wrote: > >> Moin! >> >> On 11 Apr 2019, at 5:12, Martin Thomson wrote: >>> We don't believe that DNSSEC is essential to our primary goals, >>> which >>> are improving privacy of browsing activity. As a browser, we can't >>> condition our behaviour on whether DNSSEC was present and valid for >>> a >>> variety of reasons (some of which we might discuss separately), but >>> we >>> do value resolvers that perform DNSSEC validation. >> So why not make DNSSEC validation in the resolver a requirement? It >> doesn’t interfere with local policy and offers significant benefits >> for the user. Validation in the client would be nicer, but requiring >> it >> in the resolver is a good first step. >> > > Because at the moment a DNSSEC failure response from the DoH server is > identical to an NXDOMAIN response, which causes us to fallback to > regular > DNS anyway. No it is not. These are different RCODES. > See https://bugzilla.mozilla.org/show_bug.cgi?id=1525854 The problem is to decide between SERVFAIL error caused by network events or a SERVFAIL by DNSSEC. That is a problem, but if your network or your resolvers network is bad why would you fallback to an insecure mechanism anyway? So long -Ralf —-- Ralf Weber From nobody Thu Apr 11 02:17:46 2019 Return-Path: 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 2D40F12028B for ; Thu, 11 Apr 2019 02:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_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 (2048-bit key) header.d=open-xchange.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 QjdXcCsQbnmk for ; Thu, 11 Apr 2019 02:17:42 -0700 (PDT) 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 CBD1C120157 for ; Thu, 11 Apr 2019 02:17:41 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [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 C30A76A25A; Thu, 11 Apr 2019 11:17:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554974258; bh=0oTv01dvI3jki0nOzqUxC2/p7uJAmdEfOL4RO7PLvP8=; h=Date:From:To:In-Reply-To:References:Subject:From; b=Z77/jE2KOd342CdGRNfjNUzfWa0h32wxrA/Au3q6hGh9RiYv4EXIKisWEICGeb8Mz HirQJcLSP4/fY9zdT/9AgT0Y7IZ2kbhSFRE3uWszQJd8nlbmt6evULonI2kDMo1neF u9io/K7o5CncHXEnReMYTf1s8mwlVglVEXRNBIRIimst2lc+yauZImdUWTLFlO4l0C JqhB9x7RlrEDS9w3EnflnSEY1tztHxRJ7CssbJJ28KM+IVPXvNljRvuo/uom0WSJlF QSdVv27AKJ3uV5ZDK/O7bWaqNnJJTfxU/eGhUZp2TfHiGMgD2P0Mj5C4jLKPX4RktD xzTJVIWBwbGGA== 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 B51173C036E; Thu, 11 Apr 2019 11:17:38 +0200 (CEST) Date: Thu, 11 Apr 2019 11:17:35 +0200 (CEST) From: Vittorio Bertola To: Stephen Farrell , add@ietf.org Message-ID: <1166518942.18730.1554974258678@appsuite.open-xchange.com> In-Reply-To: <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18729_150306624.1554974258672" X-Priority: 3 Importance: Medium X-Originating-Client: open-xchange-appsuite X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:17:44 -0000 ------=_Part_18729_150306624.1554974258672 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 11 aprile 2019 alle 2.37 Stephen Farrell < stephen.farrell@cs.tcd.ie mailto:stephen.farrell@cs.tcd.ie > ha scritto: > > But that's not my argument. Informed consent is entirely possible, > but the probability of it happening is miniscule. There is therefore > no point in pretending that informed consent could ever be depended > upon in this case. > While I agree that explaining things to the user might not be easy, the basic principle of GDPR-style privacy laws is that consent is required unless you fall into some specific exceptions, and I've never seen "this is too hard to explain" mentioned as a valid exception. In other words, the principle is "if you can't explain it and get proper consent, don't do it". So if you continued along this line of thought, the consequence would be that any DNS resolution activity on behalf of human beings is illegal, or, if you want to be a little more liberal, that any change of the user's DNS settings from the default is illegal, because users can't understand what they are doing and so cannot provide informed consent to such a specific change. In reality, it is pretty common for the user to ask for services that they don't fully understand in technical terms. The way this works is that the user asks for a service (for example, Internet access) and then gives general consent to any data processing activity that is necessary to provide that service (for example, DNS resolution), even if the user doesn't understand or even know such activities. Applications willing to turn on DoH could possibly use the same mechanism, offering "private DNS" or even "private browsing" as the service, but they would still be required to inform the user on which information will be acquired, who is going to process it and for which purposes, providing separate opt-ins for each purpose. (By the way - if the actual point you are trying to make is that any DNS operator, including ISPs, should be providing better information to users and make sure to really get meaningful consent, I'm all with you. But not if your point is that since consent is hard we'd rather disempower the user.) Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_18729_150306624.1554974258672 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 11 aprile 2019 alle 2.37 Stephen Farrell < stephen.farrell@cs.tcd.ie> ha scritto:

But that's not my argument. Informed consent is entirely possible,
but the probability of it happening is miniscule. There is therefore
no point in pretending that informed consent could ever be depended
upon in this case.
While I agree that explaining things to the user might not be easy, the basic principle of GDPR-style privacy laws is that consent is required unless you fall into some specific exceptions, and I've never seen "this is too hard to explain" mentioned as a valid exception. In other words, the principle is "if you can't explain it and get proper consent, don't do it".

So if you continued along this line of thought, the consequence would be that any DNS resolution activity on behalf of human beings is illegal, or, if you want to be a little more liberal, that any change of the user's DNS settings from the default is illegal, because users can't understand what they are doing and so cannot provide informed consent to such a specific change.

In reality, it is pretty common for the user to ask for services that they don't fully understand in technical terms. The way this works is that the user asks for a service (for example, Internet access) and then gives general consent to any data processing activity that is necessary to provide that service (for example, DNS resolution), even if the user doesn't understand or even know such activities. Applications willing to turn on DoH could possibly use the same mechanism, offering "private DNS" or even "private browsing" as the service, but they would still be required to inform the user on which information will be acquired, who is going to process it and for which purposes, providing separate opt-ins for each purpose.

(By the way - if the actual point you are trying to make is that any DNS operator, including ISPs, should be providing better information to users and make sure to really get meaningful consent, I'm all with you. But not if your point is that since consent is hard we'd rather disempower the user.)

Ciao,

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_18729_150306624.1554974258672-- From nobody Thu Apr 11 02:26:44 2019 Return-Path: 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 56D521202A4 for ; Thu, 11 Apr 2019 02:26:42 -0700 (PDT) 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 CBU20-pEGR4z for ; Thu, 11 Apr 2019 02:26:40 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 E167F1202A3 for ; Thu, 11 Apr 2019 02:26:39 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id y134so8449267itc.5 for ; Thu, 11 Apr 2019 02:26:39 -0700 (PDT) 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=VQtoTU445NdEOLwe9xbD7yF9SvA15Bl3t1/hxvJ11MY=; b=VvJrnuz4uaJA+qlv0ztehL7noBShX51Lagyb6GB/PvZCAapotAextJBko03cwjSZ3D Rz9bRxxrfkAYpmLNs5eI+lAk6aPKVJqbNQ5hE000mVaMAX+xxXIFso9F5mFroSQp2we5 DoAMY7SkPTYYkBS2oVjXyZWOvCqAWK+l1H/g/1e/yULox8C3YJTgELKIggNWZgquqm5f uJE2/soe32XcHxpMI23frKcWPNwuTDS+RLd5dsMfl9jxd1WwjmnWkXtuc6Homxvpagi6 HtJY7s2hd3W88KKpEzwDvLkBnst7Q62eS0easACwiKeoQgkSaMeTjW+Io3c+9fXmyhhX EQkw== 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=VQtoTU445NdEOLwe9xbD7yF9SvA15Bl3t1/hxvJ11MY=; b=MXUPcZvuoobrqPSo5cr76JepRjwUPR9Iqn70bSnBWP0eSLTluFpbmG1Bt3T+HvZXDT pQVWSJ9MjzoUoeKuLJXUeeb3GrBK1a3HXwjVbjA/DQT+jMg0D/jOKM/Z13ypRmv3WKmD 7YhVhzRG9uuBt6Gp0bo5Mglzo/nvFtaQV8FI6ERSdbNFnVb3aQGgtvruq12Jg6B03Ish rz5DKsfGisas2hMujFBmrBoU0adi4BXw4zhd5oxZ1d8kipPidXL/RWKh7NT4x3Fe8fE+ syYfMSQTpBvWdxSIthluoKCUW3X5fdPTDSvvewZ12OsgUNC/O54dwSHVsqIOvN5bV2SC xBZA== X-Gm-Message-State: APjAAAVFuCLJt+MJEt0suNFkpoWwHwRNfYjRR6uUY7fQNlWKCFH2qYK/ J6eAypWjIf+ph2zxGShUdQtdnmFSS3+BoCYDjnk= X-Google-Smtp-Source: APXvYqzQGb7ijsvX5RTAI8L5tp3uZt39wbHVm8B4R/ifKI5eKeU6hi0+/omoNllZcKrVN55EiFW5SnrtaDPRX8GHrBI= X-Received: by 2002:a02:62ce:: with SMTP id d197mr35484662jac.91.1554974799201; Thu, 11 Apr 2019 02:26:39 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> In-Reply-To: From: Valentin Gosu Date: Thu, 11 Apr 2019 11:26:28 +0200 Message-ID: To: Ralf Weber Cc: add@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="0000000000008a89e405863dc899" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:26:42 -0000 --0000000000008a89e405863dc899 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 11 Apr 2019 at 11:15, Ralf Weber wrote: > Moin! > > On 11 Apr 2019, at 11:04, Valentin Gosu wrote: > > > On Thu, 11 Apr 2019 at 10:59, Ralf Weber wrote: > > > >> Moin! > >> > >> On 11 Apr 2019, at 5:12, Martin Thomson wrote: > >>> We don't believe that DNSSEC is essential to our primary goals, > >>> which > >>> are improving privacy of browsing activity. As a browser, we can't > >>> condition our behaviour on whether DNSSEC was present and valid for > >>> a > >>> variety of reasons (some of which we might discuss separately), but > >>> we > >>> do value resolvers that perform DNSSEC validation. > >> So why not make DNSSEC validation in the resolver a requirement? It > >> doesn=E2=80=99t interfere with local policy and offers significant ben= efits > >> for the user. Validation in the client would be nicer, but requiring > >> it > >> in the resolver is a good first step. > >> > > > > Because at the moment a DNSSEC failure response from the DoH server is > > identical to an NXDOMAIN response, which causes us to fallback to > > regular > > DNS anyway. > No it is not. These are different RCODES. > Sorry for the confusion, I meant SERVFAIL. > > See https://bugzilla.mozilla.org/show_bug.cgi?id=3D1525854 > The problem is to decide between SERVFAIL error caused by network events > or a SERVFAIL by DNSSEC. That is a problem, but if your network or your > resolvers network is bad why would you fallback to an insecure mechanism > anyway? > To prevent disruptions to the user's browsing. --0000000000008a89e405863dc899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 11 Apr 2019 at 11:15, Ralf Weber <dns@fl1ger.de> wrote:
Moin!

On 11 Apr 2019, at 11:04, Valentin Gosu wrote:

> On Thu, 11 Apr 2019 at 10:59, Ralf Weber <dns@fl1ger.de> wrote:
>
>> Moin!
>>
>> On 11 Apr 2019, at 5:12, Martin Thomson wrote:
>>> We don't believe that DNSSEC is essential to our primary g= oals,
>>> which
>>> are improving privacy of browsing activity.=C2=A0 As a browser= , we can't
>>> condition our behaviour on whether DNSSEC was present and vali= d for
>>> a
>>> variety of reasons (some of which we might discuss separately)= , but
>>> we
>>> do value resolvers that perform DNSSEC validation.
>> So why not make DNSSEC validation in the resolver a requirement? I= t
>> doesn=E2=80=99t interfere with local policy and offers significant= benefits
>> for the user. Validation in the client would be nicer, but requiri= ng
>> it
>> in the resolver is a good first step.
>>
>
> Because at the moment a DNSSEC failure response from the DoH server is=
> identical to an NXDOMAIN response, which causes us to fallback to
> regular
> DNS anyway.
No it is not. These are different RCODES.

Sorry for the confusion, I meant SERVFAIL.
=C2=A0
> See https://bugzilla.mozilla.org/show_bug= .cgi?id=3D1525854
The problem is to decide between SERVFAIL error caused by network events or a SERVFAIL by DNSSEC. That is a problem, but if your network or your resolvers network is bad why would you fallback to an insecure mechanism anyway?

To prevent disruptions to the u= ser's browsing.
--0000000000008a89e405863dc899-- From nobody Thu Apr 11 02:34:33 2019 Return-Path: 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 50E86120299 for ; Thu, 11 Apr 2019 02:34:31 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=portfast.net 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 aJSNFUuP1iTw for ; Thu, 11 Apr 2019 02:34:29 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 394641202B3 for ; Thu, 11 Apr 2019 02:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=LUPm3/+6UOXH8Hw9Fc4ZM4ACgDss73CsmuKhRiKcmZg=; b=oClT40dT0bwU6i2rHah9tXHOUZ WV6Pwr27WZ+gdGd+DfpBu4G0srOBRXqxpsjauFg/zBL4yum/HckV/x1dlW3r1NQHO+sHJlca4WRKZ Jr1SZpAloXDhZqzGWLLknOxgENrSz+R5e5SVSA5ImxBSYRJs35ID4df6NpfGS6D9WUhs=; Received: from [88.212.170.147] (port=52946 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hEW6C-0000QM-WB (Exim 4.89) for add@ietf.org (return-path ); Thu, 11 Apr 2019 09:34:25 +0000 To: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> From: Ray Bellis Message-ID: <34d202a0-cfe2-d35f-edf2-f0943408a858@bellis.me.uk> Date: Thu, 11 Apr 2019 10:34:24 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:34:31 -0000 On 11/04/2019 10:26, Valentin Gosu wrote: > Sorry for the confusion, I meant SERVFAIL. > > > See https://bugzilla.mozilla.org/show_bug..cgi?id=1525854 > > The problem is to decide between SERVFAIL error caused by network > events > or a SERVFAIL by DNSSEC. That is a problem, but if your network or your > resolvers network is bad why would you fallback to an insecure > mechanism > anyway? > > To prevent disruptions to the user's browsing. But that's the entire point of DNSSEC! If the domain fails to validate, you *don't go there* Ray From nobody Thu Apr 11 02:37:25 2019 Return-Path: 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 1BCB91202B1 for ; Thu, 11 Apr 2019 02:37:24 -0700 (PDT) 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 mMwTRx5DetP4 for ; Thu, 11 Apr 2019 02:37:21 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDFC120299 for ; Thu, 11 Apr 2019 02:37:21 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 89D4A5F40689; Thu, 11 Apr 2019 11:37:20 +0200 (CEST) Received: from [172.19.152.251] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 936A95F40043; Thu, 11 Apr 2019 11:37:19 +0200 (CEST) From: "Ralf Weber" To: "Valentin Gosu" Cc: add@ietf.org, "Martin Thomson" Date: Thu, 11 Apr 2019 11:37:18 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:37:24 -0000 Moin! On 11 Apr 2019, at 11:26, Valentin Gosu wrote: >>> See https://bugzilla.mozilla.org/show_bug.cgi?id=1525854 >> The problem is to decide between SERVFAIL error caused by network events >> or a SERVFAIL by DNSSEC. That is a problem, but if your network or your >> resolvers network is bad why would you fallback to an insecure mechanism >> anyway? >> > > To prevent disruptions to the user's browsing. Again why do you think it will get better asking unencrypted? It is a nice way to find out if someone is using DoH though ;-). In regular DNS your resolving library had n servers and if one did timeout or SERVFAIL it did ask the others. It didn’t try a different transport. Maybe this is a better behaviour for DoH also. So long -Ralf —-- Ralf Weber From nobody Thu Apr 11 02:49:51 2019 Return-Path: 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 99FF31202B1 for ; Thu, 11 Apr 2019 02:49:50 -0700 (PDT) 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 UPQ7fjdcA6F8 for ; Thu, 11 Apr 2019 02:49:48 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) (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 65EE61201B2 for ; Thu, 11 Apr 2019 02:49:48 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id x3B9ngOJ016310 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 11:49:42 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id x3B9nf2b016304; Thu, 11 Apr 2019 11:49:42 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Thu, 11 Apr 2019 11:49:41 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Ralf Weber cc: Valentin Gosu , add@ietf.org, Martin Thomson In-Reply-To: Message-ID: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 09:49:50 -0000 On Thu, 11 Apr 2019, Ralf Weber wrote: >> To prevent disruptions to the user's browsing. > Again why do you think it will get better asking unencrypted? It is a nice > way to find out if someone is using DoH though ;-). How about not discussing application specific design decisions? I don't think anyone suggests it is better to ask unencryped, but when the DoH server you have configured slowly dies or get DoS'ed or whatever, users will appreciate a "way out". In this specific application being discussed, it has a soft-fail mode that works like this. I'm convinced several of us would prefer switching to a different DoH server instead, or we even use the hard-fail mode. The good thing here is that we can all write our own applications to work the way we want! -- / daniel.haxx.se From nobody Thu Apr 11 04:06:33 2019 Return-Path: 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 559671201D9 for ; Thu, 11 Apr 2019 04:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7OCBmJboA9XT for ; Thu, 11 Apr 2019 04:06:30 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 8A0B51201B6 for ; Thu, 11 Apr 2019 04:06:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:52346) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1hEXXI-000tWD-12 (Exim 4.91) (return-path ); Thu, 11 Apr 2019 12:06:28 +0100 Date: Thu, 11 Apr 2019 12:06:28 +0100 From: Tony Finch To: Thomas Peterson cc: Ray Bellis , add@ietf.org In-Reply-To: <452dec9b-1222-4e75-07b8-b497547d0e30@gmail.com> Message-ID: References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <452dec9b-1222-4e75-07b8-b497547d0e30@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 11:06:32 -0000 Thomas Peterson wrote: > As we go up the networking layers in OSI from physical to application we > go from most privileged components in a system from networking hardware, > through to kernel drivers, the kernel, and finally into userland, and at > layers 4/5 is usually the boundary between kernel and userland[0]. There is a lot low-layer code in userland: DHCP, routing protocols, diagnostic tools, many transport protocols, ... And in the other direction, in-kernel implementations of application protocols are not unheard of, especially if they are network file systms, but also HTTP, TLS, telnet (back in the day when timesharing was big) ... Tony. -- f.anthony.n.finch http://dotat.at/ Great Orme Head to the Mull of Galloway: Variable 3 or 4, occasionally 2 overnight, becoming southeast 4 or 5 later. Smooth or slight. Fair. Good. From nobody Thu Apr 11 04:36:53 2019 Return-Path: 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 708261201B1 for ; Thu, 11 Apr 2019 04:36:51 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 3wKLcT3kuP7R for ; Thu, 11 Apr 2019 04:36:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5816E12011D for ; Thu, 11 Apr 2019 04:36:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44fzWf6mq0z5BB; Thu, 11 Apr 2019 13:36:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1554982606; bh=FqSnqDC2jV5SJj2omfnc3y8MVG9E/46L5pk38RLV4Vw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jj2j96+KpHlAAU0cGy9mJw3BEyn+/BNVlqI7dW5HrNJbAm2l6BV7bG/UvjSUdmNb6 KHuIQtzkQqMdKtKATW2cWJHofGnNQJVH7iN4Ti0/Qf8lrRDVtCR3QFsyHu9+FOPhwm YkhrWjmSUbIeKBQGwPZMQuDs9orki0scVsY3mB98= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 9TEveuNgf7ki; Thu, 11 Apr 2019 13:36:45 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 11 Apr 2019 13:36:44 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BD73879AFC; Thu, 11 Apr 2019 07:36:43 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BD73879AFC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B11F740D358A; Thu, 11 Apr 2019 07:36:43 -0400 (EDT) Date: Thu, 11 Apr 2019 07:36:43 -0400 (EDT) From: Paul Wouters To: Martin Thomson cc: add@ietf.org In-Reply-To: <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> Message-ID: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 11:36:52 -0000 On Wed, 10 Apr 2019, Martin Thomson wrote: > We don't believe that DNSSEC is essential to our primary goals, which are improving privacy of browsing activity. But I assume it is also not your goal to reduce security for those who chose mozilla products? You are offering your users a DNS system override, yet you seem to find it acceptable if that results in a less secure but more private DNS server being used. That is concerning. > As a browser, we can't condition our behaviour on whether DNSSEC was present and valid for a variety of reasons (some of which we might discuss separately) You can but you won't. But I agree there is no need to discuss that here. > but we do value resolvers that perform DNSSEC validation. But you won't value it enough to make it a requirement, even though it is a core part of the specification of DNS? Again, if you are reconfiguring a system resource within the application, at the very least do not reduce security. Requiring DNSSEC validation is a no-brainer. Those who do not desire such security already can not use DNSSEC by not sending the DO bit in the query, as you already not do yourself in the mozilla products. But at this point, you would be reducing my security and i will have to disable your privacy feature. > Requiring query minimization is in keeping with the privacy goal, Don't make this security versus privacy. Enhance privacy without paying with security. > whereas DNSSEC requirements would expand the scope more than we were comfortable with. I understand your discomfort of still not supporting core fundamental security technologies that prevent DNS spoofing. It should make you even more uncomfortable that you are redirecting people to other DNS servers that might actively support DNS spoofing. Having a policy where you do not want servers to use RPZ DNS filtering, but not require them to support the DNS protocol parts that can prove they are not maliciously modifying DNS, is a policy mistake. Paul From nobody Thu Apr 11 06:01:39 2019 Return-Path: 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 9D6E11200D8 for ; Thu, 11 Apr 2019 06:01:37 -0700 (PDT) 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 uHNXTDZ1chIG for ; Thu, 11 Apr 2019 06:01:35 -0700 (PDT) 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 0C88B12017B for ; Thu, 11 Apr 2019 06:01:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3907BBE2E; Thu, 11 Apr 2019 14:01:33 +0100 (IST) 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 FUOyPLSK3Usn; Thu, 11 Apr 2019 14:01:33 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CBD51BE2C; Thu, 11 Apr 2019 14:01:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554987692; bh=0xnXseJNm3rlJcgoM3G7UnrbLlQMjQCnkwo4FbRP2P4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=G9CkrQMpcAD6AtQAcfx1mM/ebQBcMQKoEIx2/FMw7du1spHnkqmRh1n1R3AKK6zV4 zqbhdLi7Mzknis+sP31unIj83MZtPzNHyMbkGXQOjmX7sfdmyFl3CMgCa1fe/1Qvbx rBrassK9/yWZaLoZMQG1RoSiwCH5MhosnODgouaI= To: Ralf Weber Cc: Michael Sinatra , add@ietf.org, Ray Bellis References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> 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: Thu, 11 Apr 2019 14:01:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8N1AhxrHH7lp4cVMuKt3gezogNIqVy4Mm" Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:01:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8N1AhxrHH7lp4cVMuKt3gezogNIqVy4Mm Content-Type: multipart/mixed; boundary="XVDqIKe9nOoboyuK9RvHMQKxBKYdfJYqb"; protected-headers="v1" From: Stephen Farrell To: Ralf Weber Cc: Michael Sinatra , add@ietf.org, Ray Bellis Message-ID: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> In-Reply-To: <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> --XVDqIKe9nOoboyuK9RvHMQKxBKYdfJYqb Content-Type: multipart/mixed; boundary="------------2B447B07F8B0C7A0D18D0B01" Content-Language: en-GB This is a multi-part message in MIME format. --------------2B447B07F8B0C7A0D18D0B01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 11/04/2019 09:53, Ralf Weber wrote: > Moin! >=20 > On 11 Apr 2019, at 0:55, Stephen Farrell wrote: >> Basically, if the application wants to know that DNS privacy >> is being applied, it has to do it itself. (There are other >> arguments, and I'm not a browser-maker so they may have other >> reasons they think more important.) > > There is nothing in DoT that prevents you from doing that,=20 True. Applications could build-in DoT as well as or instead of DoH. (Same for Do53 too.) > so > it=E2=80=99s clearly not the reason why DoH was done.=20 There was a good bit of discussion of that that I forget TBH;-) Encapsulating in HTTP was attractive for some JS reason I never really got. And port 443 is more likely unblocked I guess compared to 853. But a browser maker would have to say why they prefer DoH to DoT I reckon. > As others said > if the goal was to hide in normal traffic that is exactly what > malware does, and this is what created a biig problem for a lot > of people trying to stop malware. Yes, people writing both malware and anti-censorship tools want to look like more normal traffic. But I'm not sure that DoH vs. DoT to an "outside" recursive are any different here given there are DoT servers that listen on 443 too. (I use that myself with stubby as some networks I use allow outbound 853 whilst others don't, so for me that's a mobility issue and not related to censorship nor any attempt to spread malware:-) But it seems in any case brittle to assume that DNS traffic from malware will continue to be easily visible. I wonder is it the case that we'd have to see a widely deployed application that uses DoH with unpredictable web sites as DNS recursive before it being hard to identify this traffic really comes into play? If so, that doesn't sound like what mozilla have said they're planning. (Mind you, I'm not sure how a browser would handle a 3xx re-direct in response to a DoH query, so it might not be terribly simple.) Maybe this suggests there's scope to document ways in which user-chosen, application-chosen, OS-chosen, and n/w-chosen DNS recursives can be handled with DoH, DoT and Do53, without having to adopt a hard position that one way is right and all others are wrong? (That said, I'm not sure if that'd be very useful or not, and in any case, it's likely premature until someone figures out how to handle split-horizon and maybe local discovery.) S. >=20 > So long > -Ralf > =E2=80=94-- > Ralf Weber >=20 --------------2B447B07F8B0C7A0D18D0B01 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------2B447B07F8B0C7A0D18D0B01-- --XVDqIKe9nOoboyuK9RvHMQKxBKYdfJYqb-- --8N1AhxrHH7lp4cVMuKt3gezogNIqVy4Mm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyvOqwACgkQWrL68XsX K+rt5w/+JtZOUOfkPUam0MI1sfuowWfQ8cowHu5SZH8ixnGLchYvGIv9Qlz1bFgk KmK7qbVeIKqW0xTiNFUaos9tuQ5dWlf9foJDwF82gia3w2XGl4j3xi6cNacALdLU nVMHzrg2M5WJfIMzPLGEXsACM5VsZ4scEG8HbrKy7C9ySrd2rAzlE5hDi/W3XGiY ZvbRVhqjIkUcv2HVWYEXGD9L2ROLZL2R1uvPU8RORy0zpqO1QL9hbwDYYmfzDCmZ sW4bNTThD0rjQWAdmmY51rT9ZYVQpJMhKdMLwxL7TpEZc81WwFo6+PtEkc+zbeJu 1Fdcufsxqu+ZNhXY6OnuG8M3MklHsg3/ALur2UrlXYITzHdd0EmcYuGxqspOpM25 FSAAxEBbAudjUXJa+vSMS+R7fmTdPVUD3MNv81ydDR7U8Am1FzEbVT0xAptRijhs SmaSOlS23mcA6sT7G6rg+XhNaAPVMVh5OfSPvLKJs7Pn72tc7ze2F3Acr0e2sQAX oPSIxyJlp/HtcPW/PBumyM6CWsGXrwYYpUgKs4mRiDm9OU01Q4i0sh5dd78C/Rxq Zd7nk3MFzDtPiWQYZy9j0MJykDSjl5pKbny7X8eU9uvDBCgHGXWxU0y/QPUOjtQs yP1WYtEvbYgvhPMabCNOCRTqbEGZ2g/oKInQz1xf/dgKY4o8QgU= =y67k -----END PGP SIGNATURE----- --8N1AhxrHH7lp4cVMuKt3gezogNIqVy4Mm-- From nobody Thu Apr 11 06:07:34 2019 Return-Path: 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 230D412021F for ; Thu, 11 Apr 2019 06:07:32 -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=isoc.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 yebTi1vWma6w for ; Thu, 11 Apr 2019 06:07:30 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770072.outbound.protection.outlook.com [40.107.77.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C3B1201DB for ; Thu, 11 Apr 2019 06:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r5K37/cNf7D8UKVt72W/1XjMalTQix65H342KfGjLB0=; b=YWDkxyIb5TGKu4jqotF//ZkBtmqQraKiHC5UVLUtNkp1+jlMg6ru9g5+Wk0r8EqRajC5UpytSDfJSDbR+C1W5BbUIwAIsBy506JOrUwC9wQPTzQ1wB/Fqr6ZaQU05q0t2wNI+M39qd/xyXVkweZMNxTRT3GMgYuBiDDUwx3LI9I= Received: from BN8PR06MB5570.namprd06.prod.outlook.com (20.178.210.219) by BN8PR06MB5442.namprd06.prod.outlook.com (20.178.209.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Thu, 11 Apr 2019 13:07:27 +0000 Received: from BN8PR06MB5570.namprd06.prod.outlook.com ([fe80::c56c:bd9b:2aba:e8b4]) by BN8PR06MB5570.namprd06.prod.outlook.com ([fe80::c56c:bd9b:2aba:e8b4%3]) with mapi id 15.20.1771.021; Thu, 11 Apr 2019 13:07:27 +0000 From: Dan York To: "add@ietf.org" Thread-Topic: FYI - HN discussion about Mozilla's DOH policy requirements for resolvers Thread-Index: AQHU8GeD1Btnhaq/ekWyQYYv0LY4pw== Date: Thu, 11 Apr 2019 13:07:27 +0000 Message-ID: <066A79A8-02F4-4EC1-A928-BF6CCFE14E2C@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=york@isoc.org; x-originating-ip: [2603:3005:4900:58e1:8d44:8275:4c57:7227] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ab1744c-6a6a-49bf-a821-08d6be7ea5d8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BN8PR06MB5442; x-ms-traffictypediagnostic: BN8PR06MB5442: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(346002)(39850400004)(396003)(199004)(189003)(2501003)(966005)(46003)(6916009)(486006)(4744005)(316002)(2616005)(99286004)(5640700003)(305945005)(25786009)(6436002)(2906002)(36756003)(476003)(478600001)(186003)(256004)(53936002)(106356001)(7736002)(33656002)(71190400001)(71200400001)(2351001)(8676002)(5660300002)(6486002)(6512007)(6506007)(1730700003)(81166006)(105586002)(6306002)(97736004)(102836004)(82746002)(6116002)(86362001)(81156014)(68736007)(14454004)(8936002)(83716004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR06MB5442; H:BN8PR06MB5570.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4vp7i9Row/hQP8X3rDwcwbpAtmENOX7+FWTvytQI75Nc4g3Mg2rdTxB2bLIXjgJovj/d0uh4crY5J9Aio+1u+tvVtoGaWSqMDGGVda/VbZt7gnOM7oXxlI5XmJIkpGX8yvaznaOFzhAtNqZKyvCIdA4cxEqSiC76QRWMxlGRu9vUaublN6e8IyrujW7ax04ytFV3tzQR9emI9dH4YdMwXHN/8o7IEWETIlMjct3luaDAuGHLr+T9VccK8tfZdW5Z/6YJ1iPTTze+XvCzABam6EWiy6ukrT5vLCu3hpoGXyNE4b8p+e9l3+poObmPyq0HgAdJxNOVMH0Ex4/mKWnfVe+be2FnFINjl2S1vRZ+CePDGoqYO4FloBDtptWnPW+fo26uXEPIZiK5YwBVcHBSFxaf1pcJI+ILaSgCEvkhUU4= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 0ab1744c-6a6a-49bf-a821-08d6be7ea5d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 13:07:27.6289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR06MB5442 Archived-At: Subject: [Add] FYI - HN discussion about Mozilla's DOH policy requirements for resolvers X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:07:32 -0000 UHVyZWx5IEZZSSwgdGhlcmUgd2FzIGEgbGVuZ3RoeSBkaXNjdXNzaW9uIG9mIE1vemlsbGHigJlz IG5ld3MgeWVzdGVyZGF5IG9uIEhhY2tlciBOZXdzIHRoYXQgbWF5IG1ha2UgZm9yIGludGVyZXN0 aW5nIHJlYWRpbmcgYXMgdGhlcmUgd2VyZSBtYW55IGRpZmZlcmVudCB2aWV3cG9pbnRzLCBpbmNs dWRpbmcgRE9IIGNyaXRpY3MgYW5kIGFkdm9jYXRlcywgRE9IIGltcGxlbWVudGVycywgbmV0d29y ayBvcGVyYXRvcnMgYW5kIG1vcmU6DQoNCmh0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20vaXRl bT9pZD0xOTYyMzc4NQ0KDQpJbiBwYXJ0aWN1bGFyLCB0aGVyZSB3YXMgYSBsZW5ndGh5IHRocmVh ZCAtIGh0dHBzOi8vbmV3cy55Y29tYmluYXRvci5jb20vaXRlbT9pZD0xOTYyNDgwNCAtICBhYm91 dCB0aGUgY2hhbGxlbmdlIG9mIERPSCB3aXRoaW4gSy0xMiBzY2hvb2xzIChkb27igJl0IGtub3cg d2hhdCBjb3VudHJ5KSB0aGF0IHRoZSBvcmlnaW5hbCBwb3N0ZXIgc3VtbWFyaXplZCBhcyAiVGhp cyBtYXkgbGVhZCB0byBtb3JlIEhUVFBTIE1JVE0gb3Igc2Nob29scyBmb3JiaWRkaW5nIEJZT0Qg QU5EIHJlbW92aW5nIEZpcmVmb3ggZnJvbSB0aGVpciBjb21wdXRlcnMu4oCdDQoNCkkgc2hhcmUg dGhpcyBqdXN0IGFzIG1vcmUgZmVlZGJhY2sgZnJvbSBhIGRpZmZlcmVudCBjb21tdW5pdHkgYWJv dXQgdGhlIHBvdGVudGlhbCBkZXBsb3ltZW50IGltcGxpY2F0aW9ucyBvZiBETlMgcHJpdmFjeSB3 b3JrLA0KRGFu From nobody Thu Apr 11 06:08:56 2019 Return-Path: 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 CFBA51201B6 for ; Thu, 11 Apr 2019 03:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 9zW9wv-GFeUX for ; Thu, 11 Apr 2019 03:53:05 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 F262812011D for ; Thu, 11 Apr 2019 03:53:04 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:bb45:ec8a:8e1a:3c8] (unknown [IPv6:2001:1488:fffe:6:bb45:ec8a:8e1a:3c8]) by mail.nic.cz (Postfix) with ESMTPSA id 47D8062207; Thu, 11 Apr 2019 12:53:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1554979982; bh=3/ehzSXXNIkDBwNHvf8VYgWzDCVFvee3vA57v8/MV8o=; h=To:From:Date; b=cmjuzX+cH0Lycpy31EmBvLzGitpN4eG9ID9G74ZJkvkw7VYevFOgzZ1+5VjwrDy9W etPY2CyxEmoMDtzaDSFpd8Ney4ZoI8ntrt1n2ZBcN3cbEpVdqox9Pg39VqRNy1p09l t8EXBh8LwScHJ6D8x+KSsatClYhQtaMxbAH+gFXo= To: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> Cc: Martin Thomson From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Openpgp: preference=signencrypt Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtDBWbGFkaW3DrXIg xIx1bsOhdCAod29yaykgPHZsYWRpbWlyLmN1bmF0QG5pYy5jej6JAlQEEwEIAD4CGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w 3gAKCRDnR98flXWjqmD6D/96U4cDZBrHQ5LhqybocZr/N2IS5Wr2SLLB4k2F5/W/wbL05gq6 Ha9/2TMqXoxRkhug+EAHFHxylPR43yN9rz0pjBXHrra87FAPHMqq/qqrOEUdhkytEqa6WIho aoEkdhaMhUyctjVjL2WZ0+MWeRjqedLQX+VCrOVPcVbLreRRhA9N3KPgNwbp9zCg6hEPi4l2 zZKedHkTNjKIAwJ0xZoMwFa1Y+vL8Em8Or+IBZuGBMP/ZMtasPOIQaT/Gvsyx1DDorwsoCdX 6zaTZy5DOWP3FIrMzus/YDbzwAYxSpWk/jF44ySbnJzdjU67EfG3UrsK+RRGw8aJqs3/4qHK ZMZZnNL+4wJpEdnZyFic/MXcw6FBszQEwrIOaM1WEfwzn2ExUYk2pM5zaBwq76OgrmGMzMEi cfMDyqLodwEQqR70PvRbkrh+R02LphwQ9c5AFXcrLjKMmeQlbQVarTUsrELcTK6rElC1ojS7 M37j0XzFE+kgNWn2fyBRgtnGDWEa7r+oDaueXJnEf0/4Ww28IwxakNc7r0N41GIBekwSxKdk epKFZgtVGGSDlFei5hb5LLWFljA1OS7CRVJKpbHafQjdPdb1vNqZAj4y2SJXvVVpI1KO5kq+ dFdYipORv0N2Iho6MNYbQUT1EBeU46G5N0viCoLS15/PxLhIAo+PzKpW97kCDQRYA5J2ARAA yHww3huLEtsdyqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zx x85WcuaO1OVqung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPp DkGodS0De9osA+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOo jGMiLoZvELY86Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxM t5LB/MSrmECB5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoR bh7i4fT0lWvMXTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJ V7xVLTtS1EamVqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p 02oSecDl5yVXplJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGX M71OpmONQJGF24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0 Q2zochS64Mcg0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYB gAAKCRDnR98flXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw 9SLUt7OGuUnIpKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrie b6iPjvAARXJCPTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTj xZzmGgvNSi6JDlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJi ba7iFPcGwcClCSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhw QYXm4/pDmNT8UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvL woHib0jEvohPMJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTN r+qHh+7Ltrkbu/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2Kg T1AcZ51E+xG+cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGo UREr0rkMnFVsWeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <89a677fa-8f14-d029-81fb-6f93d83c98bb@nic.cz> Date: Thu, 11 Apr 2019 12:53:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Thu, 11 Apr 2019 06:08:55 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 10:53:08 -0000 On 4/11/19 5:12 AM, Martin Thomson wrote: > We don't believe that DNSSEC is essential to our primary goals, which are improving privacy of browsing activity. OK, so privacy: why not consider padding?  Of course, as long as many webs are without SNI encryption, it's just such a tiny nitpick... https://tools.ietf.org/html/rfc8467 --Vladimir From nobody Thu Apr 11 06:24:50 2019 Return-Path: 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 326BE120498 for ; Thu, 11 Apr 2019 06:24:39 -0700 (PDT) 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 uLlr-bG2xnCP for ; Thu, 11 Apr 2019 06:24:34 -0700 (PDT) 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 91B5E120659 for ; Thu, 11 Apr 2019 06:24:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3382DBE2F; Thu, 11 Apr 2019 14:24:31 +0100 (IST) 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 w3KCuG2ljFOv; Thu, 11 Apr 2019 14:24:31 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D3B71BE2C; Thu, 11 Apr 2019 14:24:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1554989070; bh=vUP4G7MfcV+logKO0Vir79SjikOB63hdK1iyW8Q2kvo=; h=To:References:From:Subject:Date:In-Reply-To:From; b=07bQrvruswS6VYyf3y82geAdJ8TqpNPWiXJE7sJzWmZiS3WfIm0ebSVUxGloKiJsR s9StE3EGNFofrqtU76N939Xhy03MRkAIYcCivhMDib8ghh4neOO8m6wFi/Fmo9b2rg DwhTftdEUR7Gjq3opGzATU8VRGHC2orgF1fmh5ic= To: Vittorio Bertola , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> <1166518942.18730.1554974258678@appsuite.open-xchange.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: <859b0b52-5438-b135-ce40-445957a202ab@cs.tcd.ie> Date: Thu, 11 Apr 2019 14:24:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1166518942.18730.1554974258678@appsuite.open-xchange.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wWczW5JQeXjpbhlbbrn0CD4VhcsIsx9Ei" Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:24:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wWczW5JQeXjpbhlbbrn0CD4VhcsIsx9Ei Content-Type: multipart/mixed; boundary="S7ZJVcO26qOOyDzvepezt3H9TaADmUWkL"; protected-headers="v1" From: Stephen Farrell To: Vittorio Bertola , add@ietf.org Message-ID: <859b0b52-5438-b135-ce40-445957a202ab@cs.tcd.ie> Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <0dfd5eaa-398d-e169-f753-bda32ef28d24@brokendns.net> <2b2cdf13-d3d7-2b36-80ac-844456ced3b2@cs.tcd.ie> <1166518942.18730.1554974258678@appsuite.open-xchange.com> In-Reply-To: <1166518942.18730.1554974258678@appsuite.open-xchange.com> --S7ZJVcO26qOOyDzvepezt3H9TaADmUWkL Content-Type: multipart/mixed; boundary="------------BFCBE191EEBC4896117C6D47" Content-Language: en-GB This is a multi-part message in MIME format. --------------BFCBE191EEBC4896117C6D47 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 11/04/2019 10:17, Vittorio Bertola wrote: >=20 >> Il 11 aprile 2019 alle 2.37 Stephen Farrell < >> stephen.farrell@cs.tcd.ie mailto:stephen.farrell@cs.tcd.ie > ha >> scritto: >>=20 >> But that's not my argument. Informed consent is entirely possible,=20 >> but the probability of it happening is miniscule. There is >> therefore no point in pretending that informed consent could ever >> be depended upon in this case. >>=20 > While I agree that explaining things to the user might not be easy, > the basic principle of GDPR-style privacy laws is that consent is > required unless you fall into some specific exceptions, and I've > never seen "this is too hard to explain" mentioned as a valid > exception. In other words, the principle is "if you can't explain it > and get proper consent, don't do it". I don't claim to understand GPDR, nor am I a lawyer. I do claim that so-called consent as used by web applications (and s/w in general) is almost always bogus. I'd further argue that IETF RFCs ought never mention the term because of that ubiquitous bogosity. > So if you continued along this line of thought, the consequence would > be that any DNS resolution activity on behalf of human beings is > illegal, or, if you want to be a little more liberal, that any change > of the user's DNS settings from the default is illegal, because users > can't understand what they are doing and so cannot provide informed > consent to such a specific change. >=20 > In reality, it is pretty common for the user to ask for services that > they don't fully understand in technical terms. The way this works is > that the user asks for a service (for example, Internet access) and > then gives general consent to any data processing activity that is > necessary to provide that service (for example, DNS resolution), even > if the user doesn't understand or even know such activities. > Applications willing to turn on DoH could possibly use the same > mechanism, offering "private DNS" or even "private browsing" as the > service, but they would still be required to inform the user on which > information will be acquired, who is going to process it and for > which purposes, providing separate opt-ins for each purpose. >=20 > (By the way - if the actual point you are trying to make is that any > DNS operator, including ISPs, should be providing better information > to users and make sure to really get meaningful consent, I'm all with > you. But not if your point is that since consent is hard we'd rather > disempower the user.) I would welcome more transparency on what service providers do with user-data and derived meta-data and would never want to disempower users. But again, and no matter what a lawyer might say, I don't consider it the case that just because someone uses an ISP, means that they have given real consent to everything the ISP does, or says it does in a contract. I do accept that people who offer services have to operate as if there were real consent involved, but there is not, IMO. (That said, having DPAs force service providers to do better because of GDPR is mostly positive, but it's not a panacea. And I fully expect commercial entities to do as much as they are forced to do by laws like GDPR, but no more, and that's understandable.) So for this discussion, I don't think arguments about so-called consent are useful, as they bring in all the above issues, and those are issues that can't be resolved via IETF discussion. Cheers, S. >=20 > Ciao, >=20 > -- >=20 > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange=20 > vittorio.bertola@open-xchange.com > mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, > 10144 Torino, Italy >=20 --------------BFCBE191EEBC4896117C6D47 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------BFCBE191EEBC4896117C6D47-- --S7ZJVcO26qOOyDzvepezt3H9TaADmUWkL-- --wWczW5JQeXjpbhlbbrn0CD4VhcsIsx9Ei Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyvQA4ACgkQWrL68XsX K+piYA//aWxX/I43qY3df0guvezf5HpsZh2GsJnIb78B8+unAIX9+vpNmbrA53/b KADDOTHS6JNsD3xiS+gClbp0w5B6nbQorZlGNbGWwWWrAHxtpbXodeXxgKBIyRRx pp62/ZMQLaOJ7eCL99Ha6dsOPVNrtGS0BJsJB0jTGhj0xhkDASX+MtKVONLFXiFK lFbcUdPLJQKSEFk6MT9nS7T6HI6H7d3XFEAb8Ow5TFnNrY+qk/LVkWthUAHxooRR 2EBM/jHOOS3i1vMtptHB7FCFbTKed+OBhkahopby4UfcttS8/T0i6C/eSEzjCfWt XlE1Nc5hXFzELtT4xQg0oaEhRCftYm7XBROS/8C3toWPHtZx1G9O3mplBe8zrPzY oUscphYf9o9KaF8qoXQzCsAu//D0pXSebSwQWmwKvULWb9VIDC48Io00EsaTCnRd RtX8zVHLVL9Q94tZrFXGnpStzbpUYDTjqynbbWcvKasG5pee9r+n4JjUuNFxfD2R ChmBw9POctfGCyW/DSFl7viFhS4EyySQkz0YPaRoohy0RO/KHX81rXQkMcwIf4oV wNEAVT9YrtQwd1t4lQ+jFRJW9Bfu5H3Lq6bGotNmnXVRcBRvXpb3TmTDyHoGPitf xxdhxNpPZVBBhAdePu1vnRw15fpaedr7lnX3efenC/FzAea5U6I= =IMS0 -----END PGP SIGNATURE----- --wWczW5JQeXjpbhlbbrn0CD4VhcsIsx9Ei-- From nobody Thu Apr 11 06:42:12 2019 Return-Path: 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 1FD471202D3 for ; Thu, 11 Apr 2019 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp 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 FWmKbD8FcHHq for ; Thu, 11 Apr 2019 06:42:08 -0700 (PDT) Received: from omgo.iij.ad.jp (mo1500.iij.ad.jp [203.180.38.48]) (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 2D96A1202D1 for ; Thu, 11 Apr 2019 06:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iij.ad.jp; h=Date:From:To: Message-Id:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding;i= manabu-s@iij.ad.jp; s=omgo2; t=1554990126; x=1556199726; bh=GInTDs1Lbn/6sUueRMMq0 wChvi7Uqb6wtxwoSjbPR9M=; b=YJE79m3lQm1m+sg1B+rF44XKrswyk3X/ct4Mdbph8BoG4EWsUt9 Eyx8NmM7fpCobl6n8PomhQ/hgjxTrQM0uFeMNWP9Q95mITx5xRaZ0jYCAga43kx2BN/dyaQv01mmK s7b+FfFF2f3fO2Pcp9SienyWdta3ijVjzXqGXvpgbSpZQ/g5SyJ2QC7ZxDMTXPDojd9AxRntDEP5Z aJLkDgLe0pjRQFb4V6fp7gSyxfrgj5YPWFLQZjsa+d/fcTRUEESUN/TSphUcoF2F16ws59zWVrQ37 3nPDkj2FnrBrOx2YbA/B80ZVKgJpyagkCCfNlfHG8ABSx0VHerhi6suL9Kew==; Received: by omgo.iij.ad.jp (of-mo1500) id x3BDg6gC025218; Thu, 11 Apr 2019 22:42:06 +0900 X-Iguazu-Qid: 33PugyMzGtv3g2mii8 X-Iguazu-QSIG: v=2; s=0; t=1554990126; q=33PugyMzGtv3g2mii8; m=JSYKPnztfDRI2y02Jj+wvXDQi0LNKE+4JbuGGhVW8G0= Date: Thu, 11 Apr 2019 22:42:06 +0900 (JST) From: Manabu Sonoda To: add@ietf.org Message-Id: <370088565.0.1554990126264@laocoon.iiji.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: Laocoon Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:42:10 -0000 I read DOH-resolver-policy. (https://wiki.mozilla.org/Security/DOH-resolver-policy) I can't understand that not need DNSSEC Validation. Why you define "TRUSTED" even though you don't know response is not trusted. Mozilla will be validation by client ? It welcome !! > 2. For any filtering that does occur under the above requirement, > the party must maintain public documentation of all domains that are > blocked and a log of when particular domains are added and removed from any blocklist. I agree it if blocked reason are security, copyright, and no problem for public. But I think MUST NOT publish domains if human rights are infringed. (ex. child porn site domain..) -- Manabu Sonoda Internet Initiative Japan Inc. DNSOPS.JP board From nobody Thu Apr 11 06:49:09 2019 Return-Path: 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 DEF9612067A for ; Thu, 11 Apr 2019 06:48:59 -0700 (PDT) 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=portfast.net 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 NeGrm__AO5W4 for ; Thu, 11 Apr 2019 06:48:57 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 6AA2A12038A for ; Thu, 11 Apr 2019 06:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YPcVsrGV9Nlrx00et03gDVOzDJu8a6cFL2hiOHdzOoE=; b=KLuYv/pkid7VQa6NH+qGr22n+r yMtSIl0IkY4v6FW//VZIjud/KvU9FuVjb2ebnrbu4HnRsYqDEH76qC4dFVwSEEImkoX0C7/u9SSoI tTjU6UFbEqqGyXFGZ0zNDOTQ7WJhJWq0tJYPmr/siyCqnsiN7URIl1Um8umLUdbZNWac=; Received: from [88.212.170.147] (port=53788 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hEa4V-0004w3-Ie (Exim 4.89) (return-path ); Thu, 11 Apr 2019 13:48:55 +0000 To: Stephen Farrell Cc: add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> From: Ray Bellis Message-ID: <68e2de45-cd61-3735-4d79-01b28194b307@bellis.me.uk> Date: Thu, 11 Apr 2019 14:48:55 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 13:49:07 -0000 On 11/04/2019 14:01, Stephen Farrell wrote: > True. Applications could build-in DoT as well as or > instead of DoH. (Same for Do53 too.) It would be better (IMHO) if operating systems did it. I don't buy the arguments that browsers "need to know" whether a DNS connection is "private" or not. Users may want to know that, sure, but that can be achieved just as well via the O/S resolver system. I note that the WG charter does explicitly refer to "e.g. operating system stub resolvers" as consumers of the WG's deliverable. That would be far more preferable (again, IMHO) than having applications each implement their own stub resolver logic. > There was a good bit of discussion of that that I forget > TBH;-) Encapsulating in HTTP was attractive for some JS > reason I never really got. There's no standard W3C / ECMAScript API for making DNS lookups within a browser. With DoH specified as carried inside HTTP you don't need an API at the level of a JavaScript function API at all, because DoH is then just something else that you can drop inside a REST call that would work in any current mainstream browser. Ray From nobody Thu Apr 11 07:15:26 2019 Return-Path: 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 AD8D712025E for ; Thu, 11 Apr 2019 07:15:23 -0700 (PDT) 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 XMXPU_OC-EHO for ; Thu, 11 Apr 2019 07:15:21 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAB3120033 for ; Thu, 11 Apr 2019 07:15:21 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 33E945F40B77; Thu, 11 Apr 2019 16:15:20 +0200 (CEST) Received: from [172.19.152.251] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 6230F5F40499; Thu, 11 Apr 2019 16:15:19 +0200 (CEST) From: "Ralf Weber" To: "Stephen Farrell" Cc: "Michael Sinatra" , add@ietf.org, "Ray Bellis" Date: Thu, 11 Apr 2019 16:15:18 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> In-Reply-To: References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 14:15:24 -0000 Moin! On 11 Apr 2019, at 15:01, Stephen Farrell wrote: > Maybe this suggests there's scope to document ways > in which user-chosen, application-chosen, OS-chosen, > and n/w-chosen DNS recursives can be handled with DoH, > DoT and Do53, without having to adopt a hard position > that one way is right and all others are wrong? (That > said, I'm not sure if that'd be very useful or not, > and in any case, it's likely premature until someone > figures out how to handle split-horizon and maybe > local discovery.) Provisioning and defining how the different layers interact with each other certainly is something we should work on. Ideally we would have a standardised API in the OS that would give applications access to the secure transport they wanted, but that is a long shot from where we are now and I’ve been told that the IETF doesn’t standardise APIs. So long -Ralf —-- Ralf Weber From nobody Thu Apr 11 07:18:40 2019 Return-Path: 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 117BE1200B8 for ; Thu, 11 Apr 2019 07:18:39 -0700 (PDT) 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=portfast.net 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 5KY9ihLIxut1 for ; Thu, 11 Apr 2019 07:18:37 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 9DAD9120033 for ; Thu, 11 Apr 2019 07:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VNF5PcROZ9ON1OY5Xd4lghoIHElo1QarIEgVYZOa4oM=; b=KOJODPuLfwRQ0uGoIDImNPXWC5 Ih5BsGGuRxs50e4WGI1YbOB4oPHHvi8uayq/R+oDb2w4dauYXghowgtCyPzpmKjikSq5ZPKJuzxuf 9hnaAOm+CabvA0zVaK1gNmJaELiuG3rHqUAFQ70G3gCyxED20R+VTvqnT7ZvWVtQ6EjE=; Received: from [88.212.170.147] (port=53867 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hEaXD-0005P8-K9 (Exim 4.89) (return-path ); Thu, 11 Apr 2019 14:18:35 +0000 To: Ralf Weber , Stephen Farrell Cc: Michael Sinatra , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> From: Ray Bellis Message-ID: Date: Thu, 11 Apr 2019 15:18:34 +0100 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: <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 14:18:39 -0000 On 11/04/2019 15:15, Ralf Weber wrote: > Provisioning and defining how the different layers > interact with each other certainly is something we > should work on. Ideally we would have a standardised > API in the OS that would give applications access to > the secure transport they wanted, but that is a long > shot from where we are now and I’ve been told that > the IETF doesn’t standardise APIs. The APIs already exist, e.g. libresolv, and the higher level calls that rely on them (e.g. getaddrinfo, etc). They just need their _implementations_ to be updated to support DoX. Ray From nobody Thu Apr 11 07:31:42 2019 Return-Path: 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 6D9F61201BF for ; Thu, 11 Apr 2019 07:31:41 -0700 (PDT) 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 7jIUfL3CHvnT for ; Thu, 11 Apr 2019 07:31:40 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE971200B8 for ; Thu, 11 Apr 2019 07:31:40 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id AFFCC5F40907; Thu, 11 Apr 2019 16:31:38 +0200 (CEST) Received: from [172.19.152.251] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 CD2D75F40499; Thu, 11 Apr 2019 16:31:36 +0200 (CEST) From: "Ralf Weber" To: "Ray Bellis" Cc: "Stephen Farrell" , "Michael Sinatra" , add@ietf.org Date: Thu, 11 Apr 2019 16:31:36 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> In-Reply-To: References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 14:31:42 -0000 Moin! On 11 Apr 2019, at 16:18, Ray Bellis wrote: > On 11/04/2019 15:15, Ralf Weber wrote: > >> Provisioning and defining how the different layers >> interact with each other certainly is something we >> should work on. Ideally we would have a standardised >> API in the OS that would give applications access to >> the secure transport they wanted, but that is a long >> shot from where we are now and I’ve been told that >> the IETF doesn’t standardise APIs. > > The APIs already exist, e.g. libresolv, and the higher level calls > that rely on them (e.g. getaddrinfo, etc). Well an API exists, but my understanding was that applications wanted to have more control over the resolution process, for which I think we need a new API. > They just need their _implementations_ to be updated to support DoX. Which would be good. Do you volunteer ;-)? So long -Ralf —-- Ralf Weber From nobody Thu Apr 11 07:38:45 2019 Return-Path: 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 1B6571202B5 for ; Thu, 11 Apr 2019 07:38:43 -0700 (PDT) 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=portfast.net 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 tpuGwv1N6460 for ; Thu, 11 Apr 2019 07:38:41 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 79E2C1200B8 for ; Thu, 11 Apr 2019 07:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TFvxlleKtWsBU4Rea7OoEGErsIpu6kXDoeObCvLjqh0=; b=gWIpPE/shtcrbXXUkHO8XQ1L2E 8LaNfxbDAp5FbiRwkSgCzQBidTuyDv62G84LpvJ0xlFMDwwo3Aw/r6LO2jlSuIPiXcDHwe+TrW5Az 5xeZhI/su6Ey0OTbEz5vHAo4jk/ffBp6FPGS/5QAH/qmutRrsnxKrxBuUC4xd2o8GF7w=; Received: from [88.212.170.147] (port=53907 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hEaqc-0005iJ-8C (Exim 4.89) (return-path ); Thu, 11 Apr 2019 14:38:38 +0000 To: Ralf Weber Cc: Stephen Farrell , Michael Sinatra , add@ietf.org References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> From: Ray Bellis Message-ID: Date: Thu, 11 Apr 2019 15:38:37 +0100 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: <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 14:38:43 -0000 On 11/04/2019 15:31, Ralf Weber wrote: > Well an API exists, but my understanding was that applications wanted to > have more control over the resolution process Why? In which consensus document are those requirements stated, and how would they not be met by having the system libraries directly handle the privacy and/or encryption of the DNS requests? Ray From nobody Thu Apr 11 07:52:44 2019 Return-Path: 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 43F85120372 for ; Thu, 11 Apr 2019 07:52:43 -0700 (PDT) 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 JZOMCd23vPkj for ; Thu, 11 Apr 2019 07:52:41 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8881202ED for ; Thu, 11 Apr 2019 07:52:41 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 44B505F40BE1; Thu, 11 Apr 2019 16:52:40 +0200 (CEST) Received: from [172.19.152.251] (p4FF53610.dip0.t-ipconnect.de [79.245.54.16]) (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 128E95F40499; Thu, 11 Apr 2019 16:52:39 +0200 (CEST) From: "Ralf Weber" To: "Daniel Stenberg" Cc: add@ietf.org, "Martin Thomson" , "Valentin Gosu" Date: Thu, 11 Apr 2019 16:52:38 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 14:52:43 -0000 Moin! On 11 Apr 2019, at 11:49, Daniel Stenberg wrote: > On Thu, 11 Apr 2019, Ralf Weber wrote: > >>> To prevent disruptions to the user's browsing. >> Again why do you think it will get better asking unencrypted? It is a >> nice >> way to find out if someone is using DoH though ;-). > > How about not discussing application specific design decisions? Isn’t that the topic of the mailing list (Applications Doing DNS)? > I don't think anyone suggests it is better to ask unencryped, but when > the DoH server you have configured slowly dies or get DoS'ed or > whatever, users will appreciate a "way out". In this specific > application being discussed, it has a soft-fail mode that works like > this. Yes and me being a user of that application (though not that function) thinks that this is bad. I found it odd that most DoH configurations I’ve seen by now are singular in what they give as a target, while most OS libraries allow multiple DNS server addresses and fail between them. Why are you not doing that with DoH? The first time I saw more than one DoH server used for configuration was in draft-ietf-doh-resolver-associated-doh ( https://datatracker.ietf.org/doc/draft-ietf-doh-resolver-associated-doh/ ) and I think that this is good. So long -Ralf —-- Ralf Weber From nobody Thu Apr 11 08:18:37 2019 Return-Path: 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 768AB12012E for ; Thu, 11 Apr 2019 08:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 fm8WifjUxI9Y for ; Thu, 11 Apr 2019 08:18:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 E0C89120006 for ; Thu, 11 Apr 2019 08:18:33 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:bb45:ec8a:8e1a:3c8] (unknown [IPv6:2001:1488:fffe:6:bb45:ec8a:8e1a:3c8]) by mail.nic.cz (Postfix) with ESMTPSA id B230160149; Thu, 11 Apr 2019 17:18:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1554995911; bh=PABbrU9Yzzgkvik4MUWGx5dsY+bQzxXyOPHm1XMktkE=; h=To:From:Date; b=PE/uq0LB+BiumMSnJmRUcmZUshROElMye26U//nFwI8wphZ8w6usRTETozP+VzuTr rkcE9KsWdIZrffBNl8kGx4lU0Ajfa7tH1IEj78xJsigDyrwlawHGWFzjwaxQnMlZb6 ymxQmAepxUyfaqaBP3aMhvQ38Z4VvIyVnamhlRSk= To: Ralf Weber , Daniel Stenberg Cc: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Openpgp: preference=signencrypt Autocrypt: addr=vladimir.cunat+ietf@nic.cz; prefer-encrypt=mutual; keydata= mQINBFgDknYBEADHEQwLBlfqbVCzq7qYcBFFTc1WCAFtqiKehOrsITnKusZw4nhYwlKQxcum gj01xJOhbfHBCBeGlDydYqemKg4IfY2nwSyPwZZYMJn7L7AGrCeytr4VMvDJ7o7qDZjjim4i fv+GUwdk3plXx6oMF4nctesI8aAOuLUHAn0PfrGfNhWoaglOKgdOI6DGjhI/aGkvy+jrI/+X sdMV+3f1RuEOfI+Yu4SXFjJyhAmqEOBRxxdHqKreIIpz3Lg38yWwiVGfwgQT+nFIz9BpHH3l Wg1uS8xM3ezceBmRYV8zT9PvbeZ57BlaTR6rLae5RYwV397PSLBqqLkB5H0TDRUFBnwBsUob LebYHmJCOydvyNv5AFkLmLZ7O4j2jFo1WPSMt3ThM6wRwqrnB4Gi+6onyrZfE1DnVZMqbxZ3 VXa+E4S5YwrfCLUErGEn+d40OtoRZmQXhRPVAsdjimMj9oFM9RoxSgUrDg6Ia3n0IrKFb++z HAFbqkR5g4qzXiOMEG621GYEex2sDEKz/PD4CVKlNI9eld4ToH592kAwzJmd+sAi+Rfos0NE zxuFd0ekAOeWoURo0zoYTSWPlMOmFMvcpH6LP3leJmY7x4z/b1ng/+7UnKonVALVPFbRbElO kIfAtLKcUEofwV1jr7DyYGPalJtiDJPomB041ZHCj2RxyXY/oQARAQABtDBWbGFkaW3DrXIg xIx1bsOhdCAod29yaykgPHZsYWRpbWlyLmN1bmF0QG5pYy5jej6JAlQEEwEIAD4CGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AWIQS2AGRgtgqA54IGJEnnR98flXWjqgUCWg3w 3gAKCRDnR98flXWjqmD6D/96U4cDZBrHQ5LhqybocZr/N2IS5Wr2SLLB4k2F5/W/wbL05gq6 Ha9/2TMqXoxRkhug+EAHFHxylPR43yN9rz0pjBXHrra87FAPHMqq/qqrOEUdhkytEqa6WIho aoEkdhaMhUyctjVjL2WZ0+MWeRjqedLQX+VCrOVPcVbLreRRhA9N3KPgNwbp9zCg6hEPi4l2 zZKedHkTNjKIAwJ0xZoMwFa1Y+vL8Em8Or+IBZuGBMP/ZMtasPOIQaT/Gvsyx1DDorwsoCdX 6zaTZy5DOWP3FIrMzus/YDbzwAYxSpWk/jF44ySbnJzdjU67EfG3UrsK+RRGw8aJqs3/4qHK ZMZZnNL+4wJpEdnZyFic/MXcw6FBszQEwrIOaM1WEfwzn2ExUYk2pM5zaBwq76OgrmGMzMEi cfMDyqLodwEQqR70PvRbkrh+R02LphwQ9c5AFXcrLjKMmeQlbQVarTUsrELcTK6rElC1ojS7 M37j0XzFE+kgNWn2fyBRgtnGDWEa7r+oDaueXJnEf0/4Ww28IwxakNc7r0N41GIBekwSxKdk epKFZgtVGGSDlFei5hb5LLWFljA1OS7CRVJKpbHafQjdPdb1vNqZAj4y2SJXvVVpI1KO5kq+ dFdYipORv0N2Iho6MNYbQUT1EBeU46G5N0viCoLS15/PxLhIAo+PzKpW97kCDQRYA5J2ARAA yHww3huLEtsdyqgjiGMhtEKOLmp7yFl450HY9oPcHS02U5BC1370ssNShrdOCi2ACDbe41Zx x85WcuaO1OVqung2umX047mj2xQsiTAFRDLZsQu8cQFoEy/DBL2bk7ThfK1Lh+NyZAs0UaPp DkGodS0De9osA+4T6Nf4POYaeavbYVFSdDKS4lUboBqApKnD/TzKFxFcpuFx6FN92lteTbOo jGMiLoZvELY86Kn9KuFZ8FM2ZSNHx1Z75KouufGrdkeCoZYVYiuzT+fnt2it4dIpIlnF+yxM t5LB/MSrmECB5CAFJtxzuMccm6yDUZQSWWi9vUgxIJwvt5w0CIBT353DGeP4WnH0r5YoBKoR bh7i4fT0lWvMXTG/V2lqyzBdClMebyHffMgba26Kj6oeDygDfC5aGsVaqw1Ue/qQ5QRqTJcJ V7xVLTtS1EamVqkfKwPS0zTfnrF1jQtnO/P4qkfgBRRG9BXGGrykHpXOyqmX6Z0wbV2P4j+p 02oSecDl5yVXplJfsXfbS/xXnaSkaN/7mCU29ul26cAVNxDkDPunztSFi9K9LM2T/XWYJQGX M71OpmONQJGF24lx7Wp/kobnHtbjGDzjDPC4eSL7MA56qtrWaLM+4ePKANct2q0q6c0uSLs0 Q2zochS64Mcg0YzL1sinWPN1rXLDk3lwpIsAEQEAAYkCJQQYAQgADwUCWAOSdgIbDAUJCWYB gAAKCRDnR98flXWjqn4yEACA0f1XBAg+WMaNPtIt0k15yFPfhdbOg9GhDcYGgvFIOxRuaFWw 9SLUt7OGuUnIpKxKRXtQJss98fHkijo70ONYWPuLhfRGK/wg9Ao6MuFw5G8m431CBS/awrie b6iPjvAARXJCPTTBZk/NC988jiKdCh8PbTCHDsl+gSDytP15QUrdqSfS2Wf4653ej7+jtuTj xZzmGgvNSi6JDlb9KNtmBQKQAgpnOQM46ItESmzHDnmdcvhPLUDsjwkpIJ6clasOzaObwxJi ba7iFPcGwcClCSwYjMNXFtneCGUnEAa5RBIx+i+LV1iqB3VRvTC6tMIUueoQ7cdTy6afNkhw QYXm4/pDmNT8UMdnzwnlTpFQ0CegDQRDWc+dIDDBHGEEEYBh2vTOE04KrmYUp1bQsNegPfvL woHib0jEvohPMJ2fJtZAd1SJElgwPbM8H7emKBiTsHwF8gL7G2jo7AoGpqYjqXkCRS0tSLTN r+qHh+7Ltrkbu/ZVTTfh4Q/qw3VaLYQh4C0tBma/YevQy1O2c3TZXXFz1QF8b9/Hj/3sq2Kg T1AcZ51E+xG+cb6cUqgkihmgm39xx24GPlNAdCRuq01+iILol+Wox6OwF6hmqx1EMSmxcmGo UREr0rkMnFVsWeAYeVoE4q689qxCPu9iCMJMJnkRe1o9oQYSN7my+S98gA== Message-ID: <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> Date: Thu, 11 Apr 2019 17:18:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> Content-Type: multipart/alternative; boundary="------------F9094827C0FAA3BC27F5032B" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 15:18:37 -0000 This is a multi-part message in MIME format. --------------F9094827C0FAA3BC27F5032B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 4/11/19 4:52 PM, Ralf Weber wrote: >> How about not discussing application specific design decisions? > Isn’t that the topic of the mailing list (Applications Doing DNS)? It isn't called Firefox Doing DNS, though admittedly Firefox *currently* seems to be the focus of most discussions. If Firefox is to be taken mainly as a real-life example on this mailing-list, is there a suitable Firefox-specific place to discuss related issues? (Assuming Mozilla is actually interested in that.) --Vladimir --------------F9094827C0FAA3BC27F5032B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/11/19 4:52 PM, Ralf Weber wrote:
How about not discussing application specific design decisions?
Isn’t that the topic of the mailing list (Applications Doing DNS)?

It isn't called Firefox Doing DNS, though admittedly Firefox *currently* seems to be the focus of most discussions.

If Firefox is to be taken mainly as a real-life example on this mailing-list, is there a suitable Firefox-specific place to discuss related issues? (Assuming Mozilla is actually interested in that.)

--Vladimir

--------------F9094827C0FAA3BC27F5032B-- From nobody Thu Apr 11 08:41:59 2019 Return-Path: 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 94B3F12039A for ; Thu, 11 Apr 2019 08:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nikQ1Ws2tEje for ; Thu, 11 Apr 2019 08:41:55 -0700 (PDT) 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 DD6E7120314 for ; Thu, 11 Apr 2019 08:41:55 -0700 (PDT) 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 x3BFfgcR044378 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Apr 2019 10:41:43 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554997303; bh=aqs/+vw7ByVt3gyj9BKiWEk66tLrYCwgLf1MbO5WqIg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kNs0Z6h2eiqucJh+UNbKGmXoNanEd/49/7P4eKsDs0xfBBNeVlJbBQs6Y/D469iQ/ 17SMPbRGS3aQgNwJiVorZNKp2ar8v5TLgjF8stChzfmj36UnVtPow2AUp48QNpfbRZ XZHOyLApuyQloCYRzI9w6Ng4RijomQbopWztTBzc= 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: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= , Ralf Weber , Daniel Stenberg Cc: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> From: Adam Roach Message-ID: <9d20eb02-9322-875e-230a-e229f516819d@nostrum.com> Date: Thu, 11 Apr 2019 10:41:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 15:41:58 -0000 On 4/11/19 10:18 AM, Vladimír Čunát wrote: > > If Firefox is to be taken mainly as a real-life example on this > mailing-list, is there a suitable Firefox-specific place to discuss > related issues? (Assuming Mozilla is actually interested in that.) > Of course your input is welcome. Mozilla is an opensource project, and everyone is invited to participate. For implementation discussions, DoH is part of our networking stack, called Necko. Those are discussed on https://groups.google.com/forum/#!forum/mozilla.dev.tech.network For privacy-related discussions, use https://groups.google.com/forum/#!forum/mozilla.dev.privacy /a From nobody Thu Apr 11 08:46:10 2019 Return-Path: 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 834F91203B2 for ; Thu, 11 Apr 2019 08:46:09 -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 D879nie--qBT for ; Thu, 11 Apr 2019 08:46:06 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 3386D1203A8 for ; Thu, 11 Apr 2019 08:46:06 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id x3so5706846iol.10 for ; Thu, 11 Apr 2019 08:46:06 -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=+RgpDd559ZyAZHpMXCCGAArw91fP0b/6JWq1GVwTXAc=; b=LaZbCkqIbgDZSdpjCucVUJJs1yCh79/FYiZbjCv5ocLsU7j2FSTMg4TK3CjbF1xoWp E6TG3XwZ0HTKSF01wDYB2Q6aTHDnFhfmoi3jIVL6F26uZkGJgtGrAgGRbJTI6skI09g0 ce4dTJvlEQQp6XpswAFOB0NaCYYA4F0OPDuQA= 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=+RgpDd559ZyAZHpMXCCGAArw91fP0b/6JWq1GVwTXAc=; b=qrbbhs70LIrbLY+p+++htJYekmewrrlwlTR7HMX3CMqA2DxM9vX/oBpSGjG0JodQQt hK2j6DD3h02xlIR/S7fJFn2t5fEKBcCfa0z+lhyMAKC08uTxZYNXdXmC8RCUXXr82+VB rGeX4j6GIFs71MFpfgImA1oi37PXoI4oQ4GKj9SlFYmYq8Mv4fiP2iCu574V6j8J7rbl I97iblnhUsw5SSwLv2faBnGB2OlaoQ+nwjG9m0ThKZcI6wPT2sRgvs3GCMALX+7pu4R2 s3NhQZeYNlSTMbRwALI9hEYodUcBNGiS1t6RGm4mDNzxgoOf85TNtNR7p/9jJxJDXph4 unHg== X-Gm-Message-State: APjAAAWESlVHJWTOWhH4p+5CcyeLJk4f5zGS6mOhiACxa1dGoFniD7+C zYx46LIQC2dKRQVvlDA4OCgNwg== X-Google-Smtp-Source: APXvYqzG3775sJWINDQxLwDMHzt/SWxRAvJ4jo/mEoEpLHMv5j2mvYnIfAX02AW7LCy2MCnHzWYYWA== X-Received: by 2002:a5e:c604:: with SMTP id f4mr10950312iok.263.1554997565372; Thu, 11 Apr 2019 08:46:05 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id w17sm2787119ita.43.2019.04.11.08.46.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 08:46:04 -0700 (PDT) To: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= , Ralf Weber , Daniel Stenberg Cc: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> From: Peter Saint-Andre 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: <6c11589f-fb00-e15d-9c16-a22368351c50@mozilla.com> Date: Thu, 11 Apr 2019 09:46:03 -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: <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 15:46:10 -0000 Ahoj! On 4/11/19 9:18 AM, Vladimír Čunát wrote: > On 4/11/19 4:52 PM, Ralf Weber wrote: >>> How about not discussing application specific design decisions? >> Isn’t that the topic of the mailing list (Applications Doing DNS)? > > It isn't called Firefox Doing DNS, though admittedly Firefox *currently* > seems to be the focus of most discussions. > > If Firefox is to be taken mainly as a real-life example on this > mailing-list, is there a suitable Firefox-specific place to discuss > related issues? The Networking:DNS component is the one to watch: https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Networking%3A%20DNS&bug_status=__open__&list_id=14662850 We don't (yet) have a discussion list for "Firefox Doing DNS". > (Assuming Mozilla is actually interested in that.) Feedback is always welcome. :-) Peter From nobody Thu Apr 11 08:49:31 2019 Return-Path: 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 DEAFB1203B4 for ; Thu, 11 Apr 2019 08:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 joVVRTIEN4sj for ; Thu, 11 Apr 2019 08:49:27 -0700 (PDT) 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 A3F4C1203D0 for ; Thu, 11 Apr 2019 08:49:26 -0700 (PDT) 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 x3BFnCLu045608 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Apr 2019 10:49:15 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554997757; bh=YQQJVyAI6TCvbbLD79WeWITZYq1CioT7giSB/qONoIU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=FRNC3qZIGh3P+QtcJcULskAMxUd0LyNgnNBQWYwxGrsng85fmGgu9SyViyUjOQtx7 uQA3hOFkwb3FVNHruOnjum9JOQU26y33QJKSkO+Ymv25Vh7a17elK2OxzFFhX7Ahv0 p8ILZJ8vcrvfuwj2P973eA8jNNkcmX35B3fHOSwI= 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: Ray Bellis , Ralf Weber Cc: Michael Sinatra , add@ietf.org, Stephen Farrell References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> From: Adam Roach Message-ID: Date: Thu, 11 Apr 2019 10:49:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 15:49:29 -0000 On 4/11/19 9:38 AM, Ray Bellis wrote: > > On 11/04/2019 15:31, Ralf Weber wrote: > >> Well an API exists, but my understanding was that applications wanted >> to have more control over the resolution process > > Why? > > In which consensus document are those requirements stated That's not really the way the word "wanted" works. I mean, we could produce a consensus document that defines Ray Bellis's favorite pizza toppings, but as long as someone other than you writes it, it's probably not going to bear on the ground truth of what your favorite pizza toppings actually are. /a From nobody Thu Apr 11 08:55:57 2019 Return-Path: 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 714201203D0 for ; Thu, 11 Apr 2019 08:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 gaOFWBUD7lbq for ; Thu, 11 Apr 2019 08:55:54 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 780D3120160 for ; Thu, 11 Apr 2019 08:55:54 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x3BFrLnV000336; Thu, 11 Apr 2019 16:55:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Z1pvh6XwM1CpC7VSs+zMuuwqiEY4aoC+0lJG0mzadIo=; b=TMi+wTP719NoSWDFVk17JkhwycQmGlQpbuEUkXK7JjXfTAf7+Xa9aiUaCcC4gAyN5VaY MoGbn/UbrN54r3Fx6yVm/nrusp4c9m0stGa39biBKpmgwtRsO5UWsNlLgUftY5XLaGuB VGkNkJzFZ5AV6jwBjlnK8Fam6pDKgVmaknOwIGb/UYaQ8i9OYxXZ5Vr8QKtPgMxbJ+Iu FwKmELb96iWC1C+egi2+2zw8g1vRLGC2DVgy52OFvj1P+Ga4qgtleMdT95fos9ehxtTn 38OKVLcIBr0jQ+hGIhgp7EMVCsflsgovyEhe6LZ/pbyXkO1EG2np+MLTPbxUpnW2eA27 BA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2rsf2jnvqf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 16:55:37 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x3BFWlfT021119; Thu, 11 Apr 2019 11:55:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2rpqeywa9j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Apr 2019 11:55:35 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 11 Apr 2019 10:55:33 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Thu, 11 Apr 2019 10:55:33 -0500 From: "Salz, Rich" To: Ralf Weber , Ray Bellis CC: Michael Sinatra , "add@ietf.org" , Stephen Farrell Thread-Topic: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues Thread-Index: AQHU770Y3/sVtV2p+0uATME9kb5ubaY2MluAgAAbvoCAAAdSgIAApwmAgABFQYCAABSdAIAAAOoAgAADpAD//9RlAA== Date: Thu, 11 Apr 2019 15:55:32 +0000 Message-ID: References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> In-Reply-To: <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190403 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.66] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110105 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110106 Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 15:55:56 -0000 ICAgID4gVGhleSBqdXN0IG5lZWQgdGhlaXIgX2ltcGxlbWVudGF0aW9uc18gdG8gYmUgdXBkYXRl ZCB0byBzdXBwb3J0IERvWC4NCg0KQnJvd3NlcnMgdXBkYXRlICptdWNoKiBmYXN0ZXIgdGhhbiBw bGF0Zm9ybXMsIGFuZCBJIGRvdWJ0IGFueSBicm93c2VyIC0tIGluIHBhcnRpY3VsYXIgb25lIHNt YWxsIG9uZSB0aGF0IHRyZWF0cyAidXNlciBwcml2YWN5IiBhcyBhIHNlbGxpbmcgcG9pbnQgLS0g d2lsbCB3YWl0LiAgSXQgd291bGQgYmUgbmljZSBpZiB0aGV5IGltcGxlbWVudGVkIG9uIHRvcCBv ZiB0aGUgY29tbW9uIExpbnV4IGdldFhYWFggaW50ZXJmYWNlLCBhbmQgZXh0ZW5kZWQgdGhhdCBh cyBuZWVkZWQuDQoNCg0K From nobody Thu Apr 11 08:57:53 2019 Return-Path: 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 D1FD21203E6 for ; Thu, 11 Apr 2019 08:57:51 -0700 (PDT) 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=portfast.net 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 b6mIOz2AZZJE for ; Thu, 11 Apr 2019 08:57:49 -0700 (PDT) Received: from mail.portfast.net (mail.portfast.net [IPv6:2a03:9800:20:1::2]) (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 74B571202F1 for ; Thu, 11 Apr 2019 08:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=portfast.net; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=rsPLKZBv0q2Spks5GE9gKo/IN//vtWOpLnAjB0jNYS0=; b=GK7rAhyb5jcyXROF6HLo+Ya1Fp VZvJUUKPPX6Zh65vruKaSqomH/TNPWShZlf6liYMzBRNZXWwpIwdunFlhCwQn6OPYyYU49t3C77IE wltlm6RgD+ipGuZ3RGesL1YuirFbz7nTJ15BEWvjV3AncZF63LsBa1/PBoIlApW3t3bQ=; Received: from [88.212.170.147] (port=54740 helo=Rays-MacBook-Pro.local) by mail.portfast.net ([188.246.200.9]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1hEc5C-0007M6-8D (Exim 4.89) (return-path ); Thu, 11 Apr 2019 15:57:46 +0000 To: "Salz, Rich" , Ralf Weber Cc: Michael Sinatra , "add@ietf.org" , Stephen Farrell References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> From: Ray Bellis Message-ID: <3b217424-7042-47e5-603d-fcdfd2d64e42@bellis.me.uk> Date: Thu, 11 Apr 2019 16:57:45 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 15:57:52 -0000 On 11/04/2019 16:55, Salz, Rich wrote: > Browsers update *much* faster than platforms, and I doubt any browser > -- in particular one small one that treats "user privacy" as a > selling point -- will wait. It would be nice if they implemented on > top of the common Linux getXXXX interface, and extended that as > needed. Or they could put their considerable engineering resource into updating the O/S code at the same time so that eventually *every* application can benefit from it... Ray From nobody Thu Apr 11 09:02:52 2019 Return-Path: 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 B850E1203AC for ; Thu, 11 Apr 2019 09:02:50 -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=unavailable 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 knIRgcgtwwUS for ; Thu, 11 Apr 2019 09:02:48 -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 F0A6E12033E for ; Thu, 11 Apr 2019 09:02:47 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id u12so5756890iop.11 for ; Thu, 11 Apr 2019 09:02:47 -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=N4S6GuxiMkf2PPcW0oDI9rDSPtYdmC0e+XMmBfHlknI=; b=cDvIrlEeniqLNAjAUSJEXCN5/D9EwYSQSVrePXNxgOXi6HnfleubMs6kt7iWURAYrH xKKOTOkuR3Aq6djfuINN1y6AiuZHHVxSpsm7VTHXFiKMhHG3Mc2nubSNQEMh80QMQqIo X7SQ2Jy9KBOm9E/FSx+XAXROU9ZIV26WTpe9o= 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=N4S6GuxiMkf2PPcW0oDI9rDSPtYdmC0e+XMmBfHlknI=; b=ZNvuKN0bOqGEs5rKVu0a3o/4zkTF4P2m7vdRB8NDNC0ZTEZblV5OCRjs7UbVarDk4o YK3BSGiiL+gB8uO8Bh4OVqrX9EKEgPol/4Yd8lA/Avlp6lFmGQMU3Bp9DvrKCrALlDG0 J37zUK9kaU83ow3g45VgDbeZFYgJ+3AbTTqS+fGDFhyEtPCW/3mjhwDytadcqxmjY88s mnOYByglL0BC1AgbTCNixnKKeMpqIVQVejuyDqxVQ+Jgg9H8+8Is+zt6D0He+uYJIe8M SomYxrlWu7PURS653w1G2OxG9V1bT5mJbys5icftS6umGCoFZs6oqZn+2oGDCZPDiWXN TfeQ== X-Gm-Message-State: APjAAAUBrmF7SnKBUtMmC/EaGYMDX1avvkZxK9hkrbVEaVbpd901i/aW GLNEfYBGqvF2lcmzlCAXprQmrg== X-Google-Smtp-Source: APXvYqwJ/Qn9OSLf4qej93iFY8ib4DETolof8tW6N8mnY4tfZxiIsrR4IfyRR9A28qZmVCMKgroHAg== X-Received: by 2002:a5e:c24b:: with SMTP id w11mr3754672iop.264.1554998567271; Thu, 11 Apr 2019 09:02:47 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id t2sm2849300itb.37.2019.04.11.09.02.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 09:02:46 -0700 (PDT) To: Vittorio Bertola , Ralf Weber , Martin Thomson Cc: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> From: Peter Saint-Andre 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: Date: Thu, 11 Apr 2019 10:02:45 -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: <994839978.18707.1554973716877@appsuite.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 16:02:51 -0000 On 4/11/19 3:08 AM, Vittorio Bertola wrote: >> Il 11 aprile 2019 alle 10.59 Ralf Weber ha scritto: >> >> So why not make DNSSEC validation in the resolver a requirement? It >> doesn’t interfere with local policy and offers significant benefits >> for the user. Validation in the client would be nicer, but requiring it >> in the resolver is a good first step. > > More generally, while I understand Mozilla's desire to ensure certain standards to their users, I think it would be better to have a broader definition of what a "good resolver" is, both in terms of scope (not just privacy, but DNSSEC etc), in terms of consensus (and the effort is already ongoing in DPRIVE) and in terms of compliance: I don't know Mozilla's plans for auditing their trusted resolvers (are there any?), but it would make more sense to have an independent industry effort that certifies resolvers, rather than having each of them go through multiple accreditation processes for multiple applications, which would raise entry barriers for public resolvers and, again, promote centralization. We (Mozilla) do not want to encourage centralization, which is why we have published criteria for becoming a trusted recursive resolver within Firefox. In our conversations with various stakeholders, we have seen a desire for the kind of industry-wide effort you mention. Although it's too early to say whether something like that will come together, we are very much open to discussions exploring that direction. Peter From nobody Thu Apr 11 09:03:21 2019 Return-Path: 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 C47B7120396 for ; Thu, 11 Apr 2019 09:03:19 -0700 (PDT) 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 6Ce6MotuUZBc for ; Thu, 11 Apr 2019 09:03:17 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 5AD7B12033E for ; Thu, 11 Apr 2019 09:03:17 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id g1so3783164qki.5 for ; Thu, 11 Apr 2019 09:03:17 -0700 (PDT) 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=TRDIJu7STLFsFg7GCUjiOQ8W3bJL1d8yJCNNsABh8jY=; b=unzrZM3bjR6Z3ngk5t9PYNXWeUKUhuPZLNSkKjyA7c/qsoKzjrCsxzwpRotxmtTvi2 Nq4ioMoRnvm5BoJv4TPAaTnl5MEEofiN5Bh8BzR9ngkUWZL+la7Kj6TJIwSknh3gggk3 apByiLn5IyWZALIxtfWAsiBzkyylLTLoq9vkxLohfPh67vKVtThgWSwLU3QCE3kQCS8q 3LAL5bnTAUtiV3WFFDC1Us3Nn8vy1a83eqMU0eiXyS86X7GsyeL7XRJjbN0P79x0n6UA mOgSIM8Eq1gkuHJoqzpo9TnZL649pD1nZK1TEuR+xbj6IrJTncqcUzUi8e8SVf4U4sDF FHNA== 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=TRDIJu7STLFsFg7GCUjiOQ8W3bJL1d8yJCNNsABh8jY=; b=maJ4rKiB5QwN9y5CX788jPAOZIH4uEsFiSTGeBNinlvx4o1mUfTSwwkphVg/Nb9xkU 8o/lPBsPZS/6R+fYhJvgf7EgKvLmPTlLwbrRMiOEiK6wBIA2UN/q2tOPLnRkA+DsrcGr AElQxazKXSE9yw/YoTgv0ssg7qMxxYse6DX3+j6Ld6uY7xaolnmOI2qR43BXtxMhfBkH ibeA4oW+HoVSP6AQQ0NTXjRZjkEb/in0PtSFSv54jjOGzEJJxCfZ+aX+FDNHx7Bk9O2R NDWN+AzbtKJVK41SsYrDShQmODXtJOhkoRJOD5rJN7CMPA/c1tQMvk/SioSGEc5kszTi 2k6g== X-Gm-Message-State: APjAAAXsmyEscDNSIDrGI6K/RG/LZchJY0XVZWIOFt6d3MVwRYHfDE6x 6UEN7kSxq8P2vnSG/Er232V8TJiwalNVY4TdmW0= X-Google-Smtp-Source: APXvYqxxiM2mO/aLsnpAKSMcvLs/BgTh38cmoK2/QqjylHE+Rft6A3BhUpCKOGv5hDcEHEn6J3glHwSjvkVZ4uPZw48= X-Received: by 2002:ae9:eb0b:: with SMTP id b11mr39055315qkg.214.1554998596365; Thu, 11 Apr 2019 09:03:16 -0700 (PDT) MIME-Version: 1.0 References: <1c9bafa8-19a0-e14a-c029-3e8b5c8db929@bellis.me.uk> <80a05f5c-c864-934a-2fb7-fa54289dd574@cs.tcd.ie> <44691328-62A2-4228-BDF3-8D6DD71BC761@fl1ger.de> <1C5AEC6A-CC45-4D5F-B4F1-6510DA98A4DC@fl1ger.de> <25474449-35CC-4230-9636-077BD3067E12@fl1ger.de> In-Reply-To: From: Brian Dickson Date: Thu, 11 Apr 2019 09:03:04 -0700 Message-ID: To: Adam Roach Cc: Ray Bellis , Ralf Weber , Michael Sinatra , add@ietf.org, Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000f66f82058643520d" Archived-At: Subject: Re: [Add] [Doh] Ongoing discussion of DoH, DoT, and related issues X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 16:03:20 -0000 --000000000000f66f82058643520d Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 8:49 AM Adam Roach wrote: > On 4/11/19 9:38 AM, Ray Bellis wrote: > > > > On 11/04/2019 15:31, Ralf Weber wrote: > > > >> Well an API exists, but my understanding was that applications wanted > >> to have more control over the resolution process > > > > Why? > > > > In which consensus document are those requirements stated > > > That's not really the way the word "wanted" works. > I think the question is not "what" you want (which toppings in your analogy), but "why". Specifically, if the application(s) want more privacy (and more security, or at least no less security), why do they want/need to actually control that? Consider a slight difference, where the application doesn't control the resolution process, but is able to verify what that resolution is. And that is why the question/issue I've raised, and that Ray mentions above, is "requirements". The whole purpose of requirements is that that is a necessary element of standardizing things, so you know what the goals are before designing and coding things. So, let me ask again: What requirements (consensus or otherwise) are there, which are driving these changes to DNS resolution (in the larger context)? Brian --000000000000f66f82058643520d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 11, 2019 at 8:49 AM Adam = Roach <adam@nostrum.com> wrot= e:
On 4/11/19 9:= 38 AM, Ray Bellis wrote:
>
> On 11/04/2019 15:31, Ralf Weber wrote:
>
>> Well an API exists, but my understanding was that applications wan= ted
>> to have more control over the resolution process
>
> Why?
>
> In which consensus document are those requirements stated


That's not really the way the word "wanted" works.

I think the question is not "what" you = want (which toppings in your analogy), but "why".

<= /div>
Specifically, if the application(s) want more privacy (and more s= ecurity, or at least no less security), why do they want/need to actually c= ontrol that?
Consider a slight difference, where the application = doesn't control the resolution process, but is able to verify what that= resolution is.

And that is why the question/issue= I've raised, and that Ray mentions above, is "requirements".=

The whole purpose of requirements is that that is= a necessary element of standardizing things, so you know what the goals ar= e before designing and coding things.

So, let me a= sk again:

What requirements (consensus or otherwis= e) are there, which are driving these changes to DNS resolution (in the lar= ger context)?

Brian=C2=A0
=C2=A0
--000000000000f66f82058643520d-- From nobody Thu Apr 11 12:11:58 2019 Return-Path: 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 0CE031203F9 for ; Thu, 11 Apr 2019 12:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net 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 v8xpUEPX9zpA for ; Thu, 11 Apr 2019 12:11:55 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD2F120311 for ; Thu, 11 Apr 2019 12:11:55 -0700 (PDT) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 93F581A6550 for ; Thu, 11 Apr 2019 12:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1555009914; bh=/mSKTM075+xhqYaYay2mGfHxyJ+fmZFbaQ8oKv4zK1I=; h=To:From:Subject:Date:From; b=Q7ueu4DQmFIo1FLkC60Z1lLXuEMYZ5NIh4HclyOkyLIKi22Foz0tvlXE0NdSITnfx IF+CuN8Va9YIc/WNJZaTa4dASURg/g6edAgTKNKGZhibP9UqEQ6gnnpSKJ3tu82GL9 1qegLl5sRspWBheww0mN2+Tj/w2ebm/1xd0WYvec= X-Riseup-User-ID: 40889CEEE18F276D66C871902E445D7C4CA7A0D2700C0D91D8E6EBD2D41B6B79 Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id 2110C1209D6 for ; Thu, 11 Apr 2019 12:11:48 -0700 (PDT) To: add@ietf.org From: nusenu Openpgp: preference=signencrypt Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA== Message-ID: Date: Thu, 11 Apr 2019 19:11:00 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ilNNCuMqkb4laW2eTFubeDGL9gtpoYKWA" Archived-At: Subject: [Add] avoiding unnecessary metadata in applications doing DNS / DoH X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 19:11:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ilNNCuMqkb4laW2eTFubeDGL9gtpoYKWA Content-Type: multipart/mixed; boundary="5hFM8s62SoJvrY8czG0GBTqC6615DU1dn"; protected-headers="v1" From: nusenu To: add@ietf.org Message-ID: Subject: avoiding unnecessary metadata in applications doing DNS / DoH --5hFM8s62SoJvrY8czG0GBTqC6615DU1dn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable DNS never had something like a user-agent field and that is fine,=20 but since browsers send one by default during their (non-DoH) operations it is likely that they and other DoH clients will send the user-agent along with their DoH queries. This exposes unnecessary metadata to the resolver, something that didn't exist on the resolver before DoH. Since RFC8484 does not require user-agent headers applications implementing DoH should not include such metadata by default.=20 Some DoH implementations do it currently but it is early enough to improve that. DoH Privacy Enhancement: Do not set the user-agent header for DoH request= s https://bugzilla.mozilla.org/show_bug.cgi?id=3D1543201 --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --5hFM8s62SoJvrY8czG0GBTqC6615DU1dn-- --ilNNCuMqkb4laW2eTFubeDGL9gtpoYKWA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlyvkWwACgkQrWE4wkXN Qn4QohAAq565DoN9fv1BzcXsSVtABXMnfCMMsYk/aUjXCCIWWTAAEUy0oLPlEYBm o/Gpkc9CPpiXkQeVi/vzzBViawASXn67HoSDjATip8mSy0RwjrHShA8xpUFJ3AQn IBCJZCCUjDhsZyzoWUgi45mGojib7jutgcakI3Vcmfh/+0m6eSXEqbHvn5fbp/QO fuG+GSyFQVVTG1tNxBzZ7gYBwj7eicJHWi+/SCpFghnIp6dpeo8kSFo/4EkkPR2T 1ki7WzUXy2hw4toWI5qp7VPXmUR/qzDnvYbToHRlQBb5avd4gOhjyUQf3d6VflSr YdzBCyLss9SoLliHHiI0qrZ936b84dYBDuRsVJ8ALM+uGts4li2rceFD/uLCmjU7 5++FDhSu4o07OEB2IuzoDNsJg/sxnEXZ+oMrYb3b1WKak1+tmOmu1xGl/KoKy/6j Rkdj8HC/6aTkAUi3xdm1aJFvdh0+ikqfgdIwb19DHF8sJhrL1Iv6mfAoY7dQbahO KSYB/9A5YPbcnYflRqh9grOwtJQHAtN9r2qWJ1jHvrazomoLdciYCIE6r3sGndLU 9vM86mrfkMk9ZmWBOPf9atp6KJUbVECO91VT35S7nsOf/UJ5UJhHaAQqHvdGYiOv gi9iv/YRyHbaE8dJctt1IzPBQ2bZR0e2zUjD6A3KY7SG2qyxf+U= =cESQ -----END PGP SIGNATURE----- --ilNNCuMqkb4laW2eTFubeDGL9gtpoYKWA-- From nobody Thu Apr 11 13:26:34 2019 Return-Path: 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 08C36120326 for ; Thu, 11 Apr 2019 13:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net 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 oQMSWvoD8gjo for ; Thu, 11 Apr 2019 13:26:31 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFED120319 for ; Thu, 11 Apr 2019 13:26:30 -0700 (PDT) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 282441A7E2C for ; Thu, 11 Apr 2019 13:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1555014390; bh=mF7jSprcyFRdysyTxCY3DYDlJWvfmXy4r8DM43ZUb2I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JPyWemdl5/s4wvCdkq8UWayrnbnv+CSYgZO5HDL5z+gkW62vLaS4G+KAF8akZftn7 RaPvtVdWiytTgSfmlUuLb0SsBJZ0RhWvPsYqLqT+quYCoPTGeeVAnQXeaFCi8neyzs 7ywMFWdnjiTvNAOro+H3hbHiccYhEWdX9QFiTaNI= X-Riseup-User-ID: 3B0C8363E62239B3C1B7D10E9853815B12E0B1877E242C1A87D31A280BAE61CE Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id 6E14F120B19 for ; Thu, 11 Apr 2019 13:26:29 -0700 (PDT) To: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <89a677fa-8f14-d029-81fb-6f93d83c98bb@nic.cz> From: nusenu Openpgp: preference=signencrypt Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA== Message-ID: <0e1a7069-5e93-45af-e2e5-3c4ae301e7a8@riseup.net> Date: Thu, 11 Apr 2019 20:26:00 +0000 MIME-Version: 1.0 In-Reply-To: <89a677fa-8f14-d029-81fb-6f93d83c98bb@nic.cz> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OfoGyirkJejkgeyqglc6CLWFUxlqfC6qz" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 20:26:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OfoGyirkJejkgeyqglc6CLWFUxlqfC6qz Content-Type: multipart/mixed; boundary="HhGUaCD58litCSuQaSCkVvJdQ6VtAvAZU"; protected-headers="v1" From: nusenu To: add@ietf.org Message-ID: <0e1a7069-5e93-45af-e2e5-3c4ae301e7a8@riseup.net> Subject: Re: [Add] Mozilla's DoH resolver policy References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <89a677fa-8f14-d029-81fb-6f93d83c98bb@nic.cz> In-Reply-To: <89a677fa-8f14-d029-81fb-6f93d83c98bb@nic.cz> --HhGUaCD58litCSuQaSCkVvJdQ6VtAvAZU Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Vladim=C3=ADr =C4=8Cun=C3=A1t: > OK, so privacy: why not consider padding?=C2=A0 Of course, as long as m= any > webs are without SNI encryption, it's just such a tiny nitpick... > https://tools.ietf.org/html/rfc8467 +1 for padding https://bugzilla.mozilla.org/show_bug.cgi?id=3D1543811 --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --HhGUaCD58litCSuQaSCkVvJdQ6VtAvAZU-- --OfoGyirkJejkgeyqglc6CLWFUxlqfC6qz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlyvovAACgkQrWE4wkXN Qn70IhAAp1ZFjicXbFPY+PHBEcXag4E1HXLIMTYCnmEU7sHCpXkqHi9AdEO2LAq6 SN2/mfwyAI8MOshdFKE3QrLEwYX7GIVfZyJsB6r5JDvfVxiQkJDR3afnlTmpSs7r swzEnXGrFgFjIIBYMS9OZADrkVUvxNJT/l8JNALf40J6TPvXTF7ZDWFRsaTgkfZI QsTu+qckIVxuZyznmQzp94l6qTAdEj8dzPTk2Sn61/cVxiDDoUGxNf+V4IOQEspu 361GR2WL11EgkjGFQqQcUMup7kZL93DhbnccPh21U+grObfcjgQi0sdHyVBFN61b sYjILGMV6aE3sxgRJ8DdmmAzLvMR1SDwDlvgstFQqgtnb9iW4in5TvMc3IgFDFDo rf3x0cVQNl3E9J9QitsPTCLjVpLCHvF9l1Qfwg6MGm2iZQRVPHflRa14ECbcChcf K1I8msk2PQM0ue2N+94yoyUMf4JuHOM6ARsSgZ6Bv0zFs2H7QVTJwoYuQad14yhi a2pYBRg67GMj1DZ5NknGHnPA+2c9Rzi75cg2k9shP7qiFJZq1hz44U4gZ9KdZ6Kg Ejr+y/Si9nYTyUbLURimx39WLm/O9B6Z+af6tXrbpaMITqDplrWkv/Syy45H0gaQ NO8CF+zWlNwrt/aulz2ZMML8b/L8poag+XiMQ9KwQpC7iqngkSQ= =cxtz -----END PGP SIGNATURE----- --OfoGyirkJejkgeyqglc6CLWFUxlqfC6qz-- From nobody Thu Apr 11 13:34:29 2019 Return-Path: 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 F1307120602 for ; Thu, 11 Apr 2019 13:34:22 -0700 (PDT) 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 6iwd9rDoSt6u for ; Thu, 11 Apr 2019 13:34:21 -0700 (PDT) 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 0A7C41205D0 for ; Thu, 11 Apr 2019 13:34:21 -0700 (PDT) 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, 11 Apr 2019 13:34:18 -0700 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, 11 Apr 2019 13:34:18 -0700 From: Paul Hoffman To: Peter Saint-Andre CC: "add@ietf.org" Thread-Topic: [Ext] [Add] Mozilla's DoH resolver policy Thread-Index: AQHU8KXvwBvRx3s4UkuTZVugeIoZAw== Date: Thu, 11 Apr 2019 20:34:18 +0000 Message-ID: <1A4EBCEB-4779-4407-90D5-D1733E0BB9F8@icann.org> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> <6c11589f-fb00-e15d-9c16-a22368351c50@mozilla.com> In-Reply-To: <6c11589f-fb00-e15d-9c16-a22368351c50@mozilla.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: <110DE7D0DD989B419153A8211A269A60@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Add] [Ext] Mozilla's DoH resolver policy X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 20:34:23 -0000 On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre wrote: >> If Firefox is to be taken mainly as a real-life example on this >> mailing-list, is there a suitable Firefox-specific place to discuss >> related issues?=20 >=20 > The Networking:DNS component is the one to watch: >=20 > https://bugzilla.mozilla.org/buglist.cgi?product=3DCore&component=3DNetwo= rking%3A%20DNS&bug_status=3D__open__&list_id=3D14662850 >=20 > We don't (yet) have a discussion list for "Firefox Doing DNS". >=20 >> (Assuming Mozilla is actually interested in that.) >=20 > Feedback is always welcome. :-) Do you mean "feedback on the ADD list" or "feeback in the Bugzilla tracker"= or both? --Paul Hoffman= From nobody Thu Apr 11 13:40:25 2019 Return-Path: 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 352D812031C for ; Thu, 11 Apr 2019 13:40:24 -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 7jYRqWS5n3cW for ; Thu, 11 Apr 2019 13:40:22 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 ED563120310 for ; Thu, 11 Apr 2019 13:40:21 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id n11so6600131ioh.1 for ; Thu, 11 Apr 2019 13:40:21 -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=dk7TRgVS28KAL+lmlQjl9N/is0M3kZJ5g/gWshtRkG8=; b=Gqe5Dlm3IqT0Nx69n2CjqUpenAT8R+cCSrPnQv2WK9VxzySLkpCZdpuoS0Q0RB6W8Z 1II7WOQEhUmg8outlQPISC+3Js9I78IB2gJMrEb4VyBXllYXMOtJSgg0M0bdqe+mJJed E8xiIissUhuwCtB15KiTUOfmaMhxxWUhhpN74= 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=dk7TRgVS28KAL+lmlQjl9N/is0M3kZJ5g/gWshtRkG8=; b=jHT+S9agSSsLU4rJZJksIFOwyFF3sDfkGvlYPopp9I9OAGw4vgLERfxPI+5hfvkbQW gUJLg20i4bxwuxKfCmCfN+qAClKGgZHlpnauga1GfVNguH9fY0m/Y1iW0yWj8EsaADTX J9PtMNyCQqmK6Jacwrzvx+lE2KrGVEtkRy4mWyWrWf/mTD+vBn7x2lETxeOFWIs+AlPj DqgfwiZqMr3uOhqOTEmFSp2LFo3ifnWEKr8W2CPfNoaiwrMem2UWp0mYEC0n28emi0O/ q1gsmnbWo9MuMDAEiXZ01Xq86a2/rSRt5ucrt8zxcIqA9GvLjmmx4PcHt83tARS9yEFI DX7Q== X-Gm-Message-State: APjAAAUh3FfaEtHjriPLxveNikvY4P7XVYNb1e45q0/TWxphpvbnK5wg BUn4AXo4JUoBezjqPsS/uZieRO3T6yc= X-Google-Smtp-Source: APXvYqwu67tHaeMa2ykniCQvTiKjOe4nEDjRrwPJ7BoqbXD8l1Kzys3mL8Bc2DUXr60AwWXAcNumMg== X-Received: by 2002:a6b:5a03:: with SMTP id o3mr2084600iob.9.1555015221242; Thu, 11 Apr 2019 13:40:21 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id t23sm14818838ioj.19.2019.04.11.13.40.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 13:40:20 -0700 (PDT) To: Paul Hoffman Cc: "add@ietf.org" References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> <6c11589f-fb00-e15d-9c16-a22368351c50@mozilla.com> <1A4EBCEB-4779-4407-90D5-D1733E0BB9F8@icann.org> From: Peter Saint-Andre 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: Date: Thu, 11 Apr 2019 14:40:19 -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: <1A4EBCEB-4779-4407-90D5-D1733E0BB9F8@icann.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] [Ext] Mozilla's DoH resolver policy X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 20:40:24 -0000 On 4/11/19 2:34 PM, Paul Hoffman wrote: > On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre wrote: >>> If Firefox is to be taken mainly as a real-life example on this >>> mailing-list, is there a suitable Firefox-specific place to discuss >>> related issues? >> >> The Networking:DNS component is the one to watch: >> >> https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Networking%3A%20DNS&bug_status=__open__&list_id=14662850 >> >> We don't (yet) have a discussion list for "Firefox Doing DNS". >> >>> (Assuming Mozilla is actually interested in that.) >> >> Feedback is always welcome. :-) > > Do you mean "feedback on the ADD list" or "feeback in the Bugzilla tracker" or both? Personally I welcome feedback wherever folks feel comfortable providing it. The discussion lists that Adam Roach mentioned are also appropriate. Peter From nobody Thu Apr 11 13:51:08 2019 Return-Path: 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 DC1011205DE for ; Thu, 11 Apr 2019 13:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 8GSv3p4g7ieJ for ; Thu, 11 Apr 2019 13:51:05 -0700 (PDT) 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 6192D12032E for ; Thu, 11 Apr 2019 13:51:05 -0700 (PDT) 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 x3BKoe93094165 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Apr 2019 15:50:41 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1555015843; bh=Dq+MU4qqQb9q+0DCTeBOJrDITIatsaqfi4hx3Xt2LfQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=XnPkoSIdB0xFDK1M8ISyI98NfCmgm+96IG/TPCUOaO32qVwhJ5UmG5OUjK8YAnq4x NvCns+TcIum49Ma6LCER4mwwIq+cSdOvWY4/s/iMmgc68dmydETmFdZCKX6L0YbhrV o4GJjw3rRFTsOGhdF9ws7FscOofNrMv0XfI9BcJA= 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 , Peter Saint-Andre Cc: "add@ietf.org" References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> <6c11589f-fb00-e15d-9c16-a22368351c50@mozilla.com> <1A4EBCEB-4779-4407-90D5-D1733E0BB9F8@icann.org> From: Adam Roach Message-ID: <5bb4970e-376d-44e8-95cc-0040bc2eac4d@nostrum.com> Date: Thu, 11 Apr 2019 15:50:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1A4EBCEB-4779-4407-90D5-D1733E0BB9F8@icann.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Add] [Ext] Mozilla's DoH resolver policy X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 20:51:07 -0000 On 4/11/19 3:34 PM, Paul Hoffman wrote: > On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre wrote: >>> If Firefox is to be taken mainly as a real-life example on this >>> mailing-list, is there a suitable Firefox-specific place to discuss >>> related issues? >> The Networking:DNS component is the one to watch: >> >> https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Networking%3A%20DNS&bug_status=__open__&list_id=14662850 >> >> We don't (yet) have a discussion list for "Firefox Doing DNS". >> >>> (Assuming Mozilla is actually interested in that.) >> Feedback is always welcome. :-) > Do you mean "feedback on the ADD list" or "feeback in the Bugzilla tracker" or both? > > --Paul Hoffman I think we'd like to prevent the "Applications Doing DNS" list from becoming just the "Mozilla Doing DNS" list. To the extent that you'd like to engage with a broader slice of Mozilla than just those of us who participate in the IETF, I'd encourage you to take Mozilla-specific concerns to the mailing lists I pointed to earlier. You can also comment on bugs in the component that Peter points to, but there's a pretty strict policy of "no advocacy in bugs," so you may find the mailing lists more satisfying. This is probably as good a place as any to point to the code of conduct for these mailing lists: https://www.mozilla.org/en-US/about/governance/policies/participation/ /a From nobody Thu Apr 11 15:47:55 2019 Return-Path: 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 2501A120408 for ; Thu, 11 Apr 2019 15:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 v0UuUN1ANxWL for ; Thu, 11 Apr 2019 15:47:50 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 C8F55120406 for ; Thu, 11 Apr 2019 15:47:49 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id g127so4459340vsd.6 for ; Thu, 11 Apr 2019 15:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/HnqjDE2jLs5OZtnbFB66etXxoL922LJr+fIJPBUoV8=; b=GK52fy4JR3pBr2JYmZfj0ySXdiiducXGSxGhoQUfxy6CK5ua3fzNqALp2movJy0j48 dxkQOaB4TL2OW+/bQLpy2KYk4YHqSrJ4CSoTza5k3+LdaRewB6XQ6HmhJSHE7VEg170s dPPdB8vYhyX4Bn2hFsweuyPic05GMGQdJvxy44fF0Yy1e56qg+tsfRJ4nXTfnMytZgsm XShaQZONKPtScisSG+84lRWn+f8jhIOg0m2pOrpPrINcjz5D2yLZeMz2icIARo/Ggx51 j0JnYj6pAxAuiu+2ZZSC2jClGLGB5OOsru/TJ30DxhvAFJP1xU4p8HheRCBxR0fOWnpV 7+Vw== 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=/HnqjDE2jLs5OZtnbFB66etXxoL922LJr+fIJPBUoV8=; b=X9/HWauo91N1t096SiD94xmewdNxStSGlr4rzqj9SSnic5zD0esJEAuYHQW1cV5wdD IqjCv4v0l0Deb5Slz11SSwYbBU89ZAbKYdbx5k1KAjFFwuWPJ5+N1cU8ICKl+rAbARwX ycF4y38rTGhtcZ/L9o6RNsIzrhnbKRDHo/dNry/k+qXWkOWDWiB0Pk4w+bUA5sfspjVi 6VZLmpiW8s8HPv4nxsX8SIZY9MJRcrdf/uDkHfRWkTF+YQGBrIZLerfNWpvA7Lya6lvc cZo6gvBZT5TO1MknNjpzNFwStRfFSKCzaFTorbRELmm8TnAQaVufGSoXYPlG/TLggHRD Pjkw== X-Gm-Message-State: APjAAAXV0rQWj8V4jLTk5odyH2gx/H9IA6MKBfrwWnDxpM1PkZ23iqxA SKCvJbxJe43NyHBZzOKliNK8Urolz52ao1nkJ0ExWA== X-Google-Smtp-Source: APXvYqzqgB3UXRkl+o5e68RumByCLAEyPyltB6VlKyKTKuRnzX+vkZ31HWtXakzN2EuXS9vuXnLTwVOlSss5+KPKm/M= X-Received: by 2002:a05:6102:199:: with SMTP id r25mr27945088vsq.166.1555022868445; Thu, 11 Apr 2019 15:47:48 -0700 (PDT) MIME-Version: 1.0 References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> In-Reply-To: From: Ben Schwartz Date: Thu, 11 Apr 2019 18:47:37 -0400 Message-ID: To: Brian Dickson Cc: Joe Abley , add@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b9ce2e058648f9be" Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 22:47:53 -0000 --000000000000b9ce2e058648f9be Content-Type: multipart/alternative; boundary="000000000000b17471058648f963" --000000000000b17471058648f963 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 10, 2019 at 3:17 AM Brian Dickson wrote: > [Much of the greatly appreciated flow has been elided by me below, to > highlight one area of concern...] > > On Tue, Apr 9, 2019 at 7:26 AM Joe Abley wrote: > >> Consider an end-user who wants to use some service over the Internet. >> -- Initialisation Phase -- >> >> The end-user uses an application to begin a session with some service or >> other. >> -- Established Phase -- >> >> The application begins to communicate with the service end-points. >> > > The area I want to focus on here, is the distinction between arbitrary > end-users (without admin privileges), and end-users with administrative > privileges on the machine they are using. > > In the former case, in the current world, the user *might* not have the > ability to select, configure, change, override, or do anything with regards > to selection of DNS resolver. > (There are a plethora of reasons why the entity who has administrator > privileges might disable user access to make these changes, such as > third-party DNS resolvers, or custom resolver configurations such as RPZ.) > > In the current world, such a user might attempt to connect to some > arbitrary end-point (such as a web site), and the attempt might fail as a > result of how the DNS resolver that the user's machine is using, is > operated. > > Let's presume there is a good reason for this, and that this prevents the > user from being exposed to something "bad" (for some value of "bad", such > as malware, or offensive content, or similar.) > > In Joe's thought experiment, it would *appear* the user has the ability > to select the service end-point (where the service provides a replacement > DNS resolution that pre-empts the pre-existing DNS resolution as provided > to the user.) > > The result is that the user has been provided the means to make changes to > DNS, *that the administrator of the machine didn't permit*. > I can't parse this claim. In my vocabulary, a non-admin user is defined as a user who can only take actions that the administrator permits. Perhaps you mean "that the administrator permitted unintentionally"? The user is now free to use arbitrary DNS servers, whether they are > trustworthy or malicious. > > The scope of the resulting injury may be limited to that single user on > the machine in question, but depending on what that injury is (e.g. > malware), the consequences may impact more than the individual user, and > may impact other machines on the local network. > > There is also the issue with how user changes can be performed, such as by > modifications to configuration files. > > If there is not some "special sauce" to limit how those configuration > files are able to be changed, the general presumption on multi-user systems > is that the ownership and permissions would need to allow changes by the > user. > Chrome and Firefox have made clear that administrators will have the ability to control the DoH setting, disabling or limiting non-admin users' choice. Perhaps this shows that they agree with you on this point, and intend to support this use case. This in turn means that a malicious application would not require elevated > privileges beyond those of the user in question, to change that user's DNS > resolver, thus lowering the bar for such resolver changes. > > Equally true, would be the impact of someone leaving their machine > unattended with a browser open. Even if the user were not an administrator, > the DNS choice for the user could be changed, which is a much broader and > more subtle attack than browsing to a malicious site directly. > Note that most browsers have long supported proxy settings, so an attacker with access to the browser settings can easily redirect all user traffic to a machine of their choosing. This is of course just one of myriad ways that an attacker with full login access can compromise your security. In general, I think the IETF has done well to consider such attacks out of scope for our work. NB: All of the above is the situation where the user does not have > administrative privileges, but enables the user to expose him/herself to > hostile resolvers and hostile content as a result, with knock-on effects. > > In contrast, a user who does have administrative privileges (such as > someone who owns their own machine), would already have the ability to > change DNS resolvers, so nothing particularly new happens as a result of > these changes. > (But also, the need for the user to make those changes via the application > is a moot issue; the user can already make the change directly on their > system.) > > TL; DR: the ability for a user to select an encrypted channel to a DNS > resolver, is in and of itself a privilege escalation, if the user is not a > machine administrator. > I disagree with this characterization. Users who can install arbitrary software (e.g. SSH, Windows Remote Desktop, Opera Mini) have always been able to send DNS over such an encrypted channel. Users who can only install software selected by their administrator will continue to perform DNS only in the manner permitted by their administrator. There's nothing new here. > And once the channel is established, control has already been lost. > > Brian > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000b17471058648f963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 10, 2019 at 3:17 AM Brian= Dickson <brian.peter.dickson@gmail.com> wrote:
[Much of the greatl= y appreciated flow has been elided by me below, to highlight one area of co= ncern...]

On Tue, Apr 9, 2019 at 7:26 AM Joe Abley <jabley@hopcount.ca> wrote:
Consider an = end-user who wants to use some service over the Internet.=C2=A0
-= - Initialisation Phase --

The end-user uses an app= lication to begin a session with some service or other.=C2=A0
-- = Established Phase --

The application begins to com= municate with the service end-points.

The area I want to focus on here, is the distinction between arbitra= ry end-users (without admin privileges), and end-users with administrative = privileges on the machine they are using.

In the f= ormer case, in the current world, the user might not have the abilit= y to select, configure, change, override, or do anything with regards to se= lection of DNS resolver.
(There are a plethora of reasons why the= entity who has administrator privileges might disable user access to make = these changes, such as third-party DNS resolvers, or custom resolver config= urations such as RPZ.)

In the current world, such = a user might attempt to connect to some arbitrary end-point (such as a web = site), and the attempt might fail as a result of how the DNS resolver that = the user's machine is using, is operated.

Let&= #39;s presume there is a good reason for this, and that this prevents the u= ser from being exposed to something "bad" (for some value of &quo= t;bad", such as malware, or offensive content, or similar.)
=
In Joe's thought experiment, it would appear the = user has the ability to select the service end-point (where the service pro= vides a replacement DNS resolution that pre-empts the pre-existing DNS reso= lution as provided to the user.)

The result is tha= t the user has been provided the means to make changes to DNS, that the = administrator of the machine didn't permit.

I can't parse this claim.=C2=A0 In my vocabu= lary, a non-admin user is defined as a user who can only take actions that = the administrator permits.=C2=A0 Perhaps you mean "that the administra= tor permitted unintentionally"?

The user is now free to use arbitrary DNS servers, whether they are = trustworthy or malicious.

The scope of the resulti= ng injury may be limited to that single user on the machine in question, bu= t depending on what that injury is (e.g. malware), the consequences may imp= act more than the individual user, and may impact other machines on the loc= al network.

There is also the issue with how user = changes can be performed, such as by modifications to configuration files.= =C2=A0

If there is not some "special sauce&qu= ot; to limit how those configuration files are able to be changed, the gene= ral presumption on multi-user systems is that the ownership and permissions= would need to allow changes by the user.=C2=A0

Chrome and Firefox have made clear that administrato= rs will have the ability to control the DoH setting, disabling or limiting = non-admin users' choice.=C2=A0 Perhaps this shows that they agree with = you on this point, and intend to support this use case.

This in turn means that a malicious application wo= uld not require elevated privileges beyond those of the user in question, t= o change that user's DNS resolver, thus lowering the bar for such resol= ver changes.

Equally true, would be the impact of = someone leaving their machine unattended with a browser open. Even if the u= ser were not an administrator, the DNS choice for the user could be changed= , which is a much broader and more subtle attack than browsing to a malicio= us site directly.

Note th= at most browsers have long supported proxy settings, so an attacker with ac= cess to the browser settings can easily redirect all user traffic to a mach= ine of their choosing.=C2=A0 This is of course just one of myriad ways that= an attacker with full login access can compromise your security.=C2=A0 In = general, I think the IETF has done well to consider such attacks out of sco= pe for our work.

NB: All of the= above is the situation where the user does not have administrative privile= ges, but enables the user to expose him/herself to hostile resolvers and ho= stile content as a result, with knock-on effects.

= In contrast, a user who does have administrative privileges (such as someon= e who owns their own machine), would already have the ability to change DNS= resolvers, so nothing particularly new happens as a result of these change= s.
(But also, the need for the user to make those changes via the= application is a moot issue; the user can already make the change directly= on their system.)

TL; DR: the ability for a user = to select an encrypted channel to a DNS resolver, is in and of itself a pri= vilege escalation, if the user is not a machine administrator.
<= /div>

I disagree with this characterization= .=C2=A0 Users who can install arbitrary software (e.g. SSH, Windows Remote = Desktop, Opera Mini) have always been able to send DNS over such an encrypt= ed channel.=C2=A0 Users who can only install software selected by their adm= inistrator will continue to perform DNS only in the manner permitted by the= ir administrator.

There's nothing new here.
=C2=A0
<= div dir=3D"ltr">
And once the channel is es= tablished, control has already been lost.

Brian
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000b17471058648f963-- --000000000000b9ce2e058648f9be Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAaL3BBR5dTStlASRolxP3y DY+IxHbiovmzqU/f+TB49DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA0MTEyMjQ3NDlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAN8YrTpsSeVeNDqn/mZ+1GpcyVBMTpU0GmcHvTvhx pKYPduok4x1luyruyhayJfEdwppliWlRDZXSa/XdLc7JY9v2kAwVeSyablS3LbFSMtrNy/sdFze4 z+eBCpthgkyfAs3+2N1LHbpe9lQWWLjVwl22Q16+bu03y15YN2OwKlLhi4pg/qg6HS0RhJd+j4gd Hj5px8i1ncIjJRZAQkoYYCYtjRrOmdIImrpdwX4OJurFdj4YGbwOXXk9TmsVJvJ/ogdYVTDfyIXR qe1y5QNzv8mvaeOEg0JHP1belufkHEIbvWR8veVeh1eARHuDqBz7kWsSEWANiReo4LZ1jZ3exA== --000000000000b9ce2e058648f9be-- From nobody Thu Apr 11 17:14:55 2019 Return-Path: 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 246FD12009E for ; Thu, 11 Apr 2019 17:14:53 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 lh3vXIUrfqxU for ; Thu, 11 Apr 2019 17:14:50 -0700 (PDT) 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 8D7DD120013 for ; Thu, 11 Apr 2019 17:14:50 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id o129so4631217qke.8 for ; Thu, 11 Apr 2019 17:14:50 -0700 (PDT) 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=JIlSCApWuySzXnQayu2fDIGm5CVF6UGbjk0EAfJUnXo=; b=D+JDyFX21PIDydgD0ZnEQ9eVvqXJWQF/eUkS2SJLFAnaD//VF775ScXpsT2SZrBlE8 IN3lXYI6Y3tOK8S1BvvOlCyxV0HGbH9/u8kYAeyCNmr/o9nz6dmcI4T74+Ae0w7/tH3n lLtlumVHcylxEBjXlxTMy/Oibi4XjXqijmQNHsWBqB0Y5ZKwhPk/CRZRvtuu4ijmiXzJ LFpkIWi3U+vRnOJmooJtlKkPJ60luRq5059O3yV+cm2oktzgbAoWPQm0qq6iv+mMuomZ F786W3Uf9hSyJ16BF2Q9gQK1P3QNJ1HxVTEtrjOZZ3NynGM6lDUoW/6LxPnMm9cHXXRd 9lYQ== 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=JIlSCApWuySzXnQayu2fDIGm5CVF6UGbjk0EAfJUnXo=; b=bWLBIb63gRd127mjfHeoiT9V9dGJywV48BKl7esoMqumyNAP81nj4UqWO/Rx/GhjQ9 FQSF1LkcebsfsIyvpytbLGF6/dKOR49PJpBDAhkHo5DGef6kw0InZlKbmX9tUmHWKQwI BVsSHFbcqtOQopgHHmLj+dKbGY3b+WRqqzauQvRN6nmOmwbQETV3/mMK9fnaalu9wR43 2AtsElZGPV5Vk65+Wi2RBn9bIWvwwbHwdeg/Ol+jFKzDGTSP3pcHuamdCIJiATRa5v6y TQAGxZLsUyqZ6jwomSOYrc4dWVQs6nDrFgYb7dZueaFUrchzwt9wr65IwrUKJcC4TH75 TDRA== X-Gm-Message-State: APjAAAVGfIxYxG3W4wEBwYBzzKQseXLD1Zd0GSU4vgqaXEg0OsMXbR6G /+yYUeWc4Ceu19SDP/61lHsEaOTb2W90H1WzXN4= X-Google-Smtp-Source: APXvYqxnldHaPMK3yo3OOdZ4ZvvoYbC9qfVNo5Y92W0mWTg9aQrV4MWyEaO3Rt1CUvvOpA8CMsAWyBHUeBamThMtokk= X-Received: by 2002:ae9:eb0b:: with SMTP id b11mr41160152qkg.214.1555028089649; Thu, 11 Apr 2019 17:14:49 -0700 (PDT) MIME-Version: 1.0 References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> In-Reply-To: From: Brian Dickson Date: Thu, 11 Apr 2019 17:14:37 -0700 Message-ID: To: Ben Schwartz Cc: Joe Abley , add@ietf.org Content-Type: multipart/alternative; boundary="000000000000e63eb505864a30e8" Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 00:14:53 -0000 --000000000000e63eb505864a30e8 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 3:47 PM Ben Schwartz wrote: > > > On Wed, Apr 10, 2019 at 3:17 AM Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> >> In Joe's thought experiment, it would *appear* the user has the ability >> to select the service end-point (where the service provides a replacement >> DNS resolution that pre-empts the pre-existing DNS resolution as provided >> to the user.) >> >> The result is that the user has been provided the means to make changes >> to DNS, *that the administrator of the machine didn't permit*. >> > > I can't parse this claim. In my vocabulary, a non-admin user is defined > as a user who can only take actions that the administrator permits. > Perhaps you mean "that the administrator permitted unintentionally"? > Not really. The distinction I'm trying to make is the following: - Assume the administrator installs the browser as the administrator has always installed the browser, with the defaults unchanged. (Pretty common, IMHO.) - Assume that the {network,system} administrator(s) use DNS as a control point, including limiting access to outside DNS resolvers. (Also fairly common.) - If the software, in its default configuration, enables the user to select arbitrary HTTPS servers for DNS resolution, this is user-level configuration which has the effect of overriding system-level (and locked) configurations. (This is what is proposed, and even ships in Firefox if you visit 'about:config'.) - So, while technically true that it falls into "permitted unintentionally", that puts the blame on the victim, in this case the administrator. For example, the administrator may be very familiar with DNS, and may not be familiar with changes to an application's capabilities or defaults. E.g. From a security/interface perspective, consider that currently the configuration elements do NOT actually contain a name component called 'DNS'. Unless I had been closely following a bunch of mailing lists and reading release notes, I would not know to look for 'trr' as the component affecting DNS. I also would not have been able to find it by looking at the stock user preferences, as only non-default preferences are saved; I literally had to use 'strings' in the binary, or read the source, to determine the variables. > > The user is now free to use arbitrary DNS servers, whether they are >> trustworthy or malicious. >> >> The scope of the resulting injury may be limited to that single user on >> the machine in question, but depending on what that injury is (e.g. >> malware), the consequences may impact more than the individual user, and >> may impact other machines on the local network. >> >> There is also the issue with how user changes can be performed, such as >> by modifications to configuration files. >> >> If there is not some "special sauce" to limit how those configuration >> files are able to be changed, the general presumption on multi-user systems >> is that the ownership and permissions would need to allow changes by the >> user. >> > > Chrome and Firefox have made clear that administrators will have the > ability to control the DoH setting, disabling or limiting non-admin users' > choice. Perhaps this shows that they agree with you on this point, and > intend to support this use case. > That may be true, but does not change the fact that in the stock configuration, non-privileged users will have access (and already have access!!!) to this capability, i.e. to over-ride DNS resolver choice. The other problem with this is that, if the administrators fail to make such a configuration change, the only way to DETECT their error is by looking for the mistake, ON THE SPECIFIC HOST. The encrypted transport over port 443 is the secondary issue, or maybe primary issue. Yes, the administrator can fix the issue, IF they know about it. But, their existing tool set will not alert them to the error. This also means BYOD is dead. It isn't so much a question of whether the administrators can disable a feature, it is whether it is on-by-default (or even simple enabled for use) on a system where there are unprivileged users. On a machine owned by the (only) user, an off-by-default configuration isn't a significant roadblock. Alternatively, different builds based on single-user systems (installed in user's home directory) versus multi-user systems (installed centrally) may be sufficient to address the concern. I would like to see a commitment to do that, however. > > This in turn means that a malicious application would not require elevated >> privileges beyond those of the user in question, to change that user's DNS >> resolver, thus lowering the bar for such resolver changes. >> >> Equally true, would be the impact of someone leaving their machine >> unattended with a browser open. Even if the user were not an administrator, >> the DNS choice for the user could be changed, which is a much broader and >> more subtle attack than browsing to a malicious site directly. >> > > Note that most browsers have long supported proxy settings, so an attacker > with access to the browser settings can easily redirect all user traffic to > a machine of their choosing. This is of course just one of myriad ways > that an attacker with full login access can compromise your security. In > general, I think the IETF has done well to consider such attacks out of > scope for our work. > You're mixing apples and oranges, by combining the DNS semantics with the HTTP semantics. Currently, DNS is, in many enterprise settings, a critical component of both monitoring and mitigating a variety of security issues (mostly malware, but also data exfiltration). Suggesting that, because this new DNS stuff happens in the browser, that it shouldn't be treated as a DNS issue, will probably raise the ire of folks in the security, DNS, enterprise, and anti-malware spaces. It doesn't matter what other things have already been possible, IMHO, what matters is the new things that are enabled. The bypassing of existing INTERNAL DNS controls, in an enterprise environment, is a HUGE deal, and one reason lots of folks are interested in discussing both the problem spaces and potential solution spaces. DNS complements other stuff that browsers do, in protecting users; the phrase "belt and suspenders" is an appropriate analogy. Making changes that don't provide equivalent enterprise-level controls over user DNS configuration limitations, (and specifically in the shipped default settings), is akin to removing either the belt or suspenders. It means that there is now only one element preventing one's pants from being located at one's ankles. (Use of a disturbing visual in the analogy is deliberate. :-) ) > > NB: All of the above is the situation where the user does not have >> administrative privileges, but enables the user to expose him/herself to >> hostile resolvers and hostile content as a result, with knock-on effects. >> >> In contrast, a user who does have administrative privileges (such as >> someone who owns their own machine), would already have the ability to >> change DNS resolvers, so nothing particularly new happens as a result of >> these changes. >> (But also, the need for the user to make those changes via the >> application is a moot issue; the user can already make the change directly >> on their system.) >> >> TL; DR: the ability for a user to select an encrypted channel to a DNS >> resolver, is in and of itself a privilege escalation, if the user is not a >> machine administrator. >> > > I disagree with this characterization. > [snip] > Users who can only install software selected by their administrator will > continue to perform DNS only in the manner permitted by their administrator. > Currently, there is no "in the manner". Use of the passive voice obscures the change, unfortunately. It is a change compared to the current DNS environment, demonstrably: - DNS is configured only by the administrator, either through a system configuration mechanism local to the system, or handled via DHCP (but not capable of being altered by a non-admin user). What HAS changed (or more precisely, "will have changed") is that a DEFAULT configuration of a browser (I say default, as this is what the existing builds are configured to enable, and public statements by the browser vendors support this as the intended configuration), WILL enable user bypass of DNS resolver choice which had previously been configured by the administrator. Enabling this change of mode SHOULD require an active configuration by the administrator, and NOT be the consequence of inaction. Currently, the proposed scenario is the latter. Brian --000000000000e63eb505864a30e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 11, 2019 at 3:47 PM Ben S= chwartz <bemasc@google.com> = wrote:


On Wed, Apr 10, 2019 at 3:17 AM Brian Dickson= <bri= an.peter.dickson@gmail.com> wrote:

In Joe's thought experiment, it would appear the = user has the ability to select the service end-point (where the service pro= vides a replacement DNS resolution that pre-empts the pre-existing DNS reso= lution as provided to the user.)

The result is tha= t the user has been provided the means to make changes to DNS, that the = administrator of the machine didn't permit.

I can't parse this claim.=C2=A0 In my vocabu= lary, a non-admin user is defined as a user who can only take actions that = the administrator permits.=C2=A0 Perhaps you mean "that the administra= tor permitted unintentionally"?
Not really.
The distinction I'm trying to make is= the following:
  • Assume the administrator installs the bro= wser as the administrator has always installed the browser, with the defaul= ts unchanged. (Pretty common, IMHO.)
  • Assume that the {network,syste= m} administrator(s) use DNS as a control point, including limiting access t= o outside DNS resolvers. (Also fairly common.)
  • If the software, in = its default configuration, enables the user to select arbitrary HTTPS serve= rs for DNS resolution, this is user-level configuration which has the effec= t of overriding system-level (and locked) configurations. (This is what is = proposed, and even ships in Firefox if you visit 'about:config'.)
  • So, while technically true that it falls into "permitted uninte= ntionally", that puts the blame on the victim, in this case the admini= strator.
For example, the administrator may be very familiar with = DNS, and may not be familiar with changes to an application's capabilit= ies or defaults.=C2=A0

E.g. From a security/interf= ace perspective, consider that currently the configuration elements do NOT = actually contain a name component called 'DNS'.
Unless I = had been closely following a bunch of mailing lists and reading release not= es, I would not know to look for 'trr' as the component affecting D= NS.
I also would not have been able to find it by looking at the = stock user preferences, as only non-default preferences are saved; I litera= lly had to use 'strings' in the binary, or read the source, to dete= rmine the variables.
=C2=A0

The user is now free to use arbitrary DNS servers= , whether they are trustworthy or malicious.

The s= cope of the resulting injury may be limited to that single user on the mach= ine in question, but depending on what that injury is (e.g. malware), the c= onsequences may impact more than the individual user, and may impact other = machines on the local network.

There is also the i= ssue with how user changes can be performed, such as by modifications to co= nfiguration files.=C2=A0

If there is not some &quo= t;special sauce" to limit how those configuration files are able to be= changed, the general presumption on multi-user systems is that the ownersh= ip and permissions would need to allow changes by the user.=C2=A0

Chrome and Firefox have made clear= that administrators will have the ability to control the DoH setting, disa= bling or limiting non-admin users' choice.=C2=A0 Perhaps this shows tha= t they agree with you on this point, and intend to support this use case.

That may be true, but does= not change the fact that in the stock configuration, non-privileged users = will have access (and already have access!!!) to this capability, i.e. to o= ver-ride DNS resolver choice.

The other problem wi= th this is that, if the administrators fail to make such a configuration ch= ange, the only way to DETECT their error is by looking for the mistake, ON = THE SPECIFIC HOST.
The encrypted transport over port 443 is the s= econdary issue, or maybe primary issue.
Yes, the administrator ca= n fix the issue, IF they know about it. But, their existing tool set will n= ot alert them to the error.
This also means BYOD is dead.

It isn't so much a question of whether the admini= strators can disable a feature, it is whether it is on-by-default (or even = simple enabled for use) on a system where there are unprivileged users.

On a machine owned by the (only) user, an off-by-defa= ult configuration isn't a significant roadblock. Alternatively, differe= nt builds based on single-user systems (installed in user's home direct= ory) versus multi-user systems (installed centrally) may be sufficient to a= ddress the concern. I would like to see a commitment to do that, however.
=C2=A0

<= div>This in turn means that a malicious application would not require eleva= ted privileges beyond those of the user in question, to change that user= 9;s DNS resolver, thus lowering the bar for such resolver changes.

Equally true, would be the impact of someone leaving their= machine unattended with a browser open. Even if the user were not an admin= istrator, the DNS choice for the user could be changed, which is a much bro= ader and more subtle attack than browsing to a malicious site directly.

Note that most browsers have= long supported proxy settings, so an attacker with access to the browser s= ettings can easily redirect all user traffic to a machine of their choosing= .=C2=A0 This is of course just one of myriad ways that an attacker with ful= l login access can compromise your security.=C2=A0 In general, I think the = IETF has done well to consider such attacks out of scope for our work.

You're mixing apples and = oranges, by combining the DNS semantics with the HTTP semantics.
=
Currently, DNS is, in many enterprise settings, a critical c= omponent of both monitoring and mitigating a variety of security issues (mo= stly malware, but also data exfiltration).

Suggest= ing that, because this new DNS stuff happens in the browser, that it should= n't be treated as a DNS issue, will probably raise the ire of folks in = the security, DNS, enterprise, and anti-malware spaces.

It doesn't matter what other things have already been possible, I= MHO, what matters is the new things that are enabled. The bypassing of exis= ting INTERNAL DNS controls, in an enterprise environment, is a HUGE deal, a= nd one reason lots of folks are interested in discussing both the problem s= paces and potential solution spaces.

DNS complemen= ts other stuff that browsers do, in protecting users; the phrase "belt= and suspenders" is an appropriate analogy.

M= aking changes that don't provide equivalent enterprise-level controls o= ver user DNS configuration limitations, (and specifically in the shipped de= fault settings), is akin to removing either the belt or suspenders. It mean= s that there is now only one element preventing one's pants from being = located at one's ankles. (Use of a disturbing visual in the analogy is = deliberate. :-) )
=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
NB: All of the above is the situation where the user= does not have administrative privileges, but enables the user to expose hi= m/herself to hostile resolvers and hostile content as a result, with knock-= on effects.

In contrast, a user who does have admi= nistrative privileges (such as someone who owns their own machine), would a= lready have the ability to change DNS resolvers, so nothing particularly ne= w happens as a result of these changes.
(But also, the need for t= he user to make those changes via the application is a moot issue; the user= can already make the change directly on their system.)

TL; DR: the ability for a user to select an encrypted channel to a DN= S resolver, is in and of itself a privilege escalation, if the user is not = a machine administrator.

= I disagree with this characterization.=C2=A0
=
[snip]=C2=A0
Users who can only install = software selected by their administrator will continue to perform DNS only = in the manner permitted by their administrator.

Currently, there is no "in the manner". Us= e of the passive voice obscures the change, unfortunately.=C2=A0
= It is a change compared to the current DNS environment, demonstrably:
=
  • DNS is configured only by the administrator, either through a = system configuration mechanism local to the system, or handled via DHCP (bu= t not capable of being altered by a non-admin user).
Wh= at HAS changed (or more precisely, "will have changed") is that a= DEFAULT configuration of a browser (I say default, as this is what the exi= sting builds are configured to enable, and public statements by the browser= vendors support this as the intended configuration), WILL enable user bypa= ss of DNS resolver choice which had previously been configured by the admin= istrator.

Enabling this change of mode SHOULD requ= ire an active configuration by the administrator, and NOT be the consequenc= e of inaction. Currently, the proposed scenario is the latter.
= =C2=A0
Brian
--000000000000e63eb505864a30e8-- From nobody Thu Apr 11 17:24:39 2019 Return-Path: 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 A60C81200F9 for ; Thu, 11 Apr 2019 17:24:37 -0700 (PDT) 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 USE_XoBB3tqs for ; Thu, 11 Apr 2019 17:24:35 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 5075412007C for ; Thu, 11 Apr 2019 17:24:35 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id k130so4663921qke.3 for ; Thu, 11 Apr 2019 17:24:35 -0700 (PDT) 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=fJwINI/OdbKIAuiZJjB8hA2yN5gLwqcAGwoOs9YlL0g=; b=Bzw9sun81ZCQ+Z/O5dTtHNbXITZgL3YYLoIvVNxo2ImFajHuFgAtEzDu2eX5r02Dfp Gun7R3sXsh/mh79CC++mSJUyllcHvO3F8DA0MwjipGy8wbnALef8eKszmkgDxzcZzS5j 703An3SSGB06jtWS7VlPHjpes8igyh+TnHrsB2g7bBP4Bh9VjU5ECqS/Bk9dMZcmhQPS ddzmXfUXAUww4i5ArEyMABFWxgUPFIPvhgrrGWoz0qQuGH6x/PJHJb6WBKNqbcQMbteC 4lxyE681RdLmGKuKsVt/RsMHjiix1xPMM6GYshD2cYiO8eHeIpy5j5byGeu1yPBNAFq4 y9oQ== 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=fJwINI/OdbKIAuiZJjB8hA2yN5gLwqcAGwoOs9YlL0g=; b=ZwBAZ4NEADZ1lhwFC1bLntU5vU4tJw+8DPVS+licCOcEi015oAQiYLV2HZ6Hy/VlmE Ci4hN8+TN3gQ0gChmejkUvoWgtvHW+dNuowarsgTmNhumNYvhGVjtrN6GVSFG+4lhchr kB71t+2B/lZ1HRVXwacE4gm8MxUT6aCBvhdx8RZsuzGl67bQm3xxluyGu1r2IESU+7Y+ V6FXKu43YKbNvKtDl/3GBIHhEweQZGAr05yQapkTCBh49bDD1Ryhyh1rXX2OsO91Y1Hy YLuOzMK+dRO28QcHmyhZ/O3syXuymFizwBIDC3rspA7I8OyVH5ZQTNiD60LRal1SLexc Hb5A== X-Gm-Message-State: APjAAAV8nwTjUaj3jGPgD16vfxHxFvFlTanw14SmWM+VvdO7qep/S4yJ 2U++VZcvD7KlMS1lnCLzfGCHPlL7SXlFJ6f4Juk= X-Google-Smtp-Source: APXvYqw2r+2GxjODDP8oapWxWP6PmKITyBHRkXzySXVebuYZsaiowU9knBZzVowGJcnlKrfkZyzccJXin8mYHAat6+k= X-Received: by 2002:a37:dd8:: with SMTP id 207mr41772421qkn.278.1555028674366; Thu, 11 Apr 2019 17:24:34 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> <6c11589f-fb00-e15d-9c16-a22368351c50@mozilla.com> <1A4EBCEB-4779-4407-90D5-D1733E0BB9F8@icann.org> <5bb4970e-376d-44e8-95cc-0040bc2eac4d@nostrum.com> In-Reply-To: <5bb4970e-376d-44e8-95cc-0040bc2eac4d@nostrum.com> From: Brian Dickson Date: Thu, 11 Apr 2019 17:24:23 -0700 Message-ID: To: Adam Roach Cc: Paul Hoffman , Peter Saint-Andre , "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c04fe105864a5356" Archived-At: Subject: Re: [Add] [Ext] Mozilla's DoH resolver policy X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 00:24:38 -0000 --000000000000c04fe105864a5356 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 1:51 PM Adam Roach wrote: > On 4/11/19 3:34 PM, Paul Hoffman wrote: > > On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre > wrote: > >>> If Firefox is to be taken mainly as a real-life example on this > >>> mailing-list, is there a suitable Firefox-specific place to discuss > >>> related issues? > >> The Networking:DNS component is the one to watch: > >> > >> > https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Networking%3A%20DNS&bug_status=__open__&list_id=14662850 > >> > >> We don't (yet) have a discussion list for "Firefox Doing DNS". > >> > >>> (Assuming Mozilla is actually interested in that.) > >> Feedback is always welcome. :-) > > Do you mean "feedback on the ADD list" or "feeback in the Bugzilla > tracker" or both? > > > > --Paul Hoffman > > > I think we'd like to prevent the "Applications Doing DNS" list from > becoming just the "Mozilla Doing DNS" list. To the extent that you'd > like to engage with a broader slice of Mozilla than just those of us who > participate in the IETF, I'd encourage you to take Mozilla-specific > concerns to the mailing lists I pointed to earlier. > Hmm... I disagree on multiple distinct fronts. One is "Note Well", whereby all the IETF protections/restrictions are applied to IETF-hosted mailing lists and all other IETF activities. I believe there is benefit in keeping this discussion here. The second is, even if some of these appear to be Mozilla issues, those are mostly because they're visible (not sure if "first" applies, but it could as well). Whatever surfaces here, is valuable to capture here, as a way of helping inform anyone else that tries to do similar stuff (whether in a browser, or in any other app) in future. At a minimum, being able to search this mailing list is probably very helpful. The third issue is that whatever is done, might well be appropriate to "standardize", at least in the sense of establishing expectations for how any given vendor should do whatever is being done. Ideally, the outcome could be actual interoperability between apps and some common "substrate", whether it is implemented as an API, a protocol (if we can consider "loopback" as qualifying for "on-the-wire" treatment), or a configuration file or set of files. Note that DNS itself standardized on the "master file format" for zones, even though that was one specific implementation of not-on-the-wire data (plus some metadata?). So, from the DNS perspective, it has significant precedence which is maintained, including on such things as "presentation format" (which often is a 1:1 mapping for "master file format"). Brian --000000000000c04fe105864a5356 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 11, 2019 at 1:51 PM Adam = Roach <adam@nostrum.com> wrot= e:
On 4/11/19 3:= 34 PM, Paul Hoffman wrote:
> On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre <stpeter@mozilla.com> wrote: >>> If Firefox is to be taken mainly as a real-life example on thi= s
>>> mailing-list, is there a suitable Firefox-specific place to di= scuss
>>> related issues?
>> The Networking:DNS component is the one to watch:
>>
>> https://bugzilla.mozilla.= org/buglist.cgi?product=3DCore&component=3DNetworking%3A%20DNS&bug_= status=3D__open__&list_id=3D14662850
>>
>> We don't (yet) have a discussion list for "Firefox Doing = DNS".
>>
>>> (Assuming Mozilla is actually interested in that.)
>> Feedback is always welcome. :-)
> Do you mean "feedback on the ADD list" or "feeback in t= he Bugzilla tracker" or both?
>
> --Paul Hoffman


I think we'd like to prevent the "Applications Doing DNS" lis= t from
becoming just the "Mozilla Doing DNS" list. To the extent that yo= u'd
like to engage with a broader slice of Mozilla than just those of us who participate in the IETF, I'd encourage you to take Mozilla-specific concerns to the mailing lists I pointed to earlier.
Hmm...

I disagree on multiple distinc= t fronts.
One is "Note Well", whereby all the IETF prot= ections/restrictions are applied to IETF-hosted mailing lists and all other= IETF activities. I believe there is benefit in keeping this discussion her= e.

The second is, even if some of these appear to = be Mozilla issues, those are mostly because they're visible (not sure i= f "first" applies, but it could as well).

Whatever surfaces here, is valuable to capture here, as a way of helping = inform anyone else that tries to do similar stuff (whether in a browser, or= in any other app) in future.
At a minimum, being able to search = this mailing list is probably very helpful.

The th= ird issue is that whatever is done, might well be appropriate to "stan= dardize", at least in the sense of establishing expectations for how a= ny given vendor should do whatever is being done.

= Ideally, the outcome could be actual interoperability between apps and some= common "substrate", whether it is implemented as an API, a proto= col (if we can consider "loopback" as qualifying for "on-the= -wire" treatment), or a configuration file or set of files.
=
Note that DNS itself standardized on the "master file f= ormat" for zones, even though that was one specific implementation of = not-on-the-wire data (plus some metadata?). So, from the DNS perspective, i= t has significant precedence which is maintained, including on such things = as "presentation format" (which often is a 1:1 mapping for "= master file format").

Brian
--000000000000c04fe105864a5356-- From nobody Thu Apr 11 17:41:14 2019 Return-Path: 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 0125B12035F for ; Thu, 11 Apr 2019 17:41:13 -0700 (PDT) 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=HWuXg7Zr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=7+Y5Gs5r 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 0ZFbS7ARA1yQ for ; Thu, 11 Apr 2019 17:41:11 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0E8120356 for ; Thu, 11 Apr 2019 17:41:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C5E3123317 for ; Thu, 11 Apr 2019 20:41:09 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 11 Apr 2019 20:41:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=Lvt5dTvRQWAZ0p2cTxsEYz41ZR2X4xg zLuOjRdnRtNw=; b=HWuXg7Zr3aZuW6R2awuPhiFYQwgFcdt8vC+VbhU6WpNHhIL dRn1lkU7ARSmjIQ1ey5icIn6GZ8tAZhV6qeh2dBZaRNiP1/l5j8ka2AYqnqT1uec sQpzO7t+GYlRoZQ3B7qeLOw6HPPules8Nk1It3zCwpzSR+1HreHVMYz3sAcL9wDn +bkPE/JsNDNdHx426Hdgujx4V34/cAN+7boTpXzjWxTho/Oft17263c9oDyStJkW KSd5a+0tw5O+FtWAuI6fxeQNol6zL+gQ8PQusshn6uKFoSmJoRPYKw4vhNxNx7oI JKMGbrsiFoySwjDRK/2Mfs0922tA8uPy9nd61KA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=Lvt5dT vRQWAZ0p2cTxsEYz41ZR2X4xgzLuOjRdnRtNw=; b=7+Y5Gs5r1/2+321hkT/Lfq 4xmMBgxIcwSCdxgt0xDOkxnmpCk0TjNI8p+VXdsbp6oKEDJiGa+efCT+6SFpxmNR 3p+k+wzWVW62qhFODHwVUcBan2d/fKc05CwohDoQIrIF3zP8DPD9lC1u+ABdzr8t X2/qfXqczFVb9qtrYK4HMJsCs+XbbHlkCngQkATf8ZgdSkdz/FGCveyy6ZZcbYYl +/ozunm43qBkJU+IKFsPJM5BCVltDv0RjyQCJn6GGkA/DWJQamtkqHJ1sFmFAS+b kfVXM1iDWpaWf0zYLETMznEII1DVL2pye5mtP+PeibXBR2H1bNnm4sp9jJXaL5jw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrvddtgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3822E7C131; Thu, 11 Apr 2019 20:41:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-329-gf4aae99-fmstable-20190329v1 Mime-Version: 1.0 X-Me-Personality: 92534000 Message-Id: In-Reply-To: References: Date: Thu, 11 Apr 2019 20:41:14 -0400 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] =?utf-8?q?avoiding_unnecessary_metadata_in_applications_do?= =?utf-8?q?ing_DNS_/_DoH?= X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 00:41:13 -0000 On Fri, Apr 12, 2019, at 05:12, nusenu wrote: > Since RFC8484 does not require user-agent headers > applications implementing DoH should not include > such metadata by default. What additional entropy does User-Agent provide that is not already present in - for example - the pattern of TLS extensions or HTTP/2 settings that are sent during connection establishment? From nobody Thu Apr 11 19:07:04 2019 Return-Path: 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 0A899120369 for ; Thu, 11 Apr 2019 19:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 T2oZKd91WuZc for ; Thu, 11 Apr 2019 19:07:01 -0700 (PDT) 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 11D31120052 for ; Thu, 11 Apr 2019 19:07:01 -0700 (PDT) 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 x3C26aC6044661 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Apr 2019 21:06:37 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1555034798; bh=MT8XhgelHrQaZJj+Y/JKiBh3iGmLnYfn5Joo6WxInjA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=H1qXGFzBqwMNrGjSg0o8gWfPhx9Z4ko6d7LmpGzQwJeJFFwZ8bboAc2SfnpcaHspu zBnGSi6wjZ7qxk/UYbpYXhFMjsWttuocxeneaibRKHx2yn0Nqvj06JhVt7HHnHLkLn p91UCXJXEcdrUapsYRNYcxTIUk765+N5ubO1aF60= 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: Brian Dickson Cc: Paul Hoffman , Peter Saint-Andre , "add@ietf.org" References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> <6c11589f-fb00-e15d-9c16-a22368351c50@mozilla.com> <1A4EBCEB-4779-4407-90D5-D1733E0BB9F8@icann.org> <5bb4970e-376d-44e8-95cc-0040bc2eac4d@nostrum.com> From: Adam Roach Message-ID: <15e8ab14-44a3-33a4-8f1b-8e3c18739c00@nostrum.com> Date: Thu, 11 Apr 2019 21:06:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A005F776C20407CC8FCE5C35" Content-Language: en-US Archived-At: Subject: Re: [Add] [Ext] Mozilla's DoH resolver policy X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 02:07:03 -0000 This is a multi-part message in MIME format. --------------A005F776C20407CC8FCE5C35 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 4/11/19 7:24 PM, Brian Dickson wrote: > > > On Thu, Apr 11, 2019 at 1:51 PM Adam Roach > wrote: > > On 4/11/19 3:34 PM, Paul Hoffman wrote: > > On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre > > wrote: > >>> If Firefox is to be taken mainly as a real-life example on this > >>> mailing-list, is there a suitable Firefox-specific place to > discuss > >>> related issues? > >> The Networking:DNS component is the one to watch: > >> > >> > https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Networking%3A%20DNS&bug_status=__open__&list_id=14662850 > >> > >> We don't (yet) have a discussion list for "Firefox Doing DNS". > >> > >>> (Assuming Mozilla is actually interested in that.) > >> Feedback is always welcome. :-) > > Do you mean "feedback on the ADD list" or "feeback in the > Bugzilla tracker" or both? > > > > --Paul Hoffman > > > I think we'd like to prevent the "Applications Doing DNS" list from > becoming just the "Mozilla Doing DNS" list. To the extent that you'd > like to engage with a broader slice of Mozilla than just those of > us who > participate in the IETF, I'd encourage you to take Mozilla-specific > concerns to the mailing lists I pointed to earlier. > > > Hmm... > > I disagree on multiple distinct fronts. I'll repeat the most important words from my previous message, as your response indicates that you skipped over them: "To the extent that you'd like to engage with a broader slice of Mozilla than just those of us who participate in the IETF..." /a --------------A005F776C20407CC8FCE5C35 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 4/11/19 7:24 PM, Brian Dickson wrote:


On Thu, Apr 11, 2019 at 1:51 PM Adam Roach <adam@nostrum.com> wrote:
On 4/11/19 3:34 PM, Paul Hoffman wrote:
> On Apr 11, 2019, at 8:46 AM, Peter Saint-Andre <stpeter@mozilla.com> wrote:
>>> If Firefox is to be taken mainly as a real-life example on this
>>> mailing-list, is there a suitable Firefox-specific place to discuss
>>> related issues?
>> The Networking:DNS component is the one to watch:
>>
>> https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Networking%3A%20DNS&bug_status=__open__&list_id=14662850
>>
>> We don't (yet) have a discussion list for "Firefox Doing DNS".
>>
>>> (Assuming Mozilla is actually interested in that.)
>> Feedback is always welcome. :-)
> Do you mean "feedback on the ADD list" or "feeback in the Bugzilla tracker" or both?
>
> --Paul Hoffman


I think we'd like to prevent the "Applications Doing DNS" list from
becoming just the "Mozilla Doing DNS" list. To the extent that you'd
like to engage with a broader slice of Mozilla than just those of us who
participate in the IETF, I'd encourage you to take Mozilla-specific
concerns to the mailing lists I pointed to earlier.

Hmm...

I disagree on multiple distinct fronts.



I'll repeat the most important words from my previous message, as your response indicates that you skipped over them: "To the extent that you'd like to engage with a broader slice of Mozilla than just those of us who
participate in the IETF..."

/a

--------------A005F776C20407CC8FCE5C35-- From nobody Thu Apr 11 19:42:48 2019 Return-Path: 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 F3BC9120405 for ; Thu, 11 Apr 2019 16:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 owGxqzyqPD9X for ; Thu, 11 Apr 2019 16:39:49 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 EA1C91203F6 for ; Thu, 11 Apr 2019 16:39:46 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id k32so2643502uae.3 for ; Thu, 11 Apr 2019 16:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e3ji9uEMGPoGl1TUJ+ba1E1qL6Oiv8FHqiUWuTd4j+c=; b=R6YzcJHKesufuD2j30dvzYfE9dc3fZqSFjF838xfMnlfqUIeVlx+CDbYa6NxKYBPDB Nn00YwWQAjXMXWpzhBDCV2YHOGWq/L5Jg+JAEiRE4Amb4xXMEGVcvSqsuSrNcnm1MG7k IbfIuXo7mcchqp4E98yay356YdTK0sprvmRJ7quJFgDieKvT5/YXucEzNtlD7Zg3FZqu I+I7QY0ff4wq5kQoCwIMMJQR/K5KxApdwqOAurPnCVdSQkHfvG/6LBhj89cfi1f+2fNN 8sRt8epkninwYaGte86eyJ7D0wlJYq4O+jx4ecwjrk9BfDo6qYDHN+x+gJUysztgO0U2 Q4SA== 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=e3ji9uEMGPoGl1TUJ+ba1E1qL6Oiv8FHqiUWuTd4j+c=; b=Nrvh8ycU9X/PP9cNSy264E8mGfFOJI8I11dvdfA//HQ82qVV2EYh7Iot6lUdq5yo7X aYlRiVLES2Kfy+XrvOyChmFtMh+4RO8HBN+Nsge+/YjqNzdLs2Rb1srouI1gj0YW5xM2 N8SfJrxiVUGXaXwmDqnN3SnUj0Y8tK1PHfBei6/8exeeH3nznE+Ql/+IU7WJoxP1dwl+ BSm9lXRD4JqZmanpeCLEVNbLt8QFyFP3GpovJc5dMRof0gtUNaM5jScqQAG0MveMgRMj ol+F4ZfhIf23RkOsp8wfjtT5fqcYPpTj2I79aei3/u/3goqvUk/0if8rgyS9T0daA6XT mAdA== X-Gm-Message-State: APjAAAXhDy8OEMecJ9X3pLDAsCNBWFKv3tV6qUkJL8TF+1Bc+M0wNWiO 6SzX5oTSYBNE+fEK+s9XfpQQfKAe+arKPPquz5rM5Q== X-Google-Smtp-Source: APXvYqze0P0PPr+wHy4uqHvNv+7xI/iPBOWj7+m6/QxunGrWDWpJ9Re9nRphX6gy0/nYfpckCoQGoLOEcuC6PNs1Q5E= X-Received: by 2002:a9f:2c09:: with SMTP id r9mr26777342uaj.56.1555025985351; Thu, 11 Apr 2019 16:39:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Thu, 11 Apr 2019 19:39:34 -0400 Message-ID: To: nusenu Cc: dns-privacy@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000083d2ce058649b3c5" Archived-At: X-Mailman-Approved-At: Thu, 11 Apr 2019 19:42:46 -0700 Subject: Re: [Add] avoiding unnecessary metadata in applications doing DNS / DoH X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 23:39:51 -0000 --00000000000083d2ce058649b3c5 Content-Type: multipart/alternative; boundary="000000000000799d58058649b3be" --000000000000799d58058649b3be Content-Type: text/plain; charset="UTF-8" Moving thread from ADD to DPRIVE. I would suggest reaching out to the authors of https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 if you're interested in advancing that line of work. One major challenge related to User-Agent is forming a workable threat model. It seems likely that an interested server could easily identify distinct user agents, even without this header field. For example, the TLS fingerprint alone is sufficient to uniquely identify most TLS implementations[1], and different HTTP/2 implementations produce different framing patterns. Active probing (e.g. returning slightly invalid responses and observing how the client reacts) would likely allow the server to identify the client software completely. It's harder to motivate this kind of protection if it only works against "friendly" servers, especially because the User-Agent is extremely useful for server operations, capacity planning, etc. The DOHPE draft also contains several other suggestions (e.g. removing locale and language preference information) that may be easier to justify. [1] https://tlsfingerprint.io/ On Thu, Apr 11, 2019 at 3:12 PM nusenu wrote: > > DNS never had something like a user-agent field and that is fine, > but since browsers send one by default during their (non-DoH) operations > it is likely that they and other DoH clients will send the user-agent > along with their DoH queries. > > This exposes unnecessary metadata to the resolver, something that > didn't exist on the resolver before DoH. > > Since RFC8484 does not require user-agent headers > applications implementing DoH should not include > such metadata by default. > Some DoH implementations do it currently but it is early > enough to improve that. > > > DoH Privacy Enhancement: Do not set the user-agent header for DoH requests > https://bugzilla.mozilla.org/show_bug.cgi?id=1543201 > > > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000799d58058649b3be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Moving thread from ADD to DPRIVE.

I would suggest reaching out to the authors of=C2=A0https://tools.ietf.org/html/= draft-dickinson-doh-dohpe-00=C2=A0if you're interested in advancing= that line of work.

One major challenge related to User-= Agent is forming a workable threat model.=C2=A0 It seems likely that an int= erested server could easily identify distinct user agents, even without thi= s header field.=C2=A0 For example, the TLS fingerprint alone is sufficient = to uniquely identify most TLS implementations[1], and different HTTP/2 impl= ementations produce different framing patterns.=C2=A0 Active probing (e.g. = returning slightly invalid responses and observing how the client reacts) w= ould likely allow the server to identify the client software completely.

It's harder to motivate this kind of protection = if it only works against "friendly" servers, especially because t= he User-Agent is extremely useful for server operations, capacity planning,= etc.

The DOHPE draft also contains several other = suggestions (e.g. removing locale and language preference information) that= may be easier to justify.


On Thu, Apr 11= , 2019 at 3:12 PM nusenu <nus= enu-lists@riseup.net> wrote:

DNS never had something like a user-agent field and that is fine,
but since browsers send one by default during their (non-DoH) operations it is likely that they and other DoH clients will send the user-agent
along with their DoH queries.

This exposes unnecessary metadata to the resolver, something that
didn't exist on the resolver before DoH.

Since RFC8484 does not require user-agent headers
applications implementing DoH should not include
such metadata by default.
Some DoH implementations do it currently but it is early
enough to improve that.


DoH Privacy Enhancement: Do not set the user-agent header for DoH requests<= br> https://bugzilla.mozilla.org/show_bug.cgi?id= =3D1543201



--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000799d58058649b3be-- --00000000000083d2ce058649b3c5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBS4aouAXEsFW4KS8Jag1Jc c0+2RXAtUNMdmutFSA01FzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA0MTEyMzM5NDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEARWZrEZD7yoY/2lrPCYIP5Q/L94sNr/EHZSZfLWHh GCYOmMZ3687LySjEzzHQetEecc4ZIsGh2Kzhi01+fA6OjlbA8JJn52DeJbsdqBcWxYCXJavN2Njf i8/BI2bnpaUsKKF6x/2BONOzGkCDOMety6AgAtWXeaYmlWBEtdu9ClaV1SgHMfDfKUFX9R4Qknfx oKvZxBLPM6ofG7mehVRNVFNiMIz7glpBeeEO/bg4LuZ4x5OcNAGOJSL4eCOroIUnfRUoh7zpFEfp AsUjayLWKK62U5M8lWc9Nfwf0wR8rFchRETQEKud9TtyN7pUyDAByA51b5dtrf4fhnBu6HEJUw== --00000000000083d2ce058649b3c5-- From nobody Thu Apr 11 19:56:26 2019 Return-Path: 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 66E2D1204AD for ; Thu, 11 Apr 2019 19:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=deD3e+f3; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=ePmvyecR 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 kxSdLc7xXqqf for ; Thu, 11 Apr 2019 19:56:22 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEF41204D6 for ; Thu, 11 Apr 2019 19:56:22 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1555037781; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=t1oOmmsjinP/jUMY8oRHbhdyANRoo9tmV3bWD3e5it0=; b=deD3e+f3vGQDYYaBi89uzQ57Ah4loPSQ2Lgsxvr5jwolkcGmiIeRFsAT fFoS0CXWtwq5VtOhAyO2BAQL+FzEDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1555037781; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=t1oOmmsjinP/jUMY8oRHbhdyANRoo9tmV3bWD3e5it0=; b=ePmvyecRWYvZFarwfVFoXTPolt6bVZMG7kxNHCPspBj6qYnkr9mJMrwi XhOi2eMN5rhH7zmb4Drx8ozHFbSKijsGzjhUxmYQKED19VXaSI1WWvsDTS bmAcbJRh1VmmB68FYpBp2cP39yw5OXebE2rOLy12jQTrfJhwBp6pL8RTks EtLrWui4DIn3hPo2oFL/AwCcIfHZBYX/xjpR6UMtoYdq1tCRmnpPFL1DP8 FtF4Y1GRU5NeyG/zzq7sSpMeObnuLaASQpS79tDn/nqLN/X58Y3rfvGoeW bapC+zFym6+ljhE9+Fxqq85lmlccdZcN65S4BkTkYritFVrkZMvflw== Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 8119FF99E; Thu, 11 Apr 2019 22:56:20 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CAADD2019D; Thu, 11 Apr 2019 22:43:45 -0400 (EDT) From: Daniel Kahn Gillmor To: Martin Thomson , add@ietf.org In-Reply-To: References: Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 11 Apr 2019 22:43:45 -0400 Message-ID: <87ftqo7xjy.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Add] avoiding unnecessary metadata in applications doing DNS / DoH X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 02:56:24 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu 2019-04-11 20:41:14 -0400, Martin Thomson wrote: > On Fri, Apr 12, 2019, at 05:12, nusenu wrote: >> Since RFC8484 does not require user-agent headers >> applications implementing DoH should not include >> such metadata by default.=20 > > What additional entropy does User-Agent provide that is not already > present in - for example - the pattern of TLS extensions or HTTP/2 > settings that are sent during connection establishment? This argument (and Ben Schwartz's) are both examples of the leaky-boat approach to problem-not-solving. The leaky boat approach is where you point out to me that the boat is leaking under my seat. I then point out that i am not going to bother fixing the leak under me, because the boat is also leaking under you. If we don't reduce the entropy of (standardize) the User-Agent because it only leaks the same entropy as TLS extensions settings, then we might as well also not standardize TLS extensions because any standardization effort will be moot due to the same leakage in the User-Agent. This beautifuly circular argument also works between UA and H2 settings, or between H2 settings and TLS extensions themselves. If we follow this line of reasoning, we can't possibly try to address any of them without addressing all of them at once. and everyone knows that addressing all of them at once is impossible, so why bother trying? This is a great way to decide that you will simply never fix something, by claiming that it's impossible to do so. But in the real world, if you want a large problem fixed, you need to tackle individual pieces. Solving the first individual piece might not give you *anything* in the way of addressing your goal, but you need to take it anyway if you want to solve the second piece, and so on. let's not make that mistake. Rather, let's try to fix things that we know contribute to the concerns that people are raising, even if we can't fix them all a once. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXK/7YQAKCRB2GBllKa5f +FNmAQCA2KX62hND9y6RJy29pWsYEuRWC1O2+VXZTqRcVTpxKQEAwT/B6KdRHA3p B2zyeFVVXXVzrU0IDpZhKYZHtvwbFAc= =Zcbo -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 12 04:36:42 2019 Return-Path: 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 944301202A1 for ; Fri, 12 Apr 2019 04:36:40 -0700 (PDT) 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 hJ4wOo77cHoR for ; Fri, 12 Apr 2019 04:36:38 -0700 (PDT) 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 94C991202A3 for ; Fri, 12 Apr 2019 04:36:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE2C6BE53; Fri, 12 Apr 2019 12:36:34 +0100 (IST) 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 oR1AiSFufIRV; Fri, 12 Apr 2019 12:36:33 +0100 (IST) 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 3D8A1BE2E; Fri, 12 Apr 2019 12:36:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1555068993; bh=g7xcIPWD8oPaAN2gwNeVmFPm+zG4mSCbC08COvGfb5Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rl/UTnTi14ev+Rq0m5fz0Wt2T2DydGkBoUl3q6xF1Sj2kkAyMyeblj4kQppqj/vD/ IDfpoIfcGsbf2q+slCHbjQ9aN0ODkQTFFp7rClffhrsem/MEsXvYYW5cmgMD3QoJwo tI1G42uWh2GhzWtDYp4cDTI/CvxKyLL20gXYybX4= To: Daniel Kahn Gillmor , Martin Thomson , add@ietf.org References: <87ftqo7xjy.fsf@fifthhorseman.net> 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: <29c99cf0-e703-4827-9d9e-fcdb005b5b0d@cs.tcd.ie> Date: Fri, 12 Apr 2019 12:36:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87ftqo7xjy.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bPytIoeqy86saLUojnXBVq7CCPyY27ddP" Archived-At: Subject: Re: [Add] avoiding unnecessary metadata in applications doing DNS / DoH X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 11:36:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bPytIoeqy86saLUojnXBVq7CCPyY27ddP Content-Type: multipart/mixed; boundary="6EQLlEcDCFN77taIgC2KmeOO5ewaa7REL"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , Martin Thomson , add@ietf.org Message-ID: <29c99cf0-e703-4827-9d9e-fcdb005b5b0d@cs.tcd.ie> Subject: Re: [Add] avoiding unnecessary metadata in applications doing DNS / DoH References: <87ftqo7xjy.fsf@fifthhorseman.net> In-Reply-To: <87ftqo7xjy.fsf@fifthhorseman.net> --6EQLlEcDCFN77taIgC2KmeOO5ewaa7REL Content-Type: multipart/mixed; boundary="------------5B2C044A12ADE17C38C8D8D0" Content-Language: en-GB This is a multi-part message in MIME format. --------------5B2C044A12ADE17C38C8D8D0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +many to DKG below. And in this specific situation there's an additional reason: getting closer to systemic equivalence with Do53 and DoT that do not have as much leakiness. Cheers, S. On 12/04/2019 03:43, Daniel Kahn Gillmor wrote: > On Thu 2019-04-11 20:41:14 -0400, Martin Thomson wrote: >> On Fri, Apr 12, 2019, at 05:12, nusenu wrote: >>> Since RFC8484 does not require user-agent headers >>> applications implementing DoH should not include >>> such metadata by default.=20 >> >> What additional entropy does User-Agent provide that is not already >> present in - for example - the pattern of TLS extensions or HTTP/2 >> settings that are sent during connection establishment? >=20 > This argument (and Ben Schwartz's) are both examples of the leaky-boat > approach to problem-not-solving. The leaky boat approach is where you > point out to me that the boat is leaking under my seat. I then point > out that i am not going to bother fixing the leak under me, because the= > boat is also leaking under you. >=20 > If we don't reduce the entropy of (standardize) the User-Agent because > it only leaks the same entropy as TLS extensions settings, then we migh= t > as well also not standardize TLS extensions because any standardization= > effort will be moot due to the same leakage in the User-Agent. This > beautifuly circular argument also works between UA and H2 settings, or > between H2 settings and TLS extensions themselves. >=20 > If we follow this line of reasoning, we can't possibly try to address > any of them without addressing all of them at once. and everyone knows= > that addressing all of them at once is impossible, so why bother trying= ? >=20 > This is a great way to decide that you will simply never fix something,= > by claiming that it's impossible to do so. >=20 > But in the real world, if you want a large problem fixed, you need to > tackle individual pieces. Solving the first individual piece might not= > give you *anything* in the way of addressing your goal, but you need to= > take it anyway if you want to solve the second piece, and so on. >=20 > let's not make that mistake. Rather, let's try to fix things that we > know contribute to the concerns that people are raising, even if we > can't fix them all a once. >=20 > --dkg >=20 >=20 --------------5B2C044A12ADE17C38C8D8D0 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------5B2C044A12ADE17C38C8D8D0-- --6EQLlEcDCFN77taIgC2KmeOO5ewaa7REL-- --bPytIoeqy86saLUojnXBVq7CCPyY27ddP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyweEAACgkQWrL68XsX K+rWgRAArk8pwTPu+hSEJZHd2xEDgtQgkR//q1WJ1FNA/OCIiP0Enk9PyBJS9PgQ 8Bf72ibc/qGDehOq2jlzZMcxUnZ0Ule0Zt/Udn21bXbBra9BGXGkUGmTnlnrPw9z CqmJLgowPdr6n+qxWn6nKEFM+/HEQvhsfhtxG51G858rYQJCFaqk7x+0zcWUeGGz yirGb0+lbXhN53uNmhPtBBcm1mG48CUHaJjsGI56oVXEvMzOr6rognkxzhk69D9J /IzXO+unpztq0xDqB4x0+xb416v6iF4AjlgHvRTKAgVZ4kYbvyMWUkKwBG2yV23d cvnxN8+HSsbFQCQtiyXpCymudbYbku4m6VE90hX0VelFK2ayJmjeFZ/H9ocgzIiQ 5HjYIhj5HRdMKVRRtAfZFUdr5f5/ODk+t2iaZjqLMfHBGpkClsO8UFY1kfjkoOOB GWANwpnTm9U7xIqQnDY78NdX9mr4dxNNk/fYH2cvc9qgQ/ynGEqYaVFcnJQnYfad PrlXhTZv0PAxYU+q62QAuFYIW3xjPRUw71BvKwthSjZEO6DXDWrEzPoFC5tpvyLz 0w9WVSsuv+1OTOcnRcsLNmpQ2C78Md+DzoIXINuBfjyNx5xLHnLQbOOsF3157TaC Oe42Oj6BhozgBUGlI9Jyv2GG3PQGcPBbaqq+ZFu+Ih23Y5PjwUE= =rVtF -----END PGP SIGNATURE----- --bPytIoeqy86saLUojnXBVq7CCPyY27ddP-- From b13253@gmail.com Fri Apr 12 01:38:48 2019 Return-Path: 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 D592212018D for ; Fri, 12 Apr 2019 01:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wDZeRT_bFHnk for ; Fri, 12 Apr 2019 01:38:47 -0700 (PDT) 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 69A38120096 for ; Fri, 12 Apr 2019 01:38:47 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id z76so5142256qkb.12 for ; Fri, 12 Apr 2019 01:38:47 -0700 (PDT) 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; bh=oIEvr43JKq0hQwz+lc0KiP/F8pPAR4Y2bhfdvzfTjRA=; b=T322BW9Qy2s1U9H4fEEaahIK99QmZia+sMn5O93Jlk0k3+BzmlpkS9lvaOT2CBwZE/ /5TPd5LYJ4DP7ot8gOa52mvTOacbWelKOK6Hy/cd5dgL2kqBenmQ0kOfK74SEm2ImtxA j3sZ5vEoRY/KQhcfFzcFK3sfq9jz8Cn5I8uqXHHXkdIQGaQACUMY5WlbmfAymYq+Rw4v wJmWWoDaaV8oO2BwypOgJPMdap2BIY3ieGUJ0y2L/vL6jgQcO5y7pBWbXpqWyDjeNhJC YTDW2cvpocAZ22jTWq6bpxkoFObsVXOksBjCVzMXm0FX5+p9prvRxQMJEd5qsqGvGnZE X50g== 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; bh=oIEvr43JKq0hQwz+lc0KiP/F8pPAR4Y2bhfdvzfTjRA=; b=QB+0x3UJN0ITI6hSzAdXmSGFNoyA6gj0agvNTuJhqxXuPi89U/Y0qTTwYVxVvE9Eek 1/x5jlE/KU9qP07RTImocH9b4ykc4Fke6ztJ8VPQBPoDfdYzs6xmI3VKD4HNrqwbgse8 s+vEvm0119Dk2Gx/LpbwXwLjgGA/FnEcEKvebtYlrcskQIsBoSx+I5PN07GJWUU10mN/ wZEyZNmYicH1fJq2cMy8Mi4aMa33q0WmFxtspGTzUY98LZu7JnFkzLbDEr8kNYEYrf5Z vYwD2fyzqYMNeQfrUsyuZDBZBXNZf5Ed6l/elNnnxmG36fyDGE882ayTm+fAS5k83fme qYrg== X-Gm-Message-State: APjAAAVbEhS+Ym+GYe/ORwvnRKx031MCE2VQxMVDJtZP5MvwR2MgWQLY UCUGzUp6ndJFxFrM3QLzuC+kPu7oFFs6wBOGdCnwIpZIHZY= X-Google-Smtp-Source: APXvYqweF+ygr/9lk4l2HzUgTtTCVSVouC9EhjYr7DVcysAQSQA0FrrNIAjIuPPWVBMkkueYLU8q4MCKpJC5kGCPw+M= X-Received: by 2002:a05:620a:13e7:: with SMTP id h7mr17823114qkl.269.1555058326295; Fri, 12 Apr 2019 01:38:46 -0700 (PDT) MIME-Version: 1.0 References: <87ftqo7xjy.fsf@fifthhorseman.net> In-Reply-To: <87ftqo7xjy.fsf@fifthhorseman.net> From: StarBrilliant Date: Fri, 12 Apr 2019 16:38:10 +0800 Message-ID: To: add@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] avoiding unnecessary metadata in applications doing DNS / DoH X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 11:38:26 -0000 On Fri, Apr 12, 2019 at 10:56 AM Daniel Kahn Gillmor wrote: > On Thu 2019-04-11 20:41:14 -0400, Martin Thomson wrote: > > On Fri, Apr 12, 2019, at 05:12, nusenu wrote: > >> Since RFC8484 does not require user-agent headers > >> applications implementing DoH should not include > >> such metadata by default. > > > > What additional entropy does User-Agent provide that is not already > > present in - for example - the pattern of TLS extensions or HTTP/2 > > settings that are sent during connection establishment? > > This argument (and Ben Schwartz's) are both examples of the leaky-boat > approach to problem-not-solving. The leaky boat approach is where you > point out to me that the boat is leaking under my seat. I then point > out that i am not going to bother fixing the leak under me, because the > boat is also leaking under you. > > If we don't reduce the entropy of (standardize) the User-Agent because > it only leaks the same entropy as TLS extensions settings, then we might > as well also not standardize TLS extensions because any standardization > effort will be moot due to the same leakage in the User-Agent. This > beautifuly circular argument also works between UA and H2 settings, or > between H2 settings and TLS extensions themselves. > > If we follow this line of reasoning, we can't possibly try to address > any of them without addressing all of them at once. and everyone knows > that addressing all of them at once is impossible, so why bother trying? > > This is a great way to decide that you will simply never fix something, > by claiming that it's impossible to do so. > > But in the real world, if you want a large problem fixed, you need to > tackle individual pieces. Solving the first individual piece might not > give you *anything* in the way of addressing your goal, but you need to > take it anyway if you want to solve the second piece, and so on. > > let's not make that mistake. Rather, let's try to fix things that we > know contribute to the concerns that people are raising, even if we > can't fix them all a once. Hi, Actually this question was already discussed in the past while RFC 8484 was being proposed. I want to give some reasons we concluded why it is a bad idea not to suppress User-Agent. 1) User-Agent makes it possible to workaround bad implementations or old versions. (e.g. I use User-Agent to workaround a bug in an old version of Firefox, in my https://github.com/m13253/dns-over-https implementation.) 2) Disabling User-Agent does not make it more private because we still have TLS fingerprint and H/2 fingerprint. Additionally, different DNS parsers have subtle differences which can be probed with malformed packets or certain responses. 3) Whenever certain clients are known to have vulnerabilities, the server warn the users to upgrade their client software by detecting the version number in User-Agent. Best regards, StarBrilliant From nobody Fri Apr 12 05:51:25 2019 Return-Path: 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 B15AD12049A for ; Fri, 12 Apr 2019 05:51:23 -0700 (PDT) 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 (2048-bit key) header.d=open-xchange.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 IJE2Lp1yHB-5 for ; Fri, 12 Apr 2019 05:51:22 -0700 (PDT) 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 A0D651204AC for ; Fri, 12 Apr 2019 05:51:19 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [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 96F9A6A26A; Fri, 12 Apr 2019 14:51:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1555073477; bh=9ndA+piL+Uu0/ZnaOkxLMFPX6nbLCLGOjLDpfEMxH20=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=fo47IabC9o2Ao5F3Vo+jbytLRnaEulQiWEM5Owqfr5167zgZwiGPu8nyuQnf4m77B rKHXANBD1OSCNYAH2RuhCHcAPmT6ldMmpndSmXAow7nLT8RlKTxtMXvqNdFX1ynQj8 eV1eF9iB/Hgv6WyrY9aKnd4Sk5aSEjCw1iIRWNmiQ7X7Xcunu1zt7ADyXEvE1Bz/l8 8I3FaBCTPZ0lbNJURMsKyRQpyi+HCfOXQqPR2gIxiOA7YacYs6QDNDdS34KZdsLRzW lpbQfGLwBNhsNXjtq9W+yuZ4/ffaMrjxoHu1fpAM/QivWnyMZaos9qkgA2kgIKiLZW yA3T6Hoy+YVYA== 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 894133C036E; Fri, 12 Apr 2019 14:51:17 +0200 (CEST) Date: Fri, 12 Apr 2019 14:51:17 +0200 (CEST) From: Vittorio Bertola To: Peter Saint-Andre Cc: add@ietf.org Message-ID: <2117970434.22779.1555073477503@appsuite.open-xchange.com> In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.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-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 12:51:24 -0000 > Il 11 aprile 2019 alle 18.02 Peter Saint-Andre ha scritto: > > We (Mozilla) do not want to encourage centralization, which is why we > have published criteria for becoming a trusted recursive resolver within > Firefox. In our conversations with various stakeholders, we have seen a > desire for the kind of industry-wide effort you mention. Although it's > too early to say whether something like that will come together, we are > very much open to discussions exploring that direction. Well, let's have them :) and I also heard such desire from several people. I guess this kind of effort is not in topic for the IETF; maybe, as for DNSSEC, ISOC and/or ICANN could act as the hosts of a "Do* deployment" initiative that would also discuss the non-technical parts that are missing. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Apr 12 09:02:37 2019 Return-Path: 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 D55FC1202E0 for ; Fri, 12 Apr 2019 09:02:35 -0700 (PDT) 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=unavailable 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 WM3hBzRaTmnq for ; Fri, 12 Apr 2019 09:02:33 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F30C1200E6 for ; Fri, 12 Apr 2019 09:02:32 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id AB71B206EE; Fri, 12 Apr 2019 09:02:31 -0700 (PDT) From: Wes Hardaker To: Peter Saint-Andre Cc: Vittorio Bertola , Ralf Weber , Martin Thomson , add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> Date: Fri, 12 Apr 2019 09:02:31 -0700 In-Reply-To: (Peter Saint-Andre's message of "Thu, 11 Apr 2019 10:02:45 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 16:02:36 -0000 Peter Saint-Andre 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: 1) Regardless of how many items you have listed, most of your users will take the default. Have you considered randomly selecting defaults for each user? If they all pass your policy test, then this should be acceptable? 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. Have you considered randomly rotating all queries through every item in the list, or turning the list into a series of checkboxes instead of a single-choice radio dialog to avoid centralizing my privacy (which suddenly becomes less private)? -- Wes Hardaker USC/ISI From nobody Fri Apr 12 10:14:07 2019 Return-Path: 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 ; 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 ; 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 ; Fri, 12 Apr 2019 10:14:02 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id v10so9097366iom.8 for ; 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 Cc: add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> From: Peter Saint-Andre 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: 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From nobody Fri Apr 12 10:55:08 2019 Return-Path: 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 17F89120260 for ; Fri, 12 Apr 2019 10:55:06 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 WXzM_dCBwEtW for ; Fri, 12 Apr 2019 10:55:03 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 920921200B1 for ; Fri, 12 Apr 2019 10:55:03 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id n11so9249429ioh.1 for ; Fri, 12 Apr 2019 10:55:03 -0700 (PDT) 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=SwEdZ3ZfeMspKZRJ4JBsN1oN2DGPQ1mAjbrOen8tJH0=; b=E+Lm6ZFsjawawsxWHjXWy3uWnbre8JKFEXRo2stDTwVnBlZ0zY7AfjVXw/NZh59wot eRRMxGZz0Xd9ED6b5luF3Kc/8dtRGac3hmOZqg3/Nz6oi81ePSQyrRMNB5CsZvtGlYi2 B3PqVksVTprMzjMj4s7/cjW8GouNcEN6u22GoQ4tbO9IBqxEds+nsmks9AsWZd+WJYD8 WN2IOwZmCFykE1+O4ugUPwgRBaoHfrOpQEKKI+e9dKix1Rp96DTw5lrNIit3bLCtyRcY 180u7rDaoQWhT0UBDTIqmRVplW9OoowHB+c/r4KQDKgMSIW6NVjvcXWMNib+qJdfIZ1J 5y8Q== 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=SwEdZ3ZfeMspKZRJ4JBsN1oN2DGPQ1mAjbrOen8tJH0=; b=FszTwqbLu7Xj1Qhsi+UDH/XPLefDqJeHHEqcqNiVSJJJJFte6Iqfl4gyRVDjmaBQKP 9vvMH9Uppi+ZmNRjrohP3foSkBEcq7CjSP1fCgUf6Q+HTRqk4JyJ8TUlbsV0JeQFvRj1 SOE6u3CSu67jCLTMoNwaQz32YuykYvBVPMNNcrec8NInq9HAmz0dSTJ7DWZwxAqDvl0q rVLWt23kk88l+eyiLtUj4+Kq0dYgs6G9SezrkUEtmtRv55QlmNsUxMoyu8rV3kxKvKuq 0gbLxzr5YRUnDDv07NIAilx3XF+xJ01jk6O1qk0XgROJJLWkr6lpyFKJG+VtB1KZQ4Sl UdtA== X-Gm-Message-State: APjAAAXwOjRVIRtrOMGdAC/ugA8ceiO5ytfeMgIegk79G0U2c01lKyI3 tLSpuUjtu+M5nnVW9pLcBqNKU6xZk4U5C+P4YMFFvw== X-Google-Smtp-Source: APXvYqw8AKUrxXcQr9bEa5Z2Hb+weT6NCF4rcXO6ScUk0HH6vwVZUytomOL0WwOl2IOJaJjFE/Av4kNUBGEdIqGE05k= X-Received: by 2002:a6b:6f09:: with SMTP id k9mr633645ioc.163.1555091702619; Fri, 12 Apr 2019 10:55:02 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> In-Reply-To: From: Ted Hardie Date: Fri, 12 Apr 2019 10:54:35 -0700 Message-ID: To: Peter Saint-Andre Cc: Wes Hardaker , add@ietf.org Content-Type: multipart/alternative; boundary="0000000000008725b8058659003f" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 17:55:06 -0000 --0000000000008725b8058659003f Content-Type: text/plain; charset="UTF-8" Howdy, On Fri, Apr 12, 2019 at 10:14 AM Peter Saint-Andre wrote: > > > Have you considered randomly rotating all queries > > through every item in the list, > > We've considered random rotation but "there are problems with this". > > So, I assume Wes didn't mean sending all queries to all entities on the list, because that would be wasteful of bandwidth and very leaky of information. I think he meant "random rotation", which is the question you answered. But the reality is that folks have been dealing with the DNS round-robin problem a long time and the change in transport protocols doesn't change the parameters of the problem that much. Generally speaking, you are optimizing for reduced latency. I think it was Duane Wessels who introduced the "ladder race" method, which works pretty well over time; there are also lots of variations of it. Ladder race works by starting from a list, either with a known default or no default. You pick two for the first query and race them. The winner becomes the default and is raced against a random member of the list for the next query or after a period of time--in this case, I'd suggest basing that time period on the HTTPS set up time (e.g. 5x the set-up time). Once you have raced the entire list, you have a resolver choice that has the lowest latency for that particular client. You then re-race after a longer elapsed period of time; if you get the same choice, you lengthen the time between races. Every time the race returns the same choice, the signal that this is a stable choice increases and the time lengthens. If there is a change, you drop back to a shorter race time. What this should do is associate the clients with the lowest latency resolver. If a resolver gets busy, its latency will increase and it will go down in the races and shed clients, so this is a blended signal of network distance and resolver load. It will vary over time, but there are lots of clients for whom that variation won't result in a change in assigned server. In this case, you also don't need all the servers to speak the same protocol; you could blend DoT and DoH servers into the same list. That might actually reward the use of DoT where it is not blocked, because the response time for a cache fill is likely to be a bit better (as there is less overhead without the mime-type processing in DoH). Mechanisms like ladder race and its variations basically provide you some way gathering data to make the choice in a way that optimize what you want; the key is doing it in a way that is friendly enough to the resolvers and the network. But I don't think this is a new problem, even if this code is new to Firefox. regards, Ted --0000000000008725b8058659003f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Fri, Apr 12, 2019 at 10:14 AM Peter Saint-Andre <stpeter@mozilla.com> wrote:
<= br> > Have you considered randomly rotating all queries
> through every item in the list,

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


So, I assume Wes didn't mean sendi= ng all queries to all entities on the list, because that would be wasteful = of bandwidth and very leaky of information.=C2=A0 I think he meant "ra= ndom rotation", which is the question you answered.=C2=A0
But the reality is that folks have been dealing with the DNS r= ound-robin problem a long time and the change in transport protocols doesn&= #39;t change the parameters of the problem that much.=C2=A0 Generally speak= ing, you are optimizing for reduced latency.=C2=A0 I think it was Duane Wes= sels who introduced the "ladder race" method, which works pretty = well over time; there are also lots of variations of it.

Ladder race works by starting from a list, either with a known defau= lt or no default.=C2=A0 You pick two for the first query and race them.=C2= =A0 The winner becomes the default and is raced against a random member of = the list for the next query or after a period of time--in this case, I'= d suggest basing that time period on the HTTPS set up time (e.g. 5x the set= -up time).=C2=A0 Once you have raced the entire list, you have a resolver c= hoice that has the lowest latency for that particular client.=C2=A0 You the= n re-race after a longer elapsed period of time; if you get the same choice= , you lengthen the time between races.=C2=A0 Every time the race returns th= e same choice, the signal that this is a stable choice increases and the ti= me lengthens.=C2=A0 If there is a change, you drop back to a shorter race t= ime.

What this should do is associate the clients = with the lowest latency resolver.=C2=A0 If a resolver gets busy, its latenc= y will increase and it will go down in the races and shed clients, so this = is a blended signal of network distance and resolver load.=C2=A0 It will va= ry over time, but there are lots of clients for whom that variation won'= ;t result in a change in assigned server.=C2=A0

In this case, you also don't need all the servers to speak the same = protocol; you could blend DoT and DoH servers into the same list.=C2=A0 Tha= t might actually reward the use of DoT where it is not blocked, because the= response time for a cache fill is likely to be a bit better (as there is l= ess overhead without the mime-type processing in DoH).

=
Mechanisms like ladder race and its variations basically provide you s= ome way gathering data to make the choice in a way that optimize what you w= ant; the key is doing it in a way that is friendly enough to the resolvers = and the network. But I don't think this is a new problem, even if this = code is new to Firefox.

regards,
Ted
--0000000000008725b8058659003f-- From nobody Fri Apr 12 13:38:06 2019 Return-Path: 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 DF10A120145 for ; Fri, 12 Apr 2019 13:38:04 -0700 (PDT) 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 RF2O0LwyFR7a for ; Fri, 12 Apr 2019 13:38:03 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45471200EF for ; Fri, 12 Apr 2019 13:38:03 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 2E8AB20B0A; Fri, 12 Apr 2019 13:38:02 -0700 (PDT) From: Wes Hardaker To: Ted Hardie Cc: Peter Saint-Andre , Wes Hardaker , add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> Date: Fri, 12 Apr 2019 13:38:02 -0700 In-Reply-To: (Ted Hardie's message of "Fri, 12 Apr 2019 10:54:35 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 20:38:05 -0000 Ted Hardie writes: > So, I assume Wes didn't mean sending all queries to all entities on > the list, That would defeat the purpose of what I was saying, so yes... I meant rotate through them. > What this should do is associate the clients with the lowest latency > resolver. I wish we (collectively) could get over the notion that latency was the only, or the most important metric out there at all times. Happy-eyeballs approaches to problems can go too far. -- Wes Hardaker USC/ISI From nobody Fri Apr 12 13:51:48 2019 Return-Path: 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 BFFC412067F for ; Fri, 12 Apr 2019 13:51:46 -0700 (PDT) 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 A_2Z8DZUTqsi for ; Fri, 12 Apr 2019 13:51:44 -0700 (PDT) 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 55B9712067B for ; Fri, 12 Apr 2019 13:51:44 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id w15so17948150itc.0 for ; Fri, 12 Apr 2019 13:51:44 -0700 (PDT) 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=wIo5JTwaOa0q0rKG7w+7/X4f67/YK8Cssq4/dhTEOS8=; b=T7OM7ugrMQnq8s5Z2CTEd6EpeYfz8wQlNxxJjuNG2vAuBwd3GtyXs8v3Cvy0HFVBGI hp5Hr4bSsRFHAQyLDCyld81YLjjOi9Op+DQ3EFWSHO5MG3/G9KzdGHVBoP2w2bEl3Nqc cO5OjrO2Sb4ZZ+Xu9tgIqmVm6j2bDP+E2blWlvaXPjKQC/QCPGntLScDqDCj3NwRGP+D jtNdWfZlBkNRXKlhazDKJ3QzIE6P7HfcRqR98IjOh1uzjk6365eg2uSgcg28iOsqmTYl M8vWS6NQViIUTRjrMAN8GoB7r9Kl6PgS3vm9zQ1lp/VMhy+8JCer/hZeCt1Y1QPtcps/ XPNw== 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=wIo5JTwaOa0q0rKG7w+7/X4f67/YK8Cssq4/dhTEOS8=; b=kzl0jwQHXIVdglCtZZdoB7VSpiyAG0llIqco7USDCWvLe+ffxbhS7ON2OnOWAlDIFO jQ0elPXDQUCWzy3xmpZRc1uHL6baTz794ddijStMJed62y56IoHsoeXKpWJ2vjYYYlo5 u95ASF53otybiswipG98OYAH5qzMcddu393dtVLqOta0SiMl6AcIcz19mkaDDc2rUqQA sTDIVlBZbCNcQ2Hw8VEu08ZlHGINGUFUeReERFBDoZDIOm5HDfZYow0JD7TbKJ4oEg5n piwjUWQhCLBHoZQIXvvBYjAMp4o/tU1hhG4KVts9AHes5RemDttRFpEhXgNy9VkPVQlO pmmw== X-Gm-Message-State: APjAAAUiCleBR8LhYW/O2263+5DqcP/QdgbpqcxHh/1Z7fDXYsFDDYzC kpZxtqze+YEl3NESw4wUzftC+6+5BsizzaDpRSs= X-Google-Smtp-Source: APXvYqwTgQUDlhzrOpBcDm3T3d/OEpdkzBKhjbz3dw/i9FEYOi53MfmZiChm9GdnAThn/GUUGPr+OWrsfXJkFXPnB3U= X-Received: by 2002:a02:942c:: with SMTP id a41mr41784851jai.61.1555102303524; Fri, 12 Apr 2019 13:51:43 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> In-Reply-To: From: Ted Hardie Date: Fri, 12 Apr 2019 13:51:17 -0700 Message-ID: To: Wes Hardaker Cc: Peter Saint-Andre , add@ietf.org Content-Type: multipart/alternative; boundary="000000000000641c4105865b78e0" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 20:51:47 -0000 --000000000000641c4105865b78e0 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 12, 2019 at 1:38 PM Wes Hardaker wrote: > > > What this should do is associate the clients with the lowest latency > > resolver. > > I wish we (collectively) could get over the notion that latency was the > only, or the most important metric out there at all times. > Happy-eyeballs approaches to problems can go too far. > The world of browsers cares a lot about latency, since it effects page load time and thus revenue. I don't think it is going away as *a* metric, in other words. Systems like this also distribute load even among uncoordinated servers, which is a useful characteristic for both networks and server operators. What else do you want to see optimized here? Ted --000000000000641c4105865b78e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 12, 2019 at 1:38 PM Wes Harda= ker <wjhns1@hardakers.net>= ; wrote:

> What this should do is associate the clients with the lowest latency > resolver.

I wish we (collectively) could get over the notion that latency was the
only, or the most important metric out there at all times.
Happy-eyeballs approaches to problems can go too far.
=
The world of browsers cares a lot about latency, since it ef= fects page load time and thus revenue.=C2=A0 I don't think it is going = away as *a* metric, in other words.=C2=A0 Systems like this also distribute= load even among uncoordinated servers, which is a useful characteristic fo= r both networks and server operators.

What else do= you want to see optimized here?

Ted

=C2=A0
--000000000000641c4105865b78e0-- From nobody Fri Apr 12 14:35:18 2019 Return-Path: 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 D3FF612031C for ; Fri, 12 Apr 2019 14:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 vqLZ1uvSLLlA for ; Fri, 12 Apr 2019 14:35:13 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 EA353120301 for ; Fri, 12 Apr 2019 14:35:12 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id g24so2478641vki.2 for ; Fri, 12 Apr 2019 14:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZKyEqp6Jg7znTLcie0N1m8rYMjomHMm5U8iAYlBxs8Q=; b=uIRA918+3wNS2DfVxFqFIl50n+CjaOgA89qI/AD3PJXm8fWb+UkLh4lwNXCmW2rnC2 XS1z5TvuM5xHu6QiP0Jg5El4FU5D7g/K3/Qql8n4g/+0Mip6P4WjUXbrvd28he33FiWZ /P0quOw9LEu12L6Q1sdV6zr0AFbC8+dlgyUQ+S6/vnZ4mPUJK6lFNfCjBZTJk+RsROlX UeyxqwTdsWbyFtXd5+RfSAmUhaFiqkeyrnzCdW5/c8xDbyx8tDckJ/SYHgIA9cGTTxCG tSH+hq0rh94s9gxkJ0Hokccqi0p4PCgFuROa5RE3x3qfew/XEyW7I2hxkip9CftQGZXp rCRA== 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=ZKyEqp6Jg7znTLcie0N1m8rYMjomHMm5U8iAYlBxs8Q=; b=hGxC+Qq1H7TqSEzEWB+GEP9nzSrJ2VoUjM8dXa0uxnNJnsXMVlwT2S+EtYXljxhGVl WK2ZzF2dVOPCc4DbZpO8S0BaZIVHKRwDH4KI2LNKCgS4xWbyGoKUO1+ywv63ue6ZsyqW hr1+gklj9AHYd6YjPtIciVtYxKu2hTQWRbcXcA6toFI6AGpjg2SxN1gSecRzIRwNuJb8 hnPBWAKIQzGGdralfnM6RezEENOqfo8NCAST9elbp8w2uBLmlXy0dzt+iuT+YtgijZx8 pfp8Swhgp5T4ofn/snFiQdX71rUIzD8ZOfDMnGPHzQYXtMcjqvPpuRXbcXYcHBsfChP+ 9iGg== X-Gm-Message-State: APjAAAWjWfyLwaBMvLbQ/i1GEMONqlEnNIEfWWe4hHw8s1IBISGBAsyv RXWdyy0PJaTHYHNcrYj27PyNI4heUnBd/6Kk49TRSw== X-Google-Smtp-Source: APXvYqwWPmDMMRTcJYPpqnqTMZ5Pd4rx8XRsV5F6H09s9Q2Cg8t8fXjBXBhmEhwmODchgZlTGZEvuoslOrW+Dljisu4= X-Received: by 2002:a1f:9ec8:: with SMTP id h191mr17010106vke.79.1555104911616; Fri, 12 Apr 2019 14:35:11 -0700 (PDT) MIME-Version: 1.0 References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> In-Reply-To: From: Ben Schwartz Date: Fri, 12 Apr 2019 17:34:59 -0400 Message-ID: To: Brian Dickson Cc: Joe Abley , add@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e0abf705865c133d" Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:35:17 -0000 --000000000000e0abf705865c133d Content-Type: multipart/alternative; boundary="000000000000d8bcd105865c13ae" --000000000000d8bcd105865c13ae Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 8:14 PM Brian Dickson wrote: > > > On Thu, Apr 11, 2019 at 3:47 PM Ben Schwartz wrote: > >> >> >> On Wed, Apr 10, 2019 at 3:17 AM Brian Dickson < >> brian.peter.dickson@gmail.com> wrote: >> >>> >>> In Joe's thought experiment, it would *appear* the user has the ability >>> to select the service end-point (where the service provides a replacement >>> DNS resolution that pre-empts the pre-existing DNS resolution as provided >>> to the user.) >>> >>> The result is that the user has been provided the means to make changes >>> to DNS, *that the administrator of the machine didn't permit*. >>> >> >> I can't parse this claim. In my vocabulary, a non-admin user is defined >> as a user who can only take actions that the administrator permits. >> Perhaps you mean "that the administrator permitted unintentionally"? >> > > Not really. > The distinction I'm trying to make is the following: > > - Assume the administrator installs the browser as the administrator > has always installed the browser, with the defaults unchanged. (Pretty > common, IMHO.) > - Assume that the {network,system} administrator(s) use DNS as a > control point, including limiting access to outside DNS resolvers. (Also > fairly common.) > - If the software, in its default configuration, enables the user to > select arbitrary HTTPS servers for DNS resolution, this is user-level > configuration which has the effect of overriding system-level (and locked) > configurations. (This is what is proposed, and even ships in Firefox if you > visit 'about:config'.) > - So, while technically true that it falls into "permitted > unintentionally", that puts the blame on the victim, in this case the > administrator. > > For example, the administrator may be very familiar with DNS, and may not > be familiar with changes to an application's capabilities or defaults. > Thanks for helping me understand. I agree: this new feature does represent a change that requires the attention of administrators who are in the position you describe, and browser vendors should make sure to made admins aware of the new feature as it becomes available. In the case of Firefox, they made a clear public announcement in May 2018: https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/, with several followup announcements over a period of many months before the feature reached stable. They even made a cartoon, for those unfamiliar with DNS: https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/. In my view, their communication on the topic has been exceptionally good. Modern browsers make similarly significant changes on a regular basis, and these changes are communicated to administrators, who must remain up to date with changes in the applications they allow. For example, last month Firefox announced that they would change their default root certificate store on Windows, which likely has implications for many system administrators. Over the past few years, browsers have introduced countless transformational new features with significant implications for enterprise IT: audio/video capture, new extension systems, tighter TLS requirements, etc. E.g. From a security/interface perspective, consider that currently the > configuration elements do NOT actually contain a name component called > 'DNS'. > Unless I had been closely following a bunch of mailing lists and reading > release notes, I would not know to look for 'trr' as the component > affecting DNS. > I also would not have been able to find it by looking at the stock user > preferences, as only non-default preferences are saved; I literally had to > use 'strings' in the binary, or read the source, to determine the variables. > Firefox has a huge number of about:config options, including many that are likely to interfere with enterprise IT administration. I'm not an expert on Firefox configuration, but admins who needed this level of control should probably already have blocked user access to the about:config flags: https://github.com/mozilla/policy-templates#blockaboutconfig. There's no need to enumerate precisely which options are relevant. It isn't so much a question of whether the administrators can disable a > feature, it is whether it is on-by-default (or even simple enabled for use) > on a system where there are unprivileged users. > In my view, this is a question that can be settled entirely between the browser vendors and their enterprise customers. Browser vendors are well aware of their customers' needs, and are always trying to keep those customers happy. On a machine owned by the (only) user, an off-by-default configuration > isn't a significant roadblock. Alternatively, different builds based on > single-user systems (installed in user's home directory) versus multi-user > systems (installed centrally) may be sufficient to address the concern. I > would like to see a commitment to do that, however. > > >> >> This in turn means that a malicious application would not require >>> elevated privileges beyond those of the user in question, to change that >>> user's DNS resolver, thus lowering the bar for such resolver changes. >>> >>> Equally true, would be the impact of someone leaving their machine >>> unattended with a browser open. Even if the user were not an administrator, >>> the DNS choice for the user could be changed, which is a much broader and >>> more subtle attack than browsing to a malicious site directly. >>> >> >> Note that most browsers have long supported proxy settings, so an >> attacker with access to the browser settings can easily redirect all user >> traffic to a machine of their choosing. This is of course just one of >> myriad ways that an attacker with full login access can compromise your >> security. In general, I think the IETF has done well to consider such >> attacks out of scope for our work. >> > > You're mixing apples and oranges, by combining the DNS semantics with the > HTTP semantics. > > Currently, DNS is, in many enterprise settings, a critical component of > both monitoring and mitigating a variety of security issues (mostly > malware, but also data exfiltration). > > Suggesting that, because this new DNS stuff happens in the browser, that > it shouldn't be treated as a DNS issue, will probably raise the ire of > folks in the security, DNS, enterprise, and anti-malware spaces. > > It doesn't matter what other things have already been possible, IMHO, what > matters is the new things that are enabled. The bypassing of existing > INTERNAL DNS controls, in an enterprise environment, is a HUGE deal, and > one reason lots of folks are interested in discussing both the problem > spaces and potential solution spaces. > I bring up proxy settings specifically because it is a pre-existing browser feature that already bypasses such internal DNS controls entirely, so the attack you described has already been possible in most browsers from the past 10+ years. It's not new. DNS complements other stuff that browsers do, in protecting users; the > phrase "belt and suspenders" is an appropriate analogy. > > Making changes that don't provide equivalent enterprise-level controls > over user DNS configuration limitations, (and specifically in the shipped > default settings), is akin to removing either the belt or suspenders. It > means that there is now only one element preventing one's pants from being > located at one's ankles. (Use of a disturbing visual in the analogy is > deliberate. :-) ) > > >> >> NB: All of the above is the situation where the user does not have >>> administrative privileges, but enables the user to expose him/herself to >>> hostile resolvers and hostile content as a result, with knock-on effects. >>> >>> In contrast, a user who does have administrative privileges (such as >>> someone who owns their own machine), would already have the ability to >>> change DNS resolvers, so nothing particularly new happens as a result of >>> these changes. >>> (But also, the need for the user to make those changes via the >>> application is a moot issue; the user can already make the change directly >>> on their system.) >>> >>> TL; DR: the ability for a user to select an encrypted channel to a DNS >>> resolver, is in and of itself a privilege escalation, if the user is not a >>> machine administrator. >>> >> >> I disagree with this characterization. >> > [snip] > >> Users who can only install software selected by their administrator will >> continue to perform DNS only in the manner permitted by their administrator. >> > > Currently, there is no "in the manner". Use of the passive voice obscures > the change, unfortunately. > It is a change compared to the current DNS environment, demonstrably: > > - DNS is configured only by the administrator, either through a system > configuration mechanism local to the system, or handled via DHCP (but not > capable of being altered by a non-admin user). > > I agree that many IT admins may think this is what they have required, but I disagree that it is a good characterization of a typical enterprise network. For example, I can easily spin up an Amazon WorkSpaces VM, access it graphically from my browser, and then open a browser in that VM. Now I have access to all the world's services without leaving a DNS trace in the enterprise network. > What HAS changed (or more precisely, "will have changed") is that a > DEFAULT configuration of a browser (I say default, as this is what the > existing builds are configured to enable, and public statements by the > browser vendors support this as the intended configuration), WILL enable > user bypass of DNS resolver choice which had previously been configured by > the administrator. > > Enabling this change of mode SHOULD require an active configuration by the > administrator, and NOT be the consequence of inaction. Currently, the > proposed scenario is the latter. > Thanks for helping me understand this concept. Change is always challenging. Sitting in the status quo forever is not an option, but change for change's sake isn't helpful either. Maybe we can find a balance. Brian > --000000000000d8bcd105865c13ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2019 at = 8:14 PM Brian Dickson <= brian.peter.dickson@gmail.com> wrote:


On Thu, Apr 11, 2019 at 3:47 PM Ben Schwartz <bemasc@google.com> w= rote:


On Wed, Apr 10, 2019 at 3:17 AM Brian Dickson= <bri= an.peter.dickson@gmail.com> wrote:

In Joe's thought experiment, it would appear the = user has the ability to select the service end-point (where the service pro= vides a replacement DNS resolution that pre-empts the pre-existing DNS reso= lution as provided to the user.)

The result is tha= t the user has been provided the means to make changes to DNS, that the = administrator of the machine didn't permit.

I can't parse this claim.=C2=A0 In my vocabu= lary, a non-admin user is defined as a user who can only take actions that = the administrator permits.=C2=A0 Perhaps you mean "that the administra= tor permitted unintentionally"?
Not really.
The distinction I'm trying to make is= the following:
  • Assume the administrator installs the bro= wser as the administrator has always installed the browser, with the defaul= ts unchanged. (Pretty common, IMHO.)
  • Assume that the {network,syste= m} administrator(s) use DNS as a control point, including limiting access t= o outside DNS resolvers. (Also fairly common.)
  • If the software, in = its default configuration, enables the user to select arbitrary HTTPS serve= rs for DNS resolution, this is user-level configuration which has the effec= t of overriding system-level (and locked) configurations. (This is what is = proposed, and even ships in Firefox if you visit 'about:config'.)
  • So, while technically true that it falls into "permitted uninte= ntionally", that puts the blame on the victim, in this case the admini= strator.
For example, the administrator may be very familiar with = DNS, and may not be familiar with changes to an application's capabilit= ies or defaults.=C2=A0

Th= anks for helping me understand.=C2=A0 I agree: this new feature does repres= ent a change that requires the attention of administrators who are in the p= osition you describe, and browser vendors should make sure to made admins a= ware of the new feature as it becomes available.=C2=A0 In the case of Firef= ox, they made a clear public announcement in May 2018:=C2=A0= https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefo= x/, with several followup announcements over a period of many months be= fore the feature reached stable.=C2=A0 They even made a cartoon, for those = unfamiliar with DNS:=C2=A0https://hacks.mozilla.org/2018/05/a-cartoon= -intro-to-dns-over-https/.=C2=A0 In my view, their communication on the= topic has been exceptionally good.

Modern browser= s make similarly significant changes on a regular basis, and these changes = are communicated to administrators, who must remain up to date with changes= in the applications they allow.=C2=A0 For example, last month Firefox anno= unced that they would change their default root certificate store on Window= s, which likely has implications for many system administrators.=C2=A0 Over= the past few years, browsers have introduced countless transformational ne= w features with significant implications for enterprise IT: audio/video cap= ture, new extension systems, tighter TLS requirements, etc.

<= /div>
E.g. From a security/interface perspective, co= nsider that currently the configuration elements do NOT actually contain a = name component called 'DNS'.
Unless I had been closely fo= llowing a bunch of mailing lists and reading release notes, I would not kno= w to look for 'trr' as the component affecting DNS.
I also would not have been able to= find it by looking at the stock user preferences, as only non-default pref= erences are saved; I literally had to use 'strings' in the binary, = or read the source, to determine the variables.

Firefox has a huge number of about:config options, i= ncluding many that are likely to interfere with enterprise IT administratio= n.=C2=A0 I'm not an expert on Firefox configuration, but admins who nee= ded this level of control should probably already have blocked user access = to the about:config flags:=C2=A0https://github.com/mozilla/policy-templates#b= lockaboutconfig.=C2=A0 There's no need to enumerate precisely which= options are relevant.

It isn&#= 39;t so much a question of whether the administrators can disable a feature= , it is whether it is on-by-default (or even simple enabled for use) on a s= ystem where there are unprivileged users.

In my view, this is a question that can be settled entirel= y between the browser vendors and their enterprise customers.=C2=A0 Browser= vendors are well aware of their customers' needs, and are always tryin= g to keep those customers happy.

On a machine owned by the (only) user, an off-by-default configuration is= n't a significant roadblock. Alternatively, different builds based on s= ingle-user systems (installed in user's home directory) versus multi-us= er systems (installed centrally) may be sufficient to address the concern. = I would like to see a commitment to do that, however.
=C2=A0

This in turn me= ans that a malicious application would not require elevated privileges beyo= nd those of the user in question, to change that user's DNS resolver, t= hus lowering the bar for such resolver changes.

Eq= ually true, would be the impact of someone leaving their machine unattended= with a browser open. Even if the user were not an administrator, the DNS c= hoice for the user could be changed, which is a much broader and more subtl= e attack than browsing to a malicious site directly.

Note that most browsers have long supported pro= xy settings, so an attacker with access to the browser settings can easily = redirect all user traffic to a machine of their choosing.=C2=A0 This is of = course just one of myriad ways that an attacker with full login access can = compromise your security.=C2=A0 In general, I think the IETF has done well = to consider such attacks out of scope for our work.

You're mixing apples and oranges, by combini= ng the DNS semantics with the HTTP semantics.

Curr= ently, DNS is, in many enterprise settings, a critical component of both mo= nitoring and mitigating a variety of security issues (mostly malware, but a= lso data exfiltration).

Suggesting that, because t= his new DNS stuff happens in the browser, that it shouldn't be treated = as a DNS issue, will probably raise the ire of folks in the security, DNS, = enterprise, and anti-malware spaces.

It doesn'= t matter what other things have already been possible, IMHO, what matters i= s the new things that are enabled. The bypassing of existing INTERNAL DNS c= ontrols, in an enterprise environment, is a HUGE deal, and one reason lots = of folks are interested in discussing both the problem spaces and potential= solution spaces.

I bring= up proxy settings specifically because it is a pre-existing browser featur= e that already bypasses such internal DNS controls entirely, so the attack = you described has already been possible in most browsers from the past 10+ = years.=C2=A0 It's not new.

= DNS complements other stuff that browsers do, in protecting users; the phra= se "belt and suspenders" is an appropriate analogy.
Making changes that don't provide equivalent enterprise-lev= el controls over user DNS configuration limitations, (and specifically in t= he shipped default settings), is akin to removing either the belt or suspen= ders. It means that there is now only one element preventing one's pant= s from being located at one's ankles. (Use of a disturbing visual in th= e analogy is deliberate. :-) )
=C2=A0

NB: All of the above is the situation w= here the user does not have administrative privileges, but enables the user= to expose him/herself to hostile resolvers and hostile content as a result= , with knock-on effects.

In contrast, a user who d= oes have administrative privileges (such as someone who owns their own mach= ine), would already have the ability to change DNS resolvers, so nothing pa= rticularly new happens as a result of these changes.
(But also, t= he need for the user to make those changes via the application is a moot is= sue; the user can already make the change directly on their system.)
<= div>
TL; DR: the ability for a user to select an encrypted ch= annel to a DNS resolver, is in and of itself a privilege escalation, if the= user is not a machine administrator.
I disagree with this characterization.=C2=A0
=
[snip]=C2=A0
Users who can = only install software selected by their administrator will continue to perf= orm DNS only in the manner permitted by their administrator.

Currently, there is no "in the man= ner". Use of the passive voice obscures the change, unfortunately.=C2= =A0
It is a change compared to the current DNS environment, demon= strably:
  • DNS is configured only by the administrator, eit= her through a system configuration mechanism local to the system, or handle= d via DHCP (but not capable of being altered by a non-admin user).
I agree that many IT admins may think = this is what they have required, but I disagree that it is a good character= ization of a typical enterprise network.=C2=A0 For example, I can easily sp= in up an Amazon WorkSpaces VM, access it graphically from my browser, and t= hen open a browser in that VM.=C2=A0 Now I have access to all the world'= ;s services without leaving a DNS trace in the enterprise network.
=C2=A0
What HAS changed (or more precisely, = "will have changed") is that a DEFAULT configuration of a browser= (I say default, as this is what the existing builds are configured to enab= le, and public statements by the browser vendors support this as the intend= ed configuration), WILL enable user bypass of DNS resolver choice which had= previously been configured by the administrator.

= Enabling this change of mode SHOULD require an active configuration by the = administrator, and NOT be the consequence of inaction. Currently, the propo= sed scenario is the latter.

Thanks for helping me understand this concept.=C2=A0 Change is always ch= allenging.=C2=A0 Sitting in the status quo forever is not an option, but ch= ange for change's sake isn't helpful either.=C2=A0 Maybe we can fin= d a balance.

Brian
<= /div>
--000000000000d8bcd105865c13ae-- --000000000000e0abf705865c133d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDrqdjRISS4q2stQoEP42Rj 5hFtjpqbzB1SZnZv2D6+KDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA0MTIyMTM1MTJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAh26PVV4SaE7R8H7nixompK5rQEywBRlx3EBEnl8C OowN85Wht3ANECSbFUYlzzg5fajwlRmL2jBByEr58Ek5gKXJSWfvFwUxzXiJrQR+8HHWoHyhiy7N cDbrRWsECyyVqpm8IRbEhLSqSAyFsUggD/vOV8aawG8F0hXme8kJ2KDy35cN4pFnkO/HqwVkHtqv 72PwXSra98o2tJIDHSD5EP+bO6126p36k4/MPdtSiSFBevh8C6xxsV7v5ANe6ZoUmZPTJj1pXAW6 2gIh7crE028r/BLdFQvL8OGFpI1S4QoIE14DIegca/ONkndRkKUmdM6zsI00HgZcT3faZEbovQ== --000000000000e0abf705865c133d-- From nobody Fri Apr 12 14:48:30 2019 Return-Path: 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 5C2FE1201C1 for ; Fri, 12 Apr 2019 14:48:28 -0700 (PDT) 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 HPffB3tGP3QF for ; Fri, 12 Apr 2019 14:48:26 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3C2120144 for ; Fri, 12 Apr 2019 14:48:25 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 268FF20B15; Fri, 12 Apr 2019 14:48:20 -0700 (PDT) From: Wes Hardaker To: Ted Hardie Cc: Wes Hardaker , Peter Saint-Andre , add@ietf.org References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> Date: Fri, 12 Apr 2019 14:48:20 -0700 In-Reply-To: (Ted Hardie's message of "Fri, 12 Apr 2019 13:51:17 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:48:28 -0000 Ted Hardie writes: > On Fri, Apr 12, 2019 at 1:38 PM Wes Hardaker wrote: >=20 > > What this should do is associate the clients with the lowest latency > > resolver. >=20=20=20=20 > I wish we (collectively) could get over the notion that latency was t= he > only, or the most important metric out there at all times. > Happy-eyeballs approaches to problems can go too far. >=20 > The world of browsers cares a lot about latency, since it effects page lo= ad time and > thus revenue.=C2=A0 I don't think it is going away as *a* metric, in other > words. Nor should it! It's an important one! I never tried to say otherwise. > What else do you want to see optimized here? Like most "triangle-like" choices, there is likely no perfect balance of metrics you could pick from and each of us would likely pick different solution points. The three big ones that are coming back time and time again are: 1. latency 2. privacy 3. authenticity Right now, most web-browsers (as you point out) are optimizing for (have always been in a race for) latency. Only recently is the desire privacy actually becoming important enough that there is a desire to use a slightly slower protocol like DOH to achieve privacy away from unencypted traffic to access point resolvers/ISPs, and from the access point resolvers/ISPs. This, itself, is probably a good trend. But then you bring in the discussion of DNSSEC and authenticity, which is the only current way to ensure end-to-end data integrity and combine this with Martin's statement of > We don't believe that DNSSEC is essential to our primary goals, which > are improving privacy of browsing activity. Which clearly shows that between the above three, they're willing to sacrifice some level of authenticity to achieve better latency and privacy. Note, though, that this choice isn't wrong. It's a choice. I may choose a different one, as may others. And I'm more than sure my list above is incomplete from an ideological stand point; it just happens to be the three biggest I could think of. It would be interesting to put a "pick two" dialog box in front of a billion users and see what was selected. Then watch them as the usability changed and see if when presented the same choice a month later if they'd stick with their original choice. --=20 Wes Hardaker USC/ISI From nobody Fri Apr 12 15:07:13 2019 Return-Path: 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 EF84612060E for ; Fri, 12 Apr 2019 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net 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 tpzrZYodgMuu for ; Fri, 12 Apr 2019 15:07:10 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB0E120605 for ; Fri, 12 Apr 2019 15:07:09 -0700 (PDT) Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 667661A2929 for ; Fri, 12 Apr 2019 15:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1555106829; bh=CgNcE5pHo+UFs0OR4VOQbyQuVDvfPRd9w80rCw8/yj0=; h=To:References:From:Subject:Date:In-Reply-To:From; b=a16zoPYkDUWOipyyJ2zUMR+mq8wciCadvsV37KeJRhpu78SrZR+WXHglKN+4T5ADj hHinDpbEPNe7IThtEtIXl3z7PrR0l/GqpVktPjhkhhHyXdzr6n/4xMPhmgydnMED7f AniluH9aQE76xWlJSRxnEimfd/bkJJxDs7L+K9Ks= X-Riseup-User-ID: 53147F8A09B8C173FCF8057EDBFA3916C4535A61E2692096C84C332A8DEC205A Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id 16E58120C5D for ; Fri, 12 Apr 2019 15:07:07 -0700 (PDT) To: add@ietf.org References: <87ftqo7xjy.fsf@fifthhorseman.net> From: nusenu Openpgp: preference=signencrypt Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA== Message-ID: Date: Fri, 12 Apr 2019 22:06:00 +0000 MIME-Version: 1.0 In-Reply-To: <87ftqo7xjy.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8a64m1GXlUhGrM1aAVuIpEKH8GKwQIesz" Archived-At: Subject: Re: [Add] avoiding unnecessary metadata in applications doing DNS / DoH X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 22:07:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8a64m1GXlUhGrM1aAVuIpEKH8GKwQIesz Content-Type: multipart/mixed; boundary="eUYqXUYBLTb1S5KSz6ai53ShDfuN4G0qH"; protected-headers="v1" From: nusenu To: add@ietf.org Message-ID: Subject: Re: [Add] avoiding unnecessary metadata in applications doing DNS / DoH References: <87ftqo7xjy.fsf@fifthhorseman.net> In-Reply-To: <87ftqo7xjy.fsf@fifthhorseman.net> --eUYqXUYBLTb1S5KSz6ai53ShDfuN4G0qH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > let's not make that mistake. Rather, let's try to fix things that we > know contribute to the concerns that people are raising, even if we > can't fix them all a once. thanks for this well written reasoning. I very much share the 'one step at a time' approach. --=20 https://twitter.com/nusenu_ https://mastodon.social/@nusenu --eUYqXUYBLTb1S5KSz6ai53ShDfuN4G0qH-- --8a64m1GXlUhGrM1aAVuIpEKH8GKwQIesz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlyxDAUACgkQrWE4wkXN Qn5whBAAvLge7J65nN+qfoTxNLBLn1zp7oBAXDdOeqL6a1hm6wbwTGe5Q6uP3n9b C8jq9aFB+NJjyRGsD+bW6x/b+WZQLqb4aCWy7C3sOq7z3BIcdEIhHnoaLLRlKDBC R4pYurzs5n6XFQA+gPOsmJg1/OMNC8upkhH0EogdQDLVd6t5H+60FjnVdVPn5paY eY0DEibobJ4lj8uy1yya9nLNAOaP9pvzz2CoJlDrfYxqERn0CbZkePE1G8AR0yR7 1qlDWmU6uXOfImlr9hppXDbhp8SSZoz4fxBwa0gwzgW3F1D9BfxhXPSX8TbZi/fe xwNO86zeCsyTYDC5ltAKCy4F2DP5mYxWNBqrtYrpN0iItvhgXv7CJtYRojeSmYMv 9uJRHzfUxhc4lzdrHM6nZDfEzdlTZbdZhyIWNaj2lea98GMf3UlUP8RGsbwtzpmx 5fkH2ytpzdOUOoTEHKIFAXb66xYn4zvtFgu8cs1/rKTh4XYqc77WZ3qoxMgPx5f5 DcK77pxGiwtvsoa4o5AUqVatxOoqB6qTm+nhoyD7UWeMIGqC4zxjvZ7Mi58UkRvQ Erd4XzEKfEXjoVfbm9lSUnuoxn2sxPrcBWiNJhT+26OYLc9e+4MvRBYA1wXTW8rd Z3tnF9HzHBvmPe+bKFIPczLmBb/DiS+ZPCY/58m6nT8m9inhsS8= =3x6y -----END PGP SIGNATURE----- --8a64m1GXlUhGrM1aAVuIpEKH8GKwQIesz-- From nobody Fri Apr 12 15:17:00 2019 Return-Path: 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 B1F601200C1 for ; Fri, 12 Apr 2019 15:16:58 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 FCtym4svxYWc for ; Fri, 12 Apr 2019 15:16:57 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 C5DF7120086 for ; Fri, 12 Apr 2019 15:16:56 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hF4Tc-0004h0-Vd for add@ietf.org; Sat, 13 Apr 2019 00:16:55 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hF4TV-00051s-3V for add@ietf.org; Fri, 12 Apr 2019 18:16:50 -0400 Received: (qmail 10891 invoked from network); 12 Apr 2019 22:16:41 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Apr 2019 22:16:41 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Fri, 12 Apr 2019 15:16:39 -0700 Cc: Ted Hardie , Peter Saint-Andre , add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4203E588-C6CE-44AD-AB26-FDD9AEED587F@huitema.net> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> To: Wes Hardaker X-Originating-IP: 168.144.250.223 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5heXGUEY33L3SuqRq/B1/dh602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO+ST6QJhH22IyI7Z98CXHvxVMZsRZacTbJPGp/MBC6Bx6aCbZ2c6nJLU4YlvYWJk6Eh5 mNm/WjPqhYqCeBiCKwwnRtk/d5gNfEtjtud5V8jp1xqbZLEGLaCXe0cUig+3Ox/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8l4YBmPrqPoeRXD34azf1rYZv5uZUEePrXZkexHL9EC3AAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0CmHJLVH4DfVNbPXJmiLfub/IRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM/9rUJrEbVA84BZVscMTXpbpuxXJTL417vaJWq5kk+j cuidX4Ts4xdG+C13IyWeZaJ+GOjRbZsGJKIJ8+QoGlarPwUimsNGvJJilSn4u6QSZOHA3oamIgMN OHVWe1RrhKws95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53tGWQiV0zRVsA5SL7kYV1JnAMgFPp7+h3kLe NmBV53UGPtBAikk5O0PTvcKVfzYFZEUZc3yAwbnQZTJbzYvHN/xRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/IAhemhJdBSJkER04dYNqSf7G3ch6MdB0XuALpEgtIRSdxZ/cxSnpMWdGZZ8 NIOHnN40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 22:16:59 -0000 =20 > On Apr 12, 2019, at 2:48 PM, Wes Hardaker wrote: >=20 > But then you bring in the discussion of DNSSEC and authenticity, which > is the only current way to ensure end-to-end data integrity and combine > this with Martin's statement of >=20 >> We don't believe that DNSSEC is essential to our primary goals, which >> are improving privacy of browsing activity. >=20 > Which clearly shows that between the above three, they're willing to > sacrifice some level of authenticity to achieve better latency and > privacy. Note, though, that this choice isn't wrong. It's a choice. I > may choose a different one, as may others. And I'm more than sure my > list above is incomplete from an ideological stand point; it just > happens to be the three biggest I could think of. On the other hand, DNSSEC does not guarantee authenticity either. It guarant= ees that the mappings of name to IP address is authentic, but that's not the= same thing as guaranteeing that the connection actually terminates at the a= uthentic end point. There could well be a NAT somewhere that translates the I= P address and delivers the packets to a different server. See for example th= e many cases of rerouting 8.8.8.8 traffic to a different server. On the web, authenticity is provided by the server identity verification bui= lt in TLS and used by HTTPS. Arguably, once you have HTTPS and authenticate t= he server, then DNSSEC does not provide any additional guarantee. What DNSSEC provides is something else. If the name resolution points to the= IP address of the wrong server, the TLS authentication will fail, and so wi= ll the connection. Falsified name resolution is thus a form of DOS attack, a= nd DNSSEC protects against that. That's nice, but not essential. Of course, DNSSEC is useful for other scenarios, such as retrieving keys. Bu= t these are not quite the main web scenarios. -- Christian Huitema=20= From nobody Fri Apr 12 16:20:20 2019 Return-Path: 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 EBEDD1203EB for ; Fri, 12 Apr 2019 16:20:17 -0700 (PDT) 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 xC-Cjbgxth4D for ; Fri, 12 Apr 2019 16:20:15 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 C94C2120341 for ; Fri, 12 Apr 2019 16:20:15 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id A89B13AB03E; Fri, 12 Apr 2019 23:20:14 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8CA6916006A; Fri, 12 Apr 2019 23:20:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 62252160070; Fri, 12 Apr 2019 23:20:14 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yz3fBHOLhbbi; Fri, 12 Apr 2019 23:20:14 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1A01116006A; Fri, 12 Apr 2019 23:20:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <4203E588-C6CE-44AD-AB26-FDD9AEED587F@huitema.net> Date: Sat, 13 Apr 2019 09:20:10 +1000 Cc: Wes Hardaker , Ted Hardie , add@ietf.org, Peter Saint-Andre Content-Transfer-Encoding: quoted-printable Message-Id: <6757A8CC-D3CE-482F-B191-B002EBCA2F84@isc.org> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <4203E588-C6CE-44AD-AB26-FDD9AEED587F@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 23:20:18 -0000 > On 13 Apr 2019, at 8:16 am, Christian Huitema = wrote: >=20 >=20 >=20 >> On Apr 12, 2019, at 2:48 PM, Wes Hardaker = wrote: >>=20 >> But then you bring in the discussion of DNSSEC and authenticity, = which >> is the only current way to ensure end-to-end data integrity and = combine >> this with Martin's statement of >>=20 >>> We don't believe that DNSSEC is essential to our primary goals, = which >>> are improving privacy of browsing activity. >>=20 >> Which clearly shows that between the above three, they're willing to >> sacrifice some level of authenticity to achieve better latency and >> privacy. Note, though, that this choice isn't wrong. It's a choice. = I >> may choose a different one, as may others. And I'm more than sure my >> list above is incomplete from an ideological stand point; it just >> happens to be the three biggest I could think of. >=20 > On the other hand, DNSSEC does not guarantee authenticity either. It = guarantees that the mappings of name to IP address is authentic, but = that's not the same thing as guaranteeing that the connection actually = terminates at the authentic end point. There could well be a NAT = somewhere that translates the IP address and delivers the packets to a = different server. See for example the many cases of rerouting 8.8.8.8 = traffic to a different server. >=20 > On the web, authenticity is provided by the server identity = verification built in TLS and used by HTTPS. Arguably, once you have = HTTPS and authenticate the server, then DNSSEC does not provide any = additional guarantee. >=20 > What DNSSEC provides is something else. If the name resolution points = to the IP address of the wrong server, the TLS authentication will fail, = and so will the connection. Falsified name resolution is thus a form of = DOS attack, and DNSSEC protects against that. That's nice, but not = essential. >=20 > Of course, DNSSEC is useful for other scenarios, such as retrieving = keys. But these are not quite the main web scenarios. And if Mozilla add DANE support then DNSSEC in the DoH server is = essential. DNSSEC requires that *all* servers in the DNS lookup path = implement DNSSEC for correct operation (recover from different classes = of attack). DANE can protect against various attacks on the WPKI. > -- Christian Huitema=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Apr 12 16:44:22 2019 Return-Path: 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 E38EF120412 for ; Fri, 12 Apr 2019 16:44:20 -0700 (PDT) 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 SR0rEEBMFCKb for ; Fri, 12 Apr 2019 16:44:19 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566F2120348 for ; Fri, 12 Apr 2019 16:44:19 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id B8E2E20DA7; Fri, 12 Apr 2019 16:44:18 -0700 (PDT) From: Wes Hardaker To: Christian Huitema Cc: Wes Hardaker , Ted Hardie , add@ietf.org, Peter Saint-Andre References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <4203E588-C6CE-44AD-AB26-FDD9AEED587F@huitema.net> Date: Fri, 12 Apr 2019 16:44:18 -0700 In-Reply-To: <4203E588-C6CE-44AD-AB26-FDD9AEED587F@huitema.net> (Christian Huitema's message of "Fri, 12 Apr 2019 15:16:39 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 23:44:21 -0000 Christian Huitema writes: > > Which clearly shows that between the above three, they're willing to > > sacrifice some level of authenticity to achieve better latency and > > privacy. Note, though, that this choice isn't wrong. It's a choice. I > > may choose a different one, as may others. And I'm more than sure my > > list above is incomplete from an ideological stand point; it just > > happens to be the three biggest I could think of. > > On the other hand, DNSSEC does not guarantee authenticity either. It > guarantees that the mappings of name to IP address is authentic, but > that's not the same thing as guaranteeing that the connection actually > terminates at the authentic end point. There could well be a NAT > somewhere that translates the IP address and delivers the packets to a > different server. See for example the many cases of rerouting 8.8.8.8 > traffic to a different server. Yes, you're absolutely right. There are a ton of layers of the protocol stack that get involved, and attacks at any point along the way can break the connection so it becomes unusable. Without DNS security, may never get to the right place. Without routing security, you may never get to the right place. Without TLS security, you may never get to the right place. If you don't type things properly, you may get to the wrong place. Protecting all layers increases your odds that you're getting to the right place. If you only check the highest layer (and you trust it implicitly) you still may be misdirected at other layers, causing client failures that may have been avoidable. > Arguably, once you have HTTPS and authenticate the server, then DNSSEC > does not provide any additional guarantee. That is one view, yes. As I said in my previous note about other choices: it's not wrong! You're prioritizing your needs and tradeoffs, however, and others may have different prioritization. Its in this selection of trade-offs that we seem unable to help users make informed, personal decisions. -- Wes Hardaker USC/ISI From nobody Sat Apr 13 01:11:34 2019 Return-Path: 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 E9255120092 for ; Sat, 13 Apr 2019 01:11:32 -0700 (PDT) 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 (2048-bit key) header.d=open-xchange.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 7lZIHToYWQXR for ; Sat, 13 Apr 2019 01:11:31 -0700 (PDT) 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 A14AF120043 for ; Sat, 13 Apr 2019 01:11:31 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [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 13BA36A264; Sat, 13 Apr 2019 10:11:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1555143089; bh=5HsxfdU0YSkpeJdivT2FPU5RWDoWVtRfyl57VWc/2wY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ZhswvN6vf9VrtK8ShdyvNn+2v2OhWjPSoIggencF3hh/++2kVQ7YhUDt/UBcylec7 KKs6fXGz9NppZ6t8ydI8j7UrShd/thbfHt1wANdilYqhBRyhqf5LIx6u7Q4sknSIgz eWIYfZiK6d4GYRspvFo1K3WBPYqHYByS3YhgCZsROlArx3qxTRM70D8txHcXOtCCfE cuXsGg0LXpBtQAfz1hGmoYHOoh2hhxhMiYGd2fVGEl04gQ+gT2uXj26iB5OH6aq69y HIeXZZpHj9zAluaqYGX01ysP13P5sIEeUwopT/cu2DV5zMmCXLjpjouXNGtWJLNbL0 lddMgcx5xPSTw== 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 E8A813C036E; Sat, 13 Apr 2019 10:11:28 +0200 (CEST) Date: Sat, 13 Apr 2019 10:11:28 +0200 (CEST) From: Vittorio Bertola To: Peter Saint-Andre Cc: add@ietf.org Message-ID: <544663959.23797.1555143088877@appsuite.open-xchange.com> In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.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-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 08:11:33 -0000 > Il 12 aprile 2019 alle 19.14 Peter Saint-Andre ha scritto: > > 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? It is still centralization if there is a single entity deciding who can run an "accredited" DoH provider, i.e. one that will be actually part of the available choices / rotation set / default for most users. If there can be no other way than having a single entity (or a few entities) doing something for everyone, then you need to get into the realm of building organizational and regulatory machinery that guarantees the public interest (ICANN anyone?). And this is hard and always controversial. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Sat Apr 13 01:19:21 2019 Return-Path: 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 1CF711200C4 for ; Sat, 13 Apr 2019 01:19:20 -0700 (PDT) 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 (2048-bit key) header.d=open-xchange.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 V6k5c_oMunWJ for ; Sat, 13 Apr 2019 01:19:18 -0700 (PDT) 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 76390120092 for ; Sat, 13 Apr 2019 01:19:18 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [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 759D86A264; Sat, 13 Apr 2019 10:19:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1555143556; bh=E3IKoYjOdOi8LZpz5T5G/qwPitgRtB6995QyGKRFxtk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=05DKDj8UBN5grvw2zKYL80hMpj1IJ0lKba0dDOGhkyP8TpiRY67FiTiYWvSCZ7huq lcOUm4v5fXew7in1G9uh/ZFUSD5Gf9YQ5ublmoM7Ri//RLYwQg0OOUOo3JPua5U8E1 za+HLniPAW3lOf1woC3KtHuMXJL38VAIZoqi5VznNqlKiov2PYxS6RFY0hLrKifBYn D4RfrfIM58g1JCfR6M/o0tOChq5haHmf2vLRg2u5QFw3SaVqN5pNr47orDHe1dIQHI kOCZt9hBMcwma4eiuR6JArp/sLGeWSJU/O0HPsa1hu5e3HI+FXJDaJTljWAWPzQA8f N1DAPYul3MSKQ== 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 692AF3C036E; Sat, 13 Apr 2019 10:19:16 +0200 (CEST) Date: Sat, 13 Apr 2019 10:19:15 +0200 (CEST) From: Vittorio Bertola To: Wes Hardaker Cc: add@ietf.org Message-ID: <1888048494.23821.1555143556369@appsuite.open-xchange.com> In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.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-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2019 08:19:20 -0000 > Il 12 aprile 2019 alle 23.48 Wes Hardaker ha scritto: > > Like most "triangle-like" choices, there is likely no perfect balance of > metrics you could pick from and each of us would likely pick different > solution points. > > The three big ones that are coming back time and time again are: > > 1. latency > 2. privacy > 3. authenticity > > Right now, most web-browsers (as you point out) are optimizing for (have > always been in a race for) latency. The policy problem of optimizing only for latency is that in many cases an operator can lower the latency of their service almost at will by throwing more money at it, so if someone has a lot more money to throw than the others and is determined to use it, any algorithm only focusing on latency will always pick their service and you will get full centralization, which is deadly for privacy. Ciao, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Tue Apr 16 08:57:43 2019 Return-Path: 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 3FD9F1207A9 for ; Tue, 16 Apr 2019 08:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=comcast.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 GR10o6h8LftD for ; Tue, 16 Apr 2019 08:57:34 -0700 (PDT) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 28DC4120C76 for ; Tue, 16 Apr 2019 07:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190220p; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1555426733; x=2419340333; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zkHxgUMsZZ5SQgdf+3hYjDvK/H15jfxSRZxXHljg5rw=; b=wqpiOq7S7eU36rlKO3f+1jJDsgeQDPesHM2ygg/riBCUWq4MtRfyhDCtepiomcgC Zt2ii3WaS7E4+NKfKiFE18HpfFSYUYNkzi+NOFIW+J+4WUKIzRHXzHKLPTZZ0cHs Rm/ORMDcKtW6OGElOGRFQv4xuIyL98f/WUnKGbASkY+kS6xtngYBgxu+PODLp5Wp ECo5BcIvUXoBeXduXejrfQEGRMX8EJAVYGG8VkY7K0C+1nIriRenDGRrll+8o7Zx xZVQWGCl2Vndkc9Tk9CeAolG3JlfT0HPFXGIBkKmbYarLUx/GJTANhvrw9YN5ieB vgCpDM9B+VbWzTXV+bRJ20hSR7RZ/Z809H0pqfR2Nl9yivQRVdjVRqooD+Scn0AJ KueF2Xd5NL3YQcIBCZ/960I6NbKVl+HevDVSRyxC6eSl9HCEevlntsYC3jzStkD1 eswTWdrCpdhqvi6iJc/3QzMpuf4C9FsqxlKHYjhdlM3+bjnzorGXs3beFh2fFoc1 LA6XjcYG3jGVUwCMwDXZgKIuoRWXA9jFMP7l15EWgfwlDeKyPTNHTglNIrvuM2Zo Xz5e0eraNvLnG67pSpYhiGu68tyh123WOL4F7VlFyCjgidHrX6ANjuOcfIf7ew9F b7nAlYTkb3/8mZMMHbzSZSnJ/D9xD6YsY3vC7KQ90RA=; X-AuditID: 60729ed4-f1dff7000000add3-80-5cb5edac487f Received: from COPDCEXC40.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 2A.82.44499.DADE5BC5; Tue, 16 Apr 2019 08:58:53 -0600 (MDT) Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC40.cable.comcast.com (147.191.125.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 16 Apr 2019 10:58:52 -0400 Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.004; Tue, 16 Apr 2019 10:58:52 -0400 From: "Livingood, Jason" To: Peter Saint-Andre , "add@ietf.org" Thread-Topic: [Add] Mozilla's DoH resolver policy Thread-Index: AQHU77Dlc8CwVfKDqk2z5i9MnPeCkqY15qUAgAACYACAAKNWAIAAYRaAgAAChQCAAHO2gIABT09RgABW7gCABeCDgA== Date: Tue, 16 Apr 2019 14:58:52 +0000 Message-ID: <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 x-originating-ip: [96.114.156.9] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsWSUDRnsu7at1tjDP58Z7H4f3odm8WzlacY HZg8liz5yeTRd6CLNYApqoHRpiSjKDWxxCU1LTWvONWOSwED2CSlpuUXpbomFuVUBqXmpCZi VwZSmZKak1mWWqSP1Rh9rOYkdDFlnLxxh6ngF3PFiymn2BsY3zB3MXJySAiYSCw6eoipi5GL Q0hgF5PEsc5rzBBOC5DzYwNU5jSjRM+tpewgLWwCZhJ3F14BaxcR8JJ4/+8ZWFxYwEBizbtz LBBxQ4mXr5uharIkWn5dBIpzcLAIqEpc26cPEuYVcJE48fQG1LJ7zBL9f1+zgSQ4Bewl5kxa BTaHUUBM4vupNUwgNrOAuMStJ/OZIM4WkFiy5zzUC6ISLx//YwWxRQX0JR5svcIIEVcAuu0U G8heZgFNifW79CHGWEkc7DnJCGErSkzpfsgOcY+gxMmZT1ggWsUlDh/ZwTqBUWIWks2zECbN QjJpFpJJs5BMWsDIuoqRz9JMz9DQRM/Q1ELPyNBoEyM40cy7soPx8nSPQ4wCHIxKPLz+N7fG CLEmlhVX5h5ilOBgVhLhdUzZEiPEm5JYWZValB9fVJqTWnyIUZqDRUmcN/ERULVAemJJanZq akFqEUyWiYNTqoGxniXtvrljt9a2w1b3cg9pvnysUHL6tumjc7JCQZ/kvlyb+Tfe4Kzwc/P2 21PlUuKNmleteXaFT3jxrNzSNvasY96S6+f1S7QmcD4zfr2hfPe8zcxNGk/WnbyyQSXq/Abe 6JlG6SKRvkHLXu7JelBQ7NV2ToS99J+3se9Vqx1ZWo7cPoud911QYinOSDTUYi4qTgQAXyIK VDADAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 15:57:42 -0000 IENoaW1pbmcgaW4gbGF0ZSBvbiB0aGUgdGVjaG5pY2FsIGFzcGVjdHMgb2YgdGhlIHBvbGljeSAt IGFuZCBkaXNjdXNzaW9uIG9mIHdoZXRoZXIgb3Igbm90IHRvIGluY2x1ZGUgRE5TU0VDIGluIHRo ZSBUUlIgcmVxdWlyZW1lbnRzLiBJTU8sIE1vemlsbGEgY2FuIGxlYWQgdGhlIHdheSBhbmQgaGVs cCBzcHVyIGFkb3B0aW9uLiBTYWlkIGFub3RoZXIgd2F5LCB0aGlzIGlzIE1vemlsbGEncyAnc2hh cmtzIHdpdGggbGFzZXIgYmVhbXMnIG1vbWVudCBvbiBETlMgc2VjdXJpdHkgJiBwcml2YWN5LiA7 LSkgU28gSSdkIHNheSByZXF1aXJlIEROU1NFQyB2YWxpZGF0aW9uIGFzIHdlbGwgYXMgbmF0aXZl IElQdjYgc3VwcG9ydC4NCg0KSmFzb24NCg0K From nobody Tue Apr 16 09:00:28 2019 Return-Path: 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 AF2BC120AF7 for ; Tue, 16 Apr 2019 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=comcast.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 fii_ML_iE9Rs for ; Tue, 16 Apr 2019 09:00:19 -0700 (PDT) Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 EBE60120D2D for ; Tue, 16 Apr 2019 08:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190220p; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1555427320; x=2419340920; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x4VIGCTTIEj7tQDyRkVXJYT7kygLlsLOfFOb99F6O7M=; b=OAhHBfDyEY5LsIIuBn67h49Le+g3cSXsWOKlt7+HF8OFGcNilmJSeJ+X4ta5nAXw bzgHAqonFRR6+F9KeMJ1KxvGgoLzGLvfxNqN17n8ec8Ie7T2BKEj+lkBIJBCF0lJ 8m0lzllC3yBlJ4vXsv/K7HZgROPRKOGJf0FtCiOMvY5Mv/jwYwWscDNy7JtXUAV2 QEAN2A7UNqw6K0PrZ1vkPCWZPw/8qBBsxy4pmnoWdEltAf3UGpLXUQzv/LXW3IBx 3QAe1kB8Zb1EDO3TgmRE9f/oMA1WF7XXDAGO2mn4+ARXew0zNVCQgul+jvvsyaoG k9BAusfrbjUOf3VLJcuYgcgr0NMpq9xifceAgRbOHfDyDuskwy9qwwdAMZ/YpPHj 8foEwGzM1z5D46XwzZLlOmlaLp+sEAIzLy47E4j7KlSWFpWmVMB5KcD4qk9tjLDT YVhlNeeuWF8fYRYgCtzcPC/A2YanEEmpH4rUvIeEXaA9kNa/xkztp/IcINVkBJxN nMzAARDO5A/Fs7Rcu7XdybGKKkWVEpcHebihW8YxSxQd9MMo2KXDHOsT+latXu5C qHwjN+76wCGA9Y6UlAsJekkQHftleD8p/lTwBg6VMBcymxLem9wNgHrvx66Hkzdb 2pzYnrdkEPlgnpWyo/3Uff9g/kS0nMYuN5HvPqXkcSY=; X-AuditID: 60729ed4-f05ff7000000add3-05-5cb5eff8054a Received: from COPDCEXC37.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id A1.D3.44499.8FFE5BC5; Tue, 16 Apr 2019 09:08:40 -0600 (MDT) Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC37.cable.comcast.com (147.191.125.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 16 Apr 2019 11:08:39 -0400 Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1713.004; Tue, 16 Apr 2019 11:08:39 -0400 From: "Livingood, Jason" To: Peter Saint-Andre , "add@ietf.org" Thread-Topic: [Add] Mozilla's DoH resolver policy Thread-Index: AQHU77Dlc8CwVfKDqk2z5i9MnPeCkqY15qUAgAACYACAAKNWAIAAYRaAgAAChQCAAHO2gIABT09RgABW7gCABeCDgIAAAr2A Date: Tue, 16 Apr 2019 15:08:39 +0000 Message-ID: <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> In-Reply-To: <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.1.190326 x-originating-ip: [68.87.29.7] Content-Type: text/plain; charset="utf-8" Content-ID: <17EB57F44A4BE74EADBC9361ED2F3E4E@comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsWSUDRnsu6P91tjDFofG1j8P72OzeLZylOM DkweS5b8ZPLoO9DFGsAU1cBoU5JRlJpY4pKalppXnGrHpYABbJJS0/KLUl0Ti3Iqg1JzUhOx KwOpTEnNySxLLdLHaow+VnMSupgybh9sYC94xlHx724rUwPjCY4uRk4OCQETiQWzjjJ2MXJx CAnsYpL4eXQ3E4TTwiTxes8DFgjnNKPEv/57LCAtbAJmEncXXmEGsUUEvCTe/3vGDmILCxhI rHl3jgUibijx8nUzVE2eROfhh2A2i4CqxN7u/6wgNq+Ai8TcNX/YIBbMZJE49+ci2CBOAVeJ nfs/MYHYjAJiEt9PrQGzmQXEJW49mc8EcbeAxJI955khbFGJl4//gQ0VFdCXeLD1CiNEXE5i 7muQozmAejUl1u/ShxhjJXF17VuokYoSU7ofskPcIyhxcuYTFohWcYnDR3awTmCUmIVk8yyE SbOQTJqFZNIsJJMWMLKuYuSzNNMzNDTRMzS10DMyNNrECE41867sYLw83eMQowAHoxIPr//N rTFCrIllxZW5hxglOJiVRHgdU7bECPGmJFZWpRblxxeV5qQWH2KU5mBREudNfARULZCeWJKa nZpakFoEk2Xi4JRqYOxgtH2vp8RZ6f5UuuiTDZOFKUNt+4UNtiLxE+2NTv85950tUOWJza+5 G57taz7nq2tjOmeip5kds9jPrw3Jh88vtfb2YUoJ59ac5XL3R40T18K9+yL5ntiZr5i6ylUu 7nLE2493WZTs/wXuZl0ofvZT7el1LxkZbK8zbJnj/CAmSVz0W2FUhxJLcUaioRZzUXEiAG1H kz0xAwAA Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 16:00:27 -0000 QW5kIGZvciBlYXNlIG9mIGFueSByZXBsaWVzLCBJIGhhdmUgYSBzZXBhcmF0ZSBxdWVzdGlvbiBv biBDRE4gbG9jYWxpemF0aW9uIHZpYSBFQ1MuIFRoZSA2dGggcHJpdmFjeSByZXF1aXJlbWVudCBz dWdnZXN0cyB0aGF0IEVDUyBjYW5ub3QgYmUgdXNlZCB1bmxlc3MgdGhlcmUgaXMgZW5jcnlwdGlv biBiZXR3ZWVuIHRoZSByZXNvbHZlciBhbmQgdGhlIGF1dGhvcml0YXRpdmUgc2VydmVyLCBwcmVz dW1hYmx5IHZpYSBEb1QuIFRoaXMgc3VnZ2VzdHMgdGhhdCB0aGUgcHJpdmFjeSBjb25jZXJuIGlz bid0IHRoYXQgdGhlIG5ldHdvcmsvZ2VvZ3JhcGhpYyBoaW50IHByb3ZpZGVkIGJ5IEVDUyBpcyBw cm9ibGVtYXRpYyBpbiBhbmQgb2YgaXRzZWxmLCBidXQgdGhhdCBpdCBzaG91bGQgbm90IGJlIG9i c2VydmFibGUgYWxvbmcgdGhlIG5ldHdvcmsgcGF0aCB1c2VkIGluIHJlY3Vyc2lvbi4gDQoNCkJ1 dCBpZiBUUlItdG8tYXV0aCByZWN1cnNpb24gaXMgbm90IGF2YWlsYWJsZSB2aWEgRG9ULCBJIHdv bmRlciB3aGF0IHRoZSByZWNvbW1lbmRlZCBtZWNoYW5pc20gaXMgZm9yIHByb3ZpZGluZyBhIG1v cmUgcHJpdmFjeS1wcm90ZWN0aXZlIG5ldHdvcmstZ2VvZ3JhcGhpYyBoaW50IHRvIGFuIGF1dGhv cml0YXRpdmUgc2VydmVyLCBpbiBvcmRlciBmb3IgZXhhbXBsZSBmb3IgYSBDRE4gdG8gZHluYW1p Y2FsbHkgcmVzcG9uZCB3aXRoIGEgbG9jYWxpemVkIHJlc3BvbnNlLiBNYXliZSBzb21ldGhpbmcg bmV3IG5lZWRzIHRvIGJlIHN0YW5kYXJkaXplZD8gV2hhdCBvcHRpb25zIGRvIGZvbGtzIHN1Z2dl c3Q/DQoNClRoYW5rcw0KSmFzb24NCg0K From nobody Tue Apr 16 10:45:41 2019 Return-Path: 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 763381203AA for ; Tue, 16 Apr 2019 10:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 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, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 sP53_YViinlK for ; Tue, 16 Apr 2019 10:45:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5C5551203AE for ; Tue, 16 Apr 2019 10:45:39 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x3GHRJro013847; Tue, 16 Apr 2019 18:45:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=/T+gwNQV85wWsZw7JAfnsvYTmuc6mtrLoxEwoEwyww0=; b=eLkym5w3OBRJoJKHWnZISIj9FCMCaVFsg70OKi/jLJ5m/COiwc6clLAOryett1sz1sAY AjMPwa7uSyzwWcJzrscWY+CrLg+f8Bg2qdQ3ub0RqE4SaBQFPRj1i4aR+qgMfaHqE6iZ jb/f8wNeaU1oT3sjyx6yWRJGCDa0RW9g/MojJbY8swn/TnC2Qi+gh2GlfzK/RB3aS+0R DquEGL1MBmtWgf1+USQavCl0dFeHGU8MgszUADivGRyVm4EvSTosExnLaizSciRXyMKD WwSvcLvYdmZ+95CLiaPpctosdeargduW5JjpX3EiIAsX/k1Zx3DZVrN1OAH8lRFvo5E3 wQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2ru866dar4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Apr 2019 18:45:32 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x3GHWAGs000495; Tue, 16 Apr 2019 13:45:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2rub3veusu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 16 Apr 2019 13:45:31 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 16 Apr 2019 12:45:30 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Tue, 16 Apr 2019 12:45:30 -0500 From: "Salz, Rich" To: Vittorio Bertola , Peter Saint-Andre CC: "add@ietf.org" Thread-Topic: [Add] Mozilla's DoH resolver policy Thread-Index: AQHU77Dlc8CwVfKDqk2z5i9MnPeCkqY192kAgAACYACAAKNWAIAAYRWAgAAChQCAAHO3gIABPojtgABntQCAAPrAAIAFFFGA Date: Tue, 16 Apr 2019 17:45:29 +0000 Message-ID: <67A22E3D-9DA8-4F71-ABF4-38A13802436B@akamai.com> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <544663959.23797.1555143088877@appsuite.open-xchange.com> In-Reply-To: <544663959.23797.1555143088877@appsuite.open-xchange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190403 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.49] Content-Type: text/plain; charset="utf-8" Content-ID: <0C1B4FFA1A51DC4F8776D38C5C1D3C0A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=722 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904160113 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=729 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904160113 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 17:45:41 -0000 SXQncyBraW5kYSBsaWtlIGEgbmV3ICJ0cnVzdGVkIHJvb3QiIHByb2dyYW0sIGlzbid0IGl0Pw0K DQo= From nobody Tue Apr 16 11:20:45 2019 Return-Path: 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 DAD4412010C for ; Tue, 16 Apr 2019 11:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 FF57YK-T6B8f for ; Tue, 16 Apr 2019 11:20:42 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 10D9412011C for ; Tue, 16 Apr 2019 11:20:42 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id s2so12119341vsi.5 for ; Tue, 16 Apr 2019 11:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xLqWr1foNBCiTWuXmLzF4HxigCGFuvQUgWNUkx7w5Hg=; b=jUp7yL5qLIovdFeqVY4o1mdH+FUi/vhHoPS4L6bxQLXBvuwKxELA27QKPp/VXshaid AGoC6Iihi2Vfo7HuJ54XhszKUcju5zDy+d9bOUFm2M+mm2iaoPaE673feiOYXwuA22gN EZH8iOLIkSvcMmkrwjJeidDP6VQlljG6ILBG6DUa92H1p3ElmVY+WinDWs1Urzvo79SU 1CAdNrNwBLjck4BlVnvLYIB66taV30chkQQ10P+5JG/yIoqVCK+kdYaC0o7kHaAUP3Fo XOd6BMkFRQY7aLJ1Kk73y0VylbAelOF6PL9fmhdXTOca91RADRQO9fHDT6UROTCIzjC6 3lqw== 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=xLqWr1foNBCiTWuXmLzF4HxigCGFuvQUgWNUkx7w5Hg=; b=hkXb421D6T1Ls4NUbt1cUs9GVCrhN2tm3yORgo31a2FrAXegXDvPDRWV3MEidEsxxn fgsgy6GecuUvRCLvOjCbZmYkTwCHwDP713Qwi3W/mYwI3bVRW2I3rOtylQwhkfbax1VV +XvnNkx09IlhepZwF3L6Ajg/RRMQcVhTAg6hnOXucrxQo6bl6umtKGCgN2SbSabAn2tg DyNP7721VF8PxFSZnOJ4XJbe+lGz86JMEJrtcwZY1lcv3IK9C5MpFQkoB5HxKgwX5W5a cFlLmyhGy35pXjqpf8QntSNdAOw/P+hJk5MnxXnH3H1BOXCf799mPUCdtugU4tX8drYr 6xWw== X-Gm-Message-State: APjAAAUAF9wf3a/dtQrmY7YXcZkq3Ok2fqONyx1JUCsp/kGGKpS0dRxW r4vDzfw4x/WxFhdobm3+UtFNi20V3PjynfEAb3Qx7g== X-Google-Smtp-Source: APXvYqyHJV0mYORVAF7xRAZSyqqm8eMD2dJD74VNyRQ43GyxvuHWp2xzsJGtiGwWNL+smKqzNzTChkwq6wYmU/DAOsE= X-Received: by 2002:a67:f305:: with SMTP id p5mr45842800vsf.191.1555438840738; Tue, 16 Apr 2019 11:20:40 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> In-Reply-To: <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> From: Ben Schwartz Date: Tue, 16 Apr 2019 14:20:28 -0400 Message-ID: To: "Livingood, Jason" Cc: Peter Saint-Andre , "add@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009a10900586a9d3a0" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 18:20:44 -0000 --0000000000009a10900586a9d3a0 Content-Type: multipart/alternative; boundary="00000000000092de650586a9d367" --00000000000092de650586a9d367 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 16, 2019 at 12:00 PM Livingood, Jason < Jason_Livingood@comcast.com> wrote: > And for ease of any replies, I have a separate question on CDN > localization via ECS. The 6th privacy requirement suggests that ECS cannot > be used unless there is encryption between the resolver and the > authoritative server, presumably via DoT. This suggests that the privacy > concern isn't that the network/geographic hint provided by ECS is > problematic in and of itself, but that it should not be observable along > the network path used in recursion. > > But if TRR-to-auth recursion is not available via DoT, I wonder what the > recommended mechanism is for providing a more privacy-protective > network-geographic hint to an authoritative server, in order for example > for a CDN to dynamically respond with a localized response. Maybe something > new needs to be standardized? What options do folks suggest? > The "exit IP" of a widely-distributed large-scale resolver service is such a network-geographic hint, with the level of granularity (and privacy) depending on the scale and architecture of the resolver service. I think the question of whether we can improve on ECS is interesting, but I would encourage you to follow up in DPRIVE or DNSOP, rather than this ADD list, since that question is equally relevant regardless of whether the query is originated by an application. Thanks > Jason > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000092de650586a9d367 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 16, 2019 at 12:00 PM Livingoo= d, Jason <Jason_Livingood= @comcast.com> wrote:
And for ease of any replies, I have = a separate question on CDN localization via ECS. The 6th privacy requiremen= t suggests that ECS cannot be used unless there is encryption between the r= esolver and the authoritative server, presumably via DoT. This suggests tha= t the privacy concern isn't that the network/geographic hint provided b= y ECS is problematic in and of itself, but that it should not be observable= along the network path used in recursion.

But if TRR-to-auth recursion is not available via DoT, I wonder what the re= commended mechanism is for providing a more privacy-protective network-geog= raphic hint to an authoritative server, in order for example for a CDN to d= ynamically respond with a localized response. Maybe something new needs to = be standardized? What options do folks suggest?

The "exit IP" of a widely-distributed large-scale resolv= er service is such a network-geographic hint, with the level of granularity= (and privacy) depending on the scale and architecture of the resolver serv= ice.

I think the question of whether we can improv= e on ECS is interesting, but I would encourage you to follow up in DPRIVE o= r DNSOP, rather than this ADD list, since that question is equally relevant= regardless of whether the query is originated by an application.

Thanks
Jason

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000092de650586a9d367-- --0000000000009a10900586a9d3a0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMB/CJK1MgpV83jiIZMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDMxMzA4MjIxOVoXDTE5MDkw OTA4MjIxOVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCsphkGEsCh0fF4+6Wsi1u40JxI6W6Izew+dLGK4b93LCRAuJ8y g9wSnwGAtk9/23VmtKwBrMaJD5j9SVZpscvLAjrWwADl/THU22uTW0MsUE2fPOPv2s4hE+vMgRmK P2E+xpI6n0gFvn8qrUHO1dm6PJaP5SWa+zdB/Ja1LgMJTpevQqjK4LKjWmHFPR6CplS4RImjGk7U 0I6invTyQnL5p583t5PI7FcM5UyjAqxGEETdAuc7N4IqjNETvPwL0wLIzxPDA5PMqcWPSzg7sBAB LVUQRYNIAJPlVpUdg1IeAjil5BaaWBjEeCLBSGDFX3WaWfMNzQvRZr4i6oJxzV+1AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFFSy8ovdLNSQc8aqxOgKS7sBOm/UMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCbQ++Znz6xh85ZlZEN Y/vAF0vn111O0c2houe4LlLQkoQ1QS4fH5EYcBx/393FTq5n08ezWYVtmeQ6W15e34CqjYNop1Vh mihZ+3J6+LL/6YNi91cp5yMFgxOP9aI/Y8IaIWZJAY2e8yHbYSq0z8kka0H6S4VvFjwtRogkWW95 0SStEwo/8viJ02BwpmVj4YIA6Fva1ZbeN2TnUMCAHJAlKWOGlpHxpcdcWckED0XbSY9w6bllMw1T tsbiUwQxDeO++Y8NfS8rieZgfv3RlobKihE8xbIVGRHIq1gup4nXv6XDwHDYyGhafIfUD4Ix00Wk gnODGb+jPwoQlDX0X64qMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMB/CJK1Mg pV83jiIZMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCSMOhj5b+2Tluhhos7t7RQ 6e7FHsrQDaiy5eeaaPybHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTA0MTYxODIwNDFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGvahDWc9BwX6iI9SAQJfOdKfZ1FqWPX1PtGaqqTh padXFuOtcxHLsCPubxxLY44I7YwfycwySWB0lItvQm46s6dq+qTdMLboSl7ydOMQlF8i39rjJbzJ Gl7/W8wYfzLZQU7e4VfqAkrNPBd+caqw08UQsGq8Mz125GmawZVJjRV3vEXDuZuSPHcd5a30cT3c quJGKNBR8D9CDBvMKDYCq5rui8UBdryHQ1SZap1D3/Z6KLsd5ZbaQTdyQQrECq671nBtu0DIyT/3 ORxdjn5lrh8FpL8B3aZW628XvPo4fe7biipgyL9TeeoEfs0LDdNJ/bgGJgR/usameQmYZzA1XQ== --0000000000009a10900586a9d3a0-- From nobody Tue Apr 16 11:25:46 2019 Return-Path: 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 D3B9B12010C for ; Tue, 16 Apr 2019 11:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 iQJGyw-znVTH for ; Tue, 16 Apr 2019 11:25:43 -0700 (PDT) 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 BBB50120308 for ; Tue, 16 Apr 2019 11:25:41 -0700 (PDT) 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 x3GIPabw018967 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 Apr 2019 13:25:38 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1555439138; bh=yVH6+3UKTlQ+uY48kAZ2ENxl+oAaeU9OvDr1ooGT/L8=; h=Subject:To:References:From:Date:In-Reply-To; b=keePlNVRJ1BXkiiGDkoWEhO7/xDXIqu1SUrYl0beyXSQPB/8Yhdxf4/nylU3WnlfN zbL+6l60QEa262lV1oYcBp6SYylh6LwB/QjHi1sUJ5XwUKiCV7qBbhM2F05YP/F1wy 1JWDqSbfwMkU63EFRDBtN4EtWrw8g/En/ek0Eycs= 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: "Livingood, Jason" , Peter Saint-Andre , "add@ietf.org" References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> From: Adam Roach Message-ID: <2d1d4351-a19f-9f6c-dc03-7827bcddae95@nostrum.com> Date: Tue, 16 Apr 2019 13:25:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 18:25:45 -0000 On 4/16/19 10:08 AM, Livingood, Jason wrote: > But if TRR-to-auth recursion is not available via DoT, I wonder what the recommended mechanism is for providing a more privacy-protective network-geographic hint to an authoritative server, in order for example for a CDN to dynamically respond with a localized response. Maybe something new needs to be standardized? What options do folks suggest? I realize that the kind of change I'm pointing to here would represent a significant shift in deployment models, but perhaps some out-of-the-box thinking would be useful. The results reported in are very encouraging. /a From nobody Tue Apr 16 14:31:46 2019 Return-Path: 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 8019B120155 for ; Tue, 16 Apr 2019 14:31:44 -0700 (PDT) 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 1hP3j9V7LI5C for ; Tue, 16 Apr 2019 14:31:42 -0700 (PDT) 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 DAA82120112 for ; Tue, 16 Apr 2019 14:31:41 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id c20so13119637qkc.10 for ; Tue, 16 Apr 2019 14:31:41 -0700 (PDT) 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=17ry2HpytYB8Xbc8y00DYcMw6w4ffVSFY33How1lCtQ=; b=jlthfLaftzlNQ+C94Yyi3YMybDE3te4U2L+HvxA65PNj+h2TaWiO/JavuGP0oASbqM lXpnCmPqD3GgZB8HPwC4dqiM1As1c3bElIcEa/oBpEL/+7QvA01NSClD96i4rweZpUVs IEgcmuT/mosA4iydtJV/LlPydtO5dQU0EiyIPCjvo8U9JzPsULYamO0Sr3/yCGgvqwW4 YtozulFk20l74+7dX6ofQ6Xn+aQCbh4W29HXTf7hP/wCcnRhEFByx1jwWVQCA1AXbd+4 QzJMQXha/W/bS+2bGT/xoNtoX5riJFqHR3iQha9u3OL4dZSyp73HPmYVlVacjxlUL0V5 2OZA== 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=17ry2HpytYB8Xbc8y00DYcMw6w4ffVSFY33How1lCtQ=; b=eTbICqaSisI4cZl7lZJxAlA/ljrphe1x3Z+lnRr33GP8SdhkSajHmG9NTUQu8k09iQ 2jtJBLu9PjAxvEpaefkTvrAfefFL16Sl9N4EYl+Zzen9ya+QrshCIhrZm5rFNYYDCeR+ chIMWw7qfZBwU4dPkqMuQTt42nRhpS8L93ULCXneQxoJqAL1tBN8q7rNCthgWF7/F+U/ GHZf46LQ5GWbtMIGBF3caIVvlmuy55XxUlamwfFGx/juXeOivJhP0qMj4rKz5z6ZIFcC vQxulUnjBSzsnyPqPRuFkpguh54GDp5VM87qPSOC8OYFt9L/tLCS4ppcdt5TV6qOcUI0 TL8A== X-Gm-Message-State: APjAAAXI9KZTbOpY+4TaEiLg5YGyyIX7Bgjx3/qpchuCIh+vXNMTeqnp pRnkGidtQPGehlzoe/2aeyKsJ8F6G/krKduJpHc= X-Google-Smtp-Source: APXvYqzsJXT1ltRS5pasiiJyEecvtjdljSROEjJ9yKx8EvsY2nBi+o+dDlhnuqosrr843JLo5Z3zAnLmndU6E9UP9QA= X-Received: by 2002:a37:dd8:: with SMTP id 207mr64765529qkn.278.1555450300924; Tue, 16 Apr 2019 14:31:40 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> In-Reply-To: <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> From: Brian Dickson Date: Tue, 16 Apr 2019 14:31:28 -0700 Message-ID: To: "Livingood, Jason" Cc: Peter Saint-Andre , "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a708f80586ac7e28" Archived-At: Subject: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 21:31:44 -0000 --000000000000a708f80586ac7e28 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason < Jason_Livingood@comcast.com> wrote: > And for ease of any replies, I have a separate question on CDN > localization via ECS. The 6th privacy requirement suggests that ECS cannot > be used unless there is encryption between the resolver and the > authoritative server, presumably via DoT. This suggests that the privacy > concern isn't that the network/geographic hint provided by ECS is > problematic in and of itself, but that it should not be observable along > the network path used in recursion. > > But if TRR-to-auth recursion is not available via DoT, I wonder what the > recommended mechanism is for providing a more privacy-protective > network-geographic hint to an authoritative server, in order for example > for a CDN to dynamically respond with a localized response. Maybe something > new needs to be standardized? What options do folks suggest? That's a great question. Apologies in advance for always providing long answers. :-) IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip. I may be oversimplifying the situation, but I believe the vast majority of authority DNS services (or proxy services in front of those) structure their internal representation of things as geo->answer mappings, and generally have some flavor of ip->geo mapping on their front-end(s). Those internal representations may be non-standard, but there are standards for geo representations for country and sub-country levels, e.g. ISO-3166, with 3166-1 being countries, and 3166-2 being sub-country 3-letter codes. I think there is sufficient anonymity in using these codes instead of ECS, which would remove the need to encrypt the resolver-auth transactions, and potentially offer other benefits to auth operators which as a consequence, would potentially improve both the quality of results (by standardizing the GEO codes, and placing the ip->geo accuracy responsibility onto the resolver). There are other ways to improve the whole ECS model by moving to GEO. For example, a query to an authority server with GEO might return not only an answer, but also a hint about the granularity at the specific GEO code. A query for e.g. CA-ON might return an answer for CA-0, indicating that no more-specific answers within CA are available, while a query for e.g. CA might return an answer for CA-1 (indicating that more-specific answers are available, hinting that the resolver might want to ask again). The GEO stuff could be treated analogous to QNAME minimization; ask for the next-more-specific answer IFF more-specifics are available. It would require the resolver to have its own IP->GEO mapping stuff, but has the benefit of getting consistent results across authority providers (always right or always wrong, and the resolver has both the ability and incentive to fix any IP-GEO mapping errors). It probably helps scaling on the cache side (resolver) and zone side (authority). Any authorities doing ECS probably already have the GEO->zone stuff and possibly even encode it that way; the incremental work in supporting an EDNS GEO would in those cases be negligible. Honestly, if GEO can get standardized and reach critical mass, I think it would be valuable on its own, even without the privacy aspects, and I think it would be nice to use it and to deprecate ECS, eventually. Brian. --000000000000a708f80586ac7e28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 16, 2019 at 9:00 AM Livin= good, Jason <Jason_Living= ood@comcast.com> wrote:
And for ease of any replies, I have a separate question on C= DN localization via ECS. The 6th privacy requirement suggests that ECS cann= ot be used unless there is encryption between the resolver and the authorit= ative server, presumably via DoT. This suggests that the privacy concern is= n't that the network/geographic hint provided by ECS is problematic in = and of itself, but that it should not be observable along the network path = used in recursion.

But if TRR-to-auth recursion is not available via DoT, I wonder what the re= commended mechanism is for providing a more privacy-protective network-geog= raphic hint to an authoritative server, in order for example for a CDN to d= ynamically respond with a localized response. Maybe something new needs to = be standardized? What options do folks suggest?

=
That's a great question. Apologies in advance for always providing= long answers. :-)

IMHO, the privacy issue is the = IP portion, not the geo portion, of geo-ip.

I may = be oversimplifying the situation, but I believe the vast majority of author= ity DNS services (or proxy services in front of those) structure their inte= rnal representation of things as geo->answer mappings, and generally hav= e some flavor of ip->geo mapping on their front-end(s).

Those internal representations may be non-standard, but there are = standards for geo representations for country and sub-country levels, e.g. = ISO-3166, with 3166-1 being countries, and 3166-2 being sub-country 3-lette= r codes.

=C2=A0I think there is sufficient anonymi= ty in using these codes instead of ECS, which would remove the need to encr= ypt the resolver-auth transactions, and potentially offer other benefits to= auth operators which as a consequence, would potentially improve both the = quality of results (by standardizing the GEO codes, and placing the ip->= geo accuracy responsibility onto the resolver).

Th= ere are other ways to improve the whole ECS model by moving to GEO. For exa= mple, a query to an authority server with GEO might return not only an answ= er, but also a hint about the granularity at the specific GEO code. A query= for e.g. CA-ON might return an answer for CA-0, indicating that no more-sp= ecific answers within CA are available, while a query for e.g. CA might ret= urn an answer for CA-1 (indicating that more-specific answers are available= , hinting that the resolver might want to ask again). The GEO stuff could b= e treated analogous to QNAME minimization; ask for the next-more-specific a= nswer IFF more-specifics are available.

It would r= equire the resolver to have its own IP->GEO mapping stuff, but has the b= enefit of getting consistent results across authority providers (always rig= ht or always wrong, and the resolver has both the ability and incentive to = fix any IP-GEO mapping errors).

It probably helps = scaling on the cache side (resolver) and zone side (authority).
<= br>
Any authorities doing ECS probably already have the GEO->z= one stuff and possibly even encode it that way; the incremental work in sup= porting an EDNS GEO would in those cases be negligible.

Honestly, if GEO can get standardized and reach critical mass, I thin= k it would be valuable on its own, even without the privacy aspects, and I = think it would be nice to use it and to deprecate ECS, eventually.

Brian.
--000000000000a708f80586ac7e28-- From nobody Tue Apr 16 14:36:26 2019 Return-Path: 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 A3C38120155 for ; Tue, 16 Apr 2019 14:36:24 -0700 (PDT) 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 Zrwr3j3NLCMN for ; Tue, 16 Apr 2019 14:36:22 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 270D4120140 for ; Tue, 16 Apr 2019 14:36:22 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id y5so13119340qkc.11 for ; Tue, 16 Apr 2019 14:36:22 -0700 (PDT) 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=LN/iwFyoDF9aAg+CeE/ZRMz6ji+yYzGSsFmdDNceUCs=; b=XGPQ6S3QWvuhRkzFNRT3YNOI2mbj0Wzi4JwcD+dNrRzH6+j48Ur1XDFpEV/kw8AXef zhh0xkPCAr4G2pGASjwLMIEN4CuViX49Tt0KhW2wUNxrRfuTh3gB8SH8KzAPybWv96Q5 tcXRAuu9xQoMh437BTZPeevaNdGgRYlfuRWZb4s/2KwUytovQVqwsxGAIKq5Pe2IrjOK iaXG7H4z2AHRyzBBo+LDfrWdt3o/Jk62TicJZpH4Rfghliee2egzPlTAkcEEDcqtenGY G77LX2kSCPkHdiFemn8QCBNYpZHadHgNrQ+3+zOcPXARKzp1/EcJkMtxqU79vdMBlV4b /xKg== 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=LN/iwFyoDF9aAg+CeE/ZRMz6ji+yYzGSsFmdDNceUCs=; b=ZAiZO/yQRD1YUSv9VvkHtBtFAdOI043Ao22xQe3hDhNrg6ujetaFT1KAI9+ezzKe7U GZ97Xqo4+nZiQMiX7bCmk2lAYBT15M/wKESwIQTrXEtBJQEeAkr8wygyggZ6Vz7M7sK2 0IxR9QXA5PgQXGTRmQfospwM1lEzx4bXJoR9rvT5FDVjzcBQ/z0tWiaj4yA/1AXmcoec wZSArFlwxG/T+PXOKKiLMCrfyhj0X+fQwWFb1gNPh2dbLckga4vEwOm4090VnUvFQ+7a F0nKJ2CIRLfDwO2o/QxGDkMfOm1FH1YLAR2QAq6CX65FhwEjn7E7NG0qtqy0I5oZyyMa VvbQ== X-Gm-Message-State: APjAAAV+MPSnU6cS7WTXb/Lv3orgXT4D+elwZakMfZVCefwcIFwHsUBA b9zEicc862jf5EuCeThk4ISGWBoyHtPZoOCfmrp1K5xR X-Google-Smtp-Source: APXvYqyxkwpWpAxrZS4rgZ0RBl4vj42t58GN4RvLDLWRzVGdEj5ofQCg0WdEGYfOU027/ltiDpcnMp/bflPwzMtWGeM= X-Received: by 2002:a37:784:: with SMTP id 126mr7332343qkh.10.1555450581234; Tue, 16 Apr 2019 14:36:21 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> In-Reply-To: From: Brian Dickson Date: Tue, 16 Apr 2019 14:36:10 -0700 Message-ID: To: "Livingood, Jason" Cc: Peter Saint-Andre , "add@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005c39640586ac8fff" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 21:36:25 -0000 --0000000000005c39640586ac8fff Content-Type: text/plain; charset="UTF-8" On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson wrote: > > > On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason < > Jason_Livingood@comcast.com> wrote: > >> And for ease of any replies, I have a separate question on CDN >> localization via ECS. The 6th privacy requirement suggests that ECS cannot >> be used unless there is encryption between the resolver and the >> authoritative server, presumably via DoT. This suggests that the privacy >> concern isn't that the network/geographic hint provided by ECS is >> problematic in and of itself, but that it should not be observable along >> the network path used in recursion. >> >> But if TRR-to-auth recursion is not available via DoT, I wonder what the >> recommended mechanism is for providing a more privacy-protective >> network-geographic hint to an authoritative server, in order for example >> for a CDN to dynamically respond with a localized response. Maybe something >> new needs to be standardized? What options do folks suggest? > > > That's a great question. Apologies in advance for always providing long > answers. :-) > > IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip. > > I may be oversimplifying the situation, but I believe the vast majority of > authority DNS services (or proxy services in front of those) structure > their internal representation of things as geo->answer mappings, and > generally have some flavor of ip->geo mapping on their front-end(s). > > Those internal representations may be non-standard, but there are > standards for geo representations for country and sub-country levels, e.g. > ISO-3166, with 3166-1 being countries, and 3166-2 being sub-country > 3-letter codes. > > I think there is sufficient anonymity in using these codes instead of > ECS, which would remove the need to encrypt the resolver-auth transactions, > and potentially offer other benefits to auth operators which as a > consequence, would potentially improve both the quality of results (by > standardizing the GEO codes, and placing the ip->geo accuracy > responsibility onto the resolver). > > There are other ways to improve the whole ECS model by moving to GEO. For > example, a query to an authority server with GEO might return not only an > answer, but also a hint about the granularity at the specific GEO code. A > query for e.g. CA-ON might return an answer for CA-0, indicating that no > more-specific answers within CA are available, while a query for e.g. CA > might return an answer for CA-1 (indicating that more-specific answers are > available, hinting that the resolver might want to ask again). The GEO > stuff could be treated analogous to QNAME minimization; ask for the > next-more-specific answer IFF more-specifics are available. > I forgot to mention another aspect of this idea: privacy-preserving iteration. Rather than only querying for the more-specific code associated with the client, the resolver could just as easily do queries for all of the next-specific-level entries, possibly in parallel, possibly randomized order. The resolver would be able to provide an answer to the client once the particular answer it was looking for was received, and would have the added benefit of pre-populating its cache for the other geographically-close answers. Brian > > It would require the resolver to have its own IP->GEO mapping stuff, but > has the benefit of getting consistent results across authority providers > (always right or always wrong, and the resolver has both the ability and > incentive to fix any IP-GEO mapping errors). > > It probably helps scaling on the cache side (resolver) and zone side > (authority). > > Any authorities doing ECS probably already have the GEO->zone stuff and > possibly even encode it that way; the incremental work in supporting an > EDNS GEO would in those cases be negligible. > > Honestly, if GEO can get standardized and reach critical mass, I think it > would be valuable on its own, even without the privacy aspects, and I think > it would be nice to use it and to deprecate ECS, eventually. > > Brian. > --0000000000005c39640586ac8fff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Apr 16, 2019 at 2:31 PM Brian Dic= kson <brian.peter.dicks= on@gmail.com> wrote:


On Tue, Apr 16, 2019 at 9= :00 AM Livingood, Jason <Jason_Livingood@comcast.com> wrote:
And for ease of any replies, I= have a separate question on CDN localization via ECS. The 6th privacy requ= irement suggests that ECS cannot be used unless there is encryption between= the resolver and the authoritative server, presumably via DoT. This sugges= ts that the privacy concern isn't that the network/geographic hint prov= ided by ECS is problematic in and of itself, but that it should not be obse= rvable along the network path used in recursion.

But if TRR-to-auth recursion is not available via DoT, I wonder what the re= commended mechanism is for providing a more privacy-protective network-geog= raphic hint to an authoritative server, in order for example for a CDN to d= ynamically respond with a localized response. Maybe something new needs to = be standardized? What options do folks suggest?

=
That's a great question. Apologies in advance for always providing= long answers. :-)

IMHO, the privacy issue is the = IP portion, not the geo portion, of geo-ip.

I may = be oversimplifying the situation, but I believe the vast majority of author= ity DNS services (or proxy services in front of those) structure their inte= rnal representation of things as geo->answer mappings, and generally hav= e some flavor of ip->geo mapping on their front-end(s).

Those internal representations may be non-standard, but there are = standards for geo representations for country and sub-country levels, e.g. = ISO-3166, with 3166-1 being countries, and 3166-2 being sub-country 3-lette= r codes.

=C2=A0I think there is sufficient anonymi= ty in using these codes instead of ECS, which would remove the need to encr= ypt the resolver-auth transactions, and potentially offer other benefits to= auth operators which as a consequence, would potentially improve both the = quality of results (by standardizing the GEO codes, and placing the ip->= geo accuracy responsibility onto the resolver).

Th= ere are other ways to improve the whole ECS model by moving to GEO. For exa= mple, a query to an authority server with GEO might return not only an answ= er, but also a hint about the granularity at the specific GEO code. A query= for e.g. CA-ON might return an answer for CA-0, indicating that no more-sp= ecific answers within CA are available, while a query for e.g. CA might ret= urn an answer for CA-1 (indicating that more-specific answers are available= , hinting that the resolver might want to ask again). The GEO stuff could b= e treated analogous to QNAME minimization; ask for the next-more-specific a= nswer IFF more-specifics are available.
=
I forgot to mention another aspect of this idea: privacy-pre= serving iteration. Rather than only querying for the more-specific code ass= ociated with the client, the resolver could just as easily do queries for a= ll of the next-specific-level entries, possibly in parallel, possibly rando= mized order. The resolver would be able to provide an answer to the client = once the particular answer it was looking for was received, and would have = the added benefit of pre-populating its cache for the other geographically-= close answers.

Brian

=C2= =A0

It would require the resolv= er to have its own IP->GEO mapping stuff, but has the benefit of getting= consistent results across authority providers (always right or always wron= g, and the resolver has both the ability and incentive to fix any IP-GEO ma= pping errors).

It probably helps scaling on the ca= che side (resolver) and zone side (authority).

Any= authorities doing ECS probably already have the GEO->zone stuff and pos= sibly even encode it that way; the incremental work in supporting an EDNS G= EO would in those cases be negligible.

Honestly, i= f GEO can get standardized and reach critical mass, I think it would be val= uable on its own, even without the privacy aspects, and I think it would be= nice to use it and to deprecate ECS, eventually.

= Brian.
--0000000000005c39640586ac8fff-- From nobody Tue Apr 16 14:58:54 2019 Return-Path: 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 E5E3012023F for ; Tue, 16 Apr 2019 14:58:52 -0700 (PDT) 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=emu.st 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 dlI3nlYYyOcD for ; Tue, 16 Apr 2019 14:58:51 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 702271200FB for ; Tue, 16 Apr 2019 14:58:51 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 343AA3B01B; Wed, 17 Apr 2019 07:58:49 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1555451929; bh=nWtjyqTFVqXqmciAigJzaOW71js=; h=Comments:Received:Date:Message-ID:From:To:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=pYSWuH9ngiZqQD1ruQYuysOIVqmzfyDDxRRKuMf41NKNg0XDbLtcGxU0+6GjcsbXb jDaSJJxXXeBmO4+880thT6yogffnXhCDF2k78Xnb3F7Y2f+ZzekOdxfvrKkYlUokYC QPc8UlfhWS62KmsqkFKn42Bgw2ryJwRydWhacO/k=acO/k= Comments: QMDA 0.3a Received: (qmail 59654 invoked by uid 1001); 16 Apr 2019 21:58:49 -0000 Date: 16 Apr 2019 21:58:49 +0000 Message-ID: <20190416215849.59653.qmail@f3-external.bushwire.net> From: "Mark Delany" To: add@ietf.org References: <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 21:58:53 -0000 On 16Apr19, Brian Dickson allegedly wrote: > There are other ways to improve the whole ECS model by moving to GEO. There are other reasons for using ECS besides GEO and that is topological proximity and path costs. While it is true that many are using GEO as a proxy for topology because it's close enough for their application, e.g: if countryCode[ip] == "UK" then serve a London IP. if countryCode[ip] == "AU" then serve a Sydney IP. there are others who use ECS as input into path and cost metrics as part of calculating an answer. They do this because latency means everything or costs mean everything or both! Such calculations fail to work with geo-only data - particularly if your deployment is more fine-grained than country-code level. Mark. From nobody Tue Apr 16 15:19:13 2019 Return-Path: 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 C5AE2120192 for ; Tue, 16 Apr 2019 15:19:11 -0700 (PDT) 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 3LRB2U2rd_Is for ; Tue, 16 Apr 2019 15:19:09 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 89952120045 for ; Tue, 16 Apr 2019 15:19:09 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id v20so25191697qtv.12 for ; Tue, 16 Apr 2019 15:19:09 -0700 (PDT) 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=rFtMb/4UjltufnKb3yV44CwHzyDUrLXvK+FeMUQIr4o=; b=Y4NUFFVFNtBpn8xgb8dxknIic83LiZLECG8y3adE+utD6Re+d9Vns8dkCNsyeKHBYW AT6uJpWRSOs5HWfKDI0E3UYfvex1/jiB0PoUwiBrEkntFa08BjJkycGEwyzfmhTqDmEG XxXXPjBiStdRZmu/ANiP71K9ZZtg1t/Qtz4zcCWQjo9c3FjUyT+i2cXHcdmRHsDeaKHn eFYlnpjWj8bqQClhOtnMmSOveVo365Ym0GqfrQJA+j+JQVIuX59cFnRIU06dIJDi23cJ 0NPnIBopqMyUe2CHTOkN7WYJxkKLQJzKs/SL5+j1C1BvhsVJw1KcnrhDkaAM0zVllCtK dzVA== 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=rFtMb/4UjltufnKb3yV44CwHzyDUrLXvK+FeMUQIr4o=; b=ol2n84weYz5EvKEozyWe4vR3RinNwzyyZGMSHvjOGyXuZ2bhPoRcuamTSOG1/xTj+v P0IY2l7oY52aY+d0d1q/Ass/aWlNQQojy2Egt75hssVWeRHAqI1pyYoDr96y8GbsSE83 K8Z0gmyMTb+vYC/HzNPKTUutzIFbhzMkI2L+XlDV3L34rPgXVQOXL1eUI1CcNGQFry4f 86lzPNQtn5ORQbIhGW6D+2Qjyhv7l4ubq97cYnzyytv4YX0aIBjjmiFtPZM4BDAcONA0 JHExQnqSV1GcMwqLTe/bEIIgRgmh+SKa55lF2tc+pdlGzGk+jXIFV4mPs32AVBJt+c0Y LqwA== X-Gm-Message-State: APjAAAVpsTHY+R717pSYosPTGdwKDHgZrhQK17rhedFbfpAraLh/UGZm UFDqxen9qo65ge/eaHFvD4sE+dtUzgGS1HJHdkdbCHMh2cQ= X-Google-Smtp-Source: APXvYqwv/lMbrsXcrIZYVK/OTQGRKr6++eLx/7zWhQ8d6s/V0R2L8HLg9xOrknaH4Brer5KJeg6Z1CcNU8RLlJ/AUzs= X-Received: by 2002:ac8:1638:: with SMTP id p53mr66535099qtj.257.1555453148673; Tue, 16 Apr 2019 15:19:08 -0700 (PDT) MIME-Version: 1.0 References: <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> <20190416215849.59653.qmail@f3-external.bushwire.net> In-Reply-To: <20190416215849.59653.qmail@f3-external.bushwire.net> From: Brian Dickson Date: Tue, 16 Apr 2019 15:18:57 -0700 Message-ID: To: Mark Delany Cc: add@ietf.org Content-Type: multipart/alternative; boundary="0000000000006439d30586ad2832" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 22:19:12 -0000 --0000000000006439d30586ad2832 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 16, 2019 at 2:58 PM Mark Delany wrote: > On 16Apr19, Brian Dickson allegedly wrote: > > > There are other ways to improve the whole ECS model by moving to GEO. > > There are other reasons for using ECS besides GEO and that is > topological proximity and path costs. > > While it is true that many are using GEO as a proxy for topology > because it's close enough for their application, e.g: > > if countryCode[ip] == "UK" then serve a London IP. > if countryCode[ip] == "AU" then serve a Sydney IP. > > > there are others who use ECS as input into path and cost metrics as > part of calculating an answer. > > They do this because latency means everything or costs mean everything > or both! Such calculations fail to work with geo-only data - > particularly if your deployment is more fine-grained than country-code > level. > > Yes, I agree with what you are saying. That's why I indicated that by "geo", I meant OPTIONALLY more fine-grained than country-level: >country and sub-country levels, e.g. ISO-3166, with 3166-1 being countries, and 3166-2 being sub-country 3-letter codes. (This may or may not be adequate for some of those currently doing ECS; however, without GEO, there is no alternative.) The original question raised by JL was what alternatives there might be to ECS, that could preserve privacy without requiring encryption? In general, the existence of two solutions, ECS and GEO, would facilitate various "consenting adults" to agree on ECS where there is reason to do so. It might be a bit more data to stuff into a query (either or both of ECS and GEO), and for the answer returned to indicate which one was used (ECS or GEO). But I think that way would support multiple use cases, including encrypted or not (according to agreements with e.g. browser vendors for inclusion on some list). So, "moving" might not mean the same thing for everyone, it is more a question of "supporting a new standard, with or without supporting an older standard".. I'm pretty sure we are not in a one-size-fits-all world here. Brian --0000000000006439d30586ad2832 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 16, 2019 at 2:58 PM Mark = Delany <h4m@mike.emu.st> wrote= :
On 16Apr19, Br= ian Dickson allegedly wrote:

> There are other ways to improve the whole ECS model by moving to GEO.<= br>
There are other reasons for using ECS besides GEO and that is
topological proximity and path costs.

While it is true that many are using GEO as a proxy for topology
because it's close enough for their application, e.g:

=C2=A0 =C2=A0 if countryCode[ip] =3D=3D "UK" then serve a London = IP.
=C2=A0 =C2=A0 if countryCode[ip] =3D=3D "AU" then serve a Sydney = IP.


there are others who use ECS as input into path and cost metrics as
part of calculating an answer.

They do this because latency means everything or costs mean everything
or both! Such calculations fail to work with geo-only data -
particularly if your deployment is more fine-grained than country-code
level.


Yes, I agree with what you a= re saying.

That's why I indicated that by &quo= t;geo", I meant OPTIONALLY more fine-grained than country-level:
=

>country and sub-country levels, e.g. ISO-3166, with= 3166-1 being countries, and 3166-2 being sub-country 3-letter codes.
=

(This may or may not be adequate for some of those curr= ently doing ECS; however, without GEO, there is no alternative.)
=
The original question raised by JL was what alternatives the= re might be to ECS, that could preserve privacy without requiring encryptio= n?

In general, the existence of two solutions, ECS= and GEO, would facilitate various "consenting adults" to agree o= n ECS where there is reason to do so.

It might be = a bit more data to stuff into a query (either or both of ECS and GEO), and = for the answer returned to indicate which one was used (ECS or GEO).
<= div>
But I think that way would support multiple use cases, i= ncluding encrypted or not (according to agreements with e.g. browser vendor= s for inclusion on some list).

So, "moving&qu= ot; might not mean the same thing for everyone, it is more a question of &q= uot;supporting a new standard, with or without supporting an older standard= "..

I'm pretty sure we are not in a one-size-fits-al= l world here.

Brian=C2=A0
--0000000000006439d30586ad2832-- From nobody Tue Apr 16 16:10:20 2019 Return-Path: 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 85CAB120402 for ; Tue, 16 Apr 2019 16:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st 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 okid9emhiRTJ for ; Tue, 16 Apr 2019 16:10:18 -0700 (PDT) Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9101201CE for ; Tue, 16 Apr 2019 16:10:18 -0700 (PDT) Received: by f3.bushwire.net (Postfix, from userid 1001) id 5674F3B01B; Wed, 17 Apr 2019 09:10:16 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1555456216; bh=Trb1NlZ770zRbQ/WQYj4z8p9SJY=; h=Comments:Received:Date:Message-ID:From:Cc:Subject:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; b=PbX23KuJwkdWSxFe1Rc1i82MB7ovbasmnEfcc4KTfrOJmLXZ2pOBRTYQmzU8zy5vB g9QF4ZjVP3IXcI6qmu7qOSQjVj0GUdzmd4UyzBtKda8dxFwO/xuuRvaOb/yITLh7Z5 Lj30ASgqlDzKS+Xcl9c0wYlu478C2L8nEX3EOsMk=EOsMk= Comments: QMDA 0.3a Received: (qmail 60304 invoked by uid 1001); 16 Apr 2019 23:10:16 -0000 Date: 16 Apr 2019 23:10:16 +0000 Message-ID: <20190416231016.60303.qmail@f3-external.bushwire.net> From: "Mark Delany" Cc: add@ietf.org References: <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> <20190416215849.59653.qmail@f3-external.bushwire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 23:10:19 -0000 On 16Apr19, Brian Dickson allegedly wrote: > That's why I indicated that by "geo", I meant OPTIONALLY more fine-grained > than country-level: > > >country and sub-country levels, e.g. ISO-3166, with 3166-1 being > countries, and 3166-2 being sub-country 3-letter codes. I hope I'm not mis-understanding you, but no level of fine-grained GEO provides suitable input for topology-based solvers. I want to know which networks you are connected to and even a high-precision lat/long doesn't tell me that. Your /24 does. > I'm pretty sure we are not in a one-size-fits-all world here. For sure, but fine-grained GEO raises more questions. What if you want to send sub-country codes to trusted auths to get better resolution but only country codes to less trusted auths to get better privacy. How is that provisioned in end-user equipment and kept current? The other thing is that auths can play discovery tricks to correlate queries with client IPs anyway. E.g. issue nonce IPs with very short TTLs then watch for inbound connections. (Finally a killer app for IPv6!). So I think we want to be crystal clear about what privacy risk we think is being solved and whether it's lulling people into a false sense of security or not. Mark. From nobody Tue Apr 16 16:48:51 2019 Return-Path: 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 EF2B4120287 for ; Tue, 16 Apr 2019 16:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 zvoau-vs5Rks for ; Tue, 16 Apr 2019 16:48:47 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 6A928120285 for ; Tue, 16 Apr 2019 16:48:47 -0700 (PDT) Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1hGXol-00151f-Dt for add@ietf.org; Wed, 17 Apr 2019 01:48:48 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp04.mail2web.com with esmtp (Exim 4.63) (envelope-from ) id 1hGXoe-00025q-T9 for add@ietf.org; Tue, 16 Apr 2019 19:48:44 -0400 Received: (qmail 27073 invoked from network); 16 Apr 2019 23:48:39 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.204]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Apr 2019 23:48:39 -0000 To: Adam Roach , "Livingood, Jason" , Peter Saint-Andre , "add@ietf.org" References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> <2d1d4351-a19f-9f6c-dc03-7827bcddae95@nostrum.com> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <2e29b581-ba60-9ff2-1f8e-3c874ce2897b@huitema.net> Date: Tue, 16 Apr 2019 16:48:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2d1d4351-a19f-9f6c-dc03-7827bcddae95@nostrum.com> Content-Type: multipart/alternative; boundary="------------E01D5516A4FA944224033090" Content-Language: en-US X-Originating-IP: 168.144.250.231 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.08) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5utZCiSjLoRSjotyiirzrBN602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO+ST6QJhH22IyI7Z98CXHvxVMZsRZacTbJPGp/MBC6BxVpU7X8EkdHtMXnQwnhdcJ0h5 mNm/WjPqhYqCeBiCKwwnRtk/d5gNfEtjtud5V8jpAx8WiOp3k5R0E3oWxTrHKR/TBCf6oYXAWGet lavcAjAiREicRPMV5adYQyNOvKmgwJpy2yi2NB5qsi4dVukIa9cV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseytLy0an6SuH9Dnc48fGLIT5nvmah7oAQX1Q8bvqOef6+oRd8C8BKt7 l6hdaAN6MF9qJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+TvNcd3HWUjlOEFEnWeTdqCDg5/bq7ChmPMN Ycw1QSmR9kNK2zyQpQLXLShSKzPps8ZABLZ4N/EoBnhamdk8Kupm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhijAHO4UjZyr3s8K1Hs5JOni+NTKQHNkjJg8xvPcdYB8XgK1T2S4h8DThwS4W K6Op7v27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 23:48:50 -0000 This is a multi-part message in MIME format. --------------E01D5516A4FA944224033090 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 4/16/2019 11:25 AM, Adam Roach wrote: > On 4/16/19 10:08 AM, Livingood, Jason wrote: >> But if TRR-to-auth recursion is not available via DoT, I wonder what >> the recommended mechanism is for providing a more privacy-protective >> network-geographic hint to an authoritative server, in order for >> example for a CDN to dynamically respond with a localized response. >> Maybe something new needs to be standardized? What options do folks >> suggest? > > > I realize that the kind of change I'm pointing to here would represent > a significant shift in deployment models, but perhaps some > out-of-the-box thinking would be useful. The results reported in > > are very encouraging. On a related note, the IETF version of QUIC is including an option to automatically migrate a client's QUIC connection to a "server preferred address". This is specifically designed so the initial handshake can happen through a server anycast address, but the reminder of the connection goes through a server unicast address specific to the server site. I short, it will work as long as anycast routing remains stable for 1 RTT or 2. -- Christian Huitema --------------E01D5516A4FA944224033090 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 4/16/2019 11:25 AM, Adam Roach wrote:
On 4/16/19 10:08 AM, Livingood, Jason wrote:
But if TRR-to-auth recursion is not available via DoT, I wonder what the recommended mechanism is for providing a more privacy-protective network-geographic hint to an authoritative server, in order for example for a CDN to dynamically respond with a localized response. Maybe something new needs to be standardized? What options do folks suggest?


I realize that the kind of change I'm pointing to here would represent a significant shift in deployment models, but perhaps some out-of-the-box thinking would be useful. The results reported in <https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf> are very encouraging.


On a related note, the IETF version of QUIC is including an option to automatically migrate a client's QUIC connection to a "server preferred address". This is specifically designed so the initial handshake can happen through a server anycast address, but the reminder of the connection goes through a server unicast address specific to the server site. I short, it will work as long as anycast routing remains stable for 1 RTT or 2.

-- Christian Huitema

--------------E01D5516A4FA944224033090-- From nobody Tue Apr 16 16:53:35 2019 Return-Path: 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 817861200EC for ; Tue, 16 Apr 2019 16:53:34 -0700 (PDT) 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 Zq0AbWZ3wSy3 for ; Tue, 16 Apr 2019 16:53:32 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 F28EA1200B4 for ; Tue, 16 Apr 2019 16:53:31 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id t28so25451979qte.6 for ; Tue, 16 Apr 2019 16:53:31 -0700 (PDT) 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=YrJMeNIkm6R3GbvsWuuk56neANb2OZbd6UP9eXUTm/c=; b=sKYkxsQmyo9UqqzZyjB/S7VyYLA3ZTr2UMKEGGCAdhBShSox9ugsx8chsB1t/P76mD 64HVzBuRfCDYS8qzF+aor0mmGwwB4Ab+zYXPUBhCXW4wBF3PoybPpBeIQQvuIzCYd8ve 1LbH4TqSUZURAQKTBEm0oJiaUGUsD2k27xI+BtCgfsah55gzFs25Gc8DDeEn6dGRCUL4 XeL2Sf01YHigS838qzbgWkFP996f2XKQx9fFnWKofIs9BItsxveh+NKxA3OU2SVkHHIR W2YMVlKpH2obIAbskmwYPvjd+tYNutx06oBhp8inRaNsvQczsooDV1yU4ziaZTdQEJSs /phw== 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=YrJMeNIkm6R3GbvsWuuk56neANb2OZbd6UP9eXUTm/c=; b=tLX2jrfvBC6RRgeh3hpuCV5TXjCm0jLZsmcycdw2rfFXA+f6+V83VFF8YnY5Ic6LSs UMK8MRZzLdEmNe55hDqQxc2tnyD2xFzjZrVLHIQkekQtJGlMErhmfZ7ihQ8Q1qNZbU0W /gaojr5Nv7gzDE353Gvzp4vOO8KpcDAMbE1KRRa/9X0knIHYO53xL+Wu0fVwHPgO47sx UNTpfje6g6CDspQusuKxnrVBGjh3X6RcyzAHNiz2M6x399nilu6OKZIaFoNoi0BYm+4n 2rqGDwPYl6HMJe+OWhYHXnYSsjbAW2mLy5RziY9v/0AJJGDH9M3Z71tgoLWHejJaw776 dCog== X-Gm-Message-State: APjAAAXZ9T42Qd4RYmHnydmZy/QROq8ZXqtjfw9l+uQIIjG6NwNTcgoG G2GXL7AJY8OQewD/r1iQzflv+pEfbO3M+3giA1xA4CK8 X-Google-Smtp-Source: APXvYqztpO5qFwLlfxP5SbgCN0+8G3JgRr+QoKTl0y0792Mi1k+6p53IGs6hq8ZrDJ4ANU+CycMJM30wox3ZNrhh23I= X-Received: by 2002:ac8:1a34:: with SMTP id v49mr68138552qtj.236.1555458809081; Tue, 16 Apr 2019 16:53:29 -0700 (PDT) MIME-Version: 1.0 References: <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> <20190416215849.59653.qmail@f3-external.bushwire.net> <20190416231016.60303.qmail@f3-external.bushwire.net> In-Reply-To: <20190416231016.60303.qmail@f3-external.bushwire.net> From: Brian Dickson Date: Tue, 16 Apr 2019 16:53:17 -0700 Message-ID: To: Mark Delany Cc: add@ietf.org Content-Type: multipart/alternative; boundary="000000000000c7332d0586ae799a" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 23:53:35 -0000 --000000000000c7332d0586ae799a Content-Type: text/plain; charset="UTF-8" On Tue, Apr 16, 2019 at 4:10 PM Mark Delany wrote: > On 16Apr19, Brian Dickson allegedly wrote: > > > That's why I indicated that by "geo", I meant OPTIONALLY more > fine-grained > > than country-level: > > > > >country and sub-country levels, e.g. ISO-3166, with 3166-1 being > > countries, and 3166-2 being sub-country 3-letter codes. > > I hope I'm not mis-understanding you, but no level of fine-grained GEO > provides suitable input for topology-based solvers. I want to know > which networks you are connected to and even a high-precision lat/long > doesn't tell me that. Your /24 does. > Yes, I understand. For you, ECS works fine, and GEO doesn't. So, continue to use ECS, and don't use GEO. I don't understand why that would be a problem, unless resolver operators choose not to continue to send ECS. They might make that decision based on the requirements to encrypt if ECS is used. Or, they may decide doing ECS is worth the encryption cost, and encrypt and use ECS. (Those issues would be something for you to take up with them, IMHO.) Other auth servers might make different decisions on ECS, for whatever reason. Those other auth folks might not want to encrypt, and may want to use GEO. For them, that may be good enough. Them doing GEO doesn't impact you doing ECS, unless I'm missing something obvious. GEO might not be as good as ECS, but there are plenty of cases where the difference is moot. E.g. if the zone owner (!= auth operator) has services in only a few places, and they don't benefit from any granularity improvement. > > > I'm pretty sure we are not in a one-size-fits-all world here. > > For sure, but fine-grained GEO raises more questions. What if you want > to send sub-country codes to trusted auths to get better resolution > but only country codes to less trusted auths to get better > privacy. How is that provisioned in end-user equipment and kept > current? > Don't know, don't particularly care, honestly. I would expect that to be something managed on a per-auth-provider basis, or maybe negotiated somehow? What does "trusted" mean, privacy or something else? > > > The other thing is that auths can play discovery tricks to correlate > queries with client IPs anyway. E.g. issue nonce IPs with very short > TTLs then watch for inbound connections. (Finally a killer app for > IPv6!). So I think we want to be crystal clear about what privacy risk > we think is being solved and whether it's lulling people into a false > sense of security or not. > I think that would imply cooperation between auths and those seeking to defeat the privacy of Do*. I don't think anything done resolver-auth has the ability to impact that cooperation, if it exists. I.e. if an auth does that nonce trick, it doesn't matter whether the resolver encrypts the connection, it doesn't matter whether ECS is used or GEO is used. The client's association is discovered on the data connection established based on the DNS answer. Maybe the resolver can implement counter-measures on behalf of clients, maybe not. But the issues is invariant over encrypted/clear or ECS or GEO, as far as I can tell. In fact, I'd argue the granularity aspect of GEO may provide better "cover" to clients, since the recursive could do any number of things for low TTLs that compensate. I'm not condoning any particular countermeasure, only suggesting that the existence of countermeasures which align better and scale better with GEO, could be more effective. Examples might be, requerying and keeping a variety of answer sets, and serving them randomly, i.e. a combination of "hammer" and "serve-stale". Privacy, like security is hard. Trying to mesh efficient/accurate results with privacy is also hard, and may require re-thinking solutions. There may be some need to trade off efficiency with privacy, or to consider other means of approaching the solution space for efficiency (with respect to topology). E.g. maybe instead of GEO, using ASN based mechanisms, which better reflect topology, while offering some degree of privacy. Clearly there is non-uniformity, since some ASNs have very few prefixes which are small, and others have lots of large prefixes. Thoughts on this? Brian --000000000000c7332d0586ae799a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 16, 2019 at 4:10 PM Mark = Delany <h4m@mike.emu.st> wrote= :
On 16Apr19, Br= ian Dickson allegedly wrote:

> That's why I indicated that by "geo", I meant OPTIONALLY= more fine-grained
> than country-level:
>
> >country and sub-country levels, e.g. ISO-3166, with 3166-1 being > countries, and 3166-2 being sub-country 3-letter codes.

I hope I'm not mis-understanding you, but no level of fine-grained GEO<= br> provides suitable input for topology-based solvers. I want to know
which networks you are connected to and even a high-precision lat/long
doesn't tell me that. Your /24 does.

Yes, I understand. For you, ECS works fine, and GEO doesn't.
So, continue to use ECS, and don't use GEO.

= I don't understand why that would be a problem, unless resolver operato= rs
choose not to continue to send ECS.=C2=A0

=
They might make that decision based on the requirements to encrypt
if ECS is used. Or, they may decide doing ECS is worth the encryptio= n cost,
and encrypt and use ECS.
(Those issues would be= something for you to take up with them, IMHO.)

Ot= her auth servers might make different decisions on ECS, for whatever reason= .
Those other auth folks might not want to encrypt, and may want = to use GEO.
For them, that may be good enough.

Them doing GEO doesn't impact you doing ECS, unless I'm miss= ing something obvious.

GEO might not be as good as= ECS, but there are plenty of cases where the difference is moot.
E.g. if the zone owner (!=3D auth operator) has services in only a few pla= ces, and they don't benefit
from any granularity improvement.=
=C2=A0

> I'm pretty sure we are not in a one-size-fits-all world here.

For sure, but fine-grained GEO raises more questions. What if you want
to send sub-country codes to trusted auths to get better resolution
but only country codes to less trusted auths to get better
privacy. How is that provisioned in end-user equipment and kept
current?

Don't know, don't part= icularly care, honestly.
I would expect that to be something mana= ged on a per-auth-provider basis,
or maybe negotiated somehow?

What does "trusted" mean, privacy or somet= hing else?
=C2=A0


The other thing is that auths can play discovery tricks to correlate
queries with client IPs anyway. E.g. issue nonce IPs with very short
TTLs then watch for inbound connections. (Finally a killer app for
IPv6!). So I think we want to be crystal clear about what privacy risk
we think is being solved and whether it's lulling people into a false sense of security or not.

I think that = would imply cooperation between auths and those seeking to defeat the priva= cy of Do*.
I don't think anything done resolver-auth has the = ability to impact that cooperation, if it exists.

= I.e. if an auth does that nonce trick, it doesn't matter whether the re= solver encrypts the connection,
it doesn't matter whether ECS= is used or GEO is used. The client's association is discovered on
the data connection established based on the DNS answer.
Maybe the resolver can implement counter-measures on behalf of= clients, maybe not.
But the issues is invariant over encrypted/c= lear or ECS or GEO, as far as I can tell.

In fact,= I'd argue the granularity aspect of GEO may provide better "cover= " to clients,
since the recursive could do any number of thi= ngs for low TTLs that compensate.
I'm not condoning any parti= cular countermeasure, only suggesting that the existence
of count= ermeasures which align better and scale better with GEO, could be more
effective. Examples might be, requerying and keeping a variety of ans= wer sets, and
serving them randomly, i.e. a combination of "= hammer" and "serve-stale".

Privacy,= like security is hard. Trying to mesh efficient/accurate results with priv= acy is also hard,
and may require re-thinking solutions.

There may be some need to trade off efficiency with privac= y, or to consider other means
of approaching the solution space f= or efficiency (with respect to topology).

E.g. may= be instead of GEO, using ASN based mechanisms, which better reflect topolog= y,
while offering some degree of privacy. Clearly there is non-un= iformity, since some ASNs have
very few prefixes which are small,= and others have lots of large prefixes.

Thoughts = on this?

Brian
--000000000000c7332d0586ae799a-- From nobody Tue Apr 16 18:57:26 2019 Return-Path: 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 13269120243 for ; Tue, 16 Apr 2019 15:40:17 -0700 (PDT) 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, 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 (1024-bit key) header.d=apnic.onmicrosoft.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 ltQFRl8tAZWP for ; Tue, 16 Apr 2019 15:40:13 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1310045.outbound.protection.outlook.com [40.107.131.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250A3120241 for ; Tue, 16 Apr 2019 15:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P3wDuywdO254oBDwoDs/lI0t9vOmlBCdCGMtMICjMUc=; b=obUo+T9wIq+TiU/mibnaXryd0bL3ak8StBAzt4P6oTB20mTY1/wVSdlLJ1KlXjvMm0qT/lLriF9qx6ZMZwACaMcy4ykJK1zBTQiXdQwzFV9kRX96XIiWhNNQctT9ySeix9EHcuDTKuxtlc9+BqhwKwRnDIyVoybk0N8870sW4UY= Received: from HK0PR04MB2660.apcprd04.prod.outlook.com (20.177.29.11) by HK0PR04MB3236.apcprd04.prod.outlook.com (20.177.160.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Tue, 16 Apr 2019 22:40:09 +0000 Received: from HK0PR04MB2660.apcprd04.prod.outlook.com ([fe80::218c:c614:767:6fcd]) by HK0PR04MB2660.apcprd04.prod.outlook.com ([fe80::218c:c614:767:6fcd%5]) with mapi id 15.20.1813.011; Tue, 16 Apr 2019 22:40:09 +0000 From: Geoff Huston To: "add@ietf.org" CC: Peter Saint-Andre Thread-Topic: [Add] Mozilla's DoH resolver policy Thread-Index: AQHU9KVY5LK2ZSiLR0KzB1rN7lEtJA== Date: Tue, 16 Apr 2019 22:40:09 +0000 Message-ID: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> In-Reply-To: <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: HK2PR02CA0199.apcprd02.prod.outlook.com (2603:1096:201:20::11) To HK0PR04MB2660.apcprd04.prod.outlook.com (2603:1096:203:6b::11) x-originating-ip: [61.219.139.1] authentication-results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Apple Mail (2.3445.104.8) x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5bce73d-c9fb-440f-6e23-08d6c2bc7b08 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:HK0PR04MB3236; x-ms-traffictypediagnostic: HK0PR04MB3236: x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(39830400003)(346002)(366004)(199004)(189003)(2616005)(7736002)(6486002)(446003)(229853002)(11346002)(6436002)(8936002)(5640700003)(86362001)(1730700003)(76176011)(81166006)(2906002)(81156014)(486006)(8676002)(386003)(106356001)(102836004)(5660300002)(476003)(256004)(6506007)(53546011)(26005)(186003)(2351001)(478600001)(14454004)(52116002)(6916009)(93886005)(105586002)(33656002)(57306001)(6246003)(305945005)(82746002)(316002)(68736007)(36756003)(4744005)(6512007)(71200400001)(4326008)(50226002)(97736004)(2501003)(53936002)(71190400001)(66066001)(3846002)(25786009)(6116002)(83716004)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HK0PR04MB3236; H:HK0PR04MB2660.apcprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ymSwAd/VSi2ptxsX5o8hxIvs6rml2J4D+B5d4TmpGrnyPqozRD/D+UnUd0SisZgAg7zJJHFfLyDXBlVC+g+TgXce5E/mxRy4rqgIPRnLy/o8N3DBOnNfIvC56h7SijZrY6fzu9pHAOwkw6x+TDEemy+GO2vUzRDN3V3RTSXllmDt2yLtEa/8YekDsuceGbfvYF43NifvE4Q+i3uDJ/OrEtp7zge1mw58VfpwjYx8NqIicBzxlOBQf0n/qZ1GtE9gL5AMIa5tLgJTdibfLJi0reunUq5ew3jkOqtX9ZwhV2t3ApRt8AyOmFULtrlGhVVj+zoIJ97j426GluCBN6fwS7x3EJJZCejdljKBmYghFcM8ysx8r1AmIqlOIq2ieYJclxElGOcqoVyqqU6siWGn3Guad9feY3VTYRXKnfcZeYc= Content-Type: text/plain; charset="us-ascii" Content-ID: <871D069450D53142853E3747F98E205D@apcprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-Network-Message-Id: d5bce73d-c9fb-440f-6e23-08d6c2bc7b08 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 22:40:09.7218 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR04MB3236 Archived-At: X-Mailman-Approved-At: Tue, 16 Apr 2019 18:57:24 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 22:40:17 -0000 > On 17 Apr 2019, at 12:58 am, Livingood, Jason wrote: >=20 > So I'd say require DNSSEC validation FWIW so would I - securing the channel is not the same as being able to tru= st the integrity of the content carried in the channel, and for the latter = all we have is DNSSEC. The secured channel does allow the client to place s= lightly more trust in the AD bit in the response. Geoff= From nobody Wed Apr 17 00:20:20 2019 Return-Path: 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 89BEA120161 for ; Wed, 17 Apr 2019 00:20:18 -0700 (PDT) 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 BEw0RnlD0ki2 for ; Wed, 17 Apr 2019 00:20:16 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id D7B801204BF for ; Wed, 17 Apr 2019 00:20:15 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 57BB45F42164; Wed, 17 Apr 2019 09:20:14 +0200 (CEST) Received: from [172.19.152.234] (tmo-122-49.customers.d1-online.com [80.187.122.49]) (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 955A05F4005F; Wed, 17 Apr 2019 09:20:12 +0200 (CEST) From: "Ralf Weber" To: "Ben Schwartz" Cc: "Livingood, Jason" , add@ietf.org, "Peter Saint-Andre" Date: Wed, 17 Apr 2019 09:20:05 +0200 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 07:20:19 -0000 Moin! On 16 Apr 2019, at 20:20, Ben Schwartz wrote: > I think the question of whether we can improve on ECS is interesting, but I > would encourage you to follow up in DPRIVE or DNSOP, rather than this ADD > list, since that question is equally relevant regardless of whether the > query is originated by an application. That is correct and there is work in dprive on that. However it is relevant here as Mozilla has required secure communication between recursive and authoritative servers, for which we don’t have a standard. So the question is should applications require something that is not standardised in any way (and not use something that has been standardised for over a decade - DNSSEC - but I guess that is a different question)? So long -Ralf —-- Ralf Weber From nobody Wed Apr 17 01:44:41 2019 Return-Path: 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 BC2B1120148 for ; Wed, 17 Apr 2019 01:44:39 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 iRpZEWsS_tNg for ; Wed, 17 Apr 2019 01:44:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 245DC120146 for ; Wed, 17 Apr 2019 01:44:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44kbQC3JQbz3J6; Wed, 17 Apr 2019 10:44:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1555490675; bh=ZHM7AyZFMmvJi7gy4KgSPnFzgaoG3ZAuc7kG4Kg1u1o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=u6kgdOugQcTwTZYhgHBslUcpvCs2cyKbTXXrnHyN+6kyocpGC9eqkinejpFa98CZJ vZ2NFSB+6+SmgyIt0k8Fu/LwY+g9mqvtFA6Y/33XLToRP1TMrAKutxJqOGcq7YYmQO vR/7wXLnIwbsj1ouewcoLVyMS7WFOYfXzCjRLf3E= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 0D9Gmzra4bSd; Wed, 17 Apr 2019 10:44:34 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 17 Apr 2019 10:44:33 +0200 (CEST) Received: from [10.150.23.59] (unknown [46.135.24.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 3B85F79AFC; Wed, 17 Apr 2019 04:44:32 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3B85F79AFC Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16D57) In-Reply-To: <67A22E3D-9DA8-4F71-ABF4-38A13802436B@akamai.com> Date: Wed, 17 Apr 2019 10:44:11 +0200 Cc: Vittorio Bertola , Peter Saint-Andre , "add@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <499D0B06-F676-4C2D-A809-C61477B3498D@nohats.ca> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <544663959.23797.1555143088877@appsuite.open-xchange.com> <67A22E3D-9DA8-4F71-ABF4-38A13802436B@akamai.com> To: "Salz, Rich" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 08:44:40 -0000 > On Apr 16, 2019, at 19:45, Salz, Rich wrote: >=20 > It's kinda like a new "trusted root" program, isn't it? No, dnssec is the =E2=80=9Cnew=E2=80=9D trusted root program. This is about t= ransport privacy only.=20 Paul From nobody Wed Apr 17 09:04:31 2019 Return-Path: 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 83A29120458 for ; Wed, 17 Apr 2019 09:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 FpzbX_S_j2rb for ; Wed, 17 Apr 2019 09:04:27 -0700 (PDT) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 3AD5112044D for ; Wed, 17 Apr 2019 09:04:27 -0700 (PDT) Received: by mail-wm1-f46.google.com with SMTP id z24so4265226wmi.5 for ; Wed, 17 Apr 2019 09:04:27 -0700 (PDT) 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=0PM0EhlTay0qsLSntqZwXGIujD9cEMN1GXleIRTsuUk=; b=D6mnUYhW+BRtv3K3/Vvtd1ZHkd2839NRcC0RzN5uqzzJGAQ2+H2FhD7mk2J+873w3t 46BWyZqKplc9QmOWXM2lWd/LS0nrseorxF0Y0Nej5q6XnYW17tgts0/GNdiIWtMjd/zb zqizaSp4UgcqMb8L8a7U+Lkj4WeJQEhvRw2DWYKPuyjryEND7om1ivohcbMXAvk44Yc7 Y/x9kARQIn+wkfh8yeyIIPE37c/461WP+WtpPsUu1ZbkPc8ORqZz1KG5zpxv/SiJTCoS qmT14G/db/875LIEd5+XOXmEo3HaghKmeo+prSMKsiU2SsasfmOTWX5Am+1d8qca9dvE yLRg== X-Gm-Message-State: APjAAAVlRDLols8MayQA8ovSZkyEI4LX8jt4nrmYWjeS7VbowZ0Ji/ol W7CkJrE1Hw3uB+5cWvu9H8XoG9hObaE8Cv64dBk= X-Google-Smtp-Source: APXvYqxNW4/1InrH3ZuvR7h64YkmnYWEUucg58Q4trwWqKzo/XQMieDfogzzkAhmMIFspT2YLrysAMpofoSirzTWf6E= X-Received: by 2002:a7b:c1cf:: with SMTP id a15mr364798wmj.44.1555517065263; Wed, 17 Apr 2019 09:04:25 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> In-Reply-To: From: Erik Nygren Date: Wed, 17 Apr 2019 09:04:13 -0700 Message-ID: To: Brian Dickson Cc: "Livingood, Jason" , "add@ietf.org" , Peter Saint-Andre , "Plonka, David" Content-Type: multipart/alternative; boundary="0000000000001dff9a0586bc0a9a" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 16:04:29 -0000 --0000000000001dff9a0586bc0a9a Content-Type: text/plain; charset="UTF-8" On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson wrote: > > > On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason < > Jason_Livingood@comcast.com> wrote: > >> And for ease of any replies, I have a separate question on CDN >> localization via ECS. The 6th privacy requirement suggests that ECS cannot >> be used unless there is encryption between the resolver and the >> authoritative server, presumably via DoT. This suggests that the privacy >> concern isn't that the network/geographic hint provided by ECS is >> problematic in and of itself, but that it should not be observable along >> the network path used in recursion. >> >> But if TRR-to-auth recursion is not available via DoT, I wonder what the >> recommended mechanism is for providing a more privacy-protective >> network-geographic hint to an authoritative server, in order for example >> for a CDN to dynamically respond with a localized response. Maybe something >> new needs to be standardized? What options do folks suggest? > > > That's a great question. Apologies in advance for always providing long > answers. :-) > > IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip. > > I may be oversimplifying the situation, but I believe the vast majority of > authority DNS services (or proxy services in front of those) structure > their internal representation of things as geo->answer mappings, and > generally have some flavor of ip->geo mapping on their front-end(s). > Unfortunately, Geo is only one of the dimensions used. At least some of the common and heavily used CDNs and other DNS-based routing services also need to use both ASN and in some cases the regional network location within the ASN. As an example, a CDN or other widely distributed service may have "on-net" deployments located deep within ISP regional networks. So it's not just a matter of "hand out the London cluster for UK clients". It's "hand out the right cluster in the UK for the client based on the POP for the ISP/network they are currently connected to, out of a set of well over a hundred distinct UK clusters." This level of locality can actually help privacy by reducing the number of hops and network/country borders that are crossed (and therefore reducing the chances that the service request flow traffic is crossing surveillance points). The purpose of doing this is for increasing user performance, but also avoiding congested interconnect points. Decreasing localization here would result in substantially more traffic crossing ISP backbone and interconnect links. Even for country-level, the validity of "geo" is a function of the country and works better in the US and Europe. In Asia and South America and other parts of the world there are many areas within countries (and also between ISPs). But the general point stands that the client IP is not what is needed here by authorities. Just enough information to know where the client is topologically within the network. DNS authorities would actually prefer to have the coarsest effective granularity here as it increases DNS cache hit rate. In IPv6 coarser information is easier to provide via ECS. For example, a /48 is generally fine as nothing finer-grained typically differentiates routing. IPv4 is much trickier due to fragmentation of the address space. What I'd suggest as an alternative instead is to look at a "kIP" approach. ie, to only send information via ECS at a granularity that "makes an individual appear indistinguishable amongst a set of [k] individuals". For some context, see a talk from maprg: https://www.ietf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv6-address-anonymization-03.pdf Specifying something for TRR-to-auth recursion like "When ECS is sent to authorities it should be at a k=100 aggregation (or coarser) level, unless over an encrypted channel" may provide the desired property? Having a revision or new version of ECS that makes this easier to accomplish might also be valuable. Since this is generally desirable for caching efficiency, I suspect that even once a recursive to authoritative encrypted channel is defined it will still be preferable to send these more aggregated ECS information. (Note that there may be IPR in the space around sending non-client-IP identifiers for ECS.) Also see for background a SIGCOMM 2015 paper from a few years back on ECS measurements from one CDN: https://www.akamai.com/de/de/multimedia/documents/technical-publication/end-user-mapping-next-generation-request-routing-for-content-delivery-technical-publication.pdf Erik --0000000000001dff9a0586bc0a9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue,= Apr 16, 2019 at 2:31 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:


On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason <Jason_Livingood@comcast= .com> wrote:
And for ease of any replies, I have a separate question on CDN localiza= tion via ECS. The 6th privacy requirement suggests that ECS cannot be used = unless there is encryption between the resolver and the authoritative serve= r, presumably via DoT. This suggests that the privacy concern isn't tha= t the network/geographic hint provided by ECS is problematic in and of itse= lf, but that it should not be observable along the network path used in rec= ursion.

But if TRR-to-auth recursion is not available via DoT, I wonder what the re= commended mechanism is for providing a more privacy-protective network-geog= raphic hint to an authoritative server, in order for example for a CDN to d= ynamically respond with a localized response. Maybe something new needs to = be standardized? What options do folks suggest?

=
That's a great question. Apologies in advance for always providing= long answers. :-)

IMHO, the privacy issue is the = IP portion, not the geo portion, of geo-ip.

I may = be oversimplifying the situation, but I believe the vast majority of author= ity DNS services (or proxy services in front of those) structure their inte= rnal representation of things as geo->answer mappings, and generally hav= e some flavor of ip->geo mapping on their front-end(s).

Unfortunately, Geo is only one of the dimension= s used.=C2=A0 At least some of the common and heavily used CDNs and other D= NS-based routing services also need to use both ASN and in some cases the r= egional network location within the ASN.=C2=A0 As an example, a CDN or othe= r widely distributed service may have "on-net" deployments locate= d deep within ISP regional networks.=C2=A0 So it's not just a matter of= "hand out the London cluster for UK clients".=C2=A0 It's &qu= ot;hand out the right cluster in the UK for the client based on the POP for= the ISP/network they are currently connected to, out of a set of well over= a hundred distinct UK clusters."

This level of locality can a= ctually help privacy by reducing the number of hops and network/country bor= ders that are crossed (and therefore reducing the chances that the service = request flow traffic is crossing surveillance points).

The purpose of d= oing this is for increasing user performance, but also avoiding congested i= nterconnect points.=C2=A0 Decreasing localization here would result in subs= tantially more traffic crossing ISP backbone and interconnect links.
Even for country-level, the validity of "geo" is a function of t= he country and works better in the US and Europe.=C2=A0 In Asia and South A= merica and other parts of the world there are many areas within countries (= and also between ISPs).

But the general point stands that the client= IP is not what is needed here by authorities.=C2=A0 Just enough informatio= n to know where the client is topologically within the network.=C2=A0 DNS a= uthorities would actually prefer to have the coarsest effective granularity= here as it increases DNS cache hit rate.

In IPv6 coarser information is= easier to provide via ECS.=C2=A0 For example, a /48 is generally fine as n= othing finer-grained typically differentiates routing.=C2=A0 IPv4 is much t= rickier due to fragmentation of the address space.

=
What I= 'd suggest as an alternative instead is to look at a "kIP" ap= proach. ie, to only send information via ECS at a granularity that "= makes= an individual appear indistinguishable amongst a set of [k] individ= uals&= quot;.=C2=A0=C2=A0 For some context, see a talk from maprg:=C2=A0=C2= =A0 https://www.ie= tf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv= 6-address-anonymization-03.pdf

Specifying something for TRR-to-a= uth recursion like "When ECS is sent to authorities it should be at a = k=3D100 aggregation (or coarser) level, unless over an encrypted channel&qu= ot; may provide the desired property?=C2=A0=C2=A0 Having a revision or new = version of ECS that makes this easier to accomplish might also be valuable.= =C2=A0 Since this is generally desirable for caching efficiency, I suspect = that even once a recursive to authoritative encrypted channel is defined it= will still be preferable to send these more aggregated ECS information.

(Note that there may be IPR in the space around sending non-client-IP = identifiers for ECS.)

Also see for background=C2=A0 a SIGCOMM = 2015 paper from a few years back on ECS measurements from one CDN:
https://www.akamai.com/de/de/multimedia/documents/techni= cal-publication/end-user-mapping-next-generation-request-routing-for-conten= t-delivery-technical-publication.pdf

=C2=A0=C2=A0=C2=A0=C2=A0 Er= ik


--0000000000001dff9a0586bc0a9a-- From nobody Wed Apr 17 09:20:08 2019 Return-Path: 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 86942120461 for ; Wed, 17 Apr 2019 09:20:06 -0700 (PDT) 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, 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 (1024-bit key) header.d=hopcount.ca 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 Evc-3FaZCWuK for ; Wed, 17 Apr 2019 09:20:04 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 347A7120164 for ; Wed, 17 Apr 2019 09:20:04 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id u12so21010188iop.11 for ; Wed, 17 Apr 2019 09:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aAoxvujbAtj79SdawuMhLsuZ81czFGqzLj0wXPCUfg4=; b=cP9sRFy2rbb+YNtyE5yKW0B6aN34mH+Fwfqd4oenemYxTDe2jzF6+sTaCjPY5whFgV O+ZWjrSPWjPuWG3iJj3spwqr/Y4eqlpnCz5GRUwVSALzadUY8/uZUx9IvbIa3sgVRnfI LTdadtZDtSAAW35XYb0OMC3eiZsMV3UBzswqM= 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=aAoxvujbAtj79SdawuMhLsuZ81czFGqzLj0wXPCUfg4=; b=nXBzjAg8IIgULDy5vxNZFJ+NS7Ym69TaAJZ4Jsh6RtaQlUe9U4rYZqenRh7i+tHZvC S86tcpO6DD2J19RDlctFoH0UodSuT0ub3Vp7tlI9jh/l/PPaonSGJjeX4oXOpzfm2GKS CKsRxA8GvVgxMdH4IQoW/2G/dmBBifMiDF/A4guNR3AjnLDf53Ma7p/sb9QKIJ61T5LV p8hlwSlkGKA11kgMC85QEtVud7G3ynyfStA3RYjl19AxGGoS69GDTkhtRmyAECWu1oTQ vmf7uP5AOFsmwJVyKmyH9NNVmQwoBREajDvaM0+7ZOKdR3zNQrjPkW6rGtpP2E1q/Nx0 Ydiw== X-Gm-Message-State: APjAAAWlTAZipoHbQZm0h/LKUJTbaoXC4OY0TCPLn1cS9+1buWGcHik1 Q47CaJDrctPrkDbWbN7L/DMHpw== X-Google-Smtp-Source: APXvYqzkTgn0KPAeSiXp1NSvTPVx7OFIGwEFC+wWXFjrVnB7KPf9sMu7Lzqp/m6ngJWul38OVD+gmA== X-Received: by 2002:a5d:8358:: with SMTP id q24mr28182779ior.273.1555518003461; Wed, 17 Apr 2019 09:20:03 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:2140:512e:47b0:a53d? ([2607:f2c0:e786:128f:2140:512e:47b0:a53d]) by smtp.gmail.com with ESMTPSA id 71sm1542509itz.8.2019.04.17.09.20.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 09:20:01 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AC4A9E55-85E9-42BE-8409-D5E8F924CD7E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 17 Apr 2019 12:19:59 -0400 In-Reply-To: Cc: Brian Dickson , "Livingood, Jason" , "add@ietf.org" , "Plonka, David" , Peter Saint-Andre To: Erik Nygren References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 16:20:06 -0000 --Apple-Mail=_AC4A9E55-85E9-42BE-8409-D5E8F924CD7E Content-Type: multipart/alternative; boundary="Apple-Mail=_C546DB7B-0857-4307-AF35-42AFADD6D294" --Apple-Mail=_C546DB7B-0857-4307-AF35-42AFADD6D294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Apr 2019, at 12:04, Erik Nygren wrote: > On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson = > = wrote: >=20 >=20 > On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason = > = wrote: > And for ease of any replies, I have a separate question on CDN = localization via ECS. The 6th privacy requirement suggests that ECS = cannot be used unless there is encryption between the resolver and the = authoritative server, presumably via DoT. This suggests that the privacy = concern isn't that the network/geographic hint provided by ECS is = problematic in and of itself, but that it should not be observable along = the network path used in recursion. >=20 > But if TRR-to-auth recursion is not available via DoT, I wonder what = the recommended mechanism is for providing a more privacy-protective = network-geographic hint to an authoritative server, in order for example = for a CDN to dynamically respond with a localized response. Maybe = something new needs to be standardized? What options do folks suggest? >=20 > That's a great question. Apologies in advance for always providing = long answers. :-) >=20 > IMHO, the privacy issue is the IP portion, not the geo portion, of = geo-ip. >=20 > I may be oversimplifying the situation, but I believe the vast = majority of authority DNS services (or proxy services in front of those) = structure their internal representation of things as geo->answer = mappings, and generally have some flavor of ip->geo mapping on their = front-end(s). >=20 > Unfortunately, Geo is only one of the dimensions used. At least some = of the common and heavily used CDNs and other DNS-based routing services = also need to use both ASN and in some cases the regional network = location within the ASN. As an example, a CDN or other widely = distributed service may have "on-net" deployments located deep within = ISP regional networks. So it's not just a matter of "hand out the = London cluster for UK clients". It's "hand out the right cluster in the = UK for the client based on the POP for the ISP/network they are = currently connected to, out of a set of well over a hundred distinct UK = clusters." That's what I have heard. My understanding is that for many commercial applications, knowledge of = the city associated with a request is not sufficient to meet CDN = performance expectations, and that a (city, provider) pair is the = minimum information required to produce a response. Many use more. On the other side, there are ISPs who use different source addresses for = different queries originated by their resolvers in combination with the = client-subnet option in order to tilt the decision algorithm at = particular CDNs to better match them to particular clients. It's not reasonable to reduce the dimensions available to make the = content steering decision and expect the mechanism to be implemented and = used. The amount of complexity that is tolerated in order to make this = work today is substantial, which ought to tell us something. Joe --Apple-Mail=_C546DB7B-0857-4307-AF35-42AFADD6D294 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 17 Apr 2019, at 12:04, Erik Nygren <erik+ietf@nygren.org> wrote:

On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson = <brian.peter.dickson@gmail.com> wrote:


On Tue, Apr 16, 2019 at 9:00 AM = Livingood, Jason <Jason_Livingood@comcast..com> = wrote:
And for ease of any replies, I have a separate = question on CDN localization via ECS. The 6th privacy requirement = suggests that ECS cannot be used unless there is encryption between the = resolver and the authoritative server, presumably via DoT. This suggests = that the privacy concern isn't that the network/geographic hint provided = by ECS is problematic in and of itself, but that it should not be = observable along the network path used in recursion. 

But if TRR-to-auth recursion is not available via DoT, I = wonder what the recommended mechanism is for providing a more = privacy-protective network-geographic hint to an authoritative server, = in order for example for a CDN to dynamically respond with a localized = response. Maybe something new needs to be standardized? What options do = folks suggest?

That's a great question. Apologies in advance for always = providing long answers. :-)

IMHO, the privacy issue is the IP portion, not the geo = portion, of geo-ip.

I may be oversimplifying the situation, but I believe the = vast majority of authority DNS services (or proxy services in front of = those) structure their internal representation of things as = geo->answer mappings, and generally have some flavor of ip->geo = mapping on their front-end(s).

Unfortunately, Geo is only one of the dimensions = used.  At least some of the common and heavily used CDNs and other = DNS-based routing services also need to use both ASN and in some cases = the regional network location within the ASN.  As an example, a CDN = or other widely distributed service may have "on-net" deployments = located deep within ISP regional networks.  So it's not just a = matter of "hand out the London cluster for UK clients".  It's "hand = out the right cluster in the UK for the client based on the POP for the = ISP/network they are currently connected to, out of a set of well over a = hundred distinct UK clusters." 
That's what I have heard.

My understanding is that for many commercial = applications, knowledge of the city associated with a request is not = sufficient to meet CDN performance expectations, and that a (city, = provider) pair is the minimum information required to produce a = response. Many use more.

On the = other side, there are ISPs who use different source addresses for = different queries originated by their resolvers in combination with the = client-subnet option in order to tilt the decision algorithm at = particular CDNs to better match them to particular = clients.

It's not reasonable to = reduce the dimensions available to make the content steering decision = and expect the mechanism to be implemented and used. The amount of = complexity that is tolerated in order to make this work today is = substantial, which ought to tell us something.


Joe

= --Apple-Mail=_C546DB7B-0857-4307-AF35-42AFADD6D294-- --Apple-Mail=_AC4A9E55-85E9-42BE-8409-D5E8F924CD7E 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----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXLdSLwAKCRA0jwy9hlI6 LGCpAKDGv40dym+uCHXEUZgjltvtl/z2TQCgw4J753CpEp+AEueYbjnsnscTwXk= =792Q -----END PGP SIGNATURE----- --Apple-Mail=_AC4A9E55-85E9-42BE-8409-D5E8F924CD7E-- From nobody Wed Apr 17 09:28:55 2019 Return-Path: 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 0E443120135 for ; Wed, 17 Apr 2019 09:28:54 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 7bcgdOMd02Eo for ; Wed, 17 Apr 2019 09:28:52 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 389CD1200C3 for ; Wed, 17 Apr 2019 09:28:52 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id k64so5318358itb.5 for ; Wed, 17 Apr 2019 09:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vpvLszzr5fCtdzR9yY5EGsbSP/JdpDhCjpLWhKot6wE=; b=XqPCCv8Di6ox1UTfvwck1aDbCZQh2lHeqPMQcfClNps5L8FNu2/taEX4ABXnJ/0V2L GZ+Uw2T32yS4NSda56T6QQVM2Y4qyBO5aJ0tXeMjKnRR08ByD2c7gbcmba6HdT/LwLx5 yb00i3/kqvJJKm2jqrD1AjqjdftbSgz8hFlKE= 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=vpvLszzr5fCtdzR9yY5EGsbSP/JdpDhCjpLWhKot6wE=; b=W/P8/uFRbLSCP7pv96RFy/udLex2XkPLb4a4OVFpi0Tkx7CAX1sL4RdIUMAVrgRepi dL4koLOo1CSZj4wyXxpF+2SaYKriqyPxPlbh6mOzTMB+qfjsdGwDVq8UmQyL/Hx/0Mxv 1G3xRkZFmrL91mxJymLuv+GrQIMH6IRmbOYRrZL40xeJFjQcc08JHfjRbWL4mV1eMByK V8vJg1jXoq1Bn7UOKYLo1SIxD41ASm6sCRnyYI6DxVSKoHF0PiqwcH79ddkBT5knuWuo Ov2q/HR/5GxxwVVyUNaCATtMkwE2bzjwEhXALRkwAA8YiVtBdC4EJZc3qsje56+cdv0L QDow== X-Gm-Message-State: APjAAAXJJeCGT+5JKSE8HnaSAiF9+o5DFdDwRqGYeExmgax/ZIvdQEWL g1kJBhNmpa9Qzmk7sF/IAdM/OATzXnmE8Q== X-Google-Smtp-Source: APXvYqxpvblqxqE/5LKzVHPtYdwpPvUiLRJMHn26+79FMr8mCkSwxAn0uAzlB9BN+/4qoEoUt35L3Q== X-Received: by 2002:a24:5211:: with SMTP id d17mr506215itb.26.1555518531356; Wed, 17 Apr 2019 09:28:51 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:2140:512e:47b0:a53d? ([2607:f2c0:e786:128f:2140:512e:47b0:a53d]) by smtp.gmail.com with ESMTPSA id i26sm20205719ioj.86.2019.04.17.09.28.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 09:28:49 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_E2A95961-C332-46ED-97DE-CF838A66D813"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 17 Apr 2019 12:28:46 -0400 In-Reply-To: <29A8B0C7-F58B-4DBB-BE9A-98D5CC926E53@fl1ger.de> Cc: add@ietf.org To: Ralf Weber References: <34777692-293F-42D3-AC53-598C557D4911@hopcount.ca> <2BF7C7CC-69B5-4BF7-98A7-A2466ACD3761@hopcount.ca> <29A8B0C7-F58B-4DBB-BE9A-98D5CC926E53@fl1ger.de> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Add] lifecycle of an engagement between an application and a service X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 16:28:54 -0000 --Apple-Mail=_E2A95961-C332-46ED-97DE-CF838A66D813 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10 Apr 2019, at 01:55, Ralf Weber wrote: > On 9 Apr 2019, at 18:45, Joe Abley wrote: >> In that thought experiment some (non-DNS), transport-layer = authentication has already happened. So that's exactly the mechanism to = bind name resolution within the context of that session to a unique = session cache that's populated in-band. > What if you are connected to an rouge authenticated actor. If you have = a connection and do/give something that requires a new connection and = then add domain data to it you might have successfully cached/hijacked = that new connection. We should certainly not pretend that there isn't a risk analysis to be = done, but on the flip side assuming that because risks exists that we = must be at a dead end seems like a recipe for getting nowhere. There are = and will always be risks. >>> It easily can be hundreds in parallel to different entities and even = if we had a mechanism (certs, DNSSEC) to validate the answer send back = it could be wrong for that client especially in a multi CDN world. >>=20 >> I think you're presupposing a particular architecture that has holes. = Perhaps try to imagine one that doesn't? > There is no such thing says the cynical me. I=E2=80=99ve seen so many = secure systems being abused and hacked that I=E2=80=99d rather work with = the devil I know (that of course is a very opsy position). >=20 >> No, we share less data with fewer parties. Instead of service = providers using third-party enterprise DNS providers to generate = session-specific responses based on data that's harvested from real-user = monitoring across a swathe of fourth-party sites, performance = monitoring, traffic steering, etc can all happen within the bounds of a = service contract that is already established for the purpose of using = the actual service. > I don=E2=80=99t know how you get that much parties, but in my good old = DNS world the stub asks the recursive resolver which asks the = authoritative server - with that the connection gets established. The response generated by the authority server involves an algorithm = that combines inferences about the query, the resolver that sent it, the = stub resolver that originated it, and the performance of thousands of = representative CDN tests in other protocols that seem relevant that are = collected, analysed, bought and sold by a thrilling community of third = parties in many different jurisdictions. >> But really there was a reason why I labelled these as thought = experiments and separated the lifecycle into phases. You're arguing = against a thought experiment in precisely the part of the whiteboard = that I suggest is unimportant for the purposes of the current discussion = :-) > I though the topic of this list was discussing applications doing DNS = and not some service meta discussions. I=E2=80=99m an old grey bearded = unix sysadmin, so give me connections and bits on the wire (which the = IETF is mostly about) and we can talk. The point I was trying to make (apparently not very well) is that there = are parts of the interaction between an application and a service that = can be improved if we open our minds to application-specific name = resolution, and that it might be reasonable to look for solutions that = could improve performance, reduce complexity, reduce privacy threats, = all without diminishing control to a point that is intolerable. > The thought experiment (or at least part of it) sounded exactly like = the =E2=80=9Cresolver less=E2=80=9D DNS idea we discussed in a side = meeting which has security and other problems as described above. Yes. However, that side meeting bundled all name resolution into one = bucket. My point is that if we are able to separate the aggregated = resolution problem we may well find that there are components that are = soluble. The alternative, as I think we have all noticed, is that = there's at least one perspective that makes any solution untenable. Joe --Apple-Mail=_E2A95961-C332-46ED-97DE-CF838A66D813 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----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXLdUPgAKCRA0jwy9hlI6 LNj/AJ0bxMXpCtb6CVF2NnwNSQBjBbzHagCeKv3ebWYYrezJeU+ZcS3TRGMoHqo= =bixj -----END PGP SIGNATURE----- --Apple-Mail=_E2A95961-C332-46ED-97DE-CF838A66D813-- From nobody Wed Apr 17 11:17:13 2019 Return-Path: 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 4A30012004D for ; Wed, 17 Apr 2019 11:17:11 -0700 (PDT) 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 mdMDie-fKDJi for ; Wed, 17 Apr 2019 11:17:08 -0700 (PDT) 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 A97C9120006 for ; Wed, 17 Apr 2019 11:17:08 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id k14so28501061qtb.0 for ; Wed, 17 Apr 2019 11:17:08 -0700 (PDT) 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=qPhCF8WzghGwG3qFx7seaTgC032x8Fk9jL88Y7pQLFg=; b=KS/Wh4gwys2BWaz7BUzW2zM5DRyOky4PCUAliQGuHR5buBcvD1ujmxk+gBCFRdoUsD akjn2ok3pMdEuoZ+7YUn78Aqc5tEDYHNEaur6z6ZJ0SOLsSenTdhzqNKSX3hJfiBSYMu d6MsioqVY7FaXLK1wp9p7YJRTsKQnp76UTfKDZ+X4qW+7PIMP+glmVCc5zAYiW1gGbaR 2U6ju/1OWrt5xDUQMxREC9nWLjeKdQtXHIiytx5Z+2l3arLs5hME1wRhzjHxod+mnr3x sUwLwpV+GGMooJlmtU2ZIgunHvFuDgfBBQgohAgmVdJlm275uJQaNtgwIBgyW7ugJ9Yc TuGw== 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=qPhCF8WzghGwG3qFx7seaTgC032x8Fk9jL88Y7pQLFg=; b=tykfBE405bQMTykS6q5n8n4DSX35Z/A94LeWWPatzFwnhDDR/4K+tB2hkXifTBb+fH V8SAs+y0KSdwBrIxE6pahxorXoYbha0L7Dih/clhyRmltXLBmqKZOIRsORnw0glwI4aT +IrdfzwmeelouAfg/PUQ9t20LsSj+RMJ2/hw3FWs+eWsgPkpsMsxxErMEp1JtbEbDGeK Qwqo/RV/8GfJQWuAzuJi5yDiMAGwjF6mLaKlhBtCQvoSSAQyfOIfan91upXi+lGzhc16 +/ObTeNIN6o9LTHIZAQ4aKxhGoZG4/EVKfEGBSWkLPDbD0xvNABVbsT9LMpsIyHwvm+u Th7w== X-Gm-Message-State: APjAAAXSc+4JJg9r13gM7koKRxMsNh4RHEiDIcMHjXG9QIfMdp+s2ZUI jnBXiCHqdwdTVDcyE+GUE9HAoA0oB21gEDLrYUI= X-Google-Smtp-Source: APXvYqxdqVrL+jAdMV2s+cJXmbWKCfo//LmgiP32HWm/8ZJLIhfvJUBZqioC8Nu2QTDxINQx7INS2rCdOOsZbKMOFkQ= X-Received: by 2002:ac8:1707:: with SMTP id w7mr72695508qtj.324.1555525027843; Wed, 17 Apr 2019 11:17:07 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> In-Reply-To: From: Brian Dickson Date: Wed, 17 Apr 2019 11:16:56 -0700 Message-ID: To: Erik Nygren Cc: "Livingood, Jason" , "add@ietf.org" , Peter Saint-Andre , "Plonka, David" Content-Type: multipart/alternative; boundary="000000000000b951c00586bde467" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 18:17:11 -0000 --000000000000b951c00586bde467 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 17, 2019 at 9:04 AM Erik Nygren wrote: > > On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> >> >> On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason < >> Jason_Livingood@comcast.com> wrote: >> >>> And for ease of any replies, I have a separate question on CDN >>> localization via ECS. The 6th privacy requirement suggests that ECS cannot >>> be used unless there is encryption between the resolver and the >>> authoritative server, presumably via DoT. This suggests that the privacy >>> concern isn't that the network/geographic hint provided by ECS is >>> problematic in and of itself, but that it should not be observable along >>> the network path used in recursion. >>> >>> But if TRR-to-auth recursion is not available via DoT, I wonder what the >>> recommended mechanism is for providing a more privacy-protective >>> network-geographic hint to an authoritative server, in order for example >>> for a CDN to dynamically respond with a localized response. Maybe something >>> new needs to be standardized? What options do folks suggest? >> >> >> That's a great question. Apologies in advance for always providing long >> answers. :-) >> >> IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip. >> >> I may be oversimplifying the situation, but I believe the vast majority >> of authority DNS services (or proxy services in front of those) structure >> their internal representation of things as geo->answer mappings, and >> generally have some flavor of ip->geo mapping on their front-end(s). >> > > Unfortunately, Geo is only one of the dimensions used. At least some of > the common and heavily used CDNs and other DNS-based routing services also > need to use both ASN and in some cases the regional network location within > the ASN. > Okay, so I did oversimplify. My bad. Let's consider what the situation is, for authority servers. Some (not all, not none) are CDNs. Some (not all, not none) are not doing ECS at all. Some (not all, not none) are doing ECS, but only using "vanilla" ECS functionality, via third-party IP->GEO databases/services. The potential trade-off(s), as I see them, are: - possible exposure of privacy information via ECS (as currently is done today) - possible scaling problems caused by requiring encryption, to authorities not doing ECS, or who do ECS but could equally do "GEO" - public resolver/browser requirements/agreements imposing changes on third parties (encryption) Given that the driver for these changes is "ADD" (applications doing DNS, specifically here browsers), I'm interested in whether there are ways of handling these that can balance those issues. For example, if the public recursive required that the authority support encrypted transport before doing ECS, and had the ability to fall back to GEO over non-encrypted transport, would that be feasible? The public resolver would probably need to keep track of authority servers that do/don't support encryption, as an optimization. If the fall-back didn't ever result in ECS over unencrypted sessions, that would make it mostly immune to downgrade attacks. This would also provide for a smooth deployment scheme; this could be logic deployed even before the resolver-to-auth encryption is standardized, with no "flag day" required. Since this suggestion has implications to public resolvers, it clearly requires buy-in from them, and possibly the blessing of the browser folks that GEO is acceptable from a privacy policy perspective. Feedback is welcome and sought. Thoughts? Brian --000000000000b951c00586bde467 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 17, 2019 at 9:04 AM Erik = Nygren <erik+ietf@nygren.org> wrote:

On Tue, Apr 16, 2019 at 2:31 PM B= rian Dickson <brian.peter.dickson@gmail.com> wrote:

On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason <Jason_Livingood@comcast.com= > wrote:
And = for ease of any replies, I have a separate question on CDN localization via= ECS. The 6th privacy requirement suggests that ECS cannot be used unless t= here is encryption between the resolver and the authoritative server, presu= mably via DoT. This suggests that the privacy concern isn't that the ne= twork/geographic hint provided by ECS is problematic in and of itself, but = that it should not be observable along the network path used in recursion. =

But if TRR-to-auth recursion is not available via DoT, I wonder what the re= commended mechanism is for providing a more privacy-protective network-geog= raphic hint to an authoritative server, in order for example for a CDN to d= ynamically respond with a localized response. Maybe something new needs to = be standardized? What options do folks suggest?

=
That's a great question. Apologies in advance for always providing= long answers. :-)

IMHO, the privacy issue is the = IP portion, not the geo portion, of geo-ip.

I may = be oversimplifying the situation, but I believe the vast majority of author= ity DNS services (or proxy services in front of those) structure their inte= rnal representation of things as geo->answer mappings, and generally hav= e some flavor of ip->geo mapping on their front-end(s).

Unfortunately, Geo is only one of the dimensions used.=C2=A0 At least s= ome of the common and heavily used CDNs and other DNS-based routing service= s also need to use both ASN and in some cases the regional network location= within the ASN.

<= /div>
Okay, so I did oversimplify. My bad.

Let= 's consider what the situation is, for authority servers.
Some (not all, not none) are CDNs. Some (not all, not none) are= not doing ECS at all. Some (not all, not none) are doing ECS, but only usi= ng "vanilla" ECS functionality, via third-party IP->GEO databa= ses/services.

The potential trade-off(s), as I see= them, are:
  • possible exposure of privacy information via = ECS (as currently is done today)
  • possible scaling problems caused b= y requiring encryption, to authorities not doing ECS, or who do ECS but cou= ld equally do "GEO"
  • public resolver/browser requirements/= agreements imposing changes on third parties (encryption)
Given th= at the driver for these changes is "ADD" (applications doing DNS,= specifically here browsers), I'm interested in whether there are ways = of handling these that can balance those issues.

F= or example, if the public recursive required that the authority support enc= rypted transport before doing ECS, and had the ability to fall back to GEO = over non-encrypted transport, would that be feasible?
The public = resolver would probably need to keep track of authority servers that do/don= 't support encryption, as an optimization.
If the fall-back d= idn't ever result in ECS over unencrypted sessions, that would make it = mostly immune to downgrade attacks.
This would also provide for a= smooth deployment scheme; this could be logic deployed even before the res= olver-to-auth encryption is standardized, with no "flag day" requ= ired.

Since this suggestion has implications t= o public resolvers, it clearly requires buy-in from them, and possibly the = blessing of the browser folks that GEO is acceptable from a privacy policy = perspective. Feedback is welcome and sought.

Thoug= hts?
Brian
--000000000000b951c00586bde467-- From nobody Wed Apr 17 11:35:23 2019 Return-Path: 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 5D4C3120292 for ; Wed, 17 Apr 2019 11:35:06 -0700 (PDT) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 cmDCs8igveZL for ; Wed, 17 Apr 2019 11:35:04 -0700 (PDT) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 9C2231201BA for ; Wed, 17 Apr 2019 11:35:04 -0700 (PDT) Received: by mail-it1-x131.google.com with SMTP id f22so6038475ita.3 for ; Wed, 17 Apr 2019 11:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gomFV1I2InJcFJhTgRgN3HXxQmVyUH6zxm3WFvwwyVg=; b=EjReNDy0dyKLGFZyWQRP46f+0v/yfx+Lo7O1vIeryoaUgYsEyaMbpXniTrdLVD79SD buIoWMYaRx8HTxzVcalsBYRfnpqtOqACwsvoZhhI2B/ntunVRAEHcDbnU9ApDilTkMXH r7CjkUxig2rM5opSXHOn9acApnEFKBTu7MtaA= 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=gomFV1I2InJcFJhTgRgN3HXxQmVyUH6zxm3WFvwwyVg=; b=qSUB6h3XO9ybnIRU5m3aRRgf/eu9reJNzAaU/DtKF4DIPAm6+X+XLAA8bq+wm0fpUx FCbaKv/LmnYJ99zt7dHLOKjb/zhDCEhK7SmOVxo0u8NP9Fw0V0ikCFfnIcbqXAGYPFS4 7S0pj2erdM5rmDjxtMoW2OI2BV9of6BPC6Zb4PDDRA2XmVWzzX2R/hMlr9NRdg8XWm+d KxCjGjX+hZ1e7Qr0EdSvCUOUpxcNr1J4VkdPXMFB1ziUct4Cd8Id8zAg4+YneSbwMyV5 5za+X9GhiQw5za0xA2JLtpinBpV9naAk/fRs46APvjL4FSYOQd19LkznLk/ZXWDHFm5w KCeA== X-Gm-Message-State: APjAAAW1+pPf2qNVxIsvxdPQINHKmxvMuMOi0+NFX+xhWisj3OkYY76o qIN7srEeJ/JyRPPQzxl6uXrKQw== X-Google-Smtp-Source: APXvYqz6n9er+b7Sy5fWIvG+GfSrOCs7SRFfW+tFPl62hP5XNrgL0gc/+WUbULtKXHDQXuN+bts3AQ== X-Received: by 2002:a02:7706:: with SMTP id g6mr1651308jac.118.1555526103673; Wed, 17 Apr 2019 11:35:03 -0700 (PDT) Received: from ?IPv6:2607:f2c0:e786:128f:2140:512e:47b0:a53d? ([2607:f2c0:e786:128f:2140:512e:47b0:a53d]) by smtp.gmail.com with ESMTPSA id m6sm20618453ioj.36.2019.04.17.11.35.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 11:35:02 -0700 (PDT) From: Joe Abley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_94B19AD4-AA91-4B9B-BD48-3A966AD26619"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 17 Apr 2019 14:35:00 -0400 In-Reply-To: Cc: Erik Nygren , "Livingood, Jason" , "add@ietf.org" , "Plonka, David" , Peter Saint-Andre To: Brian Dickson References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 18:35:06 -0000 --Apple-Mail=_94B19AD4-AA91-4B9B-BD48-3A966AD26619 Content-Type: multipart/alternative; boundary="Apple-Mail=_EC06F13F-FEDE-4315-B503-DCAA4D34514F" --Apple-Mail=_EC06F13F-FEDE-4315-B503-DCAA4D34514F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Apr 2019, at 14:16, Brian Dickson = wrote: > Let's consider what the situation is, for authority servers. >=20 > Some (not all, not none) are CDNs. Some (not all, not none) are not = doing ECS at all. Some (not all, not none) are doing ECS, but only using = "vanilla" ECS functionality, via third-party IP->GEO databases/services. >=20 > The potential trade-off(s), as I see them, are: So, to briefly join the threads just as further illustration to what I'm = talking about, what you're doing here looks a lot like trying to = engineer a solution for people you don't know based on requirements = you're guessing at. This seems unlikely to converge on anything useful. Being able to separate away 99% of the resolution problem in the = lifetime of a session ("established phase") into something that can be = said not to have any privacy or access control concerns beyond those = that already exist in the service being used means that all of the = traffic engineering required there can continue to be done behind the = curtain, engineered with a full serving of commercial advantage and = richly flavoured with special secret sauce. I'm not saying this is = without complication or is something that exists today, far from it: but = it at least puts the design and implementation in the hands of the = service architects who know what they need and, crucially, the details = don't necessarily need wide exposure and standardisation. If there's to be an impact on performance from privacy, e.g. from a less = sophisticated (even empty) set of available mechanisms available to do = traffic steering at response time, it seems like it'd be really nice for = it to be brief (e.g., "initialisation phase"). Joe --Apple-Mail=_EC06F13F-FEDE-4315-B503-DCAA4D34514F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 17 Apr 2019, at 14:16, Brian Dickson <brian.peter.dickson@gmail.com> wrote:

Let's consider what the situation is, = for authority servers.

Some (not all, not none) = are CDNs. Some (not all, not none) are not doing ECS at all. Some (not = all, not none) are doing ECS, but only using "vanilla" ECS = functionality, via third-party IP->GEO databases/services.

The potential = trade-off(s), as I see them, are:

So, to briefly join the threads just as further = illustration to what I'm talking about, what you're doing here looks a = lot like trying to engineer a solution for people you don't know based = on requirements you're guessing at. This seems unlikely to converge on = anything useful.

Being able to = separate away 99% of the resolution problem in the lifetime of a session = ("established phase") into something that can be said not to have any = privacy or access control concerns beyond those that already exist in = the service being used means that all of the traffic engineering = required there can continue to be done behind the curtain, engineered = with a full serving of commercial advantage and richly flavoured with = special secret sauce. I'm not saying this is without complication or is = something that exists today, far from it: but it at least puts the = design and implementation in the hands of the service architects who = know what they need and, crucially, the details don't necessarily need = wide exposure and standardisation.

If = there's to be an impact on performance from privacy, e.g. from a less = sophisticated (even empty) set of available mechanisms available to do = traffic steering at response time, it seems like it'd be really nice for = it to be brief (e.g., "initialisation phase").


Joe

= --Apple-Mail=_EC06F13F-FEDE-4315-B503-DCAA4D34514F-- --Apple-Mail=_94B19AD4-AA91-4B9B-BD48-3A966AD26619 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----- iF0EARECAB0WIQSAt40QkiztAcvphdg0jwy9hlI6LAUCXLdx1AAKCRA0jwy9hlI6 LHseAKDCRQule++HgJ9e6Fj7z7uVnKut5ACbBaW8iP+Mv0Qvv/hs81jWp7nJtmM= =LvoK -----END PGP SIGNATURE----- --Apple-Mail=_94B19AD4-AA91-4B9B-BD48-3A966AD26619-- From nobody Wed Apr 17 12:16:55 2019 Return-Path: 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 D98611200B8 for ; Wed, 17 Apr 2019 12:16:54 -0700 (PDT) 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 CwXVxkeYihDA for ; Wed, 17 Apr 2019 12:16:53 -0700 (PDT) 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 A8BB912003E for ; Wed, 17 Apr 2019 12:16:53 -0700 (PDT) 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; Wed, 17 Apr 2019 12:16:52 -0700 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; Wed, 17 Apr 2019 12:16:52 -0700 From: Paul Hoffman To: "add@ietf.org" Thread-Topic: [Add] ECS privacy concerns, alternatives? Thread-Index: AQHU9VIczoYQ2gaYVUSW1kb/Zlej+w== Date: Wed, 17 Apr 2019 19:16:51 +0000 Message-ID: References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 19:16:55 -0000 I propose that this thread could be moved to the DNSOP WG mailing list, whe= re ECS originated. I say this because ECS is a privacy problem for non-ADD = and ADD equally, and some uses of ADD (application does DoT to the user's n= ormal external resolver) don't make ECS any worse. The thread is indeed interesting, but it should probably be had where more = developers are watching. --Paul Hoffman= From nobody Wed Apr 17 12:18:23 2019 Return-Path: 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 2A2B9120308 for ; Wed, 17 Apr 2019 12:18:22 -0700 (PDT) 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 Edy3jLacW1XY for ; Wed, 17 Apr 2019 12:18:19 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 DEBA01200B8 for ; Wed, 17 Apr 2019 12:18:18 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id w5so28616996qtb.11 for ; Wed, 17 Apr 2019 12:18:18 -0700 (PDT) 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=hZ6wk0gEHXV0ai8GlTnjbhWdK7pxtJkqTKFfKLZ188c=; b=hhhiuKDkn/ldtittGVL2njTJJExqV579MfBtHho0zQGoYnm9TDTdq2/aGRx0B9T3rf XYtAIZFoU4WNDZpcU4SucPKQEDwQI6Y2LhGipNV8EvfsTHL7XlTwwq1Y/XJDhK2y4lfI tX98uPzGX4+ObKE1QxblmRjuBvewKBnQPAIpoUAriQ4n84mpOaaC9FmyPpcyzh6vE0eG b7nk2NoSVQTC67Eqt5hp5YvjASMydgkxu6zuTyZlE469hvig+AeHN0kPsx3SMJwKOqR2 7UwOc+Dima7FA/u2VDP+oe60xzgtl2cDSzj6p+pCveq5FlHru0TsvVOw2lM+xT4Sp2+1 OYwA== 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=hZ6wk0gEHXV0ai8GlTnjbhWdK7pxtJkqTKFfKLZ188c=; b=d5e+8ZqvM3nFIU9rnI/UPXr7DUU6Z8wXmxnDNjh0wn6QOz3Jas2q4RXvfNxX8MzWAT 6zam0g3MCFCEDKZhoPHW6uCGLpkhhvoxWb4hQfbc0sDeYII7v/boqRQ3yrvR8vROi4kF jrGnhU0u649HQMzQpxuSHJUa6iR0uz/cqgZZUcRM/ocCX3puaGozTphqoXI4LGhnyoSk 9gHQ/10+8ndrYI4ffw0LzoNlkp9AjzdFsncfD4G6c3WuAiBhErgRQgMH2cRAIiPrXhjJ sDgtRCWjvxkyVCqSV1dQaCVfi8oLIYvLYk1NDBjrYSZxgr2z80EKgvxohEwl62BalppV eWhg== X-Gm-Message-State: APjAAAVKwsqITPKXVXoPHxYN6DhsnGfeW3OHaWofMsGfQ3h+nHet8rwd cz1IWbPF4klfK7NnjHr73+q/DJj3xeGbsuD01e4= X-Google-Smtp-Source: APXvYqwuC/fln55k/ofyvwmdkLfPdwF4qcf0bI5oPd4RxyiU/9bQ7s7eAtrESjrgTxk4Zvf8vyEri3vV3lte/vu+AFA= X-Received: by 2002:ac8:2b83:: with SMTP id m3mr74999051qtm.305.1555528698061; Wed, 17 Apr 2019 12:18:18 -0700 (PDT) MIME-Version: 1.0 References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <994839978.18707.1554973716877@appsuite.open-xchange.com> <21C5261E-9DE0-4CFD-A949-6E91DD0C2552@cable.comcast.com> <9FDAE487-6E98-4332-BB57-A626A02A6402@cable.comcast.com> In-Reply-To: From: Brian Dickson Date: Wed, 17 Apr 2019 12:18:06 -0700 Message-ID: To: Joe Abley Cc: Erik Nygren , "Livingood, Jason" , "add@ietf.org" , "Plonka, David" , Peter Saint-Andre Content-Type: multipart/alternative; boundary="0000000000007c68f60586bebf11" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 19:18:22 -0000 --0000000000007c68f60586bebf11 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 17, 2019 at 11:35 AM Joe Abley wrote: > On 17 Apr 2019, at 14:16, Brian Dickson > wrote: > > Let's consider what the situation is, for authority servers. > > Some (not all, not none) are CDNs. Some (not all, not none) are not doing > ECS at all. Some (not all, not none) are doing ECS, but only using > "vanilla" ECS functionality, via third-party IP->GEO databases/services. > > The potential trade-off(s), as I see them, are: > > > So, to briefly join the threads just as further illustration to what I'm > talking about, what you're doing here looks a lot like trying to engineer a > solution for people you don't know based on requirements you're guessing > at. This seems unlikely to converge on anything useful. > > Actually, on this point, I beg to differ. What I am trying to do is separate out two or three classes of problem/solution, and avoiding having a single solution (with more complexity and cost) imposed on the rest of the DNS authority service community. I am very happy to leave the specifics of the "secret sauce" behind the curtain. I'm trying to find a way of distinguishing the "secret sauce" folks from the vanilla flavor folks, prior to the "established phase", so that what "established phase" looks like might be different (e.g. encrypted or not). I'm trying to do that distinction, upstream of established phase, for the benefit of those not using any special sauce, so that the cost of "vanilla" doesn't rise to being the same as the cost of "special sauce". And, I am doing this based on the requirements of a substantial portion of the non-"special-sauce" constituency, that portion of which I represent, whose requirements I not only know, but am responsible for. The fundamental question is, for me, whether it is possible to determine whether a given authority provider requires encryption, based on the dependency it has on ECS (so that it can provide "special sauce") If the authority provider does not require encryption, I would like to facilitate that, rather than always require authority providers to offer encrypted transport. I'm completely open to mechanisms that facilitate this divergence. There is not yet (AFAIK) consensus regarding requiring recursive-to-authority encrypted transport, and in the absence of such consensus, believe it is imperative that both encrypted and unencrypted transport options be supported. The resolvers may choose not to send ECS over unencrypted transport, and as long as that is a supported mode (with whatever mechanisms are required), I have no problem with resolvers and authority servers doing whatever they want over their encrypted channels. (BTW, this isn't to say that we don't also represent a substantial number of zones that do want ECS. We do, and do want to offer and use encrypted transport for those.) I am happy to lead any standardization effort (i.e. doing an internet draft) for the "geo" alternative to "ecs", and am also happy to let the "geo" thing go, as long we can discuss whether a "no-ecs, no encryption" option might be feasible. The "no ECS requirement" I'm speaking of, represents about 40% of the DNS zones served globally, who are our customers. That we are one provider with that customer base isn't as relevant, so much as that there are 40% of the zones with no need for ECS, and that the interaction between public resolvers and authority servers should be, IMHO, negotiable with respect to encrypted transport. > Being able to separate away 99% of the resolution problem in the lifetime > of a session ("established phase") into something that can be said not to > have any privacy or access control concerns beyond those that already exist > in the service being used means that all of the traffic engineering > required there can continue to be done behind the curtain, engineered with > a full serving of commercial advantage and richly flavoured with special > secret sauce. I'm not saying this is without complication or is something > that exists today, far from it: but it at least puts the design and > implementation in the hands of the service architects who know what they > need and, crucially, the details don't necessarily need wide exposure and > standardisation. > I agree that there is no specific requirement for standardization within the "special sauce" community. I was hoping that there might be some interest and value in a standardized "special sauce Lite" over and above the "special sauce" community. If not, no big deal. > > If there's to be an impact on performance from privacy, e.g. from a less > sophisticated (even empty) set of available mechanisms available to do > traffic steering at response time, it seems like it'd be really nice for it > to be brief (e.g., "initialisation phase"). > I agree whole-heartedly. I also think that the "initialisation phase" represents one place where security is extremely important, specifically in validating the identify of the service end-point. A lot of trust regarding privacy is placed on the end-point, so it is important that that trust not be misplaced. But I think that is subject for a separate thread. Brian --0000000000007c68f60586bebf11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 17, 2019 at 11:35 AM Joe = Abley <jabley@hopcount.ca> = wrote:
On 17 Apr 2019, at 14:16, Brian Dickson &l= t;brian.= peter.dickson@gmail.com> wrote:

Let's consider what the situation is= , for authority servers.

= Some (not all, not none) are CDNs. Some (not all, not none) are not doing E= CS at all. Some (not all, not none) are doing ECS, but only using "van= illa" ECS functionality, via third-party IP->GEO databases/services= .

The potential trade-off(s), as I see them, are:<= /div>

So, to briefly join the t= hreads just as further illustration to what I'm talking about, what you= 're doing here looks a lot like trying to engineer a solution for peopl= e you don't know based on requirements you're guessing at. This see= ms unlikely to converge on anything useful.


Actually, on this point, I beg to differ.=

What I am trying to do is separate out two or thr= ee classes of problem/solution, and avoiding having a single solution (with= more complexity and cost) imposed on the rest of the DNS authority service= community.

I am very happy to leave the specifics= of the "secret sauce" behind the curtain.=C2=A0

I'm trying to find a way of distinguishing the "secret sa= uce" folks from the vanilla flavor folks, prior to the "establish= ed phase", so that what "established phase" looks like might= be different (e.g. encrypted or not).

I'm try= ing to do that distinction, upstream of established phase, for the benefit = of those not using any special sauce, so that the cost of "vanilla&quo= t; doesn't rise to being the same as the cost of "special sauce&qu= ot;.

And, I am doing this based on the requirement= s of a substantial portion of the non-"special-sauce" constituenc= y, that portion of which I represent, whose=C2=A0 requirements I not only k= now, but am responsible for.

The fundamental quest= ion is, for me, whether it is possible to determine whether a given authori= ty provider requires encryption, based on the dependency it has on ECS (so = that it can provide "special sauce")
If the authority p= rovider does not require encryption, I would like to facilitate that, rathe= r than always require authority providers to offer encrypted transport.

I'm completely open to mechanisms that facilitate= this divergence.

There is not yet (AFAIK) consens= us regarding requiring recursive-to-authority encrypted transport, and in t= he absence of such consensus, believe it is imperative that both encrypted = and unencrypted transport options be supported.

Th= e resolvers may choose not to send ECS over unencrypted transport, and as l= ong as that is a supported mode (with whatever mechanisms are required), I = have no problem with resolvers and authority servers doing whatever they wa= nt over their encrypted channels.

(BTW, this isn&#= 39;t to say that we don't also represent a substantial number of zones = that do want ECS. We do, and do want to offer and use encrypted transport f= or those.)

I am happy to lead any standardization = effort (i.e. doing an internet draft) for the "geo" alternative t= o "ecs", and am also happy to let the "geo" thing go, a= s long we can discuss whether a "no-ecs, no encryption" option mi= ght be feasible.

The "no ECS requirement"= ; I'm speaking of, represents about 40% of the DNS zones served globall= y, who are our customers. That we are one provider with that customer base = isn't as relevant, so much as that there are 40% of the zones with no n= eed for ECS, and that the interaction between public resolvers and authorit= y servers should be, IMHO, negotiable with respect to encrypted transport.<= /div>

=C2=A0
= Being able to separate away 99% of the resolution problem in the lifetime o= f a session ("established phase") into something that can be said= not to have any privacy or access control concerns beyond those that alrea= dy exist in the service being used means that all of the traffic engineerin= g required there can continue to be done behind the curtain, engineered wit= h a full serving of commercial advantage and richly flavoured with special = secret sauce. I'm not saying this is without complication or is somethi= ng that exists today, far from it: but it at least puts the design and impl= ementation in the hands of the service architects who know what they need a= nd, crucially, the details don't necessarily need wide exposure and sta= ndardisation.

I agree tha= t there is no specific requirement for standardization within the "spe= cial sauce" community. I was hoping that there might be some interest = and value in a standardized "special sauce Lite" over and above t= he "special sauce" community. If not, no big deal.
=C2= =A0

If there's to be an = impact on performance from privacy, e.g. from a less sophisticated (even em= pty) set of available mechanisms available to do traffic steering at respon= se time, it seems like it'd be really nice for it to be brief (e.g., &q= uot;initialisation phase").

I agree whole-heartedly.

I also think that= the "initialisation phase" represents one place where security i= s extremely important, specifically in validating the identify of the servi= ce end-point. A lot of trust regarding privacy is placed on the end-point, = so it is important that that trust not be misplaced. But I think that is su= bject for a separate thread.

Brian=C2=A0
--0000000000007c68f60586bebf11-- From nobody Fri Apr 19 05:02:49 2019 Return-Path: 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 E430612024F for ; Fri, 19 Apr 2019 05:02:46 -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, 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=verisign.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 4qeid3yCu3-e for ; Fri, 19 Apr 2019 05:02:44 -0700 (PDT) Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 8EC8212011F for ; Fri, 19 Apr 2019 05:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1684; q=dns/txt; s=VRSN; t=1555675364; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=SrvPKNgUK0pQPbhidr4c6LfXVFU/VoFL2uBdQqzLSW8=; b=q+y8qLRuH1MYuqBPEhr5qe0buaJzOD2E6/luyEcxLU0o7IssI07gO4Ti vBPd6O7kinaA2pgZbMpbPh/nXBqdzZ1kdZYxnGACoZePCyXOfcrKW91oI WgGy3LYVnzh1geIzjcdwDiKXoPdS90OwztTnm69r1xsKsde9NxcPTA/io /MhYqiGSwVx0/eG6QkkIdUpQnvUPMBk05NClkXJeOHldj2eU2UHyV14Ka dpf3qfTTqExM9kR+Y3q7lf45Y/O4e8LVf7lCk4GOIFubu3entCoGOZXE9 aXA6PheYEK/Bb8yWc3SiTwJzfCaV3kYS3Mm2E4fQFxTBOoCZNkP42cg7h w==; X-IronPort-AV: E=Sophos;i="5.60,369,1549947600"; d="scan'208";a="7493529" IronPort-PHdr: =?us-ascii?q?9a23=3AoRYdiR1s35WorrMPsmDT+DRfVm0co7zxezQtwd?= =?us-ascii?q?8ZsesVKv/xwZ3uMQTl6Ol3ixeRBMOHsqsC0LWd7/uoGTRZp8rY6DZaKN0Efi?= =?us-ascii?q?RGoP1epxYnDs+BBB+zB9/RRAt+Iv5/UkR49WqwK0lfFZW2TVTTpnqv8WxaQU?= =?us-ascii?q?2nZkJ6KevvB4Hdkdm82fys9J3PeQVIgye2ba9vIBmsogjdq9QajZFsJ6szxR?= =?us-ascii?q?fErXVFcPlSyW90OF6fhRnx6tqs8JJ57yhcp/ct/NNcXKvneKg1UaZWByk8PW?= =?us-ascii?q?Av483ruxjDTQ+R6XYZT24bjBlGDRXb4R/jRpv+vTf0ueR72CmBIM35Vqs0Vi?= =?us-ascii?q?i476dqUxDnliEKPCMk/W7Ni8xwiKVboA+9pxF63oXZbp2ZOOZ4c6jAetwUWH?= =?us-ascii?q?dBXt1JVyNfHoy8c4UBD+0EPelCron9oUYFoR+xCASoAe/izCJDiH3r0q0gy+?= =?us-ascii?q?kvER/I0hE8H9wAs3rUotf6NKYOXu66w6bF1inDYOhU2Tvh9ITEbhIsrPeRVr?= =?us-ascii?q?xwa8rRzkwvGhvLgluSrozlOzeV2foLs2eA8eVvSeGvh3Y6oA9svjevwdssip?= =?us-ascii?q?XHiokIzV3E7iV5wIExJd28VkF7Z8WrH4VMuCGZLIZ2XN0tQ3tpuCYhy70Gtp?= =?us-ascii?q?i7cDIWx5Qgwh7ScvqKeJWG7BLkUeaeOzZ4hHR9dbKwgBay9kegyuniWcWuzF?= =?us-ascii?q?lKqS9Fn9/RvX4Ozxze8tWLRudn8ku82zuC2Rrf5vxELE06j6bWJJ0szqYtmp?= =?us-ascii?q?YPq0jPAy37lFnsgKOLeUgp+fKk5/nkb7n+qJ+TKYx5hh37P6krmMGwHfg0PR?= =?us-ascii?q?ILUmSG5euzyLju8E3kT7pUgP07l63Uv43HKssFoKOyHhVb3Zw56xmlCjeryN?= =?us-ascii?q?EYnX4aI11bYB+HlI3pO03WIPD/EPe/n0ygkDd1yPDCOb3sGojAIGTbnrv8fb?= =?us-ascii?q?lz80FSxwsvwdxC/Z5UFK0OIPXpWk/prtDXFAI2Pxaqw+b9E9V90JkSVn6IAq?= =?us-ascii?q?+cKK/SsFmI6fwzI+SUeYMZpCzxJ+Un6vPgl3M1hF8QcKez0ZYYa320BvFmLF?= =?us-ascii?q?+YYXrojNcBC2AKvg8mQezxiF2CVjpTZ3KsUKI6/T40Fp6pDYTYS4CznrOBxi?= =?us-ascii?q?a7HoZXZmBJDFCAC2vnd4KBW/sUciKdPtdhkiAYVbimU4IuzwyhuxX/y7d8KO?= =?us-ascii?q?rU/TYYtY751Nho4u3fjw099TtxD86FyWGCU3l0nn8URz8xxK1/v0h9xU2e3q?= =?us-ascii?q?h5hvxYFMZT6+lVXQcnM57T1fB6B9fzWg3fYteJRk2rQtOnAT4tVN4+394PaV?= =?us-ascii?q?5nG9q+lhDDwzaqA7gNmrOWApw06bnR33b1J8pgxHbJyrMhg0M7TcRRLWemnL?= =?us-ascii?q?Jw9xDPB47VlEWUj7uler4a3C7M6miDyXGDvEFCXw9/XqTJR2sfaVXOp9Tj+k?= =?us-ascii?q?zCV6OuCaggMgZZ08GNN7ZFZ8bojVpYWPfjNs7SY2Wrm2e/Vl60webGZYbjfk?= =?us-ascii?q?0b2z7BElUB1QsU+DzOYQEyDyKJpWXFECZzEBTkZEa6taE0tneyQk4xzhvMZF?= =?us-ascii?q?Bn3qb2+xMJi9SaSvhV1aBO8HM/rzx4HVO8xZTdFtyJu0lgcblSSdU86xFMxz?= =?us-ascii?q?Sd/0ZxOIeIIaQ7iVMENQh69Qu62xNsIotEyMcntjUmwVw2YeiU2VVAejew3Z?= =?us-ascii?q?ngKvvMJyO6qBymba/b3nne2caGvLwCvqcWsVLm6UuJEU4m/nNt3tJWlzOn7Z?= =?us-ascii?q?LWEEBaBYnxVUIz+h5wqrrZSjcw/YLP1HJqd6Kzt2mRiJoSGOI5x0P4LJ9kO6?= =?us-ascii?q?SeGVquQsA=3D?= X-IPAS-Result: =?us-ascii?q?A2EkAAA6uLlc/zCZrQplGwEBAQEDAQEBBwMBAQGBUwQBA?= =?us-ascii?q?QELAQGCd4EsCoQElTiYSoEkAxg8DwEjDIQ+AheGJjYHDgEDAQEBBAEBAQECA?= =?us-ascii?q?QECgQUMQgEOAYFoDC4ETWsBAQEBAQEBAQEBAQEBHAIMZAEBAQEDIxE6CwwEA?= =?us-ascii?q?gEIEQQBAQECAiYCAgIwFQgIAgQBDQUIEYMKghenL4EviioGgQsnAYtggUE+h?= =?us-ascii?q?CM+gmECAoF2gnOCVwSNLJklAwYCggiGD4wTI5UPi3+GOY1+AgQCBAUCFYFWC?= =?us-ascii?q?1yBIXBQgmyFfYpTcgEBAYpohGaBIQEB?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 19 Apr 2019 08:02:42 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Fri, 19 Apr 2019 08:02:42 -0400 From: "Hollenbeck, Scott" To: "adam@nostrum.com" , "vladimir.cunat+ietf@nic.cz" , "dns@fl1ger.de" , "daniel@haxx.se" CC: "add@ietf.org" Thread-Topic: [EXTERNAL] Re: [Add] Mozilla's DoH resolver policy Thread-Index: AQHU8HY8nPMEKjlTjkmjNP1O5p5U96Y3VcaAgAAGcwCADBF68A== Date: Fri, 19 Apr 2019 12:02:42 +0000 Message-ID: <2a877eed406c4746bb6da97e2407aac7@verisign.com> References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> <9d20eb02-9322-875e-230a-e229f516819d@nostrum.com> In-Reply-To: <9d20eb02-9322-875e-230a-e229f516819d@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 12:02:47 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2YgQWRhbSBSb2FjaA0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwg MTEsIDIwMTkgMTE6NDIgQU0NCj4gVG86IFZsYWRpbcOtciDEjHVuw6F0IDx2bGFkaW1pci5jdW5h dCtpZXRmQG5pYy5jej47IFJhbGYgV2ViZXINCj4gPGRuc0BmbDFnZXIuZGU+OyBEYW5pZWwgU3Rl bmJlcmcgPGRhbmllbEBoYXh4LnNlPg0KPiBDYzogYWRkQGlldGYub3JnDQo+IFN1YmplY3Q6IFtF WFRFUk5BTF0gUmU6IFtBZGRdIE1vemlsbGEncyBEb0ggcmVzb2x2ZXIgcG9saWN5DQo+DQo+IE9u IDQvMTEvMTkgMTA6MTggQU0sIFZsYWRpbcOtciDEjHVuw6F0IHdyb3RlOg0KPiA+DQo+ID4gSWYg RmlyZWZveCBpcyB0byBiZSB0YWtlbiBtYWlubHkgYXMgYSByZWFsLWxpZmUgZXhhbXBsZSBvbiB0 aGlzDQo+ID4gbWFpbGluZy1saXN0LCBpcyB0aGVyZSBhIHN1aXRhYmxlIEZpcmVmb3gtc3BlY2lm aWMgcGxhY2UgdG8gZGlzY3Vzcw0KPiA+IHJlbGF0ZWQgaXNzdWVzPyAoQXNzdW1pbmcgTW96aWxs YSBpcyBhY3R1YWxseSBpbnRlcmVzdGVkIGluIHRoYXQuKQ0KPiA+DQo+DQo+IE9mIGNvdXJzZSB5 b3VyIGlucHV0IGlzIHdlbGNvbWUuIE1vemlsbGEgaXMgYW4gb3BlbnNvdXJjZSBwcm9qZWN0LCBh bmQNCj4gZXZlcnlvbmUgaXMgaW52aXRlZCB0byBwYXJ0aWNpcGF0ZS4NCj4NCj4gRm9yIGltcGxl bWVudGF0aW9uIGRpc2N1c3Npb25zLCBEb0ggaXMgcGFydCBvZiBvdXIgbmV0d29ya2luZyBzdGFj aywgY2FsbGVkDQo+IE5lY2tvLiBUaG9zZSBhcmUgZGlzY3Vzc2VkIG9uDQo+IGh0dHBzOi8vZ3Jv dXBzLmdvb2dsZS5jb20vZm9ydW0vIyFmb3J1bS9tb3ppbGxhLmRldi50ZWNoLm5ldHdvcmsNCj4N Cj4gRm9yIHByaXZhY3ktcmVsYXRlZCBkaXNjdXNzaW9ucywgdXNlDQo+IGh0dHBzOi8vZ3JvdXBz Lmdvb2dsZS5jb20vZm9ydW0vIyFmb3J1bS9tb3ppbGxhLmRldi5wcml2YWN5DQoNCkFkYW0sIHdv dWxkIGRpc2N1c3Npb24gb2YgdGhlIG9wZXJhdGlvbmFsIGFzcGVjdHMgb2YgdGhlIFRSUiBwcm9n cmFtICh0aGluZ3MgbGlrZSAidGhpcyBpcyB3aGF0J3MgZXhwZWN0ZWQgb2YgcGFydGljaXBhdGlu ZyByZXNvbHZlcnMiKSBiZSBhcHByb3ByaWF0ZSBmb3IgdGhpcyBsaXN0IG9yIG9uZSBvZiB0aGUg bGlzdHMgZGVzY3JpYmVkIGFib3ZlPw0KDQpTY290dA0K From nobody Fri Apr 19 08:54:55 2019 Return-Path: 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 ADBBD120167 for ; Fri, 19 Apr 2019 08:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 Fd-uLxECOI-s for ; Fri, 19 Apr 2019 08:54:52 -0700 (PDT) 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 EB100120170 for ; Fri, 19 Apr 2019 08:54:51 -0700 (PDT) Received: from Orochi.local (rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x3JFsbo5093955 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Apr 2019 10:54:39 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1555689284; bh=BJS/62sL2oP17e8FG1LB1Vd6KZBPql0hV5tI/QzNrPs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=vJyBrxhTh+5l8GyCHaONdBoUViIRjXdHq5oUMCjqCiKod6QaHdWGdD+JvC3j4jsyB i8i1bapqSATZmkpOfgcdaCPTJ8wKiojNxs+RLYzXHssgCOwQ8YRYzdmleIjBlkLFOr 4BJKq2nA6Eka5DcGlR1A0YPfjJBlhdsbjfNAWINI= X-Authentication-Warning: raven.nostrum.com: Host rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58] claimed to be Orochi.local To: "Hollenbeck, Scott" , "vladimir.cunat+ietf@nic.cz" , "dns@fl1ger.de" , "daniel@haxx.se" Cc: "add@ietf.org" References: <297C80CE-F017-4F4A-80E2-79941E8B9E02@icann.org> <64aeff58-6d68-4c4f-b991-2b2f62d193a0@www.fastmail.com> <90A5C5C4-373C-4B39-80C2-C115CD23CB4D@fl1ger.de> <792D4346-DE43-4BFC-85D4-FC58366E38B5@fl1ger.de> <945967b1-581f-e603-49f1-b9f173decb39@nic.cz> <9d20eb02-9322-875e-230a-e229f516819d@nostrum.com> <2a877eed406c4746bb6da97e2407aac7@verisign.com> From: Adam Roach Message-ID: <5bf5e4ae-911a-ef96-6dff-2456a6583db3@nostrum.com> Date: Fri, 19 Apr 2019 10:54:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2a877eed406c4746bb6da97e2407aac7@verisign.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 15:54:54 -0000 On 4/19/19 14:02, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Add On Behalf Of Adam Roach >> Sent: Thursday, April 11, 2019 11:42 AM >> To: Vladimír Čunát ; Ralf Weber >> ; Daniel Stenberg >> Cc: add@ietf.org >> Subject: [EXTERNAL] Re: [Add] Mozilla's DoH resolver policy >> >> On 4/11/19 10:18 AM, Vladimír Čunát wrote: >>> If Firefox is to be taken mainly as a real-life example on this >>> mailing-list, is there a suitable Firefox-specific place to discuss >>> related issues? (Assuming Mozilla is actually interested in that.) >>> >> Of course your input is welcome. Mozilla is an opensource project, and >> everyone is invited to participate. >> >> For implementation discussions, DoH is part of our networking stack, called >> Necko. Those are discussed on >> https://groups.google.com/forum/#!forum/mozilla.dev.tech.network >> >> For privacy-related discussions, use >> https://groups.google.com/forum/#!forum/mozilla.dev.privacy > Adam, would discussion of the operational aspects of the TRR program (things like "this is what's expected of participating resolvers") be appropriate for this list or one of the lists described above? Speaking only for myself [and not in any official role] -- My suggestion would be that you decide what you're trying to accomplish and post to one or the other accordingly. If you want to have a conversation with other Mozilla contributors about the specific TRR policy that Mozilla has adopted, I'd use a Mozilla mailing list. If you want to provide input to something that you see the IETF eventually publishing, I'd post it here. In the latter case, I would imagine you'd talk in more general terms about operational guidance for all applications, rather than focusing on suggestions for a single product: the chances that the IETF publishes a document that focuses on guidance for a single product are vanishingly small. /a From nobody Thu Apr 25 14:06:01 2019 Return-Path: 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 D58311200CE for ; Thu, 25 Apr 2019 14:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.502 X-Spam-Level: X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 pSh5ZVuH0oJR for ; Thu, 25 Apr 2019 14:05:58 -0700 (PDT) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 DB9C3120052 for ; Thu, 25 Apr 2019 14:05:57 -0700 (PDT) Received: by mail-yw1-xc29.google.com with SMTP id t79so423489ywc.7 for ; Thu, 25 Apr 2019 14:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GV0HaOEUbIB2xhkW5dQpzH+19RRPjRCOCvtdf1KXSEo=; b=f8RFCIJJE9gxpsLp5rz1pyzX/VwAQSt5v+eAJTOBqay+3/idt2Fn1eETZz0R06HQI6 Ms8ejhltZDp2GzR2lSuGzq8NW9ExHSZX/Esm9YDfeLqbENcLfFENJyvawyEp/fkgyUk/ Pni3txRO+6Tqnj6XV8zVI3M0kZSeaSzkx6VHNXMYkCmaLe7wJ8OrqYKBOsWQuovP7N01 q83MA7JzkXq+GJY3ZpH9ie5Yu70XVndDYiVBU3ekNMsdW0L/TSi7SpR1U8PxSfUtru5Q j9wiGXR8rT1XG2ADNCIwwMtK/XOAr6yhwzBV0Sw5MTe1pwzKQGkyGQPdV2s04QmmqISt 1U9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GV0HaOEUbIB2xhkW5dQpzH+19RRPjRCOCvtdf1KXSEo=; b=StSGkRfQGCvXtNMlQkNBcFyAx1diqPEiPb+J73Yl6Si7pKW/oURdK8PmnXUxSskCdA kkCaCPBpuNkGA2QUmlbT8zLmzqmq1tnMHnOIZ6gXKBtdF00rUJW0ILcmqn3x9e7bdCAF 9/QzhDK+KDQiRgDzproKJoi9Pg0Ik83WTUOgJJ1pezVda6rXMHgC9eEYXpdLIQxB+VHB 9e6xspaCuyaAiQxYOSOsD9AxM5V0dacX0NYTCtSQ1fj7G8tUMW/qOr+0rLubE87dZ4Py 3Pz2Z9ZxSJQOTTOAlnL+/2yZy0TtSqxMBQaMaWCW+kRluv2DwNr0Np9NgQ9nhDAA6Fmf hriw== X-Gm-Message-State: APjAAAVnQ1cw62vJJZLMLxI+YAjue7Kahy5MjK25U7v5YErfn+e9HlVY +6NJGLh5M5w/DQwLULCNHHP8amNQxJAv3bDtXoXIX260FcMDmg== X-Google-Smtp-Source: APXvYqxX3AHMwkh0CpZIsbzl7RKq0mPlNyUtFW3pddWE1hKJDwsHNBrouKAtsXTKDbJUtoBAIYrm78422ZQxCswkyi4= X-Received: by 2002:a81:3a82:: with SMTP id h124mr34264545ywa.263.1556226356407; Thu, 25 Apr 2019 14:05:56 -0700 (PDT) MIME-Version: 1.0 From: Puneet Sood Date: Thu, 25 Apr 2019 17:05:44 -0400 Message-ID: To: add@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:06:00 -0000 [Sorry for not replying to the thread. This is a response to https://mailarchive.ietf.org/arch/msg/add/D_eoqhhz0m0sNzSW2fWdt_mcjCY#] >From Brian Dickson Wed, 17 April 2019 19:18 UTC > > On Wed, Apr 17, 2019 at 11:35 AM Joe Abley ; wrote: > > On 17 Apr 2019, at 14:16, Brian Dickson ; > > wrote: > > > > Let's consider what the situation is, for authority servers. > > > > Some (not all, not none) are CDNs. Some (not all, not none) are not doing > > ECS at all. Some (not all, not none) are doing ECS, but only using > > "vanilla" ECS functionality, via third-party IP->GEO databases/services. > > > > The potential trade-off(s), as I see them, are: > > > > > > So, to briefly join the threads just as further illustration to what I'm > > talking about, what you're doing here looks a lot like trying to engineer a > > solution for people you don't know based on requirements you're guessing > > at. This seems unlikely to converge on anything useful. > > > > > Actually, on this point, I beg to differ. > > What I am trying to do is separate out two or three classes of > problem/solution, and avoiding having a single solution (with more > complexity and cost) imposed on the rest of the DNS authority service > community. > > I am very happy to leave the specifics of the "secret sauce" behind the > curtain. > > I'm trying to find a way of distinguishing the "secret sauce" folks from > the vanilla flavor folks, prior to the "established phase", so that what > "established phase" looks like might be different (e.g. encrypted or not). > > I'm trying to do that distinction, upstream of established phase, for the > benefit of those not using any special sauce, so that the cost of "vanilla" > doesn't rise to being the same as the cost of "special sauce". > > And, I am doing this based on the requirements of a substantial portion of > the non-"special-sauce" constituency, that portion of which I represent, > whose requirements I not only know, but am responsible for. > > The fundamental question is, for me, whether it is possible to determine > whether a given authority provider requires encryption, based on the > dependency it has on ECS (so that it can provide "special sauce") > If the authority provider does not require encryption, I would like to > facilitate that, rather than always require authority providers to offer > encrypted transport. > > I'm completely open to mechanisms that facilitate this divergence. > > There is not yet (AFAIK) consensus regarding requiring > recursive-to-authority encrypted transport, and in the absence of such > consensus, believe it is imperative that both encrypted and unencrypted > transport options be supported. > > The resolvers may choose not to send ECS over unencrypted transport, and as > long as that is a supported mode (with whatever mechanisms are required), I > have no problem with resolvers and authority servers doing whatever they > want over their encrypted channels. > > (BTW, this isn't to say that we don't also represent a substantial number > of zones that do want ECS. We do, and do want to offer and use encrypted > transport for those.) > > I am happy to lead any standardization effort (i.e. doing an internet > draft) for the "geo" alternative to "ecs", and am also happy to let the > "geo" thing go, as long we can discuss whether a "no-ecs, no encryption" > option might be feasible. > > The "no ECS requirement" I'm speaking of, represents about 40% of the DNS > zones served globally, who are our customers. That we are one provider with > that customer base isn't as relevant, so much as that there are 40% of the > zones with no need for ECS, and that the interaction between public > resolvers and authority servers should be, IMHO, negotiable with respect to > encrypted transport. I think this can be solved by having the recursive resolver probe for ECS support for a zone. If an authoritative nameserver serves a zone that does not support ECS, it can respond w/o the ECS option (https://tools.ietf.org/html/rfc7871#section-7.2.1). A recursive resolver can use this as a signal to not send ECS to the nameserver *for that zone* in the future. The recursive resolver would need to probe periodically to handle the situation when the ECS support changes. What am I missing here? -Puneet > > > > > Being able to separate away 99% of the resolution problem in the lifetime > > of a session ("established phase") into something that can be said not to > > have any privacy or access control concerns beyond those that already exist > > in the service being used means that all of the traffic engineering > > required there can continue to be done behind the curtain, engineered with > > a full serving of commercial advantage and richly flavoured with special > > secret sauce. I'm not saying this is without complication or is something > > that exists today, far from it: but it at least puts the design and > > implementation in the hands of the service architects who know what they > > need and, crucially, the details don't necessarily need wide exposure and > > standardisation. > > > > I agree that there is no specific requirement for standardization within > the "special sauce" community. I was hoping that there might be some > interest and value in a standardized "special sauce Lite" over and above > the "special sauce" community. If not, no big deal. > > > > > > If there's to be an impact on performance from privacy, e.g. from a less > > sophisticated (even empty) set of available mechanisms available to do > > traffic steering at response time, it seems like it'd be really nice for it > > to be brief (e.g., "initialisation phase"). > > > > I agree whole-heartedly. > > I also think that the "initialisation phase" represents one place where > security is extremely important, specifically in validating the identify of > the service end-point. A lot of trust regarding privacy is placed on the > end-point, so it is important that that trust not be misplaced. But I think > that is subject for a separate thread. > > Brian From nobody Thu Apr 25 14:37:32 2019 Return-Path: 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 DB5A41202BC for ; Thu, 25 Apr 2019 14:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.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 5jje_gkRbhgD for ; Thu, 25 Apr 2019 14:36:17 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 2430B120261 for ; Thu, 25 Apr 2019 14:36:17 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id y6so1288551ior.5 for ; Thu, 25 Apr 2019 14:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=InOFG33nQ5BRBo6RV3gr3fFS/pEH6wxkBnvZyYnmu5A=; b=D+Rq/OWxGbyTIBLEhRBqPhJecHoLHYoj1O6e30KPi4JbJWjQ4US5/bYS00iVibBgPE VqSXLB2cMZmZ0HTCCKHvDNHiLmZcHFpHRxU08cOWBqI5AIDT02V7bjFfBjU0cWJCPTVs Lc2Am1ELG/oeAKCjMzbKvNUkzKf/nAtQA7gzg= 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:reply-to :from:date:message-id:subject:to:cc; bh=InOFG33nQ5BRBo6RV3gr3fFS/pEH6wxkBnvZyYnmu5A=; b=Yv9UFXMSpMjQBaq3ZzSiC6EjdLTNXXP+IzjKxjwRQ7bEWnLtfWV76QZxNfGbKwk3m7 zAY0H2xGsqY3zSsWsqpqlPrVxAFzQeTwH0lhZDk2n2GH8hPB+znMwbXsAm7+BGmAn06b kAbNj3jtCsprP/c5A/h2GbsaJm727GcEG0tvmIPOEdyeXfChZdfEdqqISQyBNDDVTg/8 jQ5mkfe/28rWIYiKcPAh50iwvUhYlVFhCFwrqUfqehUxWqxYbecYyugxdCPGmH77km9y MIdYswXVenVCYSqldNyMSXXhxbJF8wnZ2FPsVzyTFql9BVPcP/gVtcBH5yhuoT5QJFmS zZLg== X-Gm-Message-State: APjAAAU0gqBX9GAvTMCGe69WLhhBRMp63XcijMKnB+U37Q9/cCwGvgSq Z6d1koldq7tVk7DDS4Ep5L16v6p5mswNjrocJwOCej9YEzQ= X-Google-Smtp-Source: APXvYqzyJeiMHKg4z8bLCM0/qciAjaf2wpu2Uq3yjAf768kIJNUVzSkwLHxRfqPoM0EFYFbEeG5Df2hj3IT26kYVvx8= X-Received: by 2002:a6b:2c92:: with SMTP id s140mr11321208ios.114.1556228175645; Thu, 25 Apr 2019 14:36:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: ek@loon.com From: Erik Kline Date: Thu, 25 Apr 2019 14:36:03 -0700 Message-ID: To: Puneet Sood Cc: add@ietf.org Content-Type: multipart/alternative; boundary="00000000000099a8650587619beb" Archived-At: X-Mailman-Approved-At: Thu, 25 Apr 2019 14:37:30 -0700 Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 21:36:21 -0000 --00000000000099a8650587619beb Content-Type: text/plain; charset="UTF-8" On Thu, 25 Apr 2019 at 14:06, Puneet Sood wrote: > [Sorry for not replying to the thread. This is a response to > https://mailarchive.ietf.org/arch/msg/add/D_eoqhhz0m0sNzSW2fWdt_mcjCY#] > > >From Brian Dickson Wed, 17 April 2019 > 19:18 UTC > > > > On Wed, Apr 17, 2019 at 11:35 AM Joe Abley ; wrote: > > > On 17 Apr 2019, at 14:16, Brian Dickson >; > > > wrote: > > > > > > Let's consider what the situation is, for authority servers. > > > > > > Some (not all, not none) are CDNs. Some (not all, not none) are not > doing > > > ECS at all. Some (not all, not none) are doing ECS, but only using > > > "vanilla" ECS functionality, via third-party IP->GEO > databases/services. > > > > > > The potential trade-off(s), as I see them, are: > > > > > > > > > So, to briefly join the threads just as further illustration to what > I'm > > > talking about, what you're doing here looks a lot like trying to > engineer a > > > solution for people you don't know based on requirements you're > guessing > > > at. This seems unlikely to converge on anything useful. > > > > > > > > Actually, on this point, I beg to differ. > > > > What I am trying to do is separate out two or three classes of > > problem/solution, and avoiding having a single solution (with more > > complexity and cost) imposed on the rest of the DNS authority service > > community. > > > > I am very happy to leave the specifics of the "secret sauce" behind the > > curtain. > > > > I'm trying to find a way of distinguishing the "secret sauce" folks from > > the vanilla flavor folks, prior to the "established phase", so that what > > "established phase" looks like might be different (e.g. encrypted or > not). > > > > I'm trying to do that distinction, upstream of established phase, for the > > benefit of those not using any special sauce, so that the cost of > "vanilla" > > doesn't rise to being the same as the cost of "special sauce". > > > > And, I am doing this based on the requirements of a substantial portion > of > > the non-"special-sauce" constituency, that portion of which I represent, > > whose requirements I not only know, but am responsible for. > > > > The fundamental question is, for me, whether it is possible to determine > > whether a given authority provider requires encryption, based on the > > dependency it has on ECS (so that it can provide "special sauce") > > If the authority provider does not require encryption, I would like to > > facilitate that, rather than always require authority providers to offer > > encrypted transport. > > > > I'm completely open to mechanisms that facilitate this divergence. > > > > There is not yet (AFAIK) consensus regarding requiring > > recursive-to-authority encrypted transport, and in the absence of such > > consensus, believe it is imperative that both encrypted and unencrypted > > transport options be supported. > > > > The resolvers may choose not to send ECS over unencrypted transport, and > as > > long as that is a supported mode (with whatever mechanisms are > required), I > > have no problem with resolvers and authority servers doing whatever they > > want over their encrypted channels. > > > > (BTW, this isn't to say that we don't also represent a substantial number > > of zones that do want ECS. We do, and do want to offer and use encrypted > > transport for those.) > > > > I am happy to lead any standardization effort (i.e. doing an internet > > draft) for the "geo" alternative to "ecs", and am also happy to let the > > "geo" thing go, as long we can discuss whether a "no-ecs, no encryption" > > option might be feasible. > > > > The "no ECS requirement" I'm speaking of, represents about 40% of the DNS > > zones served globally, who are our customers. That we are one provider > with > > that customer base isn't as relevant, so much as that there are 40% of > the > > zones with no need for ECS, and that the interaction between public > > resolvers and authority servers should be, IMHO, negotiable with respect > to > > encrypted transport. > > I think this can be solved by having the recursive resolver probe for > ECS support for a zone. If an authoritative nameserver serves a zone > that does not support ECS, it can respond w/o the ECS option > (https://tools.ietf.org/html/rfc7871#section-7.2.1). A recursive > resolver can use this as a signal to not send ECS to the nameserver > *for that zone* in the future. The recursive resolver would need to > probe periodically to handle the situation when the ECS support > changes. > > What am I missing here? > My recollection from the DPRIVE 104 discussion about TLS to the authoritative was that a non-probing method was considered preferable. Generalizing from there, I think folks want to minimize the amount of "probe and remember" activity that has to take place (no matter the problem domain). > > > > > > Being able to separate away 99% of the resolution problem in the > lifetime > > > of a session ("established phase") into something that can be said not > to > > > have any privacy or access control concerns beyond those that already > exist > > > in the service being used means that all of the traffic engineering > > > required there can continue to be done behind the curtain, engineered > with > > > a full serving of commercial advantage and richly flavoured with > special > > > secret sauce. I'm not saying this is without complication or is > something > > > that exists today, far from it: but it at least puts the design and > > > implementation in the hands of the service architects who know what > they > > > need and, crucially, the details don't necessarily need wide exposure > and > > > standardisation. > > > > > > > I agree that there is no specific requirement for standardization within > > the "special sauce" community. I was hoping that there might be some > > interest and value in a standardized "special sauce Lite" over and above > > the "special sauce" community. If not, no big deal. > > > > > > > > > > If there's to be an impact on performance from privacy, e.g. from a > less > > > sophisticated (even empty) set of available mechanisms available to do > > > traffic steering at response time, it seems like it'd be really nice > for it > > > to be brief (e.g., "initialisation phase"). > > > > > > > I agree whole-heartedly. > > > > I also think that the "initialisation phase" represents one place where > > security is extremely important, specifically in validating the identify > of > > the service end-point. A lot of trust regarding privacy is placed on the > > end-point, so it is important that that trust not be misplaced. But I > think > > that is subject for a separate thread. > > > > Brian > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000099a8650587619beb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, 25 Apr 2019 at 14:06, Puneet = Sood <puneets=3D40google.= com@dmarc.ietf.org> wrote:
[Sorry for not replying to the thread. This is a response= to
https://mailarchive.ietf.org/a= rch/msg/add/D_eoqhhz0m0sNzSW2fWdt_mcjCY#]

>From Brian Dickson <brian.peter.dickson@gmail.com> Wed, 17 April 2019= 19:18 UTC
>
> On Wed, Apr 17, 2019 at 11:35 AM Joe Abley <jabley@hopcount.ca>; wrote:
> > On 17 Apr 2019, at 14:16, Brian Dickson <brian.peter.dickson@gmail.com= >;
> > wrote:
> >
> > Let's consider what the situation is, for authority servers.<= br> > >
> > Some (not all, not none) are CDNs. Some (not all, not none) are n= ot doing
> > ECS at all. Some (not all, not none) are doing ECS, but only usin= g
> > "vanilla" ECS functionality, via third-party IP->GEO= databases/services.
> >
> > The potential trade-off(s), as I see them, are:
> >
> >
> > So, to briefly join the threads just as further illustration to w= hat I'm
> > talking about, what you're doing here looks a lot like trying= to engineer a
> > solution for people you don't know based on requirements you&= #39;re guessing
> > at. This seems unlikely to converge on anything useful.
> >
> >
> Actually, on this point, I beg to differ.
>
> What I am trying to do is separate out two or three classes of
> problem/solution, and avoiding having a single solution (with more
> complexity and cost) imposed on the rest of the DNS authority service<= br> > community.
>
> I am very happy to leave the specifics of the "secret sauce"= behind the
> curtain.
>
> I'm trying to find a way of distinguishing the "secret sauce&= quot; folks from
> the vanilla flavor folks, prior to the "established phase", = so that what
> "established phase" looks like might be different (e.g. encr= ypted or not).
>
> I'm trying to do that distinction, upstream of established phase, = for the
> benefit of those not using any special sauce, so that the cost of &quo= t;vanilla"
> doesn't rise to being the same as the cost of "special sauce&= quot;.
>
> And, I am doing this based on the requirements of a substantial portio= n of
> the non-"special-sauce" constituency, that portion of which = I represent,
> whose=C2=A0 requirements I not only know, but am responsible for.
>
> The fundamental question is, for me, whether it is possible to determi= ne
> whether a given authority provider requires encryption, based on the > dependency it has on ECS (so that it can provide "special sauce&q= uot;)
> If the authority provider does not require encryption, I would like to=
> facilitate that, rather than always require authority providers to off= er
> encrypted transport.
>
> I'm completely open to mechanisms that facilitate this divergence.=
>
> There is not yet (AFAIK) consensus regarding requiring
> recursive-to-authority encrypted transport, and in the absence of such=
> consensus, believe it is imperative that both encrypted and unencrypte= d
> transport options be supported.
>
> The resolvers may choose not to send ECS over unencrypted transport, a= nd as
> long as that is a supported mode (with whatever mechanisms are require= d), I
> have no problem with resolvers and authority servers doing whatever th= ey
> want over their encrypted channels.
>
> (BTW, this isn't to say that we don't also represent a substan= tial number
> of zones that do want ECS. We do, and do want to offer and use encrypt= ed
> transport for those.)
>
> I am happy to lead any standardization effort (i.e. doing an internet<= br> > draft) for the "geo" alternative to "ecs", and am = also happy to let the
> "geo" thing go, as long we can discuss whether a "no-ec= s, no encryption"
> option might be feasible.
>
> The "no ECS requirement" I'm speaking of, represents abo= ut 40% of the DNS
> zones served globally, who are our customers. That we are one provider= with
> that customer base isn't as relevant, so much as that there are 40= % of the
> zones with no need for ECS, and that the interaction between public > resolvers and authority servers should be, IMHO, negotiable with respe= ct to
> encrypted transport.

I think this can be solved by having the recursive resolver probe for
ECS support for a zone. If an authoritative nameserver serves a zone
that does not support ECS, it can respond w/o the ECS option
(https://tools.ietf.org/html/rfc7871#section-7.2.1<= /a>). A recursive
resolver can use this as a signal to not send ECS to the nameserver
*for that zone* in the future. The recursive resolver would need to
probe periodically to handle the situation when the ECS support
changes.

What am I missing here?



>
>
> > Being able to separate away 99% of the resolution problem in the = lifetime
> > of a session ("established phase") into something that = can be said not to
> > have any privacy or access control concerns beyond those that alr= eady exist
> > in the service being used means that all of the traffic engineeri= ng
> > required there can continue to be done behind the curtain, engine= ered with
> > a full serving of commercial advantage and richly flavoured with = special
> > secret sauce. I'm not saying this is without complication or = is something
> > that exists today, far from it: but it at least puts the design a= nd
> > implementation in the hands of the service architects who know wh= at they
> > need and, crucially, the details don't necessarily need wide = exposure and
> > standardisation.
> >
>
> I agree that there is no specific requirement for standardization with= in
> the "special sauce" community. I was hoping that there might= be some
> interest and value in a standardized "special sauce Lite" ov= er and above
> the "special sauce" community. If not, no big deal.
>
>
> >
> > If there's to be an impact on performance from privacy, e.g. = from a less
> > sophisticated (even empty) set of available mechanisms available = to do
> > traffic steering at response time, it seems like it'd be real= ly nice for it
> > to be brief (e.g., "initialisation phase").
> >
>
> I agree whole-heartedly.
>
> I also think that the "initialisation phase" represents one = place where
> security is extremely important, specifically in validating the identi= fy of
> the service end-point. A lot of trust regarding privacy is placed on t= he
> end-point, so it is important that that trust not be misplaced. But I = think
> that is subject for a separate thread.
>
> Brian

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000099a8650587619beb-- From nobody Thu Apr 25 15:50:49 2019 Return-Path: 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 B8B9D12008A for ; Thu, 25 Apr 2019 15:50:45 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 IU_BkZQv0ptQ for ; Thu, 25 Apr 2019 15:50:43 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 754211200C5 for ; Thu, 25 Apr 2019 15:50:43 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id d13so2081970qth.5 for ; Thu, 25 Apr 2019 15:50:43 -0700 (PDT) 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=/QYDsQsMy0LMFI35qXObh/2ktuxJN/In+AKsetciYbE=; b=TAICJDW1UPiLvuJRNlXvmcXNquqvGBM82PGJGMq2cENsiwOjNlRhG1/M+Ujvv3tp1I FhtT5CzpZ4uyacmxTqZ6tlVXm9NdmwRz6/PoAdQw5vfN/1NSbwjmuS7yOIWq3y+VRzjm duYDEgqfeKZ4e71JGG6zX4jTWFzDskGCvj977Ub1Jg0rjIl0VdbezxJvb9iJqhrjcOFB KWzmqWib/Uq5ryCyARJmqYSos2Xfhog9eV49cvwqpxwyvX4rLnV8kDzbS+IN5lcSWOSh M5uxgHZbq1ys9zf8MXd7rH/aNstVqaBWSN/eJpmViGl9Ep64IAVBj8PSB1DtDZQPfRxa qOhw== 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=/QYDsQsMy0LMFI35qXObh/2ktuxJN/In+AKsetciYbE=; b=im4ALaiXTwN5JeUuL7UMtOrOlSDm4uFm/JEwxhW8IW+W1ZbfrByVKYxAdBakIBUwdE z+Wvcdw6G0gwq1bf65ZekgBUCJqFhkc9zOFIklyCOJDT7BWi49V68FaxwnP+xtypuFgI KT6LCQBGZWDm32KdJhKjdKi2U5eRvxPtmAM4VDzvF7qzU70B58Zd53+d/ELhD4k3uBCx 0XHDP3984PGUNIfVcApKT+mch5pEYBy5DTvVsg5K6wSa1G80b7oCzWyGWLIzK4b6yCKi lrdSKXskJW0Rtqf1eUDbgnOFJqOEOutuaX1fky5t7k9DWaKLzpz9FuYFLi7ODXKKTn5O tyLg== X-Gm-Message-State: APjAAAVJxwJ/V2Cmh/W3vgcbe7meYHFG2IKcRqQHEIlTXwSfxzNvvTVo iG3FEGXsN3oqJI+Me7ZitLq2WI8PcP7atx+qth8= X-Google-Smtp-Source: APXvYqwvQfX8p5/gnLG6WqBsLdUwhhDrPze2giEYsJ2Drak9n6+Um/VQ7Is99is8kcRIB6jyXgcp+6K6h5HXwZARD9E= X-Received: by 2002:ac8:27b0:: with SMTP id w45mr34735954qtw.341.1556232642534; Thu, 25 Apr 2019 15:50:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Thu, 25 Apr 2019 15:50:31 -0700 Message-ID: To: ek@loon.com Cc: Puneet Sood , add@ietf.org Content-Type: multipart/alternative; boundary="000000000000d8a3e8058762a5b4" Archived-At: Subject: Re: [Add] ECS privacy concerns, alternatives? X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 22:50:46 -0000 --000000000000d8a3e8058762a5b4 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 25, 2019 at 2:37 PM Erik Kline wrote: > > > On Thu, 25 Apr 2019 at 14:06, Puneet Sood 40google.com@dmarc.ietf.org> wrote: > >> >> I think this can be solved by having the recursive resolver probe for >> ECS support for a zone. If an authoritative nameserver serves a zone >> that does not support ECS, it can respond w/o the ECS option >> (https://tools.ietf.org/html/rfc7871#section-7.2.1). A recursive >> resolver can use this as a signal to not send ECS to the nameserver >> *for that zone* in the future. The recursive resolver would need to >> probe periodically to handle the situation when the ECS support >> changes. >> >> What am I missing here? >> > > My recollection from the DPRIVE 104 discussion about TLS to the > authoritative was that a non-probing method was considered preferable. > > Generalizing from there, I think folks want to minimize the amount of > "probe and remember" activity that has to take place (no matter the problem > domain). > I think there are two independent things that could/should be pursued: (a) some way of signaling scalably about DoT/DoH support; and (b) a sufficiently scalable probing method as a stopgap in the interim. If probing is going to be done and remembered, I would prefer it be done roughly as follows: - TLS probing by IP, with support/non-support cached - ECS probing done over TLS only, with support/non-support cached (to minimize TLS usage). The signaling in (a) should, in theory, be regarding *both* ECS and TLS support, maybe as yet another delegation record (sibling to DS and NS). But it's an ugly hack. Brian --000000000000d8a3e8058762a5b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 25, 2019 at 2:37 PM Erik = Kline <ek@loon.com> wrote:


On Thu, 25 Apr 2019 at 14:06, Puneet Sood <puneets=3D40google.com@= dmarc.ietf.org> wrote:

I think this can be solved by having the recursive resolver probe for
ECS support for a zone. If an authoritative nameserver serves a zone
that does not support ECS, it can respond w/o the ECS option
(https://tools.ietf.org/html/rfc7871#section-7.2.1<= /a>). A recursive
resolver can use this as a signal to not send ECS to the nameserver
*for that zone* in the future. The recursive resolver would need to
probe periodically to handle the situation when the ECS support
changes.

What am I missing here?




--000000000000d8a3e8058762a5b4--